Previous | Table of Contents | Next |
The POA is designed to enable programmers to connect servants to:
• type-specific skeletons, typically generated by OMG IDL compilers, or
• dynamic skeletons.
Servants that are members of type-specific skeleton classes are referred to as type-specific servants. Servants connected
to dynamic skeletons are used to implement the Dynamic Skeleton Interface (DSI) and are referred to as DSI servants.
Whether a CORBA object is being incarnated by a DSI servant or a type-specific servant is transparent to its clients. Two
CORBA objects supporting the same interface may be incarnated, one by a DSI servant and the other with a type-specific servant.
Furthermore, a CORBA object may be incarnated by a DSI servant only during some period of time, while the rest of the time
is incarnated by a static servant.
The mapping for POA DSI servants is language-specific, with each language providing a set of interfaces to the POA. These
interfaces are used only by the POA. The interfaces required are the following.
• Take a CORBA::ServerRequest object from the POA and perform the processing necessary to execute the request.
• Return the Interface Repository Id identifying the most-derived interface supported by the target CORBA object in a request.
The reason for the first interface is the entire reason for existence of the DSI: to be able to handle any request in the
way the programmer wishes to handle it. A single DSI servant may be used to incarnate several CORBA objects, potentially supporting
different interfaces.
The reason for the second interface can be understood by comparing DSI servants to type-specific servants.
A type-specific servant may incarnate several CORBA objects but all of them will support the same IDL interface as the most-derived
IDL interface. In C++, for example, an IDL interface Window in module GraphicalSystem will generate a type-specific skeleton
class called Window in namespace POA_GraphicalSystem. A type-specific servant that is directly derived from the POA_GraphicalSystem::Window
skeleton class may incarnate several CORBA objects at a time, but all those CORBA objects will support the GraphicalSystem::Window
interface as the most-derived interface.
A DSI servant may incarnate several CORBA objects, not necessarily supporting the same IDL interface as the most-derived IDL
interface.
In both cases (type-specific and DSI) the POA may need to determine, at runtime, the Interface Repository Id identifying the
most-derived interface supported by the target CORBA object in a request. The POA should be able to determine this by asking
the servant that is going to serve the CORBA object.
In the case of type-specific servants, the POA obtains that information from the type-specific skeleton class from which the
servant is directly derived. In the case of DSI servants, the POA obtains that information by using the second language-specific
interface above.
11.2.10 Location Transparency
The POA supports location transparency for objects implemented using the POA. Unless explicitly stated to the contrary, all
POA behavior described in this specification applies regardless of whether the client is local (same process) or remote. For
example, like a request from a remote client, a request from a local client may cause object activation if the object is not
active, block indefinitely if the target object's POA is in the holding state, be rejected if the target object's POA is in
the discarding or inactive states, be delivered to a thread-unaware object implementation, or be delivered to a different
object if the target object's servant manager raises the ForwardRequest exception. The Object Id and POA of the target object
will also be available to the server via the Current object, regardless of whether the client is local or remote.
Note – The implication of these requirements on the ORB implementation is to require the ORB to mediate all requests to POA-based
objects, even if the client is coresident in the same process. This specification is not intended to change CORBAServices
specifications that allow for behaviors that are not location transparent. This specification does not prohibit (nonstandard)
POA extensions to support object behavior that is not location-transparent.