|
The System Object Model is an object-oriented shared library system developed by IBM. A distributed version based on CORBA, DSOM allowed objects on different computers to communicate.
SOM was intended to be used universally from IBM's mainframe computers right down to the desktop in OS/2, allowing programs to be written that would run on the desktop but use mainframes for processing and data storage. IBM produced versions of SOM/DSOM for OS/2, Microsoft Windows and various Unix-flavours (notably IBM's own AIX). SOM/DSOM was also an important part of the later versions of the VisualAge development platform, allowing different languages to call code in a standardized format.
Perhaps the most widespread uses of SOM within IBM was in later versions of OS/2, which used it for most code, including the Workplace Shell. With the "death" of OS/2 in the mid-1990s, the raison d'etre for SOM/DSOM largely disappeared; if users wouldn't be running OS/2 on the desktop, there would be no universal object library anyway. SOM/DSOM development faded, and is no longer actively developed.
For some time after the formation of the AIM alliance, SOM/DSOM was also used by Apple Computer for similar purposes. It was most widely used in their OpenDoc framework, but saw limited use in other roles as well. Most of these technologies were dropped in 1997 when Steve Jobs returned to Apple and ended many development efforts.
SOM is similar in concept to Microsoft's Component Object Model. Both systems address the problem of producing a standard library format that can be called from more than one language. Many disparage this concept because the vast majority of programs are written in a single language, and the language neutrality always adds overhead - sometimes considerable. Yet it is imporant to note that even a single language from different vendors, or even different versions of the same complier, may use incompatible formats.
SOM is considerably more robust than COM. COM builds a list of the variables and methods in the library in a fixed table, which is not resistant to change. A new version of the library may change the layout of this table, yet the programs were compiled "knowing" the old layout. This is an example of the fragile base class problem, known in this case as DLL hell when a new version of a library is installed and all programs based on the older version crash. SOM addressed these issues by providing much more information in the library, to allow the run-time linker to re-build the table on the fly. This way changes to the underlying libraries are resolved when they are loaded into programs, although there is a small cost at load-time.
SOM is also much more robust in terms of fully supporting a wide variety of OO languages. Whereas COM essentially defines a cut-down version of C++ to program to, SOM supports almost all common features and even some more esoteric ones. For instance SOM supports multiple-inheritance, meta-classes and dynamic dispatching. Some of these features are not found in most languages, which had led most SOM/COM-like systems to be simpler at the cost of supporting fewer languges. The full flexibility of multi-language support was important to IBM, however, as they had a major effort underway to support both Smalltalk (single-inheritance, dynamic-dispatch) with C++ (multiple-inheritace, fixed-dispatch).
The most notable difference between SOM and COM is support for inheritance -- COM doesn't have any. It might seem odd that Microsoft produced an object library system that could not support one of the most fundamental concepts of OO programming, but they did have their reasons. The main issue is that it is difficult to know where a base class exists in a system where libraries are loaded in potentially random order. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle (at least in other COM libraries).
SOM instead uses a simple algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches; this is the basic idea behind inheritance in most cases. The downside to this approach is that it is possible that new versions of this base class may no longer work even if the API remains the same. This possibility exists in any program, not only those using a shared library, but problem can become very difficult to track down if it exists in someone else's code. In SOM only solution is extensive testing of new versions of libraries, which is not always easy.
The flexibility offered by SOM was considered worth the trouble by almost all, and it is worth noting that similar systems, such as Sun Microsystems' Distributed Objects Everywhere also supported full inheritance. NeXT's Portable Distributed Objects avoided these issues via a strong versioning system, allowing library authors to ship new versions along with the old, thereby guarenteeing backward compatibility for the small cost of disk space.
External Links - - compares MS's and IBM's approaches to the object library system in terms of inheritance
| 
Feeds |
Contact