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.

 

Client Side Architecture

 

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.

 

Implementation Side Architecture

 

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.