Application integration -- standards

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. And, finally we will discuss the duality between object and events, which both play an important role in the design and realization of component-based systems.

Object linking and embedding

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

Features

Alternatives


slide: Object-enabling technology -- OLE

The OLE technology is characterized by its developers as 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 to reflect any updates in the spreadsheet application 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 facilities 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. The component object model underlying OLE allows for distribution along the DCE standard discussed in section DCE. The commercial competitors are currently the Apple OpenDoc framework and the IBM SOM/DSOM realization of the OMG CORBA standard. It is interesting to note that future releases of OLE are also promised to be compatible with the CORBA standard.

Distribution {\em -- OMG}

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 (being) 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

    CORBA

  • 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 C++ or Smalltalk) with their accompanying libraries and development frameworks (such as the X-window environment or the Unix operating system). 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 \zline{\c{see} section smart}
  • collections -- List , Bag, Set

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 currently include only 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 the Ref construct discussed in section smart. 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

\zline{\fbox{object model}}
  • the programmer feels that there is one language

Language binding

\zline{\fbox{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.

The object/event duality

One of the major problems in software engineering that must be resolved for each software development project is to obtain a proper modular decomposition of a system. Object orientation, supporting a component-based approach, is a big step, as it provides the mechanisms necessary to address this problem. However, as argued in our historical aside below, it provides only part of the solution. What is still lacking, somehow, is a proper solution to the problem of characterizing the interaction between collections of objects. A (partial) solution to this problem, however, is suggested by employing events to define the interaction between objects. See also sections systems and events. In the OOPSLA'92 panel, with the title The heresy of event-orientation in a world of objects, several speakers observed a discomfort with respect to the notion of events in the object-oriented community. A reason for this discomfort is the tension between objects and events, a tension which is known as the object/event duality. Traditionally, events are actions operating on passive entities, whereas objects are meant explicitly to integrate data and operations thereupon.

Events -- actions involving objects

  • requirements -- user actions
  • design -- object compositions
  • implementation -- action callbacks
  • broadcasts -- talker/listener pattern

slide: Objects and events

Why not abolish events altogether, then? The title of the panel, obviously indicates the reluctance of many software developers to part from events in modeling the behavior of (object-oriented) systems. This reluctance may be explained (partly) as a drive for continuity, a natural opposition to throwing away techniques that have proven to be beneficial in the past. (This is probably also the reason that event-based techniques also occur in modernized, read object-oriented, versions of structured development methods, as examined in section methods.) However, there are also strong arguments in favor of the position that events (which are extraneous to objects) are an essential ingredient (in modeling the behavior) of object-oriented systems. See also sections perspectives and events. The notion of events may play a role in requirements analysis, as well as in design and implementation. As for requirements analysis, the first author of  [Jacobs92], who was one of the speakers of the panel, observed that use case analysis (which is part of Objectory) in essence comes down to listing all possible events occurring in the interaction with the user. Such an analysis specifies the functional properties of a system whose behavior will be realized by an appropriate object model. As for design, we may note that events may be used to characterize the interaction between objects in a generic fashion. In section events, we discussed an example demonstrating the use of event-driven control as a means to manage the complexity of object compositions. Event-driven control also underlies the implementation of many window-based systems. An event coming from the user or window manager may trigger an action that is defined as a callback function associated with the event. See slide 11-events. In the next chapter we will look in more detail at the way in which control is handled by objects in response to events occurring in a window-based system.

Some history

In sections what and abstraction, we have sketched the history underlying the development of object-oriented programming languages, as directed towards increasingly powerful abstractions and constructs for developing reliable software. }
\setlength{\unitlength}{0.0050in}% \begin{picture}(135,298)(40,485) \thicklines \put(175,565){\vector( 0,-1){ 60}} \put(150,660){\vector( 0,-1){ 55}} \put(100,760){\vector( 0,-1){ 65}} \put(150,485){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Ravioli code}} \put( 85,580){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Object Oriented Programming}} \put( 40,770){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Spaghetti code}} \put( 85,670){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Structured Programming}} \end{picture}
slide: Some history

In short, we may characterize the genesis of structured programming as the outcome of the war against the goto and its associated spaghetti code. The subsequent development of object-oriented programming may then be understood as the realization that data is as important as control. Ironically, the disciplined use of encapsulation and inheritance (as mechanisms for data abstraction) may lead to another proliferation of control, threatening the integrity and manageability of object-oriented code. One part of the control problem of object orientation is known as ravioli code, which expresses depictively the existence of a large number of (small) objects with well-defined interfaces, which interact in a complex way. See slide 11-history. The other part of the control problem is known as the yo-yo problem, which characterizes the difficulty of locating control in a class hierarchy with virtual functions. These problems are notoriously hard to solve, yet lie at the core of good library design. As a partial solution to the problem of structuring the interaction between objects we have discussed the notion of events to define generic interactions. However, essential to a successful component-based approach, we need sufficiently high-level components to start with.