CORBA Concepts & Terminology

Object Request Broker enables objects to transparently make and receive reqeusts and responses in a distributed environment. ORB provides interoperability between applications on different machines in hetrogenous distributed environments and seamlessly interconnects multiple object systems. ORB is responsible for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect which is note refelected in the object's interface. The ORB manages the control transfer and data transfer to the object implementation and back to the client. If ORB cannot complete the invocation, it raises an exception.

CORBAServices is a collection of services (interfaces and objects) that support basic functions for using and implementing objects. These services are independent of application domain. They can be thought as augmenting and complementing the functionality of the ORB.

CORBAFacilities is a collection of IDL-defined frameworks that provide services of direct use to application objects, they are not as fundamental as CORBAServices. Some of the services are:

Life Cycle Service - defines operations for creating, copying, and moving, and deleting components on the bus.
Persistence Service - provides a single interface for storing components persistently on a varietyof storage servers.
Naming Service - allows components on the bus to locate other components by names.
Event Service - allows components on the bus to register or unregister their interest in specific events.

Request is issued by client and would consist of an operation, a target object, zero or more (actual) parameters and an optional request context.

Interface is a description of a set of possible operations that a client may request of an object.
Principal Interface is the most specific interface that the object supports.

Interface inheritance provides the composition mehcanism for permitting an object to support multiple interfaces.
Genericity in operations is via interface inheritance in IDL and the total decoupling of implementation from interface specification.

Dynamic Invocation Interface - is an api that allows client to make dynamic invications on remote CORBA objects. It is used when at compile time a client does not have knowledge about an object it wants to invoke. Once an object is discivered, the client program can obtain a definition of it, issue a parametrized call to it, and receive a reply from it, all w/o having a type-specific client stub for the remote object.

Dynamic Skeleton Interface - is an api that provides a way to deliver requests from an ORB to an object implementation when the type of the object implementation is not known at compile time. DSI, which is the server analog to the client side DII, makes it possible for the application programmer ti inspect the parameters of an incoming request to determine a target object and method.

Object Implementation is a definition that provides the information needed to create an object and to allow the object to participate in providing an appropriate set of services.

Marshalling - Conversion of a structured data into a programming language and architecture independent format. ORB = Dynamic Invocation Interface + IDL Stubs + ORB Interface + Static IDL Skeleton + Dynamic Skeleton + Object Adapter

Client makes a request to ObjectImplementation through ORB.

Definitions of the interfaces to the objects can be defined in two ways:

Interface Definition Language (IDL) - defines the types of objects according to the operations that may be performed on them and the parameters to those operations
Interface Repository - represents the components of an interface as objects permitting run-time access to these components

Both IDL & IR have equivalent expressive power

Interface Repository is a run-time distributed database that contains machine-readable versions of the IDL interfaces. (at the client side)

Implementation Repository provides a run-time repository of information about the classes a server supports, the objects that are instantiated, and their IDs. (at the server side)

