The POA and the other CORBA entities that support its existence are all contained in the PortableServer module. Shown in Listing 28.1, this module is a bit daunting at first glance. As with many other entities in the CORBA universe, its size is a function of its need to be robust and, in general, fit the needs of a large variety of applications. Spend some time with the module, but don’t let yourself get bogged down in everything it exposes. Listing 28.1 is an OMG specification (not a complete program) that’s mainly utilized internally by the ORB vendors; it’s not something that you’ll likely have to spend much time with. We follow Listing 28.1 with a section that analyzes the commonly used pieces through usage examples.
LISTING 28.1 THE PortableServer MODULE
#pragma prefix "omg.org"
module PortableServer { interface POA;
native Servant;
typedef sequence<octet> ObjectId;
exception ForwardRequest {Object forward_reference;};
// **********************************************
//
// Policy interfaces //
// **********************************************
enum ThreadPolicyValue {ORB_CTRL_MODEL, SINGLE_THREAD_MODEL };
interface ThreadPolicy : CORBA::Policy {
readonly attribute ThreadPolicyValue value;
};
enum LifespanPolicyValue {TRANSIENT, PERSISTENT};
interface LifespanPolicy : CORBA::Policy {
readonly attribute LifespanPolicyValue value;
};
enum IdUniquenessPolicyValue {UNIQUE_ID, MULTIPLE_ID };
interface IdUniquenessPolicy : CORBA::Policy {
readonly attribute IdUniquenessPolicyValue value;
};
enum IdAssignmentPolicyValue {USER_ID, SYSTEM_ID };
interface IdAssignmentPolicy : CORBA::Policy {
readonly attribute IdAssignmentPolicyValue value;
};
enum ImplicitActivationPolicyValue
{IMPLICIT_ACTIVATION, NO_IMPLICIT_ACTIVATION};
interface ImplicitActivationPolicy : CORBA::Policy {
readonly attribute ImplicitActivationPolicyValue value;
};
enum ServantRetentionPolicyValue {RETAIN, NON_RETAIN};
interface ServantRetentionPolicy : CORBA::Policy {
readonly attribute ServantRetentionPolicyValue value;
};
enum RequestProcessingPolicyValue { USE_ACTIVE_OBJECT_MAP_ONLY,
USE_DEFAULT_SERVANT, USE_SERVANT_MANAGER};
interface RequestProcessingPolicy : CORBA::Policy {
readonly attribute RequestProcessingPolicyValue value;
};
// **************************************************
//
// POAManager interface //
// **************************************************
interface POAManager {
exception AdapterInactive{};
void activate() raises(AdapterInactive);
void hold_requests(in boolean wait_for_completion) raises(AdapterInactive);
void discard_requests(in boolean wait_for_completion) raises(AdapterInactive);
void deactivate(in boolean etherealize_objects, in boolean wait_for_completion) raises(AdapterInactive);
};
// **************************************************
//
// AdapterActivator interface //
// **************************************************
interface AdapterActivator {
boolean unknown_adapter(in POA parent, in string name);
};
// **************************************************
//
// ServantManager interface //
// **************************************************
interface ServantManager { };
interface ServantActivator : ServantManager {
Servant incarnate (in ObjectId oid, in POA adapter ) raises (ForwardRequest);
void etherealize (in ObjectId oid, in POA adapter, in Servant serv,
in boolean cleanup_in_progress, in boolean remaining_activations );
};
interface ServantLocator : ServantManager { native Cookie;
Servant preinvoke(in ObjectId oid, in POA adapter,
in CORBA::Identifier operation, out Cookie the_cookie)
raises (ForwardRequest);
void postinvoke(in ObjectId oid, in POA adapter,
in CORBA::Identifier operation, in Cookie the_cookie,
in Servant the_servant);
};
// **************************************************
//
// POA interface //
// **************************************************
interface POA {
exception AdapterAlreadyExists {};
exception AdapterInactive {};
exception AdapterNonExistent {};
exception InvalidPolicy { unsigned short index; };
exception NoServant {};
exception ObjectAlreadyActive {};
exception ObjectNotActive {};
exception ServantAlreadyActive {};
exception ServantNotActive {};
exception WrongAdapter {};
exception WrongPolicy {};
//--- //
// POA creation and destruction //
//--- POA create_POA(in string adapter_name,
in POAManager a_POAManager, in CORBA::PolicyList policies)
raises (AdapterAlreadyExists, InvalidPolicy);
POA find_POA(in string adapter_name, in boolean activate_it) raises (AdapterNonExistent);
void destroy(in boolean etherealize_objects, in boolean wait_for_completion);
// **************************************************
//
// Factories for Policy objects
//
// **************************************************
ThreadPolicy create_thread_policy(in ThreadPolicyValue value);
LifespanPolicy create_lifespan_policy (in LifespanPolicyValue value);
IdUniquenessPolicy create_id_uniqueness_policy (in IdUniquenessPolicyValue value);
IdAssignmentPolicy create_id_assignment_policy (in IdAssignmentPolicyValue value);
ImplicitActivationPolicy
create_implicit_activation_policy
(in ImplicitActivationPolicyValue value);
ServantRetentionPolicy
create_servant_retention_policy
(in ServantRetentionPolicyValue value);
RequestProcessingPolicy
create_request_processing_policy
(in RequestProcessingPolicyValue value);
//---
//
// POA attributes //
//--- readonly attribute string the_name;
readonly attribute POA the_parent;
readonly attribute POAManager the_POAManager;
attribute AdapterActivator the_activator;
//--- //
// Servant Manager registration:
//
//---
ServantManager get_servant_manager() raises (WrongPolicy);
void set_servant_manager(in ServantManager imgr) raises (WrongPolicy);
//--- //
// operations for the USE_DEFAULT_SERVANT policy //
//--- Servant get_servant() raises (NoServant, WrongPolicy);
void set_servant(in Servant p_servant) raises (WrongPolicy);
// **************************************************
//
// object activation and deactivation //
// **************************************************
ObjectId activate_object( in Servant p_servant ) raises (ServantAlreadyActive, WrongPolicy);
void activate_object_with_id(in ObjectId id, in Servant p_servant) raises (ServantAlreadyActive,
ObjectAlreadyActive, WrongPolicy);
void deactivate_object(in ObjectId oid) raises (ObjectNotActive, WrongPolicy);
// **************************************************
//
// reference creation operations //
// **************************************************
Object create_reference(in CORBA::RepositoryId intf) raises (WrongPolicy);
Object create_reference_with_id (in ObjectId oid, in CORBA::RepositoryId intf)
raises (WrongPolicy);
//--- //
// Identity mapping operations:
//
//--- ObjectId servant_to_id(in Servant p_servant)
raises (ServantNotActive, WrongPolicy);
Object servant_to_reference(in Servant p_servant) raises (ServantNotActive, WrongPolicy);
Servant reference_to_servant(in Object reference)
raises (ObjectNotActive, WrongAdapter, WrongPolicy);
ObjectId reference_to_id(in Object reference) raises (WrongAdapter, WrongPolicy);
Servant id_to_servant(in ObjectId oid) raises (ObjectNotActive, WrongPolicy);
Object id_to_reference(in ObjectId oid) raises (ObjectNotActive, WrongPolicy);
};
// **************************************************
//
// Current interface //
// **************************************************
interface Current : CORBA::Current { exception NoContext { };
POA get_POA() raises (NoContext);
ObjectId get_object_id() raises (NoContext);
};
};
Well, you made it this far, which means that the code in Listing 28.1 did not scare you away from the rest of the chapter. Again, although it’s important to note every feature exposed by the module, chances are you’ll not use all these features in your applications.
One area you do need to concentrate some attention on, however, is the POA interface.
This interface is the location where you’ll spend the majority of your time when interacting with the POA.
Starting out with the manner in which a POA reference is actually obtained, the following code snippet first binds to the ORB and then uses the ORB method
resolve_initial_references() to obtain a reference to the POA:
import org.omg.CORBA.*;
import PortableServer.*;
ORB orb = ORB.init();
org.omg.CORBA.Object object =
orb.resolve_initial_references("RootPOA");
POA poa = POAHelper.narrow(object);
Once a POA reference is obtained, it’s used throughout the server to activate objects. In general, objects are commonly activated in two ways. As stated earlier in the chapter, an object in the POA is uniquely identified by its object ID. This ID can either be specified when activating an object or generated automatically by the server. If you’re simply activating a transient object, an autogenerated system ID is sufficient. If, however, the object is to be persistent (meaning that other entities can bind to it), you’ll want to specify an ID during activation. The next code snippet demonstrates both activation methods.
As you look over the code, note that an object ID is nothing more than an array of IDL octet’s (Java bytes). The POA derives absolutely no meaning from the ID’s value—it’s simply used to identify an object. The programmer develops the meaning associated with an ID’s value.
// create a dummy object
FooInterfaceI foo = new FooInterface();
// activate with a system generated
// object if
ObjectId oid = poa.activate_object(foo);
// create an object id
byte[] oid2 = new byte[10];
poa.activate_object_with_id(oid2, foo);
FROM HERE
This chapter differs from other chapters in that instead of covering the current state of CORBA, it covers something that will enter into the CORBA universe after this book is published. Depending on when you read this chapter (and how well the OMG and ORB vendors stick to their timelines), the POA may be just showing its face or may actually be in use. What must be noted, however, is that the BOA is not going anywhere for a long time. Millions of lines of fully functional code already use the BOA, and developers of new code may not want to begin using a new feature immediately after its release. As you continue to explore this book, you may want to revisit the following chapters, which complement what’s addressed here:
• Chapter 21, “CORBA Overview”
• Chapter 22, “CORBA Architecture”
Chapter 29: Internet Inter-ORB Protocol (IIOP)
Overview
As discussed in Chapter 21, “CORBA Overview,” CORBA 2.0 introduced the Internet Inter-ORB Protocol (IIOP), which brought interoperability to CORBA environments. At a high level, IIOP allows for objects developed for an Object Request Broker (ORB) from vendor A to communicate over TCP/IP with objects developed for an ORB from vendor B.
Digging further under the hood, you’ll note that IIOP is actually a TCP/IP implementation of General Inter-ORB Protocol (GIOP), which defines a standard communication
mechanism between ORBs. As is implied by the General part of its name, GIOP is transport mechanism independent, with IIOP being the transport dependent (TCP/IP) mapping.
This chapter examines GIOP and IIOP first from a general technical standpoint and then looks at what it means to integrate these technologies into your applications. Specifically, the following topics are covered:
• IIOP/GIOP design goals
• IIOP/GIOP specification elements
• Developing with IIOP/GIOP
As you study the chapter, note that two types of information are presented. The first section presents a general overview of IIOP/GIOP and then digs under the hood to present some of the nitty-gritty details. The second section actually develops a multi-ORB application. In general, this first section is interesting but is presented for reference purposes only. It’s important to know why IIOP/GIOP came into existence as well as how exactly they work, but this knowledge is not necessary to work with IIOP. The second section actually develops an application that uses IIOP to enable inter-ORB communication and therefore is of greater use to developers.