[42] POA
(Part of the CORBA FAQ, Copyright © 1996-99)

[42.1] WHAT IS THE POA?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The Portable Object Adapter (POA) superceeds the Basic Object Adapter (BOA) as the primary way of making implementation objects available to the ORB for servicing requests. All object adapters are concerned with the mechanisms to create CORBA objects and associate the CORBA objects with programming language objects that can actually do the work. The POA provides an expanded set of mechanisms for doing this.

[ Top | Bottom | Previous section | Next section ]

[42.2] WHY IS THE POA NEEDED?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The POA was added to the CORBA specification for a number of reasons:

1. The BOA was under-specified. This meant that each ORB vendor provided different APIs and different extensions to make the BOA useful. The POA fixes this by being more completely specified. The POA, itself, is specified in IDL, and addresses complex issues in more detail than the BOA did.
2. The BOA was insufficient for large-scale systems. The POA provides a lot more functionality than the POA with respect to implementing large-scale systems. Servers can better handle connections and requests from multiple clients through automatic, policy-driven behavior. Servers are better able to manage thousands, if not millions, of fine-grained objects via the POA’s ability to manage lifecycles and associations of CORBA objects and implementation objects.
3. The BOA was not completely location transparent. Whereas some semantics of the BOA changed if the implementation object was actually in the same process as the caller (client) vs. being remotely located, the POA makes the semantics much more consistent. In fact, a CORBA call on a local object will still go through the POA. This allows the POA to uniformly apply policy and service decisions. In this sense, the POA is more like the “container” concept in EJB.

[ Top | Bottom | Previous section | Next section ]

[42.3] DOES THE POA AFFECT CLIENTS?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

No. No object adapter or server-side concept affects clients. CORBA-compliant clients that used BOA-based servers should be able to use POA-based servers.

[ Top | Bottom | Previous section | Next section ]

[42.4] DOES THE POA AFFECT SERVERS?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

Yes. Transitioning from a BOA-based server to a POA-based server needs to be done with some forethought. It is not necessarily a difficult task, but should be done carefully. The POA is policy based with lots of policy choices. The task is to determine the set of policy decisions that give you the functionality you want.

Since the POA superceeds most of the BOA functionality, if you want to simply migrate a BOA-based server to a POA-based server without changing behavior, then this can be done rather easily. There are some API changes. See POA Policies. Chances are, though, if you are using the POA, you are going to want to take advantage of some of its benefits.

[ Top | Bottom | Previous section | Next section ]

[42.5] HOW DOES THE POA BENEFIT NON-DISTRIBUTED OBJECTS?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The POA is very consistent in the treatment of local and remote objects. Specifically, all CORBA calls on a CORBA object go through the POA, even if the target object is local (in the same address space). This allows the POA to uniformly apply the POA Policies.

[ Top | Bottom | Previous section | Next section ]

[42.6] HOW DOES THE POA MANAGE OBJECT LIFECYCLE?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The POA distinguishes between the CORBA object reference (IOR) and the implementation object that does the work. This implementation object is called a servant. A BOA-based approach has the IOR and servant existing at the same time. A POA-based approach can support this, but can also support IORs existing without being associated with servants, and also servants existing without being associated with IORs.

Obviously, the association between an IOR and a servant has to be made at some point, to make the servant a useable CORBA object. But this association can be done on-demand. Consider the following example scenarios to motivate the advantages of on-demand association:

• A pool of servants can be instantiated, and then associated in turn with IORs, as needed.
• A set of IORs can be created for the purposes of publishing the references to the Name Service, without going through the work to actually instantiate the servants.

Moreover, the POA allows a single servant to simultaneously support several IORs.

All of the above significantly contribute to scalable applications.

[ Top | Bottom | Previous section | Next section ]

[42.7] HOW DOES THE POA MAKE THE ASSOCIATION BETWEEN SERVANTS AND CORBA OBJECTS?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

This is where the Object ID and and POA Active Object Map come in. So, for a given POA, the Object ID identifies a specific CORBA object, which is used in the Active Object Map to identify the servant.

[ Top | Bottom | Previous section | Next section ]

[42.8] “FOR A GIVEN POA”, CAN THERE BE MORE THAN ONE?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

Yes. Actually, there can be more than one ORB per process, but this is another FAQ ;-)

[ Top | Bottom | Previous section | Next section ]

[42.9] HOW ARE MULTIPLE POAS DISTINGUISHED?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

Each POA has a name.

[ Top | Bottom | Previous section | Next section ]

[42.10] HOW ARE MULTIPLE POAS ORGANIZED?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

This is up to the application developer, but a POA hierarchy is supported. Each POA has a parent POA. There is an implicit Root POA.

[ Top | Bottom | Previous section | Next section ]

[42.11] WHAT ARE THE SEMANTICS OF THE POA HIERARCHY?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

This is better answered by describing what the semantics of the POA hierarchy are not.

• The POAs deal with policies, and the POA hierarchy is not a policy hierarchy.
• The POA hierarchy does not imply any default policies.
• The POA hierarchy does not imply any factoring of the servants by IDL interface or servant class.

In most cases, each servant is associated with at most one POA. The POA “owns” the servant and there are deletion responsibilities the POA will take. Deleting a POA will cause its servants to be deleted. Hence, the semantics of the POA hierarchy are only a containment hierarchy for POA deletion.

