Componentware on the horizon
Making sense of OLE, PDO, OpenDoc, and other technologies
Objects may be an abstraction, but they require very real protocols to communicate with others of their ilk. There are several prevailing technologies afoot, which ones gain dominance is a question best posed to the marketplace. (1,600 words)
If you have used Microsoft Office applications, you're probably familiar with the concept of linking paragraphs or cells across applications so they appear and behave as if you have a direct link into the Excel file or Word document. Microsoft accomplishes live links like this with its Object Linking and Embedding (OLE) layer.
Componentware, applets, and embedded objects all describe a concept that has taken a long time to become a reality. Componentware is best described as small objects embedded within documents that function across documents, applications, and even systems.
We will discuss object models from Microsoft (OLE), NeXT (Portable Distributed Objects [PDO]), and the OpenDoc consortium, and the effect these technologies will have on application software during the next few years.
Objects and components
First, let's define the object model as an architecture that enables objects to interact with each other according to a set protocol. In its simplest form, objects resident on a single machine communicate and share data. At the next level, these objects share data across homogeneous systems and networks. In their most complex form, objects should communicate and be usuable across differing platforms. If you thought network communications with TCP/IP was complicated, enabling cross-platform object compatibility creates a whole new level of difficulty.
The object model allows developers to write applications that can interact more closely with other products, whether they be their own or those from other vendors. This makes the application more useful and, sometimes, even a little more compact. In the old order of things a file was just a stream of characters. In the new object order, a file is a complex of text objects, images, audio clips, etc. What's more, these smaller components can interact separately from the main document itself, allowing several components across applications to intercommunicate. These are the innovations we have been hoping for in the last decade and only recently have we been able to use them on a more regular basis.
Apples and pears
Some of the popular object models include the Object Management Group's Common Object Request Broker Architecture (CORBA), IBM's System Object Model (SOM), Microsoft's OLE/Common Object Model (OLE/COM), and NeXT's PDO. Although they are quite similar -- after all, they all handle objects and intercommunicate -- there has almost always been something keeping them apart. This situation persists because the actual methods of object communication and interaction differ.
Object-oriented programming usually allows object inheritance whereby, for example, an object like a Chevy Nova inherits common features of a parent object, like a car. Some models allow objects to completely inherit others; some allow objects to perform multiple inheritance (a Chevy Nova may inherit the car object and the Chevrolet company object); still others allow only the public sections of the object to be inherited, and so on. Another thing keeping the object models apart is the way they communicate between applications. The basic transport protocols differ.
Microsoft Object Linking and Embedding
OLE is probably the most well-known of object models because of the ubiquitous PC. Microsoft's current version of OLE (2.0), released back in March 1993, still provides only in-system communications and interactions between objects. Microsoft has also made good use of components in its most popular packages and continues to do so for each new major application it develops. This is a good move considering that the future of Microsoft's operating systems depend upon OLE's existence and preponderance.
Microsoft calls OLE an "object-enabling strategy" rather than a true "object-oriented system" because that was OLE's original mission. OLE exists so non-object-oriented code can be packaged into useful little components that can be accessed as "objects" by other systems.
OLE uses the Common Object Model (COM), which defines how components interact. Each object is responsible for all its behavior and, when put into execution by the processor, is responsible for behaving according to proper design and not do things that may cause an improper state or lock the system. That's a lot of responsibility for the (usually small) components. The idea is flawed in that it assumes every programmer writes perfect code. There is another model that relies on the system to organize execution and communications. We will take a look at it later.
Microsoft wanted to maintain binary compatibility to create efficient interaction users could see, rather than become involved with complex object-oriented systems distributed across networks. Unfortunately, this results in a closed system, which is why Microsoft is working on Distributed OLE, the next-generation system it hopes will allow the real transition to object-orientedness. Distributed OLE will handle local network as well as wide-area network connections between objects in a more efficient manner. Apparently this is the year Microsoft hopes to preview the new project, although it has been in the news as "coming-soon" for quite a while.
NeXT Portable Distributed Objects
NeXT, an often underappreciated company, has put a lot of push behind its object-oriented technology. Even if you ignore the fact that NeXT has managed to interface perfectly to Microsoft OLE, Portable Distributed Objects is an interesting accomplishment in and of itself. The biggest advantage of PDO in a business sense is its maturity. It has been part of the NeXTStep operating system since 1987, when object-oriented technology was just a murmur among developers and before media-hype blew things completely out of proportion in the early '90s.
PDO is based on NeXT's OpenStep Object Model. NeXT believes in making the object the ideal rather than a component of the system. With PDO, objects are location-independent and can attach themselves to one or more processes on one or more hosts when necessary. This allows an important feature known as object migration -- the ability for an object to move independently across the system or network -- and lends itself very well to distributed computing. Applications use it by dynamically loading objects into themselves, allowing them to attach themselves as part of the program as needed.
The great news is that NeXT has developed a Distributed OLE package announced in January that provides an interface to its current PDO environment. It is currently available for Windows NT under the name D'OLE and Enterprise Object Frameworks 1.1 for Windows NT. With D'OLE, Windows users can access OpenStep and scale their applications into a much larger client/server environment.
This object model is probably the most technically adventurous of the lot. Apple, IBM, and other vendors are contributing to this effort to create a uniform object model for MacOS, Windows NT and 95, AIX, and OS/2. This consortium hopes to create componentware that allows objects to be used across multiple operating environments on a local and distributed scale. With it in place, Windows users can open up Mac documents within their own native applications without any trouble or technical voodoo involved.
The OpenDoc component software architecture involves several different technologies: IBM's System Object Model (SOM) and Distributed SOM (DSOM); the OpenDoc Document Architecture, describing how document editors interact with the components or "Parts" according to its nomenclature; the OpenDoc Component Architecture, describing how parts communicate with each other; Bento, an object storage library; the OpenDoc Scripting Architecture, a scripting and automation API; and Component Glue, an interface to Microsoft OLE/COM. SOM incorporates a separate entity responsible for watching over the independent components running on the system and to facilitate their communication and necessary translations due to differing machine byte-orders, instruction style, etc. SOM/DSOM is a much more involved process because of the differences across the platforms supported.
OpenDoc aims to target the OLE market and created the Component Glue systems to allow OLE components to appear within the OpenDoc model as independent objects that can communicate bi-directionally between the two systems. There are even development libraries allowing programmers to develop OpenDoc objects much faster than native OLE applications and still maintain full compatibility. The OpenDoc Software Development Kit version 1.0 was released in November 1995 for Macintosh and in December for OS/2 3.0. The AIX version is currently available in beta from IBM. Big Blue is also planning on releasing the Windows 95 and NT SDKs in the second quarter of this year, with final user versions shipping in the third quarter. The plan is to have OpenDoc for supported platforms by year's end.
So what's the moral of the story? Componentware technology is here to stay. 1996 may be the year the componentware war goes into full force as everyone begins releasing their own latest versions and products. We haven't had the chance to talk about other major projects, such as Sun's NEO strategy and the Object Management Group's CORBA systems. The truth is that each has a good strategy idea and certainly a great deal of push from some of the largest vendors around. It is still too early to say which will win. Microsoft is steadfast in following its own path; Apple, IBM, et al. have a very nice model that works across several popular systems; NeXT has a superb design that is slowly being reviewed or adopted by other vendors such as Sun and Digital but has yet to catch on. The fact remains that everyone we talked about here wants to work with OLE/COM in its current structure and with the future Distributed OLE system, as well. NeXT has already beaten Microsoft to the punch of creating a D'OLE system, placing its middleware products at least a furlong ahead of the others. Now, maybe Microsoft will decide to play in the sandbox with the others too; I doubt it, though.
About the author
Rawn Shah is vice president of RTD Systems & Networking, Inc., a Tucson, Arizona based network consultancy and integrator. Reach Rawn at email@example.com.
If you have technical problems with this magazine, contact firstname.lastname@example.org