The CORBA Architecture In this section, you get some additional detail on CORBA, IDL, and the Java

IDL ORB promised earlier. Any relationship between distributed objects has two sides: the client and the server. The server provides a remote interface, and the client calls a remote interface. These relationships are common to most distributed object standards, including RMI and CORBA. Note that in this context, the terms client and server define object-level rather than application-level interaction--any application could be a server for some objects and a client of others. In fact, a single object could be the client of an interface provided by a remote object and at the same time implement an interface to be called remotely by other objects. This figure shows how a one-method distributed object is shared between a CORBA client and server to implement the classic "Hello World" application.

A one-method distributed object shared between a CORBA client and server. On the client side, the application includes a reference for the remote object. The object reference has a stub method, which is a stand-in for the method being called remotely. The stub is actually wired into the ORB, so that calling it invokes the ORB's connection capabilities, which forwards the invocation to the server. On the server side, the ORB uses skeleton code to translate the remote invocation into a method call on the local object. The skeleton translates the call and any parameters to their implementation-specific format and calls the method being invoked. When the method returns, the skeleton code transforms results or errors, and sends them back to the client via the ORBs.

Between the ORBs, communication proceeds by means of a shared protocol, IIOP--the Internet Inter-ORB Protocol. IIOP, which is based on the standard TCP/IP internet protocol, defines how CORBA-compliant ORBs pass information back and forth. Like CORBA and IDL, the IIOP standard is defined by OMG, the Object Management Group. In addition to these simple distributed object capabilities, CORBAcompliant ORBs can provide a number of optional services defined by the OMG. These include services for looking up objects by name, maintaining persistent objects, supporting transaction processing, enabling messaging, and many other abilities useful in today's distributed, multi-tiered computing environments. Several Java ORBs from third-party vendors support some or all of these additional capabilities. The ORB provided with Java IDL supports one optional service, the ability to locate objects by name. CORBA stands for Common Object Request Broker Architecture.This is a framework for communication between distributed objects in a language neutral fashion.This means that using the CORBA framework, a JAVA object residing in one machine can communicate with a C++ object residing in some other machine.To achieve this the Objects interface needs to be defined in a language such that the interface can be implemented by any object wishing to communicate with other objects implementing the same interface.This language is called the Interface Definition Language or IDL.

Interface Definition Language-IDL

IDL is part of the CORBA specification which was introduced by the Object Management Group(for more details visit www.omg.org). Mappings have been defined between IDL and almost all popular languages.Once the interface is defined in IDL, the definition can be converted into a language specific interface definition using IDL compilers specific to a particular language.For example the idl2java utility bundled with jdk1.2 and idlj bundled with jdk1.3 do this conversion for JAVA.Similarly third party implementations are available for conversion to other languages also(Notably Borlands implementation known as the Visibroker provide this implementation for C++).

The backbone of CORBA is the Object Request Broker or the ORB.An ORB is a communication layer through which objects communicate with one another.The following diagram make this concept clear.

C C++ Object

J JAVA Object

O ORB for C++

O ORB for JAVA

TCP/IP and other Network layers

T

From the above diagram it is clear that in order for two objects to communicate there should be an ORB to which the object is connected.The ORB marshals and unmarshals the various method calls(arguments and return values) between objects shielding the objects themselves from the lower implementation details of the network.

Now in order for one object(say a client) to communicate with another object(say a server),the client need to have some sort of an interface to the servers behaviour.This interface is obtained by first obtaining the interface for server written in IDL and then converting it into a language specific class or interface appropriate for the client.Secondly,there should be some kind of a reference available to the client on which the methods available in the interface can be invoked.Thirdly, there should be an ORB which will

marsahal and unmarshal method invocations and return values.Now the earlier diagram can be redrawn as given below.
C++ Object
C C Client

JAVA Object S Server

Servers
I Interface in C++

Servers Interface in i JAVA

Servers Stub in C++

Server Skeleton in JAVA

O ORB for C++

O ORB for JAVA

TCP IP and other Networking Layers

T

In the above diagram except for the servers stub, everything else is locally available.This is because the Servers interface on the client side is obtained from the IDL.The class definition required to create a stub object is also obtained from the IDL compiler along with the other necessary classes which help in converting generic data types to specific ones.The only problem is the location of the server object itself.How can the client obtain a live reference to a server object located somewhere on the network?.Once this reference is obtained,the servers stub class,which the client has, can be used to create a proxy server object on the client.IDL also generates a Helper class for each CORBA object so that object references which are transmitted as CORBA Objects can be converted into specific object references(in java through the Helper classs narrow method).

Thus the problem now boils down to obtaining a live reference to a Remote Object.This can be obtained in two ways.

1. 2.

By using a Name Server By obtaining a Stringified reference.

Corba Services

The CORBA standard specifies various services that an implementation can support.The principal ones are 1. 2. 3. 4. 5. 6. 7. Life Cycle Naming Persistence Events Transactions Querying Properties.

Of these the Life Cycle and naming Services are critcal.Life Cycle services allow you to manage the life cycle of an object in a particular system.Using this service an application program can create,delete,copy or move objects in a specific system.The Naming service on the other hand lets a remote client locate an object on the network with out actually knowing the location of the object.

Corba Name Server

Every CORBA implementation provides some kind of a Name Server to which Objects can be bound,similar to rmiregistry in RMI.In Suns implementation for JAVA , this is a utility called tnameserv.Once an object is bound to this Name server,a client can obtain the bound objects reference.The Name server itself could be running on a different machine from the machine where the Server object is located..This is the most standard way of obtaining remote references.

Using Stringified Object Reference

Also known as Inter Operable Reference or IOR, IOR represents a live object reference as a string.A client can obtain an IOR to an object and create a live Object reference from the IOR.This is useful when an object can not be bound to a Name Server and still need to be accessed by a client.Suns implementation provides two methods in the org.omg.CORBA.Orb interface : the object_to_string(object) and the string_to_object(String), to convert IOR to Objects and vice versa.

For example, if we have an Object A bound to a Name Server,which has a method getObjectB() which in turn returns a B object, then Object B must be defined in the IDL(as a struct data type).When idlj executes,this struct data type is converted into a final class which can not be subclassed.The class thus created implements the Serializable interface.More specifically,this class implements the org.omg.CORBA.portable.IDLEntity.This is a tag interface that tells the ORB that this class has been generated by an IDL compiler and that it has a Helper and Holder class.No stub or Implbase class is generated for this class and therefore this class can not process remote requestsAs such when such an object is returned,the object is passed to the client by value.Ideally we would want to pass a reference to this object and yet not bind this object to a Name server.We can do this using stringified reference.

In the IDL definition, we define the getObjectB() as returning a string.We also define a separate IDL for Object B with methods that want to be remotely accessible.In the getObjectB() methods implementation, we create B object, connect it to an ORB and then covert Bs reference to a string using the object_to_string(Object) method.We then return this string to the client.Now the B object is ready to service client requests.On the client side, this string is converted back to an Object and then narrowed.The resulting object reference can be used to invoke methods on the B object residing on the server.This is analogous to exporting objects in RMI.