IBM Corporation
Object Technology Products Group
Austin, Texas
Recently, both IBM and Microsoft have been wooing developers with their object strategies, and both claim to have solved the problems necessary to permit the construction of commercial grade software components or objects. But the solutions offered are quite different. This white paper compares and contrasts IBM's System Object Model (SOM) with Microsoft's Component Object Model (COM) to assess the implications for developers building software components using these technologies.
What is required to enable the development of "system objects" intended to be supplied either as part of an operating system, a vendor tools product, or an application that:
a) Can be distributed and subclassed in binary form. Class library developers would no longer need to supply source code to allow users to subclass their objects.
b) Can be used, including full subclassing, across languages. It should be possible to build an object using one language, subclass the object using another language and use that class to build an application in yet a third language. Users of class libraries want to modify and build applications from these classes in their preferred language not necessarily the one in which the class was originally written.
c) Provides for the subsequent updating (fixes or enhancements) of these components without having to recompile preexisting clients that use them (upward binary compatibility). This is a key requirement because applications dependent upon system libraries cannot be rebuilt each time a change is made to a component in the library.
In order to solve these problems, the developers of SOM designed an advanced object model and implemented the object-oriented runtime engine necessary to support this model. SOM provides all of the concepts and mechanisms normally associated with object-oriented systems including inheritance, encapsulation and polymorphism.
SOM can be used to provide object-oriented mechanisms for procedural languages or used in conjunction with the capabilities of object- oriented programming languages like C++ or SmallTalk. In fact, several C++ vendors are currently incorporating SOM into their language runtimes.
SOM has been commercially available in IBM's product line since 1991 when it first appeared in OS/2 2.0. In addition to OS/2, it is now available for AIX, Windows and Mac System 7. Over the next two years SOM is likely to be appear on other Unix platforms and Novell's Netware, as well as IBM's Workplace, MVS and OS/400 operating systems.
DSOM is a set of SOM classes (shipped with the SOMobjects Toolkit) that extends the method dispatch mechanism embodied in the SOM runtime engine to allow methods to be invoked, in a programmer transparent way, on SOM objects that exist in a different address space from the caller. The DSOM class library is compliant with the Object Management Group's Common Object Request Broker Architecture (CORBA) specification. DSOM is a framework built using the SOM technology that allows developers to construct distributed object applications. DSOM does not implement a separate object model or runtime since DSOM is built with the SOM object model and runtime.
Interestingly, COM provides no formal representation of an object at all, which in itself is a pretty glaring omission for an "object model". Instead a COM "object" or "Windows Object" exists only in a conceptual sense. The programmer is responsible for providing the representation of the Windows Object which is arbitrary as long as it obeys the rules for how COM expects its objects to behave.
In addition, since programs using COM obtain and manipulate only "interface" references and not objects at all, it is tempting to conclude that COM is a misnomer and reflects Microsoft's attempt to redefine widely used (and understood) terms to suit the technology it has available.
COM has been commercially available on Microsoft's 16-bit Windows platform since Spring '93 and is currently available in beta form for Windows NT and Chicago. Microsoft promises that COM will also be available on Mac System 7 and other platforms sometime in the future.
COM provides very little in the way of runtime support for programmers building Windows objects. Essentially, COM is a set of rules programmers must interpret and follow in order to build these components.
Comparing SOM and COM is a bit like comparing the engine of an automobile with its specifications. A car's engine is not a specification; it is the essential piece of the car that generates the vehicle's motion. Similarly, the engine's specification will not impart motion to the car, rather it must first be used to build an engine before a car can be expected to actually move. In this crude analogy, the engine corresponds to IBM's SOM and the specification corresponds to Microsoft's COM.
An immediately observable SOM/COM difference that arises from these disparate uses of the term "object model" is a distinction in the type of code that a developer must write in every application. With SOM, a programmer writes code that uses the object infrastructure SOM provides; with COM the programmer must also write the code that implements many of the rules and guidelines that comprise the COM infrastructure (regardless of whether this code is written manually or can be partially automated via some development tool, it still must appear in every COM program).
Let's examine some specifics.
Regardless of which approach is utilized (direct-to-SOM or language bindings), the advantage to a developer is that class libraries can be built which sport robust binary interfaces. Client programs may be constructed that are derived from the classes in the library using normal object oriented inheritance techniques without compromising the ability of the class library implementor to make evolutionary changes in the library's internals, and without requiring all client programmers to use the same development language. In short, SOM objects are similar to the normal objects in an object-oriented programming language (OOPL), except that their binary interfaces have been made more robust and replaced with language-neutral mechanisms.
Microsoft's COM, on the other hand, while equally effective at hiding an object's implementation details, does not attempt to be a run-time engine for object oriented programming. In fact, Microsoft questions the appropriateness of today's object oriented programming languages for exposing the interfaces of an interoperable software component. The COM specification is a way of hiding the OOPL notion of an object and exposing instead the different abstraction called a Windows Object.
We promised earlier to look at how Windows Objects differ from typical OOPL objects. Object identity and inheritance are two important examples.
For example, if an object O supports three different interfaces (I1, I2, and I3), you could obtain and use references for O's I1, O's I2, or O's I3, but never obtain a reference for O itself. If you had a reference for O's I1 and O's I2, the only way you could even be sure that both of these referred to the same underlying object, would be to query O's I1 for a reference to I2 and then see if it was the same I2 reference you already had. In general this is always possible because COM requires every interface to support the "IUnknown" protocol. The IUnknown protocol specifies three functions that should appear in every COM interface and the first of these functions should permit you to obtain a pointer to any of an object's other interfaces.
Notice that in speaking of COM we use words like "should." This is because COM is largely a set of rules that are not actually enforced anywhere. When creating a COM Windows Object, it is the programmer's responsibility to implement all of these rules and to get them right. This is yet another difference between SOM and COM. SOM's semantics are implemented by within the SOM run-time, while almost all of COM's semantics must be implemented by the developer in each COM Windows Object. The opportunity for making mistakes when following the complex rules for COM is obvious.
Instead of offering a solution to the fragile base class problem Microsoft chose instead to constrain the semantics of their object model to preclude a mechanism that is widely regarded as one of the defining characteristics of object orientation. In 1987, Peter Wegner of Brown University introduced some order to the OO community by suggesting a subsequently well-accepted taxonomy for classifying object systems and programming languages based on the features and programming paradigms they support. In Wegner's terminology, systems that have classes and support implementation inheritance can be properly called "object- oriented," while those without implementation inheritance are characterized as "object-based." This offers a concise way of summarizing a significant difference between SOM and COM. SOM is "object-oriented" while COM is merely "object-based." Microsoft objects to this because they have improperly used the phrase "object-oriented" heavily in their COM/OLE marketing literature.
Of course, Microsoft's position is much less compelling when one considers that IBM started with a similar premise and chose instead to fix the problem by inventing SOM. The difference in approaches amounts to the fact that SOM permits class libraries to be developed using conventional object-oriented programming paradigms and to offer these same paradigms to their clients, while COM rejects the object-oriented notion of implementation inheritance in favor of totally different paradigms for client programming. Microsoft calls these new paradigms, containment and aggregation and offers them as an alternative approach for object reuse.
Aggregation and containment are essentially manual techniques for code reuse entirely implemented by developer supplied code. COM is not involved in aggregation or containment; it simply provides rules about what users must write.
Containment is used when one wants to change some aspect of the implementation of an object. It requires the programmer to encapsulate the object to be modified with another object whose interface includes the same functions as the encapsulated object. The programmer then supplies the new behavior for functions that are to be changed and provides redispatch stubs to call the corresponding function in the encapsulated object for functions that are not changed.
Aggregation is used when a programmer wishes to add functionality to an object but does not need to change any of the preexisting behavior to the object. Aggregation is really nothing more than an optimized form of containment in which the programmer is not required to write redispatch stubs for each function in the object's interface. However, the ability to support aggregation must be explicitly built into a COM object by the developer, so not all Windows objects can be used in this fashion.
With SOM, IBM has chosen to solve the fragile base class problem as opposed to constraining developers' ability to apply widely accepted object oriented techniques. Instead of redefining the commonly accepted parlance of object technology or making pronouncements on the correctness or incorrectness of prevalent object oriented techniques, SOM supports the familiar paradigm used by developers of object-oriented components. Developers of SOM objects can employ single inheritance, multiple inheritance or abstract (interface only) inheritance.
The Component Object Model on the other hand is largely a set of rules for building interoperable software components. COM places the burden of support for the protcol onto the developer who must duplicate this support in every COM object he or she implements. As a direct consequence of the lack of runtime support, implementing COM objects is a highly complex, time consuming process fraught with opportunities for misinterpretation and error. Because COM does not support many commonly accepted object- oriented concepts and mechanisms, developers are forced to adopt an unfamiliar programming paradigm and, in fact, typically have to switch between the paradigm provided by the implementation language (e.g. C++) and the paradigm enforced by COM. In comparison with SOM, COM embodies an impoverished set of functionality that places many constraints on developers.
Microsoft is a registered trademark and W indows is a trademark of Microsoft Corporation. Object Management Group and OMG are registered trademarks of the Object Management Group, Inc. OpenDoc is a trademark of Apple Computer, Inc. IBM and OS/2 are registered trademarks and SOMobjects is a trademark of IBM Corporation. All other trademarks are the property of their respective owners.
Last Updated: July 7, 1994