Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Introducing Interoperable Objects


SP 94: Introducing Interoperable Objects

For those of you who follow events in the computer industry, I have some good news: The operating-system wars are over, as are the language wars, as well as the application-framework wars. The bad news is that nobody won. Instead, the struggle has moved over to the arena of interoperable objects.

What are interoperable objects? These are objects that go beyond the usual boundaries of traditional objects--the long-standing boundaries imposed by the programming language, the process address space, and the network interface. We've coined the term to refer to the convergence of certain trends in software technology: the continued evolution of object-oriented programming into the areas of language-independent objects, distributed computing, and compound-document technologies.

Interoperable objects are in many ways a goal, rather than a practical reality. Often, what exists today is more of a spec or a white paper, instead of a working program or software component. Even so, today there are demonstrable technologies that fall (at least partially) under this rubric, including Microsoft's Object Linking and Embedding (OLE), IBM's System Object Model (SOM), OMG's Common Object Request Broker Architecture (CORBA), CI Labs OpenDoc, NextStep's Portable Distributed Objects (PDO), Novell's Appware Distributed Bus (ADB), and Taligent's Application Environment (TalAE). The purpose of this Special Report is to provide you with an in-depth look at these technologies, each of which is vying to be the dominant application platform for the rest of this decade, sometimes in conjunction with one or two of the others.

First, there's a small matter of semantics. Some observers refer to this phenomenon with different terms: distributed objects, component objects, compound documents, or middleware. However, as you'll see, the other terms are not quite accurate. For example, "distributed objects" does not quite cover some of the major contenders in this arena. Both OLE and OpenDoc, for example, do not provide a distributed version that's shipping. Other terms lean toward the proprietary domain. For example, it is conceivable that "component object" will be a candidate for trademarking. Some terms highlight only one aspect of the technology. For example, "compound documents" refers mostly to the higher, application-oriented layers of the system. Likewise, "middleware" refers only to the midlevel components of the system (the layer of abstraction above the operating system and below the application), and is not necessarily object oriented. Compared to the alternatives, interoperable objects is the best of the lot, even though it may disguise the fact that we are sometimes comparing apples, peaches, and pumpkin pie (that is, paper specifications versus proprietary implementations versus partial solutions). Keep in mind that, at present, there is no shipping system that does the entire job.

So why should you care about interoperable objects? Well, unlike some recent technological trends such as multimedia and pen-based computing, interoperable objects are likely to comprise the broad mainstream of computing over the next few years--as mainframe-based servers continue to link up with departmental computers and GUI-based desktop PCs, throughout the enterprise and across networks. Interoperable objects represent a convergence of certain trends that seems inevitable, although it is far from clear which particular technology (or vendor) will prevail.

The ongoing struggle between these emerging technologies has led to many press reports mentioning acronyms, alliances, announcements, and abdications, without explaining the underlying technologies. If you are a software developer or information-technology professional, you will need to become familiar with these concepts over the next few months or years. Many companies are now evaluating use of one or more of these technologies on a strategic basis. To assist in this process, we decided that a Dr. Dobb's Special Report on Interoperable Objects would be particularly valuable. As much as possible, we've tried to get the information for you directly from the source: the architects, designers, and technical staff at the companies promulgating each alternative. In some cases, the information here has not been released to the public until now (the Taligent article, for example). In other cases, there is a concise summary of a flood of material (on OLE, for instance). In the case of technologies that have not yet been released, working code is not available to the public. However, for the case of SOM and OLE, we present working implementations of a comparable program so that you can see for yourself the concrete details involved in making an object interoperable.

This Special Report is structured into two principal parts. This reflects the division, on the one hand, between system-level object models such as CORBA, SOM, and Microsoft's Component Object Model (COM), and, on the other, application-level technologies such as OpenDoc, OLE, and TalAE. You may notice that there are two articles on Microsoft OLE. This is because the facilities in OLE span both the system-level domain (by way of COM), as well as the application-level domain (by way of the compound document, and the linking-and-embedding services in OLE). Other application-level systems such as OpenDoc and Taligent rely upon IBM's SOM to provide the underlying object model.

The rest of this article tries to set the context for the other contributions to this Special Report, without duplicating the material. For additional background on interoperable objects, see also "Interoperable Objects," by Mark Betz (DDJ, October 1994).

Distributed Computing Before Objects

Although interoperable objects are new, distributed computing is not. The technologies for distributed computing provide in some ways the roots of interoperable objects. Distributed computing has existed, in one form or another, since the 1960s. Possibly the largest single implementation is American Airlines' SAABRE system, considered by many to be that company's most important asset. SAABRE is an airline-reservation system that was developed more than 20 years ago and is still being enhanced. Reportedly, it consists of a single application program running on top of bare hardware--which, in this case, consists of a fleet of mainframes, a Texas-sized disk farm, and over 20,000 user terminals. There is no operating system, no high-level language, never mind any object orientation. It is a distributed system nonetheless, and perhaps the ultimate example of a proprietary system. Its fully integrated design trades off complexity and flexibility in favor of maximally efficient use of hardware.

