IBM System Object Model

For the similarly named executable file format in the HP-UX operating system, see System Object Model (file format)
IBM SOM Logo

In computing, the System Object Model (SOM) is an object-oriented shared library system developed by IBM. DSOM, a distributed version based on CORBA, allowed objects on different computers to communicate.

Applications

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). 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.

Perhaps the most widespread uses of SOM within IBM were in later versions of OS/2, which used it for most code, including the Workplace Shell. Object REXX for OS/2 is able to deal with SOM classes and objects including WPS.[1]

Reasons for failure

With the "death" of OS/2 in the mid-1990s, the raison d'être for SOM/DSOM largely disappeared; if users would not be running OS/2 on the desktop, there would be no universal object library anyway. In 1997, when Steve Jobs returned to Apple and ended many development efforts including OpenDoc, SOM/DSOM development faded, and is no longer actively developed.

Despite effective "death" of OS/2 and OpenDoc, SOM could have yet another niche: Windows and cross-platform development. SOM 3.0 for WinNT was generally available in December 1996. The reasons for not advancing in these directions go beyond market adoption problems. They involve not only opportunities missed by IBM[2] but also indeed destructive incompatible changes:

Alternative implementations

Exists two projects of open-source SOM implementation. One is Netlabs Object Model (NOM) which is technically same, but not binary compatible. Another implementation is somFree which is clean room implementation of IBM SOM with binary compatibility.

Comparison to other object models

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. SOM can be considered more robust than COM. COM offers two methods of accessing methods onto an object, and an object can implement either one of them or both. The first one is dynamic and late binding (IDispatch), and is language-neutral similar to what is offered by SOM. The second one, called a Custom Interface, is using a function table which can be built in C but is also directly compatible with the binary layout of the virtual table of C++ objects in Microsoft's C++ compiler. With compatible C++ compilers, Custom Interfaces can therefore be defined directly as pure virtual C++ classes. The resulting interface can then be called by languages that can call C functions through pointers. Custom Interfaces trade robustness for performance. Once an interface is published in a released product, it can not be changed, because client applications of this interface were compiled against a specific binary layout of this interface. This is an example of the fragile base class problem, which can lead to DLL hell, as a new version of a shared library is installed and all programs based on the older version can stop functioning properly. To prevent this problem, COM developers must remember to never change an interface once it is published, and new interfaces need to be defined if new methods or other changes are required.

SOM prevents these issues by providing only late binding, 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 performance cost.

SOM is also much more robust in terms of fully supporting a wide variety of OO languages. Whereas basic 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, metaclasses 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 languages. 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 and dynamic dispatch) with C++ (multiple inheritance and fixed dispatch).

The most notable difference between SOM and COM is support for inheritance—COM does not 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; the main reason for this is that it is difficult to know where a base class exists in a system where libraries are loaded in a 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 a problem can become very difficult to track down if it exists in someone else's code. In SOM, the 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 , but 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 guaranteeing backward compatibility for the small cost of disk space.

Creators

SOM 3.0 DTK for OS/2 contains bin\sc.exe. sc.exe contains following strings:

SOMObjects Kernel Toolkit
Compiler: Andy Martin.
Runtime: Larry Raper, Scott Danforth, Mike Conner.
Bindings: Andy Martin, Larry Raper, Mike Conner.
C++ Bindings: Scott Danforth, Andy Martin.
Interface Repository: Larry Raper, Dave Hock.
Emitter Framework: Mike Conner, Liane Acker, Andy Martin.
Other tools: Andy Martin, Liane Acker.

Not mentioned in sc.exe:
Metaclass Framework: Ira R. Forman, Scott Danforth

References

  1. ↑ SOM and Object REXX by Dr. Willis Boughton (August 2004)
  2. ↑ Lost in the Garden by Roger Sessions (August 1996)
  3. ↑ Just a little SOM thing for Linux developers by Esther Schindler (February 2008)
  4. ↑ Reviving OS/2's best in the Linux desktop by Steven J. Vaughan-Nichols (February 2008)
  5. ↑ The OS/2 petition, second round (2007–2010)

External links