[41] BOA
(Part of the CORBA FAQ, Copyright © 1996-99)

[41.1] WHAT IS THE BOA?

[Recently did some wordsmithing (12/1998) and added deprecation notice (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

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.

[ Top | Bottom | Previous section | Next section ]

[41.2] WHAT ARE THE FOUR BOA ACTIVATION POLICIES FOR A CORBA SERVER?

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

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.

1. 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.
2. 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.
3. 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.
4. 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.

[ Top | Bottom | Previous section | Next section ]

[41.3] ARE THERE ANY OTHER ACTIVATION POLICIES FOR CORBA OBJECTS?

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

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 four activation policies that are part of the BOA. Other activation policies are not explicitly defined, although many other possible policies might be useful. Some other possible policies are described below but since they are not part of the BOA, the policies are not enforced.

1. Limited Shared Servers: This could be a specialization of a shared server. Servers could support multiple object instances up to a certain limit.
2. Balanced Servers: This could be a collection of unshared servers. The pool of servers could support a number of object references and the policy could demand that each server support a equal percentage of object references.

[ Top | Bottom | Previous section | Next section ]

 E-mail us