The linchpin of IBM's object-enabling infrastructure
The object industry today is a patchwork of islands of information residing within the confines of a myriad of incompatible object systems. For example, consider binary C++ class libraries that cannot be shared among developers using different C++ compilers--let alone by Smalltalk or Cobol programmers.
To address some of the key inhibitors to the widespread acceptance of object technology, and to overcome some key impediments to object interoperability, IBM created the System Object Model (SOM). SOM is the linchpin of IBM's object-enabling infrastructure. Eventually, SOM will underlay all of IBM's object technology product offerings (including OpenDoc, the Taligent frameworks, and the Workplace family of operating systems).
What is SOM?
The SOM technology was designed specifically to overcome several major obstacles to the pervasive use of object-class libraries. The goal is to enable the development of "system objects"--which can be supplied as part of an operating system, a vendor tool, or an application--with the following attributes:
- The objects can be distributed and subclassed in binary form. Developers of class libraries do not need to supply source code to allow users to subclass their objects.
- The objects can be used, with full subclassing, across languages. It is possible to implement an object using one language, subclass the object using another language, and use that class to build an application in yet a third language. Developers want to modify and build applications from class libraries in their preferred language, which is not necessarily the one in which the classes were originally written.
- The enabling technology allows for the subsequent modification (bug 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 that depend upon system libraries cannot be rebuilt each time a change is made to a component in the library.
To achieve this goal, the developers of SOM designed an advanced object model and implemented the object-oriented run-time engine necessary to support this model. SOM supports all the concepts and mechanisms normally associated with object-oriented systems, including inheritance, encapsulation, and polymorphism. In addition, SOM possesses a number of advanced object mechanisms, including support for metaclasses, three types of method dispatch (with both static- and dynamic-method resolution), dynamic class creation, and user intercept of method dispatch.
SOM has been commercially available 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 appear on other UNIX platforms and Novell's NetWare, as well as IBM's Workplace, MVS, and OS/400 operating systems. SOM has been selected by the Component Integration Laboratories (CIL) as the underlying object model and run-time engine for the OpenDoc compound-application technology. SOM is also used by Taligent (a development company that is a joint venture of Apple, IBM, and HP) in the Taligent Application Frameworks (TalAE).
One source of confusion when comparing compound document technologies has been the relationship of the OpenDoc technology to SOM. SOM is object-enabling technology. It was never intended to provide compound-document functionality. OpenDoc, developed and distributed by CLI, is built upon the SOM object model and run time, as well as SOM's distribution framework, and provides a framework specifically designed for building components, or "parts" that can be integrated into compound documents.
Backplanes and Frameworks
SOM can be thought of as analogous to the hardware backplane in a personal computer; see Figure 1. Like the hardware backplane, SOM has slots for objects or frameworks (defined later) to be inserted, analogous to the boards that plug into the hardware backplane. The major difference between a traditional PC backplane and SOM is that the PC backplane is used primarily as a communications vehicle between the computer's CPU and peripheral devices. SOM is a peer-to-peer communications vehicle interconnecting objects and frameworks with each other, rather than to a central "master" controller.
Figure 1: SOM has slots for objects or frameworks to be inserted that are analogous to the boards that plug into the hardware backplane.
SOM comes packaged with a number of frameworks. Frameworks are interrelated sets of SOM objects designed to solve a particular problem. They are analogous to the hardware boards that plug into a PC backplane, as shown in Figure 2. Like many of the boards that populate a PC backplane, the SOM frameworks are built to be extended, modified, or completely replaced. Three of the frameworks packaged with SOM are object persistence, object replication, and object distribution.
Figure 2: SOM frameworks, analogous to PC hardware boards, are interrelated sets of SOM objects designed to solve a particular problem.
The purpose of the distribution framework (sometimes called "distributed SOM") is to seamlessly extend SOM's internal method-dispatch mechanism (the piece of SOM responsible for invoking operations on objects) so that methods can be invoked in a programmer-transparent way on objects in a different address space or in a different machine from the caller.
The object-distribution framework can be viewed as a board fitting into the SOM backplane that has some components preinstalled, as well as empty sockets for additional components; see Figure 3. Components that come preinstalled in SOM's distribution framework allow messaging between objects in different address spaces on the same machine.
Figure 3: The object-distribution framework is akin to a board that fits into the SOM backplane that has some components preinstalled.
Additional components can be added (marshaling, transport, and so on) to support messaging between objects on different machines. Components also can be replaced, depending upon the particular distributed-computing environment that needs to be supported. For example, different marshaling engines, transports, or location services can be substituted for the ones supplied by IBM. Of course, if desired, the entire distribution framework could be replaced with another CORBA-compliant, distributed-object framework.
Particular installations of SOM may differ according to what frameworks and components are installed and how they are configured. It is important to note, however, that these installations do not constitute different varieties of SOM, but rather different configurations --the underlying SOM infrastructure is exactly the same in every case.
This is analogous to the almost unlimited variety of configurations available for different PC architectures (Mac, Intel, and so on). In general, different configurations run the same binary software, the differences being related to the resolution of the display or access to different peripherals. Just as you can increase the power of a PC by adding a floating-point processor or upgrading the display hardware, you can enhance SOM frameworks by adding or replacing components with ones capable of meeting the requirements---say, for example, of enterprise-wide, intergalactic, distributed-object environments.
SOM, Distributed SOM, and CORBA
SOM is a packaging technology and run-time support for the building of language-independent class libraries. SOM's distribution framework, a set of SOM classes (shipped with the SOMobjects Toolkit), allows methods to be invoked (in a programmer-transparent way) on SOM objects that exist in a different address space from the caller.
With SOM, IBM is striving to achieve many of the same objectives that the Object Management Group (OMG) aspires to with its Common Object Request Broker Architecture (CORBA) specification. Their common goal is to facilitate the interoperation of objects independent of where they are located, the programming language in which they are implemented, or the operating system or hardware architecture on which they are running.
The distributed SOM class library is fully compliant with the CORBA spec, supporting all CORBA data types, functionality, and programming interfaces. Distributed SOM is a framework built using the SOM technology that allows developers to construct distributed-object applications. Distributed SOM does not implement a separate object model or run time, since it is built with the SOM object model and run time. Currently, fully interoperable versions of the distribution framework are available for SOM on AIX, OS/2, and Windows.
Visualize SOM as a highly optimized, single-address-space, object-request broker (ORB) that provides interlanguage interoperability and supports binary subclassing and upward binary compatibility. Using SOM, objects implemented in different languages can be combined in the same address space. SOM is fully compliant with the OMG's CORBA specification. For example, SOM classes are defined by using the CORBA Interface Definition Language (IDL), and support is available for all the CORBA data types. C-language bindings for SOM classes are compliant with CORBA (CORBA does not yet have standard bindings for C++, Smalltalk, and Cobol). SOM provides an interface repository supporting the CORBA functionality and programming interfaces.
The fact that SOM deals with object implementations distinguishes it from the narrower focus of the CORBA spec (which defines object interfaces without regard to implementation). As do other CORBA-compliant implementations, SOM extends the spec's capabilities. SOM goes beyond CORBA by supporting implementation inheritance and polymorphism, providing metaclasses that are manipulated as first-order objects, and allowing dynamic addition of methods to a class interface at run time.
How Does SOM Work?
SOM achieves cross-language interoperability by building its method-dispatch mechanism based on system-defined procedure-linkage conventions. This means that SOM follows the register- and stack- utilization conventions defined by an operating system for all programs, regardless of their implementation languages. System-linkage conventions also dictate how return values are passed from the callee back to the caller. By using the system-linkage protocol, SOM can dispatch methods independent of the language in which the executable code was written. As a result, virtually any language that supports the system procedure-call linkage conventions can use a SOM class, or can be used to implement a SOM class.
SOM accomplishes upward binary compatibility by completely encapsulating the implementation details of a class. A client calling a SOM class has no information about the size and entry points to that class compiled into its executable. Method dispatch and access to instance data is effected through a set of data structures that are computed during the construction and initialization of a class.
Two of the most important SOM data structures are the ClassData structure and the SOM method table. Because these structures are completely computed at run time, a SOM class can be modified (by refactoring the class hierarchy, moving methods up the hierarchy, or adding methods or instance data, for example) without requiring recompilation of the client code. In addition, the SOM data structures can be manipulated by the programmer at run time, giving the class implementor enormous flexibility in enhancing or controlling method dispatch.
By completely encapsulating the implementation of an object, SOM overcomes what Microsoft refers to as the "fragile base class problem"--the inability to modify a class without recompiling clients and derived classes dependent upon that class.