Moving closer to the present, client/server architectures are now the norm for distributed computing systems. A client/server architecture distributes the processing across a network consisting of multiple clients (say, desktop PCs) connected to one or more servers. Today, many commercial packages and tools support development of client/server applications--allowing for choice of vendor, language, operating system, network, and data model. At present, most of these technologies (such as PowerBuilder) are procedural instead of relying on objects. You can also implement a client/server system by using C++ and Windows on the front end, and talking to an SQL server on the back end. However, the application objects stop at the boundary of the running executable. Many of the popular client/server tools assume you are building some kind of database application. If your client program needs to talk to something other than an SQL server, you may be out of luck. As Ken Haas of Intellicorp points out, client/server computing has evolved in three phases: The first was distributing the data, then came distributing the user interface, and still to come is full distribution of the complex business logic of the enterprise.

For those who need the flexibility that a mass-market shrink-wrapped tool cannot provide, an emerging standard is Distributed Computing Environment (DCE) from the Open Software Foundation (OSF). DCE implements an industrial-strength distributed computing environment on top of existing operating systems and platforms (usually UNIX workstations, but also mainframes and PCs). Although DCE is procedural rather than object oriented, many of the concepts in DCE serve as precursors for the interoperable object technologies found in CORBA, SOM, and OLE.

The OSF DCE Environment

DCE consists of a number of tools, libraries, and components that together allow great flexibility in building client/server applications. It is worthwhile to spend a moment going over the facilities in DCE, because analogous versions of these appear in the technologies discussed in this Special Report, not always with acknowledgment.

DCE provides a remote procedure call (RPC) facility that is the basis for all communication in DCE. When a client makes a request to a server, the client process invokes an RPC on the server process. At the level of client code, it looks like a call to a local function. The RPC mechanism encapsulates and hides what may be an elaborate sequence of events. The RPC facility locates the server using a naming service and binds to it and marshals parameters and transmits them across the network, doing any necessary fragmenting and reassembly (in the case of large arrays, for example) as well as any data conversion (because of differences in byte ordering).

The blueprint that drives the RPC process is the interface between client and server. The formal specification of this interface is written in a language called IDL (Interface Definition Language). IDL constructs resemble the function prototypes in C, plus typedefs and defined constants. The IDL specification to your application is run through an IDL compiler, which produces "stubs" for the client and server portions of your application, as well as header files. The client and server code uses the header files to declare the local stub functions. Client and server modules are compiled and linked in with their respective stub object files. Again, this process is similar to that found in CORBA, SOM, and OLE.

Although DCE programs can be written in any language supported by the tools (including Fortran), the underlying concepts resemble, or are derived from, C. Interoperable object technologies such as CORBA, SOM, and OLE extend this approach by adding an "object model," a way to represent objects beyond the bounds of a single application program or language. Although the technologies are different, you'll find many of the concepts in DCE--such as interfaces, stubs, proxies, IDL compilation, resource naming, unique identifiers--have counterparts in CORBA, SOM, and OLE.

The Object Model

The object model is the system-level foundation that makes possible application-level facilities such as linking-and-embedding, scripting, and compound-document construction. As mentioned previously, you can have entirely different application-level frameworks or systems--for example, TalAE and OpenDoc--built on top of the same object model (in this case, SOM). Just as DCE extends the C-function-call model across the boundaries of language, address space, and the network, so do CORBA, SOM, and OLE extend a C++-style object model across those same boundaries. So, instead of a procedural interface between client and server, you can partition your distributed application using an object-oriented factoring.

Why would you want to do this? Well, this is not the place to convince you of the benefits of inheritance, encapsulation, and polymorphism. Suffice to say that many system designers have found that factoring a complex system into objects greatly assists in managing complexity. On the other hand, if you are a experienced object-oriented developer who thinks that "C++ is to C as lung cancer is to lung," you can rest easy. Many of the obnoxious aspects of C++ have been left behind, because the only constructs needed are for specifying interfaces. And remember that it is only the interface design that is object oriented. You can program any language for which a binding is available. At the moment, the only official language binding is C, although a to-be-finalized C++ binding has been available for some time.

The principal object models are SOM, COM, and CORBA. They're not quite comparable, because CORBA is a specification rather than an implementation, but everyone compares them anyway. The CORBA architecture has been implemented by at least a half-dozen different vendors, including Digital, Hewlett-Packard, Iona, Expersoft, and SunSoft. In some cases, a vendor's design predates CORBA and has been made compliant by means of retrofitting. Although IBM's SOM is CORBA-compliant, it is different enough in design goals, scale, deployment, and market presence, that it should be considered on its own. Microsoft's COM has some fundamental differences with CORBA, such as lack of the usual notion of inheritance. Nevertheless, it, too, has been made CORBA-compliant by way of Digital's Common Object Model (not to be confused with the Component Object Model).

