Life cycle Assessment of CORBA object lifecycle

Evaluation criteria

We have discussed the lifecycle of CORBA objects, including lifecycle events, discussion of early and late binding, and general classification of CORBA object implementations. Obviously, the user wants the orb-provided application to support an effective implementation of all the different aspects of the life cycle of these CORBA objects. The Orb provides this support through object adapters (OA). A series of evaluation guidelines are defined to enable an object adapter to perform an analysis involving the effective support of the CORBA object lifecycle. The user then adopts these different evaluation criteria and applies them to the object adapters in the BOA and POA generations.

• Adapter Structure-The most important aspect is the general structure of the adapter.

• Object identification--object identification in CORBA system is not a small problem, so it is necessary to carefully examine how the specific orb generation supports the concept of object identity for CORBA objects.

• Early binding-users need to verify how different Orb generations support early binding. It is worth noting how much association the binding and the Servo object creation have with each other.

• Late binding--the mechanism provided for late binding by different orb must be validated, especially with respect to the usefulness of the application used to support persistent objects.

• Stateless servo Object--the user wants to verify that the Orb provides support for implementing a stateless servo object on its behalf. The idea is for stateless servo objects, users do not really need each CORBA object to represent a servo object instance-a single Servo object can be used as a transient capsule for multiple CORBA objects, and a special CORBA object identifier is set on the basis of each request.

• Stateful servo objects-as discussed previously, it is often important to ensure that users do not have to reactivate these servo objects for each request, and that the activation of the servo object does not exceed a threshold value for stateful servo objects.

Evaluate Boa Generation

Below is a discussion of the basic object adapters in each of the above defined assessment guidelines for the object lifecycle, describing the work done on the portable object adapters.

1. BOA Architecture

As mentioned earlier, the BOA architecture is extremely vague in many ways. Many of the features that an application requires to effectively manage the lifecycle of an object are not specific enough. Boa defines a number of functions that activate CORBA server and CORBA object implementations. Unfortunately, Boa focuses on server activation rather than on important issues like late binding and dynamic object activation. Boa also defines some functions for the generation and interpretation of object references. Boa implies a one-to-one relationship between the servo object and the CORBA object, that is, each CORBA object supported by a particular server requires a dedicated instance of the servo object.

Because the BOA specification is too vague, this paper uses the Iona Technologies Orbix 2.x Orb as a reference implementation. Again, our aim is not to give a comprehensive comparison of different boa, but to use the orb as an example to discuss general concepts.

2. Object identification

The Orb of the BOA associates the object reference with the reference data when it was created. The reference data is a 8-bit sequence of bits and is controlled by the orb. This makes it difficult to provide an application-defined object I d in a way that follows CORBA. The Orbix Orb provides the _marker () API to indicate the application-defined reference data for a CORBA object. Marker is a string that is supplied by the application and stored as part of the reference data by the Orb.

3. Early binding

As mentioned earlier, most Boa-generation Orb provides a tight coupling between the client-side pile hierarchy and the server-end framework class hierarchy. The result of this is that the creation of a servo object usually indirectly causes an object to be activated, because the servo object inherits the constructor method, which indirectly creates the binding between the Servo object and the Orb runtime module. This implies that if the user wants to return the object reference to the client, it is also necessary to create and activate the Servo object instance, which uses early binding.

4. Late binding

The BOA structure does not define how the orb and applications interact to support late binding, or object activation by command. Therefore, this paper takes the Orbix orb as an example of how the Boa orb deals with this problem.

The Orbix orb uses the loader mechanism shown in Figure 3 to support late binding. As mentioned earlier, the loader plays the role of the Servo object manager. The basic idea is that the application registers the loader instance with the Orb runtime module. The Orb runtime module activates the load () method on the loader, in turn, in the event of an object failure. This gives the loader a chance to activate the request object so that the orb can assign it.

The responsibility of the application is to determine whether the servo object is active only for a specific request service or for subsequent requests. ORB I x loader features can be used by applications to implement object pool mode for objects, which are available with commands, that is, persistent object activation.

5. Non-State servo object

The Boa ORB implementation does not provide special support for stateless servo objects. Basically, a one-to-one relationship between a CORBA object and a servo object implies that a servo object must be activated for each CORBA object. Depending on the cost of instantiating and activating a stateless servo object, the user decides whether it is worth implementing as a pool mode to reduce the number of object activations/freezes. This includes investigating the cost of activating and freezing the servo objects imposed by the Orb, as well as the costs associated with the application. The problem is that from a performance standpoint it is expensive to activate a servo object on a per-request basis, or to maintain an object pool.

6. Stateful Servo Object

As discussed earlier, the activation/freezing of a servo object is expensive for stateful servo objects, especially if it includes a lookup of the database. In this case, it is meaningful to combine late binding and object pooling. Because the BOA specification is not very clear here, it must rely on proprietary ORB support for late binding, like the Orbix loader.