Why SOM?

From EDM2
Jump to: navigation, search

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

By Brian Curran

In this article, Brian Curran overviews IBM's System Object Model (SOM) to give you a better understanding of its impact on you, whether or not you're an application developer. After defining SOM in detail, he highlights its technical strengths and significance in the marketplace.

SOM stands for IBM’s System Object Model. For most of you, that’s probably a cryptic term. So you may be asking the following questions:

  • I’ve heard of SOM, but does it really impact me?
  • What’s so special about this technology called SOM?
  • What benefits does SOM provide me as a software developer?

This article answers these questions, including why SOM technology impacts you, whether or not you are a software developer. Other SOM-related articles in this issue describe how to use SOM, including:

  • Integrating SOM with other languages: VisualAge Smalltalk and VisualAge COBOL - both using the same Valet class library
  • Using a feature called Direct-to-SOM that enables a programmer to define SOM objects with C++ instead of IDL
  • Using SOM's distributed component, called DSOM (Distributed SOM)
  • Glimpsing the future of SOMobjects 3.0 Object Services. (Note: The information provided in these "future" articles is from the SOMobjects 3.0 beta and is therefore subject to change.)

The goal for all of these SOM-related articles is simple - we want to pique your curiosity and raise your overall awareness of SOM technology. In this issue, we present a relatively small amount of information regarding SOM. Each topic uncovers only the tip of the iceberg. Much more information exists - it just won’t fit within the covers of this magazine. Our hope is that after seeing the tip of the iceberg, you will want to discover all of SOM's benefits.

What is SOM?

At the highest level, SOM is a language neutral, object-oriented programming technology for building, packaging, and manipulating binary class libraries that can share objects across address spaces. Whew! I'll elaborate on this definition, overview the technical merits of SOM, and describe why an application developer might use SOM later in this article. First, I want to demonstrate SOM's significance by identifying just a few of today's leading edge technologies that incorporate SOM's benefits.

OS/2's Workplace Shell

The Workplace Shell (WPS), OS/2's user interface, uses SOM technology. Every user interface object on the WPS is a true SOM object, and many of the WPS's dynamic capabilities are provided due to SOM's technological underpinnings.

Workplace Shell Applications and Tools

Many applications are WPS-enabled, meaning that you interact with the application using WPS objects (which are SOM objects). To provide WPS extensions or tools, developers use SOM technology when developing their software.


SOM, the object model CILabs (Component Industry Laboratories) selected specifically for OpenDoc technology, provides a packaging technology for OpenDoc components. Larry Loucks, vice president of software for IBM Personal Software Products, states "SOM just gets us plumbing. We spent a lot of time up front getting out a couple releases of this stuff to make sure we have a good understanding of the infrastructure before we get to the killer, which is component software... our approach to that is OpenDoc." as reported by Orfali, Harkey, & Edwards in their book, The Essential Distributed Objects Survival Guide. Orfali, Harkey, & Edwards communicate the dramatic potential of SOM: "As an integral part of OpenDoc, SOM will ship with every copy of OS/2 Warp, Macintosh, and AIX. This means SOM will become the first high-volume CORBA [Common Object Request Broker Architecture] ORB [object request broker]..." The authors conclude, "It will take some time before programmers get accustomed to the idea that a full-function SOM ORB is shipped with every OpenDoc runtime." It is important to note that the platform support for SOM is much broader than the initial support for OpenDoc, which is a positive statement regarding OpenDoc. With SOM support on additional platforms (such as AS/400, MVS, and others), OpenDoc components will be able to exploit SOM’s distributed capabilities and communicate with distributed objects on these additional platforms.

OS/2 SOM-Compliant Products

A scan of recent computer technology magazines revealed a large number of advertisers claiming SOM-compliant programs. Figure 1 lists a few of the products employing SOM technology.

Product Manufacturer
JBA Guidelines JBA International
ChipChat ChipChat Technology Group
Object Desktop Stardock Systems
Unite Objects Cirrus Technology
KidProof/2 Pinnacle Technology
HyperACCESS Hilgraeve
DeskMan/2 Development Technologies
VX-REXX Watcom
VisualAge C++ IBM
High C/C++ Toolset MetaWare

Figure 1. Sampling of SOM Technology Products

Whether or not you are interested in the ensuing technical section, the emerging technologies and large number of products employing SOM technology hopefully convince you of its importance. Now, let's take a look at why so many applications are employing SOM technology.

SOM's Technical Highlights

