IBM System Object Model
| Company type | Software framework |
|---|---|
| Industry | Computer software |
| Founder | IBM |
| Products | Object-oriented programming shared libraries, SOM/DSOM |
| Parent | IBM |
The System Object Model (SOM) is an object-oriented programming shared library framework created by IBM that distinctly separates an object's interface from its underlying implementation.
A distributed computing adaptation called DSOM, built upon CORBA, facilitated interaction between objects residing on separate machines.
SOM libraries offer the advantage of being updatable without necessitating recompilation of client applications. Enhancements such as adding new classes or methods, or modifying internal workings, do not disrupt compatibility, effectively resolving the fragile binary interface problem frequently encountered in technologies like C++.
The model enables defining classes in one programming language while allowing their utilization in another. This flexibility permits clients to instantiate and extend objects even if their language lacks inherent class typing capabilities.
Additionally, SOM provides an API that exposes library metadata, enabling objects to disclose their class names along with the methods they support.
Applications
IBM developed SOM to serve as a universal technology across its mainframe and desktop (OS/2) environments, allowing desktop software to take advantage of mainframe processing power and storage resources. Versions of SOM/DSOM were released for OS/2, Microsoft Windows, and several Unix platforms, including IBM’s own AIX. Following the establishment of the AIM alliance, Apple adopted SOM/DSOM primarily within its OpenDoc architecture.
Within IBM’s ecosystem, SOM was deeply integrated into later iterations of OS/2, notably within the Workplace Shell. On OS/2, Object REXX supports SOM classes and objects, enabling automation of WPS components.
IBM maintained support for SOMobjects on OS/390, where it continues to be available alongside official documentation. In 1996, Tandem Computers acquired the SOMobjects technology; subsequent acquisitions by Compaq and Hewlett-Packard led to the integration of NonStop DOM and related technologies into NonStop CORBA. Nonetheless, current NonStop product materials no longer mention SOM technology.
Fading away
The decline of OS/2 in the mid-1990s effectively eliminated the primary use case for SOM/DSOM; without OS/2 desktops, this universal object library lost its central role. In 1997, after Steve Jobs returned to Apple and discontinued initiatives such as Copland and OpenDoc, SOM was supplanted by Objective-C, which was already employed in OPENSTEP (the predecessor to Mac OS X). Consequently, development on SOM/DSOM ceased and it is no longer actively maintained, though it remains part of OS/2-based distributions like ArcaOS.
Despite the downturn of OS/2 and OpenDoc, SOM showed promise for Windows and cross-platform development. A version 3.0 release for WinNT appeared in December 1996. However, IBM missed critical opportunities and introduced incompatible modifications that impeded broader adoption:
- VisualAge C++ for Windows 3.5 was the sole version supporting SOM, including SOM 2.1 with Direct-to-SOM compiler integration; subsequent editions removed all SOM support.
- VisualAge C++ 4.0 replaced makefile-driven builds with .icc project files and eliminated command-line utilities essential for SOM development, preventing straightforward compilation of SOM examples.
- The bundled Object Component Library (OCL) was not built on SOM and abandoned Direct-to-SOM support by version 3.6.5, restricting integration capabilities.
- IBM discontinued SOMobjects download portals in the late 1990s without reinstating them; as a result, obtaining SOM 3.0 DTK for WinNT became nearly impossible until rediscovered around 2012.
- Unlike with Object REXX, IBM never open-sourced SOM despite community interest and petitions requesting its release.
These elements collectively contributed to the waning relevance of SOM despite its technical strengths and potential for cross-platform use.
Alternative implementations
There are two open-source versions of SOM available: Netlabs Object Model (NOM), which is functionally equivalent but not binary compatible, and somFree, a clean-room reimplementation of IBM SOM that maintains binary compatibility.
Comparison to compiled class libraries
SOM can be contrasted with compiled library systems such as Smalltalk, the Common Lisp Object System (CLOS), generic C++, SGI Delta/C++, Sun Object Binary Interface, Objective-C, and Java.
As of 2015, most details about these technologies remain applicable, except for Objective-C 2.0 introducing non-fragile instance variables. Some frameworks like SGI Delta/C++ and Sun OBI continue to be experimental. Language-specific solutions have mostly declined; for instance, Netscape Plugin API initially utilized Java LiveConnect but later transitioned from the JVM to the Cross Platform Component Object Model (XPCOM). Unlike Java in LiveConnect, CLOS and Smalltalk have rarely served as integration layers. Despite limited promotion in this domain, Objective-C’s runtime offers strong support for similar functionalities.
Generic C++ remains in use within Qt and KDE projects, which highlight the complexities of preserving binary compatibility without dedicated tools. GObject aims to circumvent reliance on C++ compilers but encounters comparable release-to-release binary compatibility (RRBC) challenges as generic C++. Other languages such as Delphi and Ada face similar issues; notably, Delphi implemented an unprecedented strategy to sustain binary compatibility between its 2006 and 2007 releases.
Objective-C stands out as SOM’s most viable rival, particularly with the introduction of non-fragile instance variables in version 2.0, positioning it as the leading actively maintained alternative. Historically, SOM was more frequently compared to Objective-C than to COM.
COM and XPCOM focus on managing interfaces rather than implementations, placing them below SOM, GObject, and Objective-C in terms of capabilities. Windows Runtime (WinRT) shares similarities with COM but lacks a runtime environment to address RRBC problems like those managed by SOM or Objective-C. Consequently, WinRT enforces constraints that limit procedural flexibility: public classes with constructors must be sealed to prevent subclassing; generic public classes or interfaces are disallowed; and polymorphism is confined strictly to interface implementation.
Comparison to COM
SOM is frequently compared with Microsoft’s COM, as both facilitate multi-language library formats.
Some consider SOM more robust because it exclusively employs a language-neutral calling convention akin to COM’s late binding. COM also supports early binding via custom interfaces, offering faster performance but reduced safety by allowing direct access through function tables compatible with C and C++ virtual tables. However, custom interfaces risk undefined behavior if altered after release, potentially causing client crashes—a manifestation of the fragile base class problem. To mitigate this risk, COM mandates that custom interfaces remain unchanged once published; new features must be introduced through additional interfaces.
SOM circumvents this issue by relying solely on late binding, enabling the runtime linker to dynamically rebuild function tables and resolve changes when libraries load.
SOM provides broader object-oriented capabilities than COM, including support for multiple inheritance, metaclasses, and dynamic dispatch. This extensive OO feature set allowed IBM to support multiple languages such as Smalltalk (which uses single inheritance and dynamic dispatch) and C++ (which employs multiple inheritance and fixed dispatch).
A fundamental distinction lies in inheritance support: COM does not accommodate inheritance due to difficulties in locating base classes at runtime. It requires specifying base classes at compile time, preventing insertion of derived classes within the hierarchy after compilation.
Conversely, SOM employs an algorithm that traverses the inheritance tree at runtime to find base classes until a match is discovered, aligning with conventional OO inheritance models. Nonetheless, this approach can cause compatibility issues if base classes change despite stable APIs, necessitating comprehensive testing of new library versions.
Although IBM positioned SOM and COM as competitors, they were not mutually exclusive technologies. In 1995, Novell contributed ComponentGlue technology to OpenDoc for Windows to facilitate interoperability between COM and SOM components. SOM objects could be accessed within OLE2 applications via late binding bridges (IDispatch) or through higher-performance COM interfaces—effectively implementing COM interfaces.
Comparable systems such as Distributed Objects Everywhere also support full inheritance. Meanwhile, Portable Distributed Objects tackled compatibility by employing strong versioning strategies that allow multiple library versions to coexist for backward compatibility at the expense of increased disk usage.