CORBA-based OSA API

CORBA is an emerging open distributed object computing infrastructure, which provides the higher layers a uniform view of underlying heterogeneous network and OS layers. CORBA automates many common network programming tasks such as object registration, location, activation, request demultiplexing, framing and error-handling. Figure 2.2 illustrates the CORBA architecture.

In this architecture an object is a CORBA programming entity that consists of an identity, an interface and an implementation known as servant (Figure 2.2 (A)). An object reference

uniquely identifies the object across servers. This reference associates the object with one or more servant implementations. In CCL OSA API, every CORBA object is associated with one servant.

A servant is an implementation programming language entity that defines the operations to support an Object Management Group (OMG) Interface Definition Language (IDL) interface.

Servants can be written in languages such as C, C++ or Java.

Figure 2.2 CORBA architecture

A client (Figure 2.2 (B)) is a program entity that invokes an operation on a servant. The client performs application tasks by invoking operations on object references. An object can be remote or local to the client. In CORBA, accessing a remote object should be as simple as calling an operation on a local object. A client always interacts with a servant through the corresponding object reference. Note that the CORBA concepts of client and servant are different from that of applications and servers in OSA (to be elaborated in Sections 2.3 and 2.4).

Object Request Broker (ORB) is a logical entity that can be implemented through several alternatives (such as one or more processes or a set of libraries). In CCL OSA, ORB is implemented as libraries. An ORB consists of an ORB Core (Figure 2.2 (C)) and an ORB interface (Figure 2.2 (D)). The ORB simplifies distributed programming by decoupling the client from the details of the method invocation. This makes client requests appear to be local

procedure calls. The ORB Core provides a mechanism for transparent delivery requests from clients to target servants. When a client invokes an operation, the ORB Core is responsible for finding the servant, transparently activating it if necessary, delivering the request to the object and returning any response to the client. An ORB Core is typically implemented as a run-time library linked into both client and server applications.

To decouple applications from implementation details, the CORBA specification defines an abstract ORB interface that provides various helper functions such as converting object references to strings. Specifically, CORBA IDL stubs (Figure 2.2 (E)) and skeletons (Figure 2.2 (F)) glue the clients, servants and the ORB. The CORBAIDL definitions are transformed into classes, structs, and functions in a particular language (e.g. C++, C, Java, etc.). Such transformation is automated by a CORBA IDL compiler. In CCL OSA, the target language is JAVA. We note that an object is an instance of an IDL interface. The corresponding servants implement the operations defined by the IDL. Several interfaces have been defined by IDL stubs to provide a strongly typed, Static Invocation Interface (SII) that marshals application (client) parameters into a common data-level representation. On the other hand, skeletons demarshal the data-level representation back into typed parameters that are meaningful to an application (server).

Portable Object Adapter (POA; Figure 2.2 (G)) is a CORBA portability enhancement.

POA enables ORBs to support various types of servants that process similar requirements [37].

POA associates an IDL servant with objects, demultiplexes incoming requests to the servant and dispatches the appropriate operation on that servant. The POA design results in a smaller and simpler ORB that can still support a wide range of object granularities, lifetimes, policies, implementation styles and so on.

Several POA policies are specified in CCL OSA. Threading policy specifies the POA threading model. A POA can either be single-threaded or multithreaded concurrently controlled by the ORB. CCL OSA implementation uses ORB controlled multithreading model.

Lifespan policy specifies whether the CORBA objects created within a POA are persistent or transient. A transient object is destroyed when the process creating the object terminates. On the other hand, a persistent object can live beyond the life time of the process that created it. All POAs are transient. In any CORBA system, there is a root POA called rootpoa. In CCL OSA, rootpoa creates several POAs with the persistent life span policy. An example is POA ipinitialpoa created for the FW. In CCLOSA, rootpoa creates transient objects. For example, in Initial Access service, an authentication object (with the reference ipAPIlevelauthentication _ref) is transient because this object is session-oriented and is destroyed when the authentication procedure is complete. On the other hand, the FWInitialContact object (with the reference ipinitial_ref; see Step 1 in Figure 2.3) created by ipinitialpoa is persistent and should not be destroyed after the authentication action (between an AS application and the FW) is complete. The FWInitialContact object is the first contact point for any applications to start the authentication procedure. Therefore it must be persistent and active at any time. When the CCL OSA recovers from a failure, all persistent objects will be reactivated.

Object Id uniqueness policy specifies whether the servants activated in a POA must have unique Object Ids. In CCL OSA, since every object is implemented with one servant, the servant always has a unique Object Id. Object Id assignment policy specifies whether the Object Ids in a POA are generated by the application or the ORB. In CCL OSA, object Ids are generated by the ORB to avoid accidentally generating duplicated Object Ids by the programmer.

Implicit activation policy specifies whether implicit activation of servants is supported in a POA. With the implicit policy, the POA implicitly activates an object when the server application attempts to obtain a reference to a servant that is not already active. In CCL OSA, objects in rootpoa are implicitly activated. These implicitly created transient objects can be destroyed at the end of the session of a client application or are automatically cleaned up when the server process terminates. In CCL OSA POAs such as ipinitialpoa, objects are persistent

and should not be automatically clean up when the server process terminates. Therefore, these persistent objects are explicitly activated and should be explicitly destroyed by the programmer when he/she decides to stop providing the functionality.

Servant retention policy specifies whether the POA retains active servants in an active object map. A POA either retains the associations between servants and CORBA objects or establishes a new CORBA object/servant association for each incoming request. In CCL OSA, the POA retains the associations between servants and CORBA objects in an active object map.

Request processing policy specifies how requests are processed by the POA. The alternatives include:

1. to consult its active object map only 2. to use a default servant or

3. to invoke a servant manager

There are two types of servant managers: a manager of the ServantActivator type follows the RETAIN policy. A manager of the ServantLocator type follows the NON_RETAIN policy.

Since CCL OSA uses active object map, it uses first alternative for the request processing policy;

that is, we consult POA’s active object map for request processing.

Table 2.1 POA policy modes for CCL OSA

Policy Mode of Policy

Thread Policy ORB_CTRL_MODEL

Lifespan Policy TRANSIENT (rootpoa)

PERSISTENT (e.g. ipinitialpoa) Object ID Uniqueness Policy UNIQUE_ID

ID Assignment Policy SYSTEM_ID Servant Retention Policy RETAIN

Request Processing Policy USE_ACTIVE_OBJECT_MAP_ONLY Implicit Activation Policy IMPLICIT_ACTIVATION (for rootpoa)

NO_IMPLICIT_ACTIVATION (e.g. ipinitialpoa)

The servant retention and request processing policies determine how the POA dispatches the request. The RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY policies used in our approach allow simple and quick request processing at the cost of larger memory usage as compared with other servant retention and request processing policies. Table 2.1 lists the POA policy modes used in CCL OSA.