Remember that impressive definition of SOM earlier in the article? At the highest level, SOM is a language neutral, object-oriented programming technology for building, packaging, and manipulating binary class libraries that can share objects across address spaces. Depending upon your perspective, that definition either has dramatic impact or provides very little meaning. Let's examine each part of this definition.

Language Neutral

SOM is language neutral, meaning that SOM class users and creators don't have to use the same programming language. For example, a client application need not be written in C++ to create, manipulate, and delete a SOM object implemented in C++.

SOM does not replace existing object-oriented languages; rather, it complements them so that application programs written in different programming languages can share common SOM class libraries, such as the Valet class library.

Note: SOM's language neutral capabilities are demonstrated in accompanying articles. The Valet and associated classes are implemented using C++, whereas the client programs demonstrated are VisualAge C++, VisualAge Smalltalk, and VisualAge COBOL.

Object-Oriented Programming

Entire books are written on object-oriented programming. Most of these books identify three key characteristics when determining the merits of an object-oriented environment: encapsulation, inheritance, and polymorphism. SOM fully supports all three characteristics.

Many of SOM's original design points were introduced as a better way to package object-oriented technology. All software environments have shortcomings, but SOM solves many of the deficiencies introduced by other object-oriented technologies, such as the fragile base class problem introduced by C++. In addition, SOM combines the strengths of various object technologies into one environment. Like Smalltalk, SOM supports class objects and name resolution method dispatching. Like C++, SOM supports multiple inheritance and provides strong type-checking. If you are interested in object technology, I strongly recommend that you study SOM technology.

Building, Packaging, and Manipulating

When using SOM technology to build, package, and manipulate class libraries, you will circumvent many of the deficiencies introduced by other object technologies. For example, SOM can be used with C++ to provide upwardly compatible class libraries.

Upwardly Compatible Class Libraries

You can release a new version of a SOM class, and as long as no changes to the client’s source code are required, the client code does not have to be recompiled. For example, let’s say you have a brainstorm and can now rewrite your GrainsOfSandOnBeach() method with a couple of new instance variables. When you re-release your Beach class library, none of the clients will need to recompile since the public interface remains the same. (This is the way object-oriented programming is supposed to work.)

SOM accommodates changes in implementation details without breaking the binary interface to a class library or requiring client programs to be recompiled. Specifically, you can make the following changes to SOM classes and still retain full backward, binary compatibility:

  • Add new methods
  • Change an object's size by adding or deleting instance variables
  • Insert new parent classes above a class in the inheritance hierarchy
  • Relocate methods upward in the class hierarchy

In contrast, most changes to a C++ class library, including adding or removing private instance variables, require client code to be recompiled. Keep in mind that the public interface does not have to change to force a recompilation. The C++ recompilation requirement seems trivial until you consider the following two scenarios.

Scenario 1: Your enterprise solution includes a single C++ class library that contains functions for eight applications located on 3,000 desktops. Your CIO requires that additional information be tracked, mandating a single additional instance variable and associated accesser methods. You now face the unenviable task of updating the class library, recompiling all eight applications, and redeploying 17 MB of code (eight applications at 2 MB per application plus 1 MB for class library) to 3,000 desktops. In reality, the eight applications are each in a different phase of development, and it is highly unlikely that all eight would be deployed at the same time, thereby increasing complexity.

If your class library is implemented using SOM, your workload is significantly reduced. Only the single 1 MB class library needs to be redeployed to all of the workstations. Your existing applications will not need to be recompiled and will work with the new SOM class library. Deploying a single 1 MB class library is simpler and less resource-intensive.

Scenario 2: You are a vendor of a Valet class library and have sold copies to 1,000 application developers. Hypothetically, these application developers build applications for managing all of the parking garages throughout the world. You now have a new version of the class library that incorporates bug fixes, performance enhancements, and increased functionality from a variety of new classes to support long-term parking.

Let's assume 100 of your clients are leading-edge application developers. They will be the first to extend their applications to support the library's new long-term parking feature. Obviously, the client applications will need to be recompiled to include the enhanced functionality. But what about the other 90 percent of your clients? Will they need to recompile their applications even if they don't need the functionality?

Assuming the Valet class is implemented in C++, the answer is yes. Unfortunately, developers will be forced to recompile their applications, even if their only goal is to obtain the bug fixes and performance enhancements. Of course, they could decide to ignore the update (at a cost of running with known bugs).

