topical media & game development

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Standards for interoperability

The potential of an object-oriented approach, obviously, lies in the opportunities for reuse, both of code and design. However, reuse requires a common understanding of the basic principles underlying the technology and its application. More particularly, the reuse of code requires (a much more strict) agreement with respect to the components from which an application will be constructed and the language constructs used to implement them. In this section, we will look at the object linking and embedding facilities offered by Microsoft OLE, and the standardization efforts undertaken by the OMG (Object Management Group) directed towards the interoperability of object components. In addition, we will look at the efforts of the ODMG (Object Database Management Group) undertaken to develop a standard for persistent objects.

Object linking and embedding -- COM

Reuse is not necessarily code sharing. In effect, there seems to be a trend towards sharing components at a higher level of granularity, as possibly independent applications. This approach has, for example, been taken by the Microsoft object linking and embedding facility (OLE), which offers support for embedding (a copy) of a component in a (container) component, for including a link to another component, and for storing compound objects. See slide 11-ole.

Object-enabling technology

OLE

document centered -- text, graphics, reports
component software -- standard programmatic interface
distributed object systems -- component object model

(D)COM

Features

linking, embedding, storage

Alternatives

IBM SOM/DSOM, Apple OpenDoc

slide: Object-enabling technology -- OLE

The OLE technology, which builds upon (D)COM technology, is characterized by its developers as {\em object-enabling} technology, to contrast it with a more classical language-dependent object-oriented approach relying on inheritance.

The object-linking technology allows the user to maintain a link from one application to another, so that for example a text processor may directly employ the results of a spreadsheet. Moreover, object linking is dynamic and allows any updates in the spreadsheet application to be reflected directly in the outcome of the text processor. In contrast, object embedding works more as the traditional cut and paste techniques in that it results in including only a copy of the material. To be embedded or linked, applications must satisfy a standard programmatic interface. In effect, the interface must provide the facility to request an update of the display of the information contained in the application. In this respect, the OLE technology may be characterized as document-centered.

Object Request Brokers -- CORBA

The ultimate goal of object technology may be phrased as the development of plug-compatible software that allows one to construct a particular application from off-the-shelf components. To achieve this goal, it is necessary to develop standards with respect to object interaction and communication interfaces that support information sharing between distinct components. Such standards are developed by the OMG (the Object Management Group, in which the leading vendors of software systems participate, including Digital Equipment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Object Design Inc. and Sunsoft Inc.). The OMG aims at defining standards for information sharing in widely distributed, heterogeneous (multi-vendor) networks to support the reusability and portability of commercially available components, and more generally, to develop the technology and guidelines that allow the interoperability of applications. See slide 11-standards.

Standardization -- system integration

OMG

information sharing -- technology, policy

Object Management Architecture -- interface standards

IDL

Object Services
Object Request Broker
Common Facilities -- file manipulation, print queuing, email
Application Objects -- spreadsheets, word processor

slide: The OMG standardization effort

The OMG proceeds from the assumption that object technology (including encapsulation, polymorphism and inheritance) provides the mechanism necessary for language-, platform- and vendor-independent, system integration. The OMG has proposed an abstract object model and discusses technical and political objectives in the OMA Guide (Object Management Architecture Guide). The architecture specified in OMA provides a generic description of the components that constitute a system and defines the interface standards to which the components must comply. An important aspect of OMA is the interface description language (IDL) that is introduced as a standard to describe object interfaces in a language-independent manner. According to OMA, a system must support a number of Object Services (dealing with the lifecycle of objects, persistence, naming an event notification), and a so-called Object Request Broker (which is an intermediary between the object providing a service and the client requesting a service). Also a system will need, generally, Common Facilities (such as file manipulation and print queuing), and in addition will contain a number of Application Objects (such as a spreadsheet or word-processor) that constitute the proper application. The OMG is primarily concerned with the adoption of technology by the producers and vendors of common facilities and application objects. Its contribution in this respect is the definition of a set of common object services and a standard interface to invoke such services by means of an object request broker. This standard has been adopted in CORBA (the Common Object Request Broker Architecture) which allows for the interaction between an application and distinct object request brokers. The object services envisioned in OMA are intended to deal with objects in a language- and platform-independent manner. See slide 11-services.

Object Services

life cycle -- creation and deletion
persistence -- management of object storage
naming -- mapping names to references
event notification -- registration of events

Future

transactions, concurrency, relationships, ... ,time

slide: The OMG Object Services

These services encompass the creation and deletion of objects, the management of object storage, the mapping of names to references and the registration of events as triggers for actions. In addition, services will be defined that allow transactions, concurrency, relationships between objects and time-based properties of objects to be specified. To a large extent, such services are provided by individual languages (such as Java, C++ or Smalltalk) with their accompanying libraries and development frameworks. However, the efforts of the OMG are directed towards (the ambitious goal of) providing such services in a generic fashion, independent of a particular language or environment.

