In computing, the System Object Model (SOM) is an object-orientedshared library system developed by IBM. DSOM, a distributed version based on CORBA, allowed objects on different computers to communicate.
SOM defines an interface between programs, or between libraries and programs, so that an object's interface is separated from its implementation. SOM allows classes of objects to be defined in one programming language and used in another, and it allows libraries of such classes to be updated without requiring client code to be recompiled.
A SOM library consists of a set of classes, methods, static functions, and data members. Programs that use a SOM library can create objects of the types defined in the library, use the methods defined for an object type, and derive subclasses from SOM classes, even if the language of the program accessing the SOM library does not support class typing. A SOM library and the programs that use objects and methods of that library need not be written in the same programming language. SOM also minimizes the impact of revisions to libraries. If a SOM library is changed to add new classes or methods, or to change the internal implementation of classes or methods, one can still run a program that uses that library without recompiling. This is not the case for all other C++ libraries, which in some cases require recompiling all programs that use them whenever the libraries are changed, known as the fragile binary interface problem.
SOM provides an application programming interface (API) that gives programs access to information about a SOM class or SOM object. Any SOM class inherits a set of virtual methods that can be used, for example, to find the class name of an object, or to determine whether a given method is available for an object.
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]
SOMobjects were not completely shut down by IBM. They were ported to OS/390, and are still available on this OS. One can read documentation on IBM website.[2] In 1996 Tandem Computers Inc. obtained SOMobjects technology.[3] Tandem was sold to Compaq, Compaq was sold to Hewlett-Packard. NonStop DOM and some other technologies eventually merged into NonStop CORBA, but current documentation of NonStop products does not contain signs of SOM technology still powering NonStop products.
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 Copland and OpenDoc, SOM was replaced with Objective-C[4] already being in use in OPENSTEP (to become Mac OS X later). SOM/DSOM development faded, and is no longer actively developed, although it continues to be included and used in OS/2-based systems such as ArcaOS.[5]
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 opportunities missed by IBM,[6] and destructive incompatible changes:
The first version of VisualAge C++ for Windows was 3.5. It was the first and the last version to support SOM. It had SOM 2.1 bundled in and Direct-to-SOM support in the compiler. Versions 3.6.5 and later had no trace of SOM.
SOMobjects largely relied on makefiles. VisualAge C++ 4.0 introduced .icc projects and removed icc.exe and ilink.exe command line compiler and linker from supply. It is impossible to build any SOM DTK sample out of box with VAC++ 4.0. VisualAge C++ comes with its own samples, but there are no .icc SOM samples even in VAC++ 4.0 for OS/2. vacbld.exe, the only command line compilation tool, doesn't support SOM.
VisualAge C++ bundled-in Object Component Library (OCL) was not based on SOM. It was probably meant to be ported to SOM using C++ Direct-to-SOM mode, but in VAC v3.6.5 this mode was abandoned, and OCL has no SOM interface so far.
Near the end of the 1990s, IBM shut down SOMobjects download sites and never put them back online. SOM 3.0 DTK for WinNT can't be found on IBM FTP, despite much other legacy stuff lying around freely. Despite general availability of SOM 3.0 for WinNT, it was nearly impossible to locate until the end of 2012.
Finally, IBM never open-sourced SOM (as done to Object REXX), despite several articles[7][8] and petitions.[9]
Alternative implementations
Two projects of open-source SOM implementations exist. One is Netlabs Object Model (NOM), which is technically the same, but binary incompatible. Another is somFree, which is a clean room design of IBM SOM, and binary compatible. [citation needed]
Comparison of support for compiled class libraries
Historically, SOM was compared to Microsoft's Component Object Model (COM) by IBM. However, from some points of view there is no place for COM at all. From the point of view of release to release transformations, COM is on procedural level, thus, the table 1 in RRBC article (Release-to-Release Binary Compatibility referenced earlier) does not contain COM column at all. Instead, SOM is being compared to:
Most information in this table is still applicable to modern versions (as of 2015), except Objective-C 2.0 getting so called non-fragile instance variables. Some solutions remained experimental: SGI Delta/C++ or Sun OBI. Most approaches based on one programming language were phased out or were never used actively in the same way. For instance, Netscape Plugin Application Programming Interface (NPAPI) browser plugins were written using Java API initially (LiveConnect), but Java Virtual Machine (JVM) was later excluded from the chain. It can be seen as Java replaced with Cross Platform Component Object Model (XPCOM). Common Lisp Object System (CLOS) and Smalltalk are not known as being chain links like Java in LiveConnect. Objective-C is also not known much in this role and not known to be marketed this way, but its runtime is one of the most friendly to similar use cases.
Generic C++ is still being used in Qt and the K Desktop Environment (KDE). Qt and KDE are notable for describing efforts it takes to maintain binary compatibility without special support in development tools.[10]
GObject only aimed to avoid dependence on C++ compiler, but RRBC issues are the same as in generic C++.
Objective-C is the most promising competitor to SOM (although not being actively marketed as multi-language platform), and SOM should preferably be compared to Objective-C as opposed to COM as it happened historically. With non-fragile instance variables in Objective-C 2.0 it is the best alternative amongst actively supported.
COM, XPCOM are being used actively, but they only manage interfaces, not implementations, and thus are not on the same level as SOM, GObject and Objective-C. Windows Runtime under closer look behaves much like COM. Its metadata description is based on .NET, but since WinRT does not contain special runtime to resolve RRBC issues, like in Objective-C or SOM, several restrictions had to be applied that limit WinRT on procedural level:
Another restriction is that no generic public classes or interfaces can be exposed. Polymorphism isn't available to WinRT types, and the closest you can come is implementing WinRT interfaces; you must declare as sealed any classes that are publicly exposed by your Windows Runtime Component.
Comparison to COM
SOM is similar in concept to COM. 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, 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.
While SOM and COM were contrapositioned by IBM, they were not mutually exclusive. In 1995 Novell contributed ComponentGlue[11] technology to OpenDoc for Windows. This technology provided different means to integrate between COM- and SOM-based components. In particular, SOM objects can be made available to OLE2 applications by either late binding bridge (based on IDispatch) or COM interfaces having higher performance. In essence, SOM classes are implementing COM interfaces this way.
^Ira R. Forman and Scott Danforth (1999). Putting Metaclasses to Work. Addison-Wesley. ISBN0-201-43305-2. Chapter 11 "Release-to-Release Binary Compatibility", page 246 An article with identical name and similar contents of the same author can be found on the Web: Release-to-Release Binary CompatibilityArchived 2015-10-03 at the Wayback Machine
