View source for IBM System Object Model

{{short description|Programming framework}}
{{Distinguish|System Object Model (file format)}}
{{Refimprove|date=March 2013}}
{{Infobox software
|name           = IBM SOMobjects
|logo           = IBM System Object Model Logo.png
|logo alt       = IBM SOM Logo
|screenshot     = <!-- Image name is enough -->
|caption        =
|screenshot alt =
|developer      = [[IBM]]
|latest release version = 3.0
|latest release date = December 1996
|operating system = [[OS/2]], [[Microsoft Windows|Windows]], [[AIX]], [[Classic Mac OS]], [[Copland (operating system)|Copland]], [[OS/390]], [[NonStop OS]], [[OS/400]]
|genre = [[Object-oriented programming|object-oriented]] [[shared library]] system
}}

The '''System Object Model''' ('''SOM''') is an [[Object-oriented programming|object-oriented]] [[shared library]] technology developed by [[IBM]] that supports defining an [[interface (computing)|interface]] to an [[object (computer science)|object]] so that its interface is separate from its [[implementation]]. 

'''DSOM''', a [[Distributed computing|distributed]] variant based on [[CORBA]], allowed objects on different computers to communicate.

A SOM library can be updated without requiring client code to be rebuilt. If a library is changed to add new classes or methods, or to change the internal implementation of classes or methods, a consuming program can still use it without being rebuilt. In this way, SOM addresses the [[fragile binary interface problem]] that affects other library technology such as [[C++]].

SOM allows [[class (computer science)|classes]] to be defined in one [[programming language]] and used in another. A client can create and use objects from the exposed classes and derive subclasses from the exposed classes even if the client language does not support class typing.

SOM provides an [[application programming interface]] (API) that provides access to library [[metadata]]. Each object exposes methods that provide the class name and whether the object implements a particular method, for example.

==Applications==

