Distributed SOM (DSOM)
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation
Note: The SOMobject Base Toolkit provides the capability for implementing Workstation Distributed System Object Module (DSOM) (distribution among processes on a single machine). Implementing an application that is distributed across a network of machines requires Workgroup DSOM, which is available only in the full-capability SOMobjects Developer Toolkit.
The following subjects are discussed in this section:
- A Simple DSOM Example
- Basic Client Programming
- Basic Server Programming
- Implementing Classes
- Configuring DSOM Applications
- Running DSOM Applications
- DSOM as a CORBA-compliant Object Request Broker
- Advanced Topics
- Error Reporting and Troubleshooting
- Limitations
What is Distributed SOM?
Whereas the power of SOM technology comes from the fact that SOM insulates the client of an object from the object's implementation, the power of DSOM lies in the fact that DSOM insulates the client of an object from the object's location.
Distributed SOM (or DSOM) provides a framework that allows application programs to access objects across address spaces. That is, application programs can access objects in other processes, even on different machines. Both the location and implementation of an object are hidden from a client, and the client accesses the object (by way of method calls) in the same manner regardless of its location.
DSOM currently supports two types of distribution:
- distribution among processes on the same machine (referred to as Workstation DSOM)
- and distribution among a network of machines (referred to as Workgroup DSOM).
DSOM runs on the AIX (Release 3.2.5 and above) and OS/2 (Release 2.0 and above) operating systems. A Workstation DSOM application can run on a machine in either environment using core capabilities of the SOMobjects system. Under the full capability SOMobjects Developer Toolkit, Workgroup DSOM supports distribution across local area networks comprised of both OS/2 and AIX systems. Future releases of DSOM may support large, enterprise-wide networks.
Support for TCP/IP and NewWare IPX/SPX is provided on AIX, OS/2, and Windows. NetBIOS support is provided for OS/2 and Windows. DSOM communications is extensible in that an application can provide its own transport (see Appendix C of the SOMobjects Base Toolkit Users Guide).
DSOM can be viewed in two ways:
- As a System Object Model extension that allows a program to invoke methods on SOM objects in other processes.
- As an Object Request Broker (ORB); that is, a standardized "transport" for distributed object interaction. In this respect, DSOM complies with the Common Object Request Broker Architecture (CORBA) specification, published by the Object Management Group (OMG) and x/Open.
This chapter describes DSOM from both perspectives.
DSOM features
Here is a quick summary of some of DSOM's more important features:
- Uses the standard SOM Compiler, Interface Repository, language bindings, and class libraries. Thus, DSOM provides a growth path for non-distributed SOM applications.
- Allows an application program to access a mix of local and remote objects. The fact that an object is remote is transparent to the program.
- Provides run-time services for creating, destroying, identifying, locating, and dispatching methods on remote objects. These services can be overridden or augmented to suit the application.
- Uses existing interprocess communication (IPC) facilities for Workstation communication, and common local area network (LAN) transport facilities for Workgroup communications. Support for TCP/IP, Netware IPX/SPX, and NetBios is provided. DSOM communications is extensible in that an application can provide its own transport.
- Provides support for writing multi-threaded servers and event-driven programs.
- Provides a default object server program, which can be easily used to create SOM objects and make those objects accessible to one or more client programs. If the default server program is used, SOM class libraries are loaded upon demand, so no server programming or compiling is necessary.
- Complies with the CORBA 1.1 specification, which is important for application portability.
When to use DSOM
DSOM should be used for those applications that require sharing of objects among multiple programs. The object actually exists in only one process (this process is known as the object's server); the other processes (known as clients) access the object through remote method invocations, made transparent by DSOM.
DSOM should also be used for applications that require objects to be isolated from the main program. This is usually done in cases where reliability is a concern, either to protect the object from failures in other parts of the application, or to protect the application from an object.
Some distributed applications may have special performance, reliability,or cooperative processing requirements, to which the SOM Replication framework is better suited. The Replication framework is oriented toward "groupware" (multi-party cooperative processing) applications, and has facilities for fault tolerance and recovery. The Replication framework is distinct from DSOM in that it maintains a complete replica of an object in each participant's address space, while DSOM establishes remote connections to shared objects. The Replication Framework is available only in the full-capability SOM objects Developer Toolkit.
Chapter Outline
Briefly, this section covers the following subjects:
- Tutorial example
- Programming DSOM applications
- Configuring DSOM applications
- Running DSOM applications
- DSOM and CORBA
- Advanced topics
- Error reporting and troubleshooting
Tutorial example
First, a complete example shows how an existing SOM class implementation (a "stack") can be used with DSOM to create a distributed "Stack" application. Using the "Stack" example as a backdrop, the basic DSOM interfaces are introduced.
Programming DSOM applications
All DSOM applications involve three kinds of programming:
- Client programming: writing code that uses objects;
- Server programming: writing code that implements and manages objects.
- Implementing classes: writing code that implements objects.
Three sections ("Basic Client Programming", "Basic Server Programming", and Implementing Classes") describe how to create DSOM applications from these three points of view. In turn, the structure and services of the relevant DSOM run-time environment are explained.
Note: The three sections are presented in the order above to aid in their explanation. However, the actual programming tasks are likely to be performed in the opposite order.
Additional examples are provided in these sections to illustrate DSOM services.
Configuring DSOM applications
The section "Configuring DSOM Applications" explains what is necessary to set up a DSOM application, once the application has been built.
Running DSOM applications
The section "Running DSOM Applications" explains what is necessary to run a DSOM application, once it has been built and configured.
DSOM and CORBA
Those readers interested in using DSOM as a CORBA-compliant ORB should read the section entitled "DSOM as a CORBA compliant Object Broker." That section answers the question: How are CORBA concepts implemented in DSOM?
Advanced topics
The section on "Advanced Topics" covers the following:
- Peer versus client/server processes" demonstrates how peer-to-peer object interactions are supported in DSOM.
- Dynamic Invocation Interface" details DSOM support for the CORBA dynamic invocation interface to dynamically build and invoke methods on remote objects.
- Creating user-supplied proxy classes" describes how to override proxy generation by the DSOM run time and, instead, install a proxy object supplied by the user.
- Customizing the default base proxy class"discusses how the SOMDClientProxy class can be subclassed to define a customized base class that DSOM will use during dynamic proxy-class generation.
- Sockets class" describes how DSOM uses Sockets subclasses.
Error reporting and troubleshooting
The section on "Error Reporting and Troubleshooting" discusses facilities to aid in problem diagnosis.
A Simple DSOM Example
The "Stack" interface
The "Stack" class implementation
Client program using a local stack
Client program using a remote stack
Using specific servers
A note on finding existing objects
"Stack" server implementation
Compiling the application
Installing the implementation
Setting environment variables
Registering the class in the Interface Repository
Registering the server in the Implementation Repository
Running the application
"Stack" example run-time scenario
Summary
Basic Client Programming
DSOM Object Manager
Initializing a client program
Exiting a client program
Creating remote objects
Creating an object in an arbitrary server
Proxy objects
Servers and server objects
Creating an object in a specific server
Inquiring about a remote object's implementation
Destroying remote objects
Destroying objects via a proxy
Destroying objects via the DSOM Object Manager
Destroying objects via a server object
Creating remote objects using user-defined metaclasses
Saving and restoring references to objects
Finding existing objects
Finding server objects
Invoking methods on remote objects
Determining memory allocation and ownership
Passing object references in method calls
Memory management
Memory management for method parameters
The CORBA policy for parameter memory management
The 'somdReleaseResources' method and object-owned parameters
Writing clients that are also servers
Compiling and linking clients
Basic Server Programming
Server run-time objects
Server implementation definition
SOM Object Adapter (SOMOA)
Server object
Server activation
Initializing a server program
Initializing the DSOM run-time environment
Initializing the server's ImplementationDef
Initializing the SOM Object Adapter
When initialization fails
Processing requests
Exiting a server program
Managing objects in the server
Object references, ReferenceData, and the ReferenceData table
Simple SOM object references
SOMDServer (default server-object class)
Creation and destruction of SOM objects
Mapping objects to object references
Hints on the use of create vs. create_constant
Mapping object references to objects
Dispatching a method
Example: Writing a persistent object server
Identifying the source of a request
Compiling and linking servers
Implementing Classes
Using SOM class libraries
Role of DSOM generic server program
Role of SOM Object Adapter
Role of SOMDServer
Implementation constraints
Using other object implementations
Wrapping a printer API
Parameter memory management
Building and registering class libraries
Configuring DSOM Applications
Preparing the environment
Registering class interfaces
Registering servers and classes
The 'regimpl', 'pregimpl', 'wregimpl' registration utilities
Registration steps Using 'regimpl'
Command line interface to 'regimpl'
Registration steps using 'pregimpl' or 'wregimpl'
Programmatic interface to the Implementation Repository
The 'dsom' server manager utility
Interpretation of 'dsom' messages
Verifying the DSOM environment with 'somdchk'
Freeing interprocess communication resources on AIX
Using 'somdclean'
Using 'cleanipc'
Running DSOM Applications
Running the DSOM daemon (somdd)
Running DSOM servers
DSOM as a CORBA-compliant Object Request Broker
Mapping OMG CORBA terminology onto DSOM
Object Request Broker run-time interfaces
Object references and proxy objects
Creation of remote objects
Interface definition language
C language mapping
Dynamic Invocation Interface (DII)
Implementations and servers
Object Adapters
Extensions and limitations
Advanced Topics
Peer vs. client/server processes
Multi-threaded DSOM programs
Event-driven DSOM programs using EMan
Sample server using EMan
Dynamic Invocation Interface
The NamedValue structure
The NVList class
Creating argument lists
Building a Request
Initiating a Request
Example code
Creating user-supplied proxies
Customizing the default base proxy class
Sockets class
Error Reporting and Troubleshooting
Error codes
Troubleshooting hints
Checking the DSOM setup
Analyzing problem conditions