Corba Services and Facilities

CORBA Server Features
The Object Implementation Side
An object implementation provides the semantics of the object, usually by defining data for the object
instance and code for the object's methods. Often the implementation will use other objects or
additional software to implement the behavior of the object.
Generally, object implementations do not depend on the ORB or how the client invokes the object.
Object implementations may select interfaces to ORB-dependent services by the choice of Object
Adapter.
1. Object Implementation Side Components
The Object Adapter provides interfaces between ORB and object, allowing the ORB to prepare the
object to receive a request, and allowing objects to notify the ORB that they are ready (or not ready) to
process requests.
Static IDL skeletons are the server-side equivalent of client stubs, created by the IDL compiler to
bridge between the ORB and the object implementation. There will be a skeleton for each object type
bound to the ORB.
The ORB uses the Dynamic Skeleton Interface to create a proxy skeleton for objects, typically remote,
whose static skeletons are not bound to it. ORBs will create a dynamic skeleton to pass the invocation
to the remote object via its own ORB.
Finally, there is the ORB interface itself, which provides operations on object references, plus access
to the Interface and Implementation Repositories. The object reference can take two forms: one is
directly useable in an invocation as either target or parameter; the other is the stringified object
reference since it is actually a text string.
2. Object Implementation Structure
An object implementation provides the actual state and behavior of an object. The client's view of the
object implementation is of an object instance that is always running, active, and ready to respond to
any operation in its IDL interface definition. There is no OMA operation to activate an object instance
(although there is an operation to create the instance, by invoking a factory object); the client just
sends an invocation.
The object implementation, the ORB, and CORBAservices work together to activate object instances
when needed, and then allow them to store their state and deactivate during periods
of nonuse. The object implementation interacts with the ORB in a variety of ways to establish its
identity, to create new objects, and to obtain ORB-dependent services. It primarily does this via
access to an Object Adapter, which provides an interface to ORB services that is convenient for a
particular style of object implementation.
When an invocation occurs, the ORB Core, object adapter, and skeleton arrange that a call is made to
the appropriate method of the implementation. A parameter to that method specifies the object being
invoked, which the method can use to locate the data for the object. Additional parameters are
supplied according to the skeleton definition. When the method is complete, it returns, causing output
parameters or exception results to be transmitted back to the client.
When a new object is created, the ORB may be notified so that it knows where to find the
implementation for that object. Usually, the implementation also registers itself as implementing
objects of a particular interface, and specifies how to start up the implementation if it is not already
running.

3. Object Adapters
An object adapter is the primary way that an object implementation accesses services provided by the
ORB. There are expected to be a few object adapters that will be widely available, with interfaces that
are appropriate for specific kinds of objects.
Object Adapters are responsible for the following functions:
• Generation and interpretation of object references
• Method invocation
• Security of interactions
• Object and implementation activation and deactivation
• Mapping object references to their corresponding implementations
• Registration of implementations.
The object adapter has three different interfaces:
• A private interface to the IDL skeleton
• A private interface to the ORB Core
CORBA - Object Adaptor
Object Implementation
15
1
Register
new Class
Up-call to method
Interface
A Stub
Interface
B Stub
13 Object References
2
Instantiate new
Object
Implement.
Repository
Object Adapter
14
Handle incomming
client Requests

• A public interface for use by the object implementations
4. The Basic Object Adapter (BOA)
An object adapter is an object that adapts the interface of another object to the interface expected by
the caller. In other words, it is an interposed object that uses delegation to allow a caller to invoke
requests on an object even though the caller does not know that object's true interface. The OMG
prefers not to see a proliferation of object adapters, so CORBA specifies a standard adapter called the
Basic Object Adapter (BOA). The BOA is supplied by every ORB and can be used for most CORBA
objects. The BOA includes interfaces for generating object references, registering implementations,
activating implementations, and some security related requests (e.g. authentication). It is designed
primarily for servers that reside in their own processes separate from their clients and the ORB.
The BOA can handle either a program per method, per object, or a shared program for multiple
instances of an object type. The BOA provides a small amount of persistent storage for each object,
typically used for storing a key to persistent storage.
5. The Static IDL Skeletons
This is the server side counterpart of the IDL stub interface. They connect to the server via the
mapping for its programming language, and to the Object Adapter via a proprietary interface.
Invocations pass through the skeletons from the Object Adapter to the implementation; requests return
by the corresponding return route.
Where object implementations coreside in the same process as their ORB and Object Adapter,
skeletons create virtually no noticeable load on the invocation. However, where the server
resides in its own process, the skeleton will have to manage IPC communications typically using either
shared memory or network communications.
6. The Dynamic Skeleton Interface
An interface is available which allows dynamic handling of object invocations. That is, rather than
being accessed through a skeleton that is specific to a particular operation, an object's implementation
is reached through an interface that provides access to the operation name and
parameters in a manner analogous to the client side's Dynamic Invocation Interface. Purely static
knowledge of those parameters may be used, or dynamic knowledge (perhaps determined through an
Interface Repository) may be also used, to determine parameters.
The Dynamic Skeleton Interface provides run time binding mechanism for servers to deliver request
from an ORB to an object implementation that does not have compile time knowledge of the type of
the object. The dynamic skeleton inspects the parameters of an incoming request to determine a
target object and method. The Dynamic Skeleton Interface entered the CORBA architecture along with
interoperability. However, the Dynamic Skeleton Interface specification is considered part of the
CORBA Core and not CORBA Interoperability. The Dynamic Skeleton Interface is implemented via a
Dynamic Implementation Routine. This mechanism is very handy for building bridges between ORBs.
When a client on one ORB calls a server on another ORB, the Dynamic Invocation Interface transmits
the request to the target ORB, and then the bridge uses the Dynamic Invocation Interface to invoke
the target object on that ORB. The target object is specified via the language binding, and the
operation is specified as a parameter. Without the Dynamic Skeleton Interface, this would be possible
only if the invoking ORB had linked a skeleton for the target object.
Dynamic Skeletons may be invoked both through client stubs and through the dynamic invocation
interface; either style of client request construction interface provides identical results. Dynamic
Skeleton Interface invocations do not enter the target via the same language-mapping constructs as
the static skeleton; instead, the object implementation is required to support the Dynamic
Implementation Routine.

7. The Implementation Repository
The Implementation Repository contains information that allows the ORB to locate and activate
implementations of objects.
The installation of implementations and control of policies related to the activation and execution of
object implementations is done through operations on the Implementation Repository.
In addition to its role in the functioning of the ORB, the Implementation Repository is a common place
to store additional information associated with implementations of ORB objects. For example,
debugging information, administrative control, resource allocation, security, etc., might be associated
with the Implementation Repository.