An Overview of SOM and the SOMobjects Toolkit

The System Object Model (SOM) is a new object-oriented programming technology for building, packaging, and manipulating binary class libraries.

• With SOM, class implementers describe the interface for a class of objects (names of the methods it supports, the return types, parameter types, and so forth) in a standard language called the Interface Definition Language, or IDL.

• They then implement methods in their preferred programming language (which may be either an object-oriented programming language or a procedural language such as C).

This means that programmers can begin using SOM quickly, and also extends the advantages of OOP to programmers who use non-object-oriented programming languages.

A principal benefit of using SOM is that SOM accommodates changes in implementation details and even in certain facets of a class ' interface, without breaking the binary interface to a class library and without requiring recompilation of client programs. As a rule of thumb , if changes to a SOM class do not require source-code changes in client programs, then those client programs will not need to be recompiled. This is not true of many object-oriented languages, and it is one of the chief benefits of using SOM. For instance, SOM classes can undergo structural changes such as the following, yet retain full backward, binary compatibility:

• Adding new methods,

• Changing the size of an object by adding or deleting instance variables,

• Inserting new parent (base) classes above a class in the inheritance hierarchy, and

• Relocating methods upward in the class hierarchy.

In short, implementers can make the typical kinds of changes to an implementation and its interfaces that evolving software systems experience over time.

Unlike the object models found in formal object-oriented programming languages, SOM is language-neutral. It preserves the key OOP characteristics of encapsulation, inheritance, and polymorphism, without requiring that the user of a SOM class and the implementer of a SOM class use the same programming language. SOM is said to be language-neutral for four reasons:

• All SOM interactions consist of standard procedure calls. On systems that have a standard linkage convention for system calls, SOM interactions conform to those conventions. Thus, most programming languages that can make external procedure calls can use SOM.

• The form of the SOM Application Programming Interface, or API (the way that programmers invoke methods, create objects, and so on) can vary widely from language to language, as a benefit of the SOM bindings. Bindings are a set of macros and procedure calls that make implementing and using SOM classes more convenient by tailoring the interface to a particular programming language.

• SOM supports several mechanisms for method resolution that can be readily mapped into the semantics of a wide range of object-oriented programming languages. Thus, SOM class libraries can be shared across object-oriented languages that have differing object models. A SOM object can potentially be accessed with three different forms of method resolution:

  • Offset resolution: roughly equivalent to the C++ "virtual function" concept. Offset resolution implies a static scheme for typing objects, with polymorphism based strictly on class derivation. It offers the best performance characteristics for SOM method resolution. Methods accessible through offset resolution are called static methods, because they are considered a fixed aspect of an object's interface.

  • Name-lookup resolution: similar to that employed by Objective-C and Smalltalk. Name resolution supports untyped (sometimes called "dynamically" typed) access to objects, with polymorphism based on the actual protocols that objects honor. Name resolution offers the opportunity to write code to manipulate objects with little or no awareness of the type or shape of the object when the code is compiled.

  • Dispatch-function resolution: a unique feature of SOM that permits method resolution based on arbitrary rules known only in the domain of the receiving object. Languages that require special entry or exit sequences or local objects that represent distributed object domains are good candidates for using dispatch-function resolution. This technique offers the highest degree of encapsulation for the implementation of an object, with some cost in performance.
  4.
  SOM conforms fully with the Object Management Group's (OMG) [ OMG is an industry consortium founded to advance the use of object technology in distributed, heterogeneous environments] Common Object Request Broker Architecture (CORBA) standards. In particular,

  • Interface to SOM classes are described in CORBA's Interface Definition Language, IDL, and the entire SOMobjects Toolkit supports all CORBA-defined data types.

  • The SOM bindings for the C language are compatible with the C bindings prescribed by CORBA.

  • All information about the interface to a SOM class is available at run time through a CORBA-defined "Interface Repository."

  SOM is not intended to replace existing object-oriented languages. Rather, it is intended to complement them so that application programs written in different programming languages can share common SOM class libraries. For example, SOM can be used with C++ to do the following:

  • Provide upwardly compatible class libraries, so that when a new version of a SOM class is released, client code needn't be recompiled, so long as no changes to the client's source code are required.

  • Allow other language users (and other C++ compiler users) to use SOM classes implemented in C++.

  • Allow C++ programs to use SOM classes implemented using other languages.

  • Allow other language users to implement SOM classes derived from SOM classes implemented in C++.

  • Allow C++ programmers to implement SOM classes derived from SOM classes implemented using other languages.

  • Allow encapsulation (implementation hiding) so that SOM class libraries can be shared without exposing private instance variables and methods.

  • Allow dynamic (run-time) method resolution in addition to static (compile-time) method resolution (on SOM objects).

  • Allow information about classes to be obtained and updated at run time. (C++ classes are compile-time structures that have no properties at run time.)

  ---

  [Back: Background]
  [Next: The SOM Compiler]