Assuming the Valet class is implemented using SOM, the answer to the previous question is no. Recompilation by the other 90 percent of the clients will not be required. The same Valet class library will support the applications with the enhanced long-term parking as well as the existing applications written when the Valet class library did not have the long-term parking feature. SOM's upwardly compatible class libraries provide this support.

Binary Class Libraries

SOM lets you deliver your class libraries in binary format. In layman’s terms, this means that as the producer of a SOM class library, you are able to keep proprietary information proprietary. In delivering a SOM class library, you provide two files: the DLL containing your class implementation and the IDL file containing the interface description. With these two files, any individual using a language that supports SOM can instantiate objects based upon the class library or designate the delivered classes as sub-classes and provide specializations! (Yes, our good friend, language neutrality, described earlier, allows a SOM class implemented in C++ to be extended and derived in a completely separate language.)

In contrast to delivering a SOM class in binary format, C++ programmers usually take the lesser of two evils and deliver the source code along with the class library. Few software engineers are accustomed to delivering source code as part of a procedural function library, but this practice is actually common with C++ class libraries. The alternative is too much of an administrative nightmare. If a class library provider chooses to withhold the source code, then the class library provider is making the decision to develop, test, ship, and track an instance of the class library for each of the C++ compilers on the market today. And when you consider the need for maintaining multiple versions for each instance of the class library, the task is even more daunting.

Share Objects Across Address Spaces

Now, let's look at the last part of the SOM definition. In an ideal software vacuum, objects would be ubiquitous and the benefits of object-oriented technologies would be enjoyed by all. Realizing there is no such vacuum, an object system of even minor complexity must cross the dreaded procedural boundary one or more times, whether it’s to an operating system-specific service, a communications API, or some other type of legacy interface.

For those who believe in the benefits of objects (or at least who believe in the potential for making profits with objects), the race is on to extend the procedural boundary--one of the reasons why we see such a proliferation of class libraries in today’s environments. Initially, there was tremendous emphasis on providing an object-oriented abstraction for GUI programmers. Disparity arose, however, when elegant user interfaces were being developed and programmers were still coding linked lists. Thus, we now have robust collection classes that should free up the technical resources from coding linked lists. Slowly but surely, the procedural boundaries are being extended to further and further extremities of software systems. The move to distributed objects is a natural progression of the desire to further extend the procedural boundaries. There are two reasons why you will want to share objects across address spaces:

  • Objects make sense in client software, so they will also make sense in server software
  • Objects on the client should be able to communicate with objects on the server

DSOM, SOM’s distribution component, lets you share objects across address spaces, either in the same machine or across the network. DSOM simply adds distributed capabilities to the benefits already inherent in SOM classes. DSOM also conforms with the Object Management Group’s CORBA standards. More information regarding DSOM is provided in "Distributing Objects with Distributed SOM" in this issue.

Why Use SOM in Your Application Development?

If you aren't convinced by now, here are my top 10 reasons for using SOM in your application development:

  1. To develop a WPS application or tool
  2. If you work for an object technology center and keep two object models--one for the C++ folks and one for the Smalltalk folks
  3. To understand deficiencies of other OO environments
  4. To develop component-based software, specifically using OpenDoc
  5. If you want object-oriented code on your clients as well as your large system hosts
  6. If you don't want to ship your proprietary source code
  7. If you are tired of forcing all of your clients to recompile when you change your class
  8. To develop a class library and expand your market potential beyond a single language, compiler, and platform
  9. If you are interested in the promises of CORBA and want to develop distributed object systems
  10. If you want to use a real system object model!


In this article, I've attempted to:

  • Introduce SOM technology and show its impact on you, whether or not you are an application developer. With a better appreciation of SOM technology, you can be a more informed purchaser of application software.
  • Provide an overview of SOM’s technical highlights, as well as its technical strengths.
  • Assist you in understanding when you should use SOM technology in your application development.

You'll find more concrete details in the remaining SOM articles in this issue. If you are familiar with C++ and Smalltalk, SOM looks different. But, then again, both C++ and Smalltalk looked quite different when I first saw each. So keep after it; you should be up and running with a minimal amount of effort.


  • The Essential Distributed Objects Survival Guide. Robert Orfali, Dan Harkey, Jeri Edwards; John Wiley & Sons, 1996. ISBN 0-471-12993-3.
  • Programmer's Guide, Volume I: SOM and DSOM. SOMobjects Developer Toolkit. SOMobjects Version 3.0 beta.
  • Programmer's Guide, Volume II: Object Services. SOMobjects Developer Toolkit. SOMobjects Version 3.0 beta.