A thorough exploration of the life cycle of CORBA objects

On the server side, the orb of the server reads the request from the network at run time and starts processing the request by calling Receive_message () on the first installed message interceptor. The Orb uses object keywords to identify that the target must contain a POA name, and the object can be reached by POA. After the correct POA is found, the next step is to find the object itself, and how this work is done depends on the policy defined for the PoA of the object. If the object is able to locate, the Orb continues processing the request by invoking Target_invoke () on the first installed request interceptor, and the interceptor uses the DII function invoke () to continue processing the request sequentially, as discussed in the client. This assumes that only one request interceptor is installed, and the request is eventually assigned to the target object's implementation.

When an object finishes processing a request, the Invoke () Call of the message interceptor returns, and the Interceptor now has the opportunity to verify the results of the operation by firing result () on the request object before returning to the Orb runtime module. The last thing on the server side is the Orb's firing on the Send_message () on the server message interceptor. On the client side, the interceptor is handled in a similar way: first The Orb invokes the Receive_message () method on the message interceptor, and then requests that the interceptor return the blocking call to invoke () and enable the calls to verify the result of the request. Finally, the method returned by the client that is fired on the proxy provides the results to the client.

The problem with the first edition of the POA specification is that it is difficult to determine the exact sequence of events in the lifecycle, especially on the server side. For example, the specification does not explicitly define which time on the server side to assign a thread to a particular request--many thread policies require information that is provided in the Request object. In addition, the specification does not clearly specify the order in which PoA and object lookups are related to the request interceptor, so the order is based on their logical relationship in the flowchart.

We want to identify generations of different Corba:boa (basic object adapters) and POA (Portable object adapters). This distinction will allow us to define two important milestones in the evolution of the core orb architecture.

1, Boa Generation

Boa generation of CORBA Architecture object adapters are the primary interfaces that applications use to access orb functions. It includes. An interface that generates an object reference that contains the registration implementation of one or more programs and the interfaces required to activate the implementation. "

Note that when talking about registration and activation implementations, BOA focuses on CORBA server implementations rather than CORBA object implementations. One of the main drawbacks of the BOA specification is its uncertainty when confronted with such problems. The lack of naming conventions for the generated server-side framework is also an example, which makes it impossible to correlate framework and object implementations in a way that follows CORBA. This paper uses the Orbix 2.x CORBA implementation of Iona Technologies as the benchmark for the Orb boa generation.

2, POA generation

The portable object adapter attempts to overcome the uncertainty of the initial BOA specification and, on the other hand, provides a complete set of advanced Services for object Lifecycle management.

An in-depth discussion of POA itself can be found in Schmidt and Vinoski's book, which also provides the following definition: "Object adapters are CORBA components that are responsible for enabling CORBA's object concepts to adapt to the concept of the servo object in the programming language." "This definition emphasizes that the registration and activation of the implementation is transferred from the process level to the object level." For the object lifecycle, POA itself is not the only interesting change in the evolution of the CORBA architecture. Other interesting new features include interceptors that allow monitoring of the activation lifecycle and the service context. The service context supports the sending of additional information with a standard CORBA excitation. Although the last two features have nothing to do with the concept of object adapters, we still incorporate them into the "POA generation" definition. This means that this article has abridged the history of CORBA's extensive version of Boa and PoA's views, enabling users to focus on concepts.

The following focuses on the life cycle of CORBA objects and their implementation, looking at the object lifecycle in general, and then discussing the details of the Orb of Boa and POA two generations. We look at the object lifecycle in terms of an application rather than an orb, so first look at what the application typically requires to effectively manage the lifecycle of the CORBA object.