New York
University
Computer
Science Department
Courant
Institute of Mathematical Sciences
The Object Request Broker
(ORB) Architecture
Course Title: Application Servers Course
Number: g22.3033-011
Instructor: Jean-Claude Franchitti Session: 4
The Object Request Broker (ORB) manages interaction
between clients and servers. This includes the distributed computing
responsibilities of location, referencing and 'marshalling' of parameters and
results.
The CORBA
specification defines an architecture of interfaces and services that must be
provided by the ORB, no implementation details. These are modular components so
different implementations could be used, satisfying the needs of different
platforms.
The ORB manages the interactions between clients and object implementations. Clients issue requests and invoke methods of object implementations.
The client side architecture provides clients with
interfaces to the ORB and object implementations. In consists of the following
interfaces:
Dynamic
Invocation
- This interface allows for the specification of requests at runtime. This is
necessary when object interface is not known at run-time. Dynamic Invocation
works in conjunction with the interface repository.
IDL Stub - This component consists
of functions generated by the IDL interface definitions and linked into the
program. The functions are a mapping between the client and the ORB
implementation. Therefore ORB capabilities can be made available for any client
implementation for which there is a language mapping. Functions are called just
as if it was a local object.
ORB Interface - The ORB interface may be
called by either the client or the object implementation. The interface
provides functions of the ORB which may be directly accessed by the client
(such as retrieving a reference to an object.) or by the object
implementations. This interface is mapped to the host programming language. The
ORB interface must be supported by any ORB.
ORB core - Underlying mechanism used
as the transport level. It provides basic communication of requests to other
sub-components.
The implementation side interface consists of the
ORB Interface, ORB core and IDL Skeleton Interface defined below:
IDL Skeleton
Interface -
The ORB calls method skeletons to invoke the methods that were requested from
clients. Object Adapters (OA) - Provide the means by which object
implementations access most ORB services. This includes the generation and
interpretation of object references, method invocation, security and
activation. The object adapter actually exports three different interfaces: a
private interface to skeletons, a private interface to the ORB core and a
public interface used by implementations. The OA isolates the object
implementation from the ORB core. The CORBA specification envisions a variety
of adapters, each providing specific services. The Basic Object Adapter (BOA)
is the most generic of the Object adapters.
Requests
The client requests a service from the object
implementation. The ORB transports the request, which invokes the method using
object adapters and the IDL skeleton.
The client has an object reference, an operation
name and a set of parameters for the object and activates operations on this
object. The Object Management Group / Object Model defines each operation to be
associated with a controlling parameter, implemented in CORBA as an object
reference. The client does not know the location of the object or any of the
implementation details. The request is handled by the ORB, which must locate
the target object and route the request to that object. It is also responsible
for getting results back to the client.
The request makes use of either the dynamic
invocation (dynamic link) or the IDL Stubs (static link) interface. Static
links use the IDL stubs (as local function calls) and dynamic request use the
DII . The object implementation is not aware of the difference. If the
interface was defined in the IDL and the client has an interface for the target
object the IDL stub is used. This stub is specific to the target object. The
DII is used when the interface is not known at runtime. The DII uses
information stored in the interface repository to establish the request.
Requests are passed from the ORB to the object implementation through the IDL
skeleton. The object implementation is made available by using information
stored in the implementation repository. The object implementations encapsulate
state and behavior of the object. CORBA only defines the mechanisms to invoke
operation, it does not define how activated or stopped, made to persist, etc.
Object Adapters
Object Adapters (OA) are the primary ORB service
providers to object implementations. OA have a public interface which is used
by the object implementation and a private interface that is used by the IDL
skeleton.
Example services provided by
OA's are:
·
Method
invocation ( in conjunction with skeleton),
·
Object
implementation activation and deactivation,
·
Mapping
of object reference to object implementations,
·
Generation
of object references, and
·
Registering
object implementations, used in locating object implementations when a request
comes in.
OA's may be specialized. They are a major player in
delivery of requests and are the primary service provider for object
implementations. CORBA only defines the Portable Object Adapter (POA) and any
CORBA implementation must provide a POA. The POA specification deprecates the
original BOA specification. It appears that BOA interfaces were not written
precisely enough to guarantee the portability of server code from one vendor’s
ORB to another. CORBA assumes the definition of additional object adapters.
There should not be a large number of adapters since one adapter can service
more than one implementation.
Object references
Requests are issued upon object references. Object
references are opaque references only uniform within an ORB implementation.
Since both clients and servers are using object references as opaque
references, different representation will not affect them. CORBA does have an
object reference that is used to denote no object. It is guaranteed to be
different from any other object reference, and usually maps to the null or nill
object.
Object Services
Object services refer to fundamental services
provided by their own objects that support common interactions between other
objects. The services follow the OMG Common Object Services Specification
(COSS) guidelines. Current object services include:
·
Event
Management services which refer to the asynchronous communication of different
CORBA objects with one another.
·
Naming
Object services that maps a human-readable name (string) to an object relative
to its context.
·
Persistent
services assure that an object (CORBA developed) outlives its creator. It
allows an objects state to be retained at a given point in time. This feature
is used when a host crashes or is rebooted.
·
Life-cycle
services determine the methods for an object creation and termination.
·
Concurrency
services provide for distributed locks on a given object.
·
Externalization
services collect objects and transport them as serial objects.
·
Relationship
Objects are used for CORBA object modeling and graphing.
·
Transaction
object services allow the sharing of a transaction among multiple objects.
Common Facilities
This is one of the newer areas of OMG
standardization. These are higher level specification for supporting
interoperability. This is the level most application developers will utilize.
The specifications call for higher-level services and vertical market specialty
areas. Some examples of common facilities would include system management and
compound documents. Specialty areas would be more specialized such as
geospatial data processing and financial services.
ORB Interface Operations
The ORB provides operations on references and
strings. Two operations for converting an object reference to strings and back
again. An is_nil operation for testing whether an object reference is
referencing no object. A duplicate operation allows for a duplicate reference
to the same object to be created. A release operation is provided to reclaim
the memory used by an object reference.
In addition, the ORB provides two operations used
for returning meta-information from the interface and implementation
repositories. The get_interface operation is used to extract information
regarding the object type. The get_implementation operation returns an object
that describes the object implementation from the Implementation Repository.