Compared to DCE, many of the object models lack maturity and scope. DCE provides ancillary services--such as security, authentication, directory, time, and threading--that are only in the planning stages in the case of some object models. Because OSF sells only source code, most DCE implementations are based on a common codebase, so you'll find much more interoperability between vendors than in the CORBA world.

Compound Documents

In the platform of the future, compound document technologies-- such as found in OpenDoc, TalAE, or OLE--will be layered on top of an underlying object model. Although it is too early to tell which alternative will prevail, we do know the general shape of the winner, because the existing alternatives share some common design points. The technologies have all evolved down a similar path.

The history of compound documents is much shorter than that of distributed computing, because, until the Xerox PARC Smalltalk system of the late 1970s, most mainstream computing was textual rather than graphical in nature. With graphics came the ability to present a richer set of application datatypes to the user: charts, page designs, images, and typographic-quality text. In the mid- and late 1980s, applications such as Aldus PageMaker could integrate a wide array of datatypes into a single document. Paul Brainerd of Aldus once said that the "Place" command in PageMaker (which is used to import a variety of datatypes) is "the single most important command in the entire program."

Although powerful and featureful, these programs evolved into enormous monoliths written without object-oriented tools, and they became increasingly difficult to maintain and test. At that point many vendors started switching to C++ for the implementation language. Second-generation page-makeup programs such as QuarkXPress, along with the new generation of multimedia tools such as Macromedia Director, provide even more facilities for integrating application datatypes into a document. However, the focus is still on the application and the vendor, instead of the document and the user.

This situation led to an emerging paradigm of compound-document computing. From the user's point of view, compound documents provide a "document-centric" rather than an "application-centric" model of use. The basic idea is that there is a generic shell or empty container provided by the platform vendors that can be filled with any number of different datatypes (and associated functionality) created by any number of third parties. This generic shell, in conjunction with the appropriate components, can function just as easily for doing spreadsheets as for wordprocessing or multimedia.

The germ of this idea probably came from application frameworks, which evolved in the mid-1980s out of C++ class libraries such as that from NIH, as well as from the original Smalltalk class library. The first commercial app framework was Apple's MacApp, in 1988. MacApp provided a generic implementation of the common functionality needed by most applications (such as file open/save, print, command undo, help, and so on). MacApp's design was influenced by the Model/View/Controller paradigm used in Smalltalk. This paradigm has been adopted by most frameworks, including MFC, OWL, and TalAE. MacApp was initially written in Apple's object-oriented version of Pascal, then later rewritten in C++. An object-oriented language is the ideal implementation vehicle for this, because developers can subclass and modify the generic behavior to fit their specific needs. An object-oriented language is also ideal for implementing compound document components, because an object is able to encapsulate both code and data.

More-recent mainstream frameworks include Borland OWL, Microsoft MFC, Think TCL, and Symantec Bedrock (now defunct). One of the most sophisticated app frameworks predates these four--GO's PenPoint environment, which in 1990 included a compound-document facility known as Embedded Document Architecture (EDA).

Using a complex application framework effectively often requires the source code--at least to look at the code and understand what the documentation has left out. So, most frameworks today come with the entire source. In a true compound-document architecture (such as Penpoint EDA), it is not necessary to provide the source, because the interfaces between components and containers are more precisely defined.

As app frameworks matured, they increased in functionality and size. For example, MFC grew from about 25,000 lines of C++ in Version 1, to 55,000 lines in the next release, to almost 80,000 in Version 2.5, with more to come. This dramatic increase in complexity has led to a more careful reevaluation of the interface between the generic container and the application-specific component. The idea is to insulate the developer from having to understand a large body of code, and focus more on the protocols that govern the interaction between component and generic container. The result has been a redesign of the app framework as we know it. This is why Taligent's efforts, which were initiated at Apple under the codename "Pink," did not start with the MacApp or Bedrock source code, but instead began with a clean slate. Likewise, Microsoft's OLE will eventually subsume the entire system, from the application level down to the operating-system services (in the form of the Cairo OS, due in 1996). For the moment, OLE services have been grafted on to Microsoft's existing app framework, MFC 2.5.

Compound-document technologies seem to start from the top and percolate downward to the level of the operating system. Taligent plans to first release its TalAE application environment, then follow it with TalOS, which represents functions more akin to that of an operating system. Researchers at Xerox PARC used to remark that "an operating system is a collection of things that a language does not provide." Soon one might say that an operating system is one set of services provided by a new-generation application framework. At that point, the transition to the platform of interoperable objects will be complete.


Copyright © 1994, Dr. Dobb's Journal


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.