[ Top | Bottom | Previous section | Next section ]

[42.12] WHERE DOES THE POA MANAGER FIT IN?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The POA Manager is really a different beast all together. The POA Manager groups one or more POAs and provides common system resources, such as a network connection, to its POAs.

[ Top | Bottom | Previous section | Next section ]

[42.13] WHAT ARE THE POA POLICES?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The POA policies are used to configure the POA for a particular application design or scalability optimization. For example, if you have lots of a fine-grain objects, you may want one kind of optimization, whereas if you have lots of long-duration operations, you may want another kind of optimization.

The list of POA policies includes:

• Thread Policy
  • ORB_CTRL_MODEL - the ORB controls how threads are dispatched.
  • SINGLE_THREAD_MODEL - the is only one thread.
• Lifespan Policy
  • TRANSIENT - the POA’s object references are transient (i.e., likely conversational objects).
  • PERSISTENT - the POA’s object references are persistent, which means the POA should be registered with an locator/activator (i.e., likely entity objects).
• ID Uniqueness Policy
  • UNIQUE_ID - the POA does not allow a servant to be associated with more than one CORBA Object (Object ID).
  • MULTIPLE_ID - the POA will allow a servant to be associated with more than one CORBA Object (Object ID).
  • NOTE: The name of this policy is potentially confusing. The Object IDs are always unique for a given POA. This policy is describing the uniqueness or non-uniqueness of the association between Object IDs and servants.
• ID Assignment Policy
  • USER_ID - the application code can/will determine Object IDs for the POA’s CORBA Objects.
  • SYSTEM_ID - the POA will determine Object IDs for its CORBA Objects.
• Implicit Activation Policy
  • IMPLICIT_ACTIVATION - Allows the POA to add the servant to the AOM under conditions where the association is implicit, e.g., calling servant_to_reference().
  • NO_IMPLICIT_ACTIVATION - Servants can only be associated with an Object ID through an explicit call to do so.
• Servant Retention Policy
  • RETAIN - The POA uses an Active Object Map (AOM).
  • NON_RETAIN - The POA does not use an Active Object Map (AOM).
  • NOTE: The name of this policy is potentially confusing. The policy influences whether the POA has an Active Object Map (AOM) or not to track which servants are associated with Object IDs. The application is always in control of making and breaking this association. The NON_RETAIN policy means that no AOM is used, and hence the application has supplied a Servant Manager.
• Request Processing Policy
  • USE_ACTIVE_OBJECT_MAP_ONLY - The POA relies on its Active Object Map (AOM) only to determine which Object IDs are valid and associated with servants.
  • USE_DEFAULT_SERVANT - The POA will use a default servant for requests to Object IDs that are not in the AOM.
  • USE_SERVANT_MANAGER - The POA will use a servant manager to activate an Object ID/servant that is not in the AOM.

Note, there are some cases where the policies are inter-related in most practical situations. For example, a PERSISTENT Lifespan Policy probably implies a USER_ID ID Assignment Policy. Also, the use of the USE_ACTIVE_OBJECT_MAP_ONLY requires the use of RETAIN, and the use of IMPLICIT_ACTIVATION requires the use of SYSTEM_ID and RETAIN.

Since the POA and its policies are defined in IDL, this list may be extended, or features within a particular policy may be expanded.

[ Top | Bottom | Previous section | Next section ]

[42.14] WHAT IS A SERVANT MANAGER?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The Servant Manager is application code that essentially replaces the functionality of the POA’s Active Object Map (AOM). A servant manager is needed for sophisticated schemes to map Object IDs to servants.

[ Top | Bottom | Previous section | Next section ]

[42.15] HOW DOES A REQUEST GET TO THE RIGHT POA AND RIGHT SERVANT?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

The POA’s name is part of the IOR. Also, of course, the Object ID is in the IOR. So once the request gets delivered to the right machine (part of the request’s IOR), and to the right port (part of the request’s IOR), the POA Manager listening on that port looks at the object key (part of the request’s IOR). The object key contains the POA name and the Object ID. The POA Manager uses the object key to deliver the request to the right POA, and the POA uses the object key to determine the Object ID. Depending on the POA’s policies, it directly or indirectly uses that Object ID to deliver the request to the right servant.

[ Top | Bottom | Previous section | Next section ]

[42.16] HOW DOES THE POA SUPPORT OBJECT RELOCATION?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

Very well, indeed. The POA is the unit of location and activation. This means the POA is the unit of relocation. This is powerful. Since a POA can one object, a few objects, or a lot of objects, by design, then objects can be relocated individually are in groups.

A great way to think of the POA is as a named, logical endpoint.

[ Top | Bottom | Previous section | Next section ]

[42.17] HOW DO I MIGRATE FROM BOA TO POA?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

There is no specific answer. The migration impacts will depend on the system complexity. In particular, many large systems developed with the BOA needed to do POA-like things any way to scale.

There will be some emerging case studies. It is likely that POA migration is one of those things that is not overly difficult, but should not be done without a thought. An important thing to understand is that the migration can be an evolutionary thing as the use of the POA does not affect clients, and mixed POA and BOA systems interoperate at the network (IIOP) level.

[ Top | Bottom | Previous section | Next section ]

 E-mail us