Client can make a request either through Dynamic Invoation Interface (DII - the same interface dependent of the target object's interface) or an OMG IDL stub (specific stub depending on the interface of the target object). Object Implementation receives a request as an up-call either through the OMG IDL generated skeleton or though a dynamic skeleton.

The dynamic and stub interface for invoking a request satisfy the same request semantics, and the receiver of the message cannot tell how the request was invoked.

ObjectImplmentation may call the Object Adapter and ORB while processing a request or at other times.

Client and ObjectImplementation may interact with ORB through ORB Interface for some functions. This ORB Interface is the same for all ORBs and does not depend on the object's interface or object adapter.

If a client is simultaneously accessing two object references managed by two different ORB implementations, it is the responsibility of the ORB to distinguish their object references, not the client.
Object implementations select interfaces to ORB-dependent services by the choice of Object Adapter. Thus a variety of object implementation can be supported through the use of additional object adapters.

All ORBs must provide the same language mapping to an object reference for a particular programming language. This permits a program written in a particular language to access object references indenpendent of the particular ORB.

A particular mapping of OMG IDL to a programming language should be the same for all ORB implementations.

Clients access object-type-specific stubs as library routines in their program. Thus for each object accessible through the ORB, there is a corresponding stub.

An object reference can also be converted to a string that can be stored in files or preserved or communicated by different means and subsequently turned back into an object reference by the ORB that produced the string. (Persistency of object)

An object implementation provides the actual state & behaviour of an object.

Object Adapter provides an interface to ORB services for a particular style of object implementation. It is responsible for the following functions:

Generation & interpretation of object references
Method invocation
Security of interactions
Object and implementation activation and deactivation
Mapping object references to the corresponding object implementations (***)
Registration of implementations

These functions are performed using the ORB core and any additional components necessary.

Object Adapter defines most of the services from the ORB that the Object Implementation can depend upon.

With Object Adapters, it is possible for an Object Implementation to have access to a service whether or not it is implemented in the ORB core-if the ORB core provides it, the adapter simply provides an interface to it; if not, the adapter must implement it on top of the ORB core. Every instance of a particular adapter must provide the same interface and service for all the ORBs it is implemented on. However, it is not necessary for all Object Adapters to provide the same interface or functionality. Each Object Adapter is tuned to the Object Implementation that it is supporting.

Most Object Adapters are desiged to cover a range of object implementations, so only when an implementation requires radically different services or interfaces should a new object adapter be considered.

Portable Object Adapter (POA) can be used with multiple ORBs with a minimum of rewriting needed to deal with different vendor's implementations.

OMG IDL is the language used to describe the interfaces that client objects call and object implementations provide.

OMG IDL is a declarative language, i.e. it does not include any algorithmic structures or variables.

Java IDL adds CORBA (Common Object Request Broker Architecture) capability to the JavaTM platform, providing standards-based interoperability and connectivity.

No interface repository is provided as part of Java IDL. An interface repository is not required because under normal circumstances, clients have access to generated stub files.

A client is any code (perhaps itself a CORBA object) that invokes a method on a CORBA object. The servant is an instance of the object implementation the actual code and data that implements the CORBA object.

Complete Operation
The client of a CORBA object has an object reference for the object and the client uses this object reference to issue method requests. If the server object is remote, the object reference points to a stub function, which uses the ORB machinery to forward invocations to the server object. The stub code uses the ORB to identify the machine that runs the server object and asks that machine's ORB for a connection to the object's server. When the stub code has the connection, it sends the object reference and parameters to the skeleton code linked to the destination object's implementation. The skeleton code transforms the call and parameters into the required implementation-specific format and calls the object. Any results or exceptions are returned along the same path.

The client has no knowledge of the CORBA object's location, implementation details, nor which ORB is used to access the object. Different ORBs communicate via the OMG-specified Internet InterORB Protocol (IIOP).

General Inter ORB Protocol (GIOP) specifies a standard set of message formats for communication between ORBs. GIOP was designed specifically for ORB to ORB communication using any connection-oriented protocol.

Internet Inter ORB Protocol (IIOP) is the wire protocol that ensure interoparability between client applications and CORBA objects. IIOP is a mapping of the GIOP messaging to TCP/IP connections.

Interoperable Object Reference identifies a CORBA object that can be accessed using IIOP. IOR allows a client application to make remote method calls on a CORBA object. An IOR contains a type ID and a set of one or more tagged profiles. The tag indicates the protocol ID (of which 0 indicates IIOP) and the profile contains a TCP/IP host address, a TCP/IP port, and an identifier that identifies the object. IOR is the key element to CORBA's interoperability support.

An IDL compiler such as idltojava translates the CORBA object definitions into a specific programming language according to the appropriate OMG language mapping. Thus, the idltojava compiler translates IDL defintions into Java constructs according to the IDL-Java language mapping.

The stub and skeleton files are generated by the idltojava compiler for each object type. Stub files present the client with access to IDL-defined methods in the client programming language. The server skeleton files glue the object implementation to the ORB runtime. The ORB uses the skeletons to dispatch methods to the object implementation instances (servants).

For each IDL interface, idltojava generates a Java interface and the other .java files needed, including a client stub and a server skeleton.

The Java IDL ORB supports transient objects only - objects whose lifetime is limited by the server process lifetime. Such an object can be made persistent if it store it's state in a file and re-initialize itself from the file at server creation time.

Clients typically obtain object references in the following ways:

from a factory object. For example, the client could invoke a create method on DocumentFactory object in order to create a new Document. The DocumentFactory create method would return an object refererence for Document to the client.
from the nameservice. For example, the client could obtain an object reference for the DocumentFactory by issuing a request on the nameservice.
from a string that was specially created from an object reference

The Java IDL Transient Nameservice is an object server provided with Java IDL. The Name Server stores object references by name in a tree structure similar to a file directory. A client may lookup or resolve object references by name. It is a a simple implementation of the COS Naming Service specification.

The server class has the server's main() method, which:

Creates an ORB instance
Creates a servant instance (the implementation of one CORBA object) and tells the ORB about it
Gets a CORBA object reference for a naming context in which to register the new CORBA object
Registers the new object in the naming context under a name "foobar"
Waits for invocations of the new object

The client's responsibility:

Creates an ORB
Obtains a reference to the naming context
Looks up "foobaro" in the naming context and receives a reference to that CORBA object
Invokes the object's foobar() operation and prints the result

Note:- idltojava is hard-coded to use a default preprocessor. On Windows machines, it uses the MS Visual C++ preprocessor. On Solaris machines, it uses the path /usr/ccs/lib/cpp when looking for the preprocessor. You can change the preprocessor that idltojava uses by setting two environment variables: CPP and CPARGS. Set CPP to the full pathname of the preprocessor you want to use. Set CPARGS to the complete list of arguments to be passed to the preprocessor. You can also turn off the preprocessor by adding -fno-cpp to the idltojava command line.

The complete specification for the CORBA architecture, adopted and published by the OMG, is partitioned into three main sections:

CORBA Core
CORBA Interoperability - ORB interoparbility allows a client implemented using one vendor's ORB to use the services of a server implemented using another vendor's ORB.
Mappings of OMG IDL to different languages - IDL is used to describe an object's interface, it's behaviour, in a language independent manner.

Some of the implementations of ORBs

Visigenic's Visibroker for Java
Iona's OrbixWeb

The BOA, Basic Object Adapter provides access to ORB's services such as object activation, deactivation, registration, and Object ID assignment.

The POA, Portable Object Adapter provides protability for the server implementation of an object.

org.omg.CORBA - provides the mapping of the OMG CORBA APIs to the Java programming language, including the class ORB, which is implemented so that a programmer can use it as a fully-functional Object Request Broker (ORB).

Holder Classes - OMG IDL uses OUT and INOUT parameters for returning values from operations. The mapping to the Java programming language, which does not have OUT and INOUT parameters, creates a special class for each type, called a holder class. An instance of a holder class can be passed to a Java method as a parameter, and a value can be assigned to its value field. This allows it to perform the function of an OUT or INOUT parameter.
The package org.omg.CORBA contains a Holder class for each of the basic types (BooleanHolder, LongHolder, StringHolder, and so on). It also has Holder classes for each generated class (such as TypeCodeHolder), but these are used transparently by the ORB, and the programmer usually does not see them.

Helper Classes - Helper classes, which are generated for all user-defined types in an OMG IDL interface, supply static methods needed to manipulate those types.

The idltojava compiler generates portable client stubs and server skeletons that work with any CORBA-compliant Object Request Broker (ORB) implementation which includes the Java IDL ORB provided with the JDK 1.2.

An ORB allows distributed web-enabled Java applications to transparently invoke operations on remote network services using the industry standard Internet Inter-ORB Protocol (IIOP) defined by the Object Management Group.

Requests on objects are marshalled into a common format that can be understood by a variety of language and operating systems.

Application Objects are products of a single vendor which controls their interfaces.

An object reference will identify the same object each time the reference is used in a request.

Questions & Doubts

Where does the client get object references from ?
Client knows that it wants to invoke a function FUNC1(param1, param2, param3) on object OBJ1. How does it place a request for this to happen ? What's the series of calls that needs to be made for it ?
What kind of functionality does ORB Interface provide ?