An Object Adapter (OA) provides the mechanisms that a server process uses to interact with DSOM, and vice versa. That is, an Object Adapter is responsible for server activation and deactivation, dispatching methods, activation and deactivation of individual objects, and providing the interface for authentication of the principal making a call.
DSOM defines a Basic Object Adapter (BOA) interface, described in the CORBA specification, as an abstract class (a class having no implementation, only an interface specification). The BOA interface represents generic Object Adapter methods that a server written in an arbitrary language can use to register itself and its objects with the ORB. Because it is an abstract class having no implementation, however, the BOA class should not be directly instantiated.
DSOM provides a SOM Object Adapter, SOMOA, derived from the BOA interface, that uses SOM Compiler and run-time support to accomplish dispatching of methods (that is, accepting messages, turning them into method invocations, and routing the invocations to the target object in the server process). SOMOA can be used to dispatch methods on either SOM or non-SOM object implementations, as described in the sections "Implementing Classes" and "Basic Server Programming." It is possible to use non-SOM based implementations with SOMOA, and often there is no additional programming required to use implementations (class libraries) already developed using SOM.
The SOMOA works in conjunction with the application-defined server object to map between objects and object references, and to dispatch methods on objects. By partitioning out these mapping and dispatching functions into the server object, the application can more easily customize them, without having to build object adapter subclasses.
SOMOA introduces two methods that handle execution of requests received by the server:
execute_request_loop
execute_next_request
Typically, execute_request_loop is used to receive and execute requests, continuously, in the server's main thread. The execute_next_request method allows a single request to be executed. Both methods have a non-blocking option: when there are no messages pending, the method call will return instead of wait.
On OS/2, if the server implementation has been registered as "multi-threaded" (via an IMPLDEF_MULTI_THREAD flag in the ImplementationDef), SOMOA will automatically run each request in a separate thread. If the "multi-thread" flag is not set, the server implementation can still choose to manage its own threads.
The generic server program provided by DSOM (described in the preceding topic) uses execute_request_loop to receive and execute requests on SOM objects.