SOM was intended to be used universally in IBM's [[Mainframe computer|mainframe]] and desktop ([[OS/2]]) computers, allowing programs designed for the desktop to use a mainframe for processing and data storage. IBM produced versions of SOM/DSOM for OS/2, [[Microsoft Windows]] and various [[Unix]] flavors (notably IBM's own [[AIX operating system|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.<ref>[http://www.edm2.com/index.php/SOM_and_Object_REXX SOM and Object REXX] by Dr. Willis Boughton (August 2004)</ref>

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.<ref>{{Cite web|url=http://www-03.ibm.com/systems/z/os/zos/library/bkserv/os390_r10pdf/#som|archive-url=https://web.archive.org/web/20140106003410/http://www-03.ibm.com/systems/z/os/zos/library/bkserv/os390_r10pdf/#som|url-status=dead|archive-date=January 6, 2014|title=SOMobjects for OS/390 documentation}}</ref> In 1996 Tandem Computers Inc. obtained SOMobjects technology.<ref>{{Cite web |url=http://www.thefreelibrary.com/Tandem+Delivers+Enterprise+Transaction+Processing+Capabilities+to...-a018607143 |title=Tandem Leverages IBM's SOMobjects Technology for Distributed Object Computing |access-date=2015-05-02 |archive-date=2016-03-05 |archive-url=https://web.archive.org/web/20160305105046/http://www.thefreelibrary.com/Tandem+Delivers+Enterprise+Transaction+Processing+Capabilities+to...-a018607143 |url-status=dead }}</ref> 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.

==Fading away==
{{Original research|section|date=July 2013}}

With the "death" of OS/2 in the mid-1990s, the ''[[wikt:raison d'être|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 (operating system)|Copland]] and [[OpenDoc]], SOM was replaced with [[Objective-C]] 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]].<ref>{{cite web|url=http://www.edm2.com/index.php/List_of_ArcaOS_5.0_WPS_Classes|title=List of ArcaOS 5.0 WPS Classes|access-date=2020-09-03}}</ref>

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]],<ref>[http://www.edm2.com/index.php/Lost_in_the_Garden Lost in the Garden] by Roger Sessions (August 1996)</ref> 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 [[makefile]]s. 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<ref>[https://archive.today/20130215180753/http://blogs.cio.com/esther_schindler/a_little_som_thing Just a little SOM thing for Linux developers] by Esther Schindler (February 2008)</ref><ref>{{cite web|url=http://www.desktoplinux.com/news/NS7822082064.html|title=Reviving OS/2's best in the Linux desktop| archive-url=https://web.archive.org/web/20100417133157/http://www.desktoplinux.com/news/NS7822082064.html |author=Steven J. Vaughan-Nichols|date=February 8, 2008|archive-date=2010-04-17}}</ref> and petitions.<ref>[https://web.archive.org/web/20070227095059/http://www.os2world.com/petition/ The OS/2 petition], second round (2007–2010)</ref>

==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|date=June 2020}}

==Comparison to compiled class libraries==
{{anchor|Comparison of support for compiled class libraries}}
<!-- Is this section valuable without the table? -->

SOM can be compared to the following compiled libraries: <ref>{{cite book|author=Ira R. Forman and Scott Danforth|title=Putting Metaclasses to Work|year=1999|publisher=Addison-Wesley |isbn=0-201-43305-2}}<br />Chapter 11 "Release-to-Release Binary Compatibility", page 246<br />An article with identical name and similar contents of the same author can be found on the Web: [http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/doc&file=R2R_SOM.zip Release-to-Release Binary Compatibility] {{Webarchive|url=https://web.archive.org/web/20151003013313/http://hobbes.nmsu.edu/h-viewer.php?dir=%2Fpub%2Fos2%2Fdoc&file=R2R_SOM.zip |date=2015-10-03 }}</ref>

* [[Smalltalk]]
* [[Common Lisp Object System]] (CLOS)
* generic [[C++]]
* SGI Delta/C++
* Sun Object Binary Interface
* [[Objective-C]]
* [[Java (programming language)|Java]]

As of 2015, most of the information in the linked table is applicable to modern versions, 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 (software)|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.<ref>{{Cite web|url=https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++|title=Policies/Binary Compatibility Issues With C++ - KDE Community Wiki|website=community.kde.org}}</ref>

[[GObject]] only aimed to avoid dependence on C++ compiler, but RRBC issues are the same as in generic C++.

Without special runtime many other programming languages will have the same issues, e.g., [[Delphi (programming language)|Delphi]], [[Ada (programming language)|Ada]]. It can be illustrated by so-called ''unprecedented approach'' it took to produce Delphi 2006 binary compatible Delphi 2007 release: [http://blogs.embarcadero.com/abauer/2007/02/24/32322 How to add a "published" property without breaking DCU compatibility] {{Webarchive|url=https://web.archive.org/web/20151208103747/http://blogs.embarcadero.com/abauer/2007/02/24/32322 |date=2015-12-08 }}

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

[[Component Object Model|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:

[https://docs.microsoft.com/en-us/cpp/cppcx/type-system-c-cx Type System (C++/CX)]

: A ref class that has a public constructor must be declared as sealed, to prevent further derivation.

[https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/windows-8-special-issue/windows-runtime-components-windows-runtime-components-in-a-net-world Windows Runtime Components - Windows Runtime Components in a .NET World]

: 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 often compared to Microsoft's [[Component Object Model|component object model]] (COM). Both support a library format that can be used from more than one language. 

Some consider SOM to be more robust since it only supports a language-neutral calling mechanism that is similar to COM [[late binding]]. COM also supports [[early binding]], a.k.a. custom interface, that is less safe although more performant. It allows a client to access an object via a function table that is compatible with [[C (programming)|C]] and therefore compatible with the binary layout of the virtual table of C++ objects (at least in Microsoft's C++ compiler). With a compatible C++ compiler, a custom interface can be defined as a pure virtual C++ class. The interface can be called by any language that can call C functions via a pointer. 

A risk of a custom interface is that an incompatibility can result in [[undefined behavior]]. In particular, if a version of the object is published with a modified custom interface, a client may crash. This is an example of the [[fragile base class]] problem. To prevent the problem, a rule for COM development is that once published, a custom interface cannot be changed. To add or change the exposed features of an object, it can implement additional custom interfaces.

SOM avoid this issue by providing only late binding {{endash}} allowing 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.

SOM is more robust in terms of supporting object-oriented (OO) features. Whereas COM essentially defines a cut-down version of C++ to program to, SOM supports almost all common features. It also supports some less common features such as [[multiple inheritance]], [[metaclass]]es and [[dynamic dispatch]]ing, which had led most SOM/COM-like systems <!--what does SOM/COM-like mean?--> to be simpler at the cost of supporting fewer languages. Multi-language support was important to IBM as they wanted to support both [[Smalltalk]] ([[single inheritance]] and [[dynamic dispatch]]) with [[C++]] ([[multiple inheritance]] and fixed dispatch).

A notable difference is support for inheritance. COM does not. Although may think it odd that Microsoft produced an object library technology that could not support such a fundamental concept of OO programming; the main reason is that it is difficult to know where a base class exists in memory where libraries are loaded in a order unknown at design time. 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 an algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches. This is the 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 [[application programming interface|API]] remains the same. This possibility exists in any program, not only those using a shared library, but a problem can become difficult to resolve if it exists in someone else's code. In SOM, the only solution is testing of new versions of libraries.

While SOM and COM were contrapositioned by IBM, they were not mutually exclusive. In 1995 Novell contributed ComponentGlue<ref>{{Cite web|url=http://www.novell.com/news/press/archive/1995/02/pr00063.html|title=Novell To Ship New OpenDoc(TM) Developer Release &#124; Micro Focus|website=www.novell.com}}</ref> technology to [[OpenDoc]] for Windows. This technology provided different means to integrate between COM and SOM 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.

Similar technologies, such as [[Distributed Objects Everywhere]], also support full inheritance. [[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]] at the cost of disk space.

==References==
<references />

{{OS/2}}

[[Category:IBM software|System Object Model]]
[[Category:Object request broker|SOM]]
[[Category:Object-oriented programming]]
[[Category:OS/2 technology|System Object Model]]