Consider this scenario. A distributed application codena-medDoors is to be developed for a company MacroHard, which has branches in NewDelhi, Los Angeles (LA) and Tokyo. This application is intended to synchronizeactivities, records, and information of all three branches. Thus, the entiresoftware is divided into three modules–A, B, and C–customized for the threebranches. The problem is that cities have different programming languageexpertise. New Delhi has Java programmers, LA has C++, and Tokyo has COBOL experts. So, if theseprogrammers were allowed to use their own programming languages, how wouldmodules A, B and C communicate in this distributed environment? Moreover,programmers in Delhi use Linux, in LA use Macs, and in Tokyo use Windows.
In this case, the application needs to be language andplatform independent. One solution for such an environment is CORBA (CommonObject Request Broker Architecture), developed by OMG (Object Management Group).CORBA is not a programming language, but a specification.
To make the above scenario work, we need to create aninterface for each module, which declares what functionality it will provide.For example, when module A communicates with module B through the interface, Awill know what functions B will provide, and the type of answer (return value)it can give back (return).
CORBA defines a standard for this kind of interface, usingwhat’s called an Interface Definition Language (IDL). IDL helps achievelanguage independence, as an interface defined in IDL can theoretically bemapped to any programming language using an IDL compiler. The compiler maps thedata structures defined in IDL to the data structures specific to a language.Thus, IDL interfaces are converted to Java interfaces in case of Java, and C orC++ header files in case of C or C++. As programmers will know, interfaces andheader files only define names of functions, the parameters they can accept, andthe type of return value. It’s up to the programmer to code the functionalityfor these functions.
|The CORBA IDL interface is available to both client and server objects
|Client object A tries to contact and locate server object B
|Client object asks for information about a parameter (x) from Server B
|Server object passes back information on the parameter (x)
From now on, we’ll call functions as methods, adhering tothe convention of object oriented languages.
The advantage of CORBA is that it not only works well withobject oriented languages like Java and C++ as it uses object oriented (OO)concepts like inheritance, polymorphism, interfaces, etc; but it can also beused with non-object oriented programming languages.
The other feature of CORBA–platform independence–isachieved by what’s called an Object Request Broker (ORB).
Let’s assume that an employee at the New Delhi branch wantsto know about a project X undertaken by MacroHard in LA. The project’sinformation is stored in a database in LA. The employee in New Delhicommunicates using object A on his machine with object B (module) at LA, overthe Internet. Object B uses an IDL interface to declare that a method namedgetInformation( ) can be called to query the project’s information from thedatabase. This IDL interface is also available to object A. Object A comes toknow through the interface that it has to call the method getInformation( ). Inthe present case, object A is called client object, since it’s asking object Bfor a service, and object B is the server object, since it provides the serviceto A.
Locating the server object
Locating the server object
To call the method getInformation( ) of the server object B,the client object A first needs to locate the object on the server and obtain a reference to it. So, before initializing the server object, the server–in our case, this is the machine on which the server object B lies–must start a CORBA naming service. The server object uses a unique name to register with the naming service. The client object locates the server object from the naming service,using this unique name. Subsequently, what the client gets is a reference,called IOR (Interoperable Object References), to the server object. The server object’s method–in our case, getInformation() of object B–will be executed on the machine on which the server object resides (the machine at LA).
Next, a server’s method–getInformation( ) in our case–can accept parameters. Let’s suppose the parameter it accepts is the name of the project X. Now, this parameter, which is in the machine-specific format, needs to be converted into a format that can travel across the network–in our case the Internet. This process is called marshalling and the reverse is called unmarshalling. When you compile the IDL, you also get what are called client stub and server skeleton. The client stub, residing on the client machine,provides information on the method(s) of the server object. Now, ORB comes into the picture.
ORBs are platform and language specific libraries provided by different vendors. ORBs achieve plat form independence through the process of marshalling and unmarshalling
When the client object has to invoke the server object’smethod, the required parameter name of the project is passed to the ORB by the client stub. The ORB then marshals the parameter, and the marshaled parameters are sent across the network to the machine on which the server object lies. On that machine, another ORB unmarshalls the parameters. This ORB will be specific to the language in which the server object is implemented and to the machine on which it lies. The unmarshalled parameter is now in the format specific to the server machine. This is then passed to a server skeleton. A server skeleton resides on the server, and is akin to the client stub on the client side. The server skeleton then passes the parameter to the server object. The method getInformation() of the server object is executed with the parameter, that is,X.
The result or the return value–the information about the project–is passed to the server skeleton, which communicates with the ORB,marshals the return value, which is then transferred to the client machine across the Internet. The client ORB then unmarshalls the return value, and passes it to the client object through the client stub. The client object can now display the information in a suitable format. Here, two ORBs (on the serverand client) communicate with each other. They use what’s called an Inter-ORB protocol to do this. In case of the Internet or a TCP/IP network, the name of the Inter-ORB protocol is IIOP–Internet Inter-ORB Protocol.
Next month, we’ll walk you through writing a CORBA application in Java, where you’ll be able to correlate the theoretical concepts detailed here.