Persistent objects -- ODMG

In a similar vein as the OMG, a number of vendors of object database management systems (including SunSoft, Object Design, Ontos,

O_{2}

Technology, Versant, Objectivity, Hewlett Packard, POET Software, Itasca, Intellitic, Digital Equipment Corporation, Servio, Texas Instruments) have participated in the ODMG (Object Database Management systems Group) to develop a standard for the definition and manipulation of persistent objects. The standards proposal of the ODMG encompasses an object definition language ODL, which is intended as an extension of the OMG/IDL standard, an object manipulation language, OML and an object query language, OQL, that provides SQL-like facilities for the retrieval of information. The advantage of employing an object database system over employing a relational database system is that, in principle, the application programmer may work within a unified type system, encompassing both persistent and transient objects. See slide 11-ODMG.

Persistent objects

ODMG

database extension -- unified type system

Object Definition Language

ODL

standard types -- objects and literals
references -- Ref< T >
collections -- List< T > , Bag< T >, Set< T >

Object Manipulation Language

OML

create, delete, modify, reference

Object Query Language

OQL

oql(type& value,const char* query,...)

slide: The ODMG-93 standardization efforts

The extensions to the various languages, which include C++ and Smalltalk, involve the definition of persistent objects, the creation and use of objects and facilities to pose queries concerning their attributes and relations. These extensions are proposed as language-specific bindings for respectively ODL, OML and OQL. The object model proposed by the ODMG supports objects (which may have attributes and methods), literals (which may be considered as primitive values), relationships between objects (including m-n relations), extents (which contain the collection of instances of a particular type), and named objects (to facilitate retrieval). To define objects and literals, the programmer may employ the standard types offered by the language, as well as a number of additional parametrized types to define references and collections. For references the ODMG-93 proposal employs a

Ref

smart pointer construct. For dealing with collections a number of generic collection classes such as

List

Bag

and

Set

must be provided by a standard library. (To provide a binding for Smalltalk, which does not have a type system, type annotations must be employed to define the properties of persistent objects.) The manipulation of persistent objects conforms with the manipulation of ordinary objects as far as attribute access and method invocation are concerned. However, the language-specific OML bindings must take precautions for the creation, deletion and modification of objects. In particular, when employing a reference to a persistent object, the implementation must check whether the referenced object has been modified. The C++ binding for the object query language OQL in the ODMG-93 proposal is quite simple. It consists merely of a function that allows the programmer to pass an extended SQL-like query as a string. The query may contain symbolic variables that are bound in a similar way as allowed by the C printf function. The design principle guiding the ODMG effort has been to promote that the programmer feels that there is one language. However, there are a number of difficulties that arise when defining a particular language binding for the ODMG object model, as for example for C++. See slide 11-binding.

Design principles

object model

the programmer feels that there is one language

Language binding

C++ODL/OML

objects and literals -- embedded objects are literals
relationships -- not directly supported by C++
extents -- must be maintained by programmer
keys -- simulated by C++ data members

slide: Language binding -- C++ ODL/OML

Embedded objects which are defined in C++ as object data members, must be taken as literals in the ODMG object model, whereas embedded references to objects are to be taken as objects. Relationships are not directly supported in C++. In the ODMG-93 proposal, the programmer is required to employ an explicit data structure for updating and traversing a relation. Extents, which contain the collection of instances of a type, must explicitly be maintained by the programmer. Extents may conveniently be stored in a collection that is associated with a static data member of the class. Keys, which are needed for efficient retrieval, must be simulated by C++ data members. Support for indexing and retrieval by key requires additional compiler support, for which no provision is made in the ODMG-93 proposal. Other problems that arise in defining a binding to C++ involve the naming of objects, the restriction that C++ allows for only one implementation of a particular type and the duality between arrays and pointers.

Discussion

Both the OMG and ODMG standardization efforts aim at the portability of software. The ODMG proposal not only entails the portability of design and source code, but also includes object code, in the form of persistent objects. The ODMG-93 proposal is inadequate due, partially, to the self-imposed restrictions with respect to the compiler support required.

C++ODL/OML binding -- future

no distinction between persistent and transient objects
better integration of the query sublanguage

Modifications to C++

overloading dot (access operator), r/l values, ...

Standardization efforts -- de facto market share

PDES/STEP, ODA, PCTE, OSI/NMF, ISO ODP, ANSI X3

slide: Future standardization efforts

The future C++ODL/OML binding will probably no longer distinguish between references to persistent and transient objects, and will provide a better integration of the query language OQL. To realize these goals, however, extended compiler support is needed and perhaps also modifications of C++ to allow the incorporation of code for integrity checking. It is worth noting that there are a number of additional efforts at defining a standard object model. See slide 11-efforts. The ODMG proposal is explicitly meant as a superset of the object model proposed by the OMG, in order to become what they aptly phrase as a standard enforced by a de facto market share.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.