Implementations and servers

The CORBA specification defines the term implementation as the code that implements an object. The implementation usually consists of a program and class libraries.

Servers are processes that execute object implementations. CORBA 1.1 defines four activation policies for server implementations: shared, unshared, server-per-method, and persistent, as follows.

• A shared server implements multiple objects (of arbitrary classes the same time, and allows multiple methods to be invoked at the same time.

• An unshared server, conversely, implements only a single object and handles one request at a time.

• The server-per-method policy requires a separate process to be created for each request on an object and, usually, a separate program implements each method.

  Under the shared, unshared, and server-per-method activation policies, servers are activated automatically (on demand).

• A persistent server, by contrast, is a shared server that is activated "by hand" (for example, from the command shell or from a startup script), vs. being activated automatically when the first method is dispatched to it.

The term "persistent server" refers to the relative lifetime of the server: it is "always running" when DSOM is running. (CORBA implies that persistent servers are usually started at ORB boot time.) It should not be assumed, however, that a "persistent" server necessarily implements persistent objects (that persist between ORB reboots).

In DSOM, specific process models are implemented by the server program. That is, DSOM simply starts a specified program when a client attempts to connect to a server. The four CORBA activation policies, or any other policies, can be implemented by the application as necessary. For example,

• an object that requires a server-per-method implementation could itself spawn a process at the beginning of each method execution. Alternatively, the server object in the "main" server can spawn a process before each method dispatch.

• a dedicated server could be registered for each object that requires an unshared server implementation (separate process). This may be done dynamically (see the topic "Programmatic interface to the Implementation Repository" earlier in this chapter).

An ImplementationDef object, as defined by the CORBA specification, describes the characteristics of a particular implementation. In DSOM, an ImplementationDef identifies an implementation's unique ID, the program name, its location, and so forth. The ImplementationDef objects are stored in an Implementation Repository, which is represented in DSOM by an ImplRepository object.

A CORBA-compliant ORB must provide the mechanisms for a server program to register itself with the ORB. To "register itself with the ORB" simply means to tell the ORB enough information about the server process so that the ORB will be able to locate, activate, deactivate, and dispatch methods to the server process. DSOM supports these mechanisms, so that server programs written in arbitrary languages can be used with DSOM. (See also the next topic, "Object Adapters.")

In addition to the generic registration mechanisms provided by all CORBA-compliant ORBs, DSOM provides extra support for using SOM-class DLLs. DSOM provides a generic server program that automatically registers itself with DSOM, loads SOM-class DLLs on demand, and dispatches incoming requests on SOM objects. Thus, by using the generic server program (when appropriate), a user may be able to avoid writing any server program code.