featuresmatrix intro page0. Intended Use
1. Basic Concepts
SOM (System Object Model) is a library packaging technology that enableslanguages to share class libraries regardless of the language they werewritten in. This ability to share class libraries between various objectoriented languages solves many interoperability and re-use problems betweenobject oriented and non object oriented languages as well.
Key characteristics of SOM in support of these key commercial requirementsinclude:
- the ability to create portable shrink wrapped binaries
- the ability to create class libraries in one language that can beaccessed and used by other languages
- the ability to subclass from binaries even if they were written ina different language
- the ability to add new methods and relocate existing methods withoutre-compilation of the application
- the ability to insert new classes into the inheritance hierarchy withoutrecompiling the application.
SOM provides an object model distinct from those contained in objectoriented programming languages yet does not interfere with the use of thosemodels in the same application that is using SOM. In addition, SOM canbe used with procedural programming languages thus providing an objectmodel for those languages that do not have one.
SOM consists of an Interface Definition Language (with an accompanyingcompiler), a run-time environment with procedure calls, and a set of enablingframeworks.
SOM is an IBM technology that is being licensed to other companies inanticipation of extending its benefits to heterogeneous environments. Inaddition, a number of language vendors are working on providing nativeSOM capability for their compilers.
2. Objects
SOM objects are derived from a root object which defines the essentialbehavior common to all SOM objects. Factory methods are used to createSOM objects at run time. These factory methods are invoked on a class object,in the SOM run-time.
2.1 Operations
The interface to a SOM object is defined by permitting the specificationof operation signatures which consist of an operation name and the argumentand result types. Operations are performed on methods which implement anobjects behavior.
2.2 requests
Client requests are invoked on objects by specifying the name of anobject and the name of the operation along with parameters to invoke onit. An object can support multiple operations.
2.3 messages
Messages are not explicitly identified in SOM.
2.4 specification of behavioral semantics
SOM defines object behavior by permitting the specification of operationsignatures which consist of an operation name, and the argument and resulttypes. The semantics of the operations on an object are defined by themethods that implement these operations.
2.5 methods
Methods are invoked on SOM objects. Methods can be relocated upwardin the class hierarchy without requiring the client to be re-compiled.SOM supports three different method dispatching mechanisms; offset, nameresolution, and dispatch function resolution.
The "offset resolution" mechanism implies a static schemefor typing objects and is roughly equivalent to the C++ virtual functionconcept. It offers the best performance characteristics for SOM methodresolution at a cost of some loss in flexibility.
This form of method resolution supports polymorphism that is based onthe derivation of the object's class.
Name resolution supports access to objects whose class is not knownat compile time, and permits polymorphism based on the protocols that anobject supports, rather than its derivation.
The "dispatch function" resolution is a feature of SOM thatpermits method resolution to be based on arbitrary rules known only inthe domain of the receiving object.
Dispatch function resolution is a completely dynamic mechanism thatpermits run time type checking, and open-ended forms of polymorphism.
A distinguishing feature of SOM is that all 3 forms of method resolutionare complementary and can be intermixed within client programs.
2.6 state
The state of SOM objects is accessed through published interfaces toan object. Invoking operations on objects may cause state changes.
2.7 object lifetime
SOM objects are created by invoking a create operation on a factoryobject in the SOM run time. Once created, the object will exist until explicitlydeleted or until the process that created it no longer exists. A SOM objectwould need to make use of a persistence mechanism in order to exist beyondthe life of the process that created it. A persistence mechanism is beyondthe scope of this object model discussion, however, SOM could be and hasbeen used as the basis for building a variety of persistence frameworks.
2.8 behavior/state grouping
SOM uses the classical object model in that a target object must bespecified for each operation.
2.9 communication model
Since SOM is a basic mechanism, its run-time model is one where an operationoccurs on a single thread within a single process. However, SOM code permitsconcurrent execution by multiple threads on systems where SOM supportsthe underlying threads model, therefore, multi-threaded programs can usemutual exclusion mechanisms to serialize updates to SOM objects with confidencethat critical sections in SOM are thread safe.
Complex object interactions that need to span process boundaries canbe constructed on SOM using standard inter-process communication facilitiesprovided by the underlying system. No serialization code is necessary ifprogramming in a single thread , single process model.
A class library based on SOM is used to provide SOM with distributedaccess to remote SOM objects.
2.10 events
2.11 transition rules
3. Binding
SOM provides support for both early and late binding. These bindingchoices are on a per method bases. See entry under 2.5 methods fora discussion of different method invocation models.
4. Polymorphism
The polymorphism provided by SOM depends on the method dispatching schemeselected. If "offset resolution" is used then a static schemefor typing objects is used and polymorphism is based strictly on classinheritance. If the "name resolution" method dispatching is usedthen methods are located dynamically and polymorphism is based on the actualprotocols that objects honor.
5. Encapsulation
Access to the state of SOM objects is through the operations that makeup the objects interface. Invoking operations on SOM objects can have sideeffects. SOM objects do have private data that is not accessible by invokingexternal operations. In addition, it is possible to define class attributeson SOM objects. These attributes are accessed via set and get functionsimplemented for each attribute and are invoked in the same way as methods.
6. Identity, Equality, Copy
When a SOM object is created the SOM run-time returns a pointer to theobject. It is left to higher level abstractions which build on SOM to defineobject identity, equality and copy operations.
7. Types and Classes
The SOM description for "types and classes" is essentiallythe same as that described in the OODBTG Reference Model entry in thissection in that a "type" defines a protocol shared by a groupof objects, called "instances" of the type and a class definesan implementation shard by a group of objects.
In SOM, all objects are derived from a SOM root object which definesthe essential behavior common to all SOM objects. In addition, SOM hasa root class for all SOM metaclasses which defines the essential behaviorcommon to all SOM classes. The SOM metaclasses define factory methods thatmanufacture objects of any class for which they are the metaclass.
8. Inheritance and Delegation
A class defines both an interface and an implementation for objects.The interface defines the signature of the methods supported by objectsof the class, and the implementation defines what instance variables implementthe object's state and what procedures implement its methods.
New classes are derived by sub-classing from previously existing classesthrough inheritance and specialization. Subclasses inherit their interfacesand implementations from their parent classes unless they are overridden.
SOM supports multiple inheritance. That is, a class may be derived frommultiple parent classes.
9. Noteworthy Objects
SOM has three important objects which exist as part of the run timeenvironment. The first is a root object from which all SOM objects arederived. This root object defines the essential behavior common to allSOM objects.
The second object is the root class object which defines the essentialbehavior common to all SOM classes. All SOM classes are expected to havethis class object or some class derived from it as their metaclass. Thisobject carries the methods which serve as factory objects.
The third object is a class manager. It serves as a run time registryfor all SOM class objects that have been created or dynamically loadedby the current process.
9.1 relationships
Not addressed.
9.2. attributes
SOM classes support attributes. An attribute can be thought of as aninstance variable that has accompanying "get" and "set"methods. The get and set methods are invoked the same way as other methods.
9.3 literals
SOM literal types are characters and integers.
9.4 containment
SOM is a basic technology and therefore does not have a notion of oneobject containing another. However, since SOM is a library packaging technologyit supports the construction of SOM objects which can contain other SOMobjects.
9.5 aggregates
Aggregation is used in SOM to represent collections of basic data types.The aggregation types as expressed in C are struct, union and enum.
9.6 other
10. Extensibility
In SOM, all new classes are defined in terms of a previously existingSOM class. New methods can be added and old methods can be overridden.Methods can also be relocated upward in the hierarchy without requiringre-compilation of the application. Source code is not required for sub-classingsince the binaries can be used for this purpose. This sub-classing frombinaries even extends to languages other than the one the binaries werewritten in.
10.1 dynamic
SOM is dynamic in that the class binaries can be replaced without havingto re-compiled the application.
10.2 metaclasses/metaobject protocol
In SOM all classes are real objects. SOM supports a class object whichrepresents the metaclass for the creation of all SOM classes. The SOM metaclassdefines the behavior common to all class objects. S ince it inherits fromthe root SOM object it exists at run time and contains the methods formanufacturing object instances. It also has the methods used to dynamicallyobtain information about a class and its methods at run time.
10.3 introspection
See entry under 10.2 Metaclasses/Metaobject Protocol.
11. Object Languages
SOM is designed to work with a variety of programming languages. SOMsupports an interface definition language to define interfaces and data.The IDL is then compiled (pre-compiler) and linked with the application.This does not preclude the use of a languages' object model in the sameapplication.
The use of SOM with a procedural language provides that language withobject oriented capabilities.
12. Semantics of Base Classes (+type constructors)
See entry under 10.2 Metaclasses/Metaobject Protocol.
13. Background and References
[CS92] N. Coskun and R. Sessions, "Class Objects in SOM",IBM Personal Systems Developer (Summer 1992): 67-77.
[SC92] R. Sessions and N. Coskun, "Object-Oriented Programmingin OS/2 2.0", IBM Personal Systems Developer (Winter 1992):107-120.
[OH92] R. Orfali and D. Harkey, Client/Server Programming with OS/22.0, 2nd. ed., Van Nostrand Reinhold, New York, 1992.
SOMobjects Developer Toolkit Publications Version 2.0 - IBM Order No.96F8649
Notes: "SOMobjects" is a registered trademark of IBM.