WHY
DOES CORBA NEED THE INTERFACE REPOSITORY?
The CORBA
specification support self desribing data types.
These are supported by the ANY data type and its associated typecodes.
The CORBA specification also provides Dynamic Invocation Interface and Dynamic Skeleton
Interface . Since the IIOP specification does not
provide self descirbing messages, an objects
interface must be accessible via the Interface Repository. This capability is
also critical for supporting up and down casting of super and sub interfaces
types.
WHAT
IS THE BOA?
NOTE: The
BOA has been deprecated by the OMG and replaced by the POA. ORB vendors may
support both the BOA and POA or either.
The CORBA
specification defines the BOA pseudo object in PIDL. BOA stands for Basic
Object Adapter. The BOA’s main purpose is to allow an object server to interact
with the ORB. A server process uses the BOA to tell the ORB when an object is
ready to perform operations.
WHAT
ARE THE FOUR BOA ACTIVATION POLICIES FOR A CORBA SERVER?
NOTE: The
BOA has been deprecated by the OMG and replaced by the POA. ORB vendors may
support both the BOA and POA or either.
CORBA
defines four activation policies for objects. Activation policies are specific
to the server process that “owns” the CORBA object. The activation policy
defines how objects are created within a server process. The BOA object ensures
that these activation policies are enforced. Enforcement of these rules can
simplify application development.
Note: The
CORBA activation policies are specific to creation. This means that the
activation policy does not manage the connection policy of a CORBA object. A
particular un-shared server might have only one CORBA object in its address
space. The activation policy does not forbid several client applications from
having object references that point to the same CORBA object. An application is
always free to _duplicate an object reference and pass it to some other
application.
Shared
Server: A shared server is a server process that is shared by many CORBA
objects. This means that a shared server could have more than one instance of a
particular CORBA object in its address space. This implies that different
object references of the same type refer to different CORBA object implemented
within the same process.
Un-Shared
Server: An un-shared server is allowed to construct at most one CORBA object
(of a given type) within its address space. This implies that different object
references of the same type refer to CORBA objects implemented within different
server processes.
Persistent
Server: A persistent server is a shared server that manages the activation of
objects itself. The BOA is not involved with enforcement of the activation
policy. A persistent server might start up at boot time and create a fixed
number of CORBA objects of varied types.
Per-Method
Server: The per-method policy results in a separate server for each request
made on the specified object. The BOA activates a per-method server for each
and every request made on the object. The server runs only until the request
has been serviced.
WHAT
IS THE POA?
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.
WHY
IS THE POA NEEDED?
The POA was
added to the CORBA specification for a number of reasons:
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.
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.
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.
DOES
THE POA AFFECT CLIENTS?
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.
DOES
THE POA AFFECT SERVERS?
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.
HOW
DOES THE POA BENEFIT NON-DISTRIBUTED OBJECTS?
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.
HOW
DOES THE POA MANAGE OBJECT LIFECYCLE?
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.
HOW
DOES THE POA MAKE THE ASSOCIATION BETWEEN SERVANTS AND CORBA OBJECTS?
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.
HOW
ARE MULTIPLE POAS DISTINGUISHED?
Each POA has
a name.
HOW
ARE MULTIPLE POAS ORGANIZED?
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.
WHAT
ARE THE SEMANTICS OF THE POA HIERARCHY?
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.
WHERE
DOES THE POA MANAGER FIT IN?
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.
WHAT
ARE THE POA POLICES?
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.
WHAT
IS A SERVANT MANAGER?
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.
HOW
DOES A REQUEST GET TO THE RIGHT POA AND RIGHT SERVANT?
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.
HOW
DOES THE POA SUPPORT OBJECT RELOCATION?
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.
HOW
DO I MIGRATE FROM BOA TO POA?
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.
No comments:
Post a Comment