The System Object Model (SOM) and the Component Object Model (COM): A comparison of technologies from a developer's perspective
By IBM Corporation. Object Technology Products Group. Austin, Texas
- 1 SOM
- 2 COM
- 3 Programming methodology
- 4 Relationship to languages
- 5 Static Typing
- 6 Distributed object support
- 7 Compound Document Support
- 8 Method Resolution Mechanisms
- 9 Inheritance
- 10 Functional composition mechanisms
- 11 Versioning
- 12 Complexity
- 13 Object Lifecycle support
- 14 Robust object model
- 15 Standards and platform coverage
- 16 Unique Features
- 17 Trademarks
Object enabling technology consisting of an advanced object model and a syntax-free OO runtime engine sufficient for implementing object-oriented programming languages. SOM solves the problems of cross-language access and fragile base classes allowing class libraries to be distributed and subclassed in binary form.
Ostensibly, a “language-neutral” binary interface specification but primarily a set of rules that must be implemented in every application implementing interoperable “Windows Objects”.
Comments: Based on widely accepted parlance (e.g. Wegner, OOPSLA 87), object oriented programming presumes implementation inheritance, A correct characterization of the methodology is important because it typifies the programming paradigm that will be found in applications built using the methodology. COM requires programmers to adopt an unfamiliar, proprietary programming model by redefining prevalent terms and techniques in object oriented programming. SOM, on the other hand, uses a programming model familiar to programmers who use object-oriented programming languages.
Relationship to languages
SOM: Language-neutral. Objects may be written in C or C++. Smalltalk and Cobol bindings are under development by vendors. Direct-to-SOM C++ products (available from Metaware and IBM) map the ANSI C++ language directly into SOM.
COM: Language-neutral, function pointer table based. The user is responsible for constructing the function table. Objects may be written in C or C++. Writing objects in C is more involved because the function table must be constructed manually instead of the C++ trick of using a virtual base class. Interestingly, the C++ method of using a virtual base class for building the function table may not work properly with all C++ compilers - not all compilers lay out the vtable structure the same way that the Microsoft compiler does.
Comments: COM’s object model does not map into any OOPL and cannot be used as an OOP runtime engine by compilers. SOM can be used as a common binary runtime engine for C++ compilers and other OOPLs.
SOM: Objects statically typed via the class hierarchy. For static method invocations, the compiler checks that a class is of the appropriate type.
COM: Individual interfaces are statically typed, not objects. A programmer deals with an interface pointer and must verify support for an operation at runtime.
Comments: Static typing permits the language compiler to prevent type mismatch errors from showing up at runtime. Lack of static typing introduces more runtime failure modes. COM objects require runtime operations to ascertain which interfaces are supported by an object.
Distributed object support
SOM: Provided by the DSOM framework.
COM: Will be provided in the Cairo release in 1995.
Compound Document Support
SOM: Provided by OpenDoc.
COM: Provided by OLE
Method Resolution Mechanisms
COM: User responsibility, requires 2 steps:
- Use QueryInterface or instantiation to get Interface
- Indirect function call via interface vector table
Polymorphism is not directly supported and must be emulated by user-written code using containment. COM supplies no user intercept capability. The granularity of polymorphism is at the interface level only.
- 3 Forms (offset, name, dispatch).
- User intercept capability for all three (via somDispatch).
- Granularity of polymorphism: interface level, method level, or user-defined (arbitrary).
Comments: Except for object instantiation, no COM code is involved in interface selection or function invocation. In this area COM is only a set of rules, all code involved in interface selection or function invocation is user-written. SOM, on the other hand, performs method resolution (i.e., interface selection and function invocation) completely automatically, without user-written code. SOM users may, however, optionally elect to participate in method resolution by overriding the somDispatch mechanism.
SOM: Supports single, multiple and abstract (interface) inheritance. Complete encapsulation of base class from derived class. Subclass uses only the published interfaces of the base class. Versioning is handled automatically during class construction. SOM has several mechanisms such as somIsA, etc.that can be used to simulate aggregation.
COM: Traditional OO inheritance is not supported. Instead, containment and aggregation are offered as substitutes for reuse. Implementation inheritance is considered bad due to possible implementation dependencies between a base and derived class. IUnknown interface is frozen since it must be embedded within all other interfaces.
Comments: Aggregation is essentially a manual technique entirely implemented by user-written code (COM is not involved in aggregation; it simply provides rules about what users must write). On the other hand, SOM’s implementation inheritance is automatic and not subject to the “base/derived” class problem since (in general) the only the base class’ public interface is available to the derived class. In addition, lack of inheritance at the COM level means implementors must cope with 2 different object models, one for components, and a different one at the implementation language level (since no language offers aggregation).
Functional composition mechanisms
SOM: - Containment (or Delegation (user-written)). - Inheritance. - Metaclass selection. - Derived metaclasses based on multiple inheritance. - Behavior changes are made by overriding methods.
COM: - Containment (or Delegation (user-written)). - Aggregation, but all objects not required to support it. - Behavior are made changes by front-ending with new code.
Comments: COM capabilities require user discipline and adherence to protocol conventions. SOM mechanisms are richer and more automatic. Some functions cannot be augmented via COM’s front-ending technique since methods internally invoked within an implementation do not interact with the front-end. Despite the overblown terminology, aggregation remains essentially just an optimized form of containment, allowing a user to forego the writing of the delegation code.
SOM: Automatic base/derived class version checking using major & minor numbers. Optional user written versioning using major & minor numbers. Evolution of classes permits refactoring methods, additions to inheritance tree, changes in object size, additions to interfaces.
COM: User-written versioning using major & minor numbers. Method implementation refactoring, changes in inheritance tree, or object size not visible thorough COM. Additions may NOT be made to interfaces. Old interfaces must be kept and a new interface that include all the old methods along with the newly added methods must be created.
Comments: There is a dramatic difference in philosophy between SOM and COM here. SOM permits interfaces to evolve over time without breaking existing client programs, but COM requires proliferation of new interfaces while retaining all old interfaces. Also, in SOM versioning is essentially automatic, while a user responsibility in COM.
- One object reference needed per object.
- Reference counting may be used when desired and can be automated using metaclass programming
- Inheritance is statically declared.
- Local classes and interfaces do not require globally-unique persistent Ids. DSOM makes use of UUIDs.
- No special coding required to permit subsequent implementation inheritance.
- An interface reference is required for each object interface.
- All objects must be reference counted.
- Aggregation requires user-written code to implement.
- All classes and interfaces must have a globally-unique persistent Id.
- Interface implementations must be specially coded to permit subsequent aggregation.
- All object lifecycle is implemented by the programmer.
Object Lifecycle support
SOM: All object lifecycle support provided including object creation, object destruction, object factories.
COM: Object lifecycle is implemented by the programmer according to complex rules and reference counting protocol.
Robust object model
SOM is a “language-neutral” packaging technology for class libraries. It permits libraries of object classes written in various object-oriented or procedural languages to be distributed in binary form, either as part of an operating system, a vendor tools product, or an application. Client programs written to use SOM-based class libraries are insulated from dependencies on unintentional details of the object’s implementation, so that the supplier of the class library may produce subsequent releases with fixes or enhanced capabilities without fear of breaking the client programs.
The COM model is predominately conceptual in nature. Little programmer support is provided. Type safety is the responsibility of the programmer.
Standards and platform coverage
- Invented by IBM, but built on the OMG CORBA standard.
- Supports inheritance as built into all OOP development languages.
- Uses IDL - OMG’s Interface Description Language to define all objects.
- Direct-to-SOM C++ Compiler products map ANSI C++ language directly and transparently into SOM.
- Available now on OS/2, AIX, Windows, Mac System 7. Will likely be available in the future on other Unix’s, Novell Netware, IBM’s Workplace, MVS and OS/400 operating systems.
- Invented by Microsoft, not part of any standard.
- Introduces paradigms, such as containment and aggregation, which are not part of any programming language.
- Available now on Windows 3.1. Beta avail for Windows NT & Chicago. Promised but not yet available for Mac System 7.
Comments: Incorporation of standards assures that widespread user requirements are being addressed and that compatible APIs and products may appear across a broad range of industry platforms. SOM is explicitly committed to support of industry standards while Microsoft argues that tracking standards is counterproductive. Microsoft has indicated that the CORBA specification is incomplete and evolving and that it is unlikely to support CORBA.
SOM: It is easy to overlook the runtime component of the SOM as merely providing support for language neutrality and upward binary compatibility. But, in fact, SOM embodies an advanced object model with some very important and desirable capabilities including:
- Dynamic class construction
- Name Lookup & dispatch method resolution
- Single, multiple, & abstract inheritance
- Emitter framework
- User dispatch intercept
COM: COM has comparatively impoverished functionality.
(c) IBM Corporation 1994. All rights reserved. This document is provided for informational purposes only and is subject to change without notice. IBM Corporation makes no warranty, express or implied with respect to this document. The facts contained in this document are believed accurate based on publicly available information at the time of publication.
Microsoft is a registered trademark and Windows 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.
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation