[32] SKELETONS AND IMPLEMENTATION OBJECTS
(Part of the CORBA FAQ, Copyright © 1996-99)

[32.1] HOW DOES A CORBA OBJECT PROVIDE ITS SERVICES?

[Recently expanded description to both BOA and POA (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

A CORBA Object provides a set of services to its object references. In doing so, the CORBA Object utilizes various parts of the ORB infrastructure. The skeleton (server side) infrastructure changed drastically in CORBA 2.3 when the Basic Object Adapter (BOA) was deprecated in favor of the Portable Object Adapter (POA).

The ORB and Object Adpter (OA) coordinate to provide the networking “know-how” of the CORBA Object, and the object implementation provides the actual oepration “know-how” of the CORBA Object. The ORB and OA are responsible for listening for requests, locating/activating the implementation object, and generating responses to caller. The BOA and POA are distinguished in the amount of standardization they provide and in the range of services they provide to manage policies and life-cycles of the CORBA and implementation objects. With either OA, the network request is delivered by the OA to the implementation object so that it can perform the real business logic associated with the request.

[ Top | Bottom | Previous section | Next section ]

[32.2] HOW ARE THE SKELETON AND IMPLEMENTATION OBJECT COMBINED?

[Recently expanded description to both BOA and POA (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The skeleton (server side) infrastructure changed drastically in CORBA 2.3 when the Basic Object Adapter (BOA) was deprecated in favor of the Portable Object Adapter (POA). This FAQ discusses both the BOA and POA.

The BOA offers two ways to associate the implementation object with the skeleton:

1. Derived: In the derived approach, the implementation object “is” also a skeleton. This is usually obtained via inheritance. The ORB’s IDL compiler would generate an appropriate skeleton class (based on the IDL interface and data types) and the developer would derive their own implementation class from it. The skeleton is able to listen to the network, de-marshall/re-marshall data types, etc. The implementation knows how and what to do within the body of the CORBA operations. A CORBA server will simply instantiate the implementation and tell the BOA that it “is ready”. Since the implementation “is” also a skeleton, the CORBA Object will be able to respond to CORBA requests.
2. Delegated: In the delegated approach, The ORB’s IDL compiler would generate an appropriate skeleton class (based on the IDL interface and data types) which would then delegate the actual operation execution to another class. The skeleton is still responsible for reading and writing to the network, de-marshall/re-marshall data types, etc. The implementation knows how and what to do within the body of the CORBA operations. While the implementation does not actually inherit from the skeleton, it still needs to implement the same set of minimal methods corresponding the to IDL operations. A CORBA server will need to instantiate the skeleton, instantiate the implementation, instruct the skeleton as to the where abouts of the implementation (often known as TIEing the skeleton and implementation together) and the tell the BOA that the skeleton “is ready”.

The POA is much more flexible and powerful than the BOA. The POA is fully described in another FAQ. The POA also introduces some new terminology, such as servant. This FAQ will use the BOA terminology to the extent possible.

At a basic level, the POA offers the same alternatives as the BOA for using derivation (inheritance) and delegation to associate implementation objects with the skeleton. Additionally, the POA provides the ability for a single implementation object to represent many CORBA objects in the skeleon. This is an important scalability mechanism.

At a more sophisticated level, however, the POA also allows the life-cycle of the implementation object to be independent of the life-cycle of the cooresponding CORBA object in the skeleton. Specifically, implementation objects can exist without being associated with the skeleton, and likewise the skeleton can represent CORBA objects that are not associated (always) with an implementation object. This is also an important scalability mechanism.

[ Top | Bottom | Previous section | Next section ]

 E-mail us