The most important part of knowing CORBA is, you should know the full form of CORBA, that is Common Object Request Broker Architecture. You dont even have to necessarily understand this full form, if you are only planning to see where it fits in a software solution.

To understand CORBA, let us start with our simple program. Remember the functions which we would have used in our first C program. One such function that every one is familiar is part of the famous "Hello World" Program. The function we used was the 'printf' function which takes in a "Hello World" as parameter and does some task of outputting it on to a console.

printf("Hello World");

The signature of this function as defined in one of the headers would be

void printf(char* p_strOutput);

Now assume that we want to output this "Hello World" onto another machines console instead of your own machine. Let us see one way to do this.

We could use some sort of mechanisms like RPC(Remote Procedure Call). That is we make this function/procedure a remote procedure, that can be invoked remotely. We will prefix it with RPC and call this function

void RPC_printf(char* p_strOutputFromRemoteMachine);

Now basically we have defined this function and will henceforth call this as an interface. Once we have defined this interface, we need to implement this interface so that it prints onto the console what ever is passed on to the 'p_strOutputFromRemoteMachine' parameter. We can as well assume that the implementation of this 'RPC_printf' functions is the same as the one used by the normal printf function. Now one question that would come up in mind is. We have jsut copied the same implementation of the function 'printf' and renamed it by giving a prefix 'RPC_'. How will this work remotely? Once we answer this question, we can as well understand what is RPC, and can then go ahead to understand what is CORBA in its basic structure.

First and foremost, the C function printf cannot be accessed across the process or across the machine boundary. Both of the caller, that is our Hello World program and the implementation of the printf function has to be on the same machine and within the same process. But our interface RPC_printf can be accessed across processes and machine boundaries. How do we do that? Once we have created the interface RPC_printf. we now generate some helper methods that will help us put this to the outside world. We could use some tool to generate what is known as the stub/skeleton in CORBA terminology. The stub is what is used on the client side. On the client side, the client will make a call RPC_printf and to the user of this method on the client, it will just be that he has made a call similiar to the printf statement. But since it is a stub onto which the call is made, the stub will take care of passing the information to the relevant skeleton on the other process which can possibly lie on the other machine. The task of identifying and sending it to the remote server machine is done by the stub on the client side.

Now the information has gone to the server side or the server skeleton. It is the reponsbility of the server skeleton to do the task that is required of the function RPC_printf and return back. The skeleton of the server side now delegates it to our implementation of RPC_printf, which can be just the copy of the implementation of the normal printf fucntion. Once this function is completed, the skeleton on the server side will pass information back to the client stub to indicate that he has completed the task sucessfully.

If we have understood the above scenario, then we have already understood RPC. But RPC has some limitations. Let us examine them. Most of the RPC will always work only on the same platforms and with the same set of language interfaces. The C style RPC on solaris will not necessarily work with the C style RPC on windows. Moreover, it could also be tied to a specific language and also a specific network protocols. We cannot call this C style interface from Java(It will give us compiler errors in the first step itself). CORBA indeed solves these 3 problems of platform, operating and network dependencies for a RPC mechanism.

Let us examine how the problems are solved by CORBA. To solve language independence, the interface RPC_printf now renamed as 'CORBA_printf' will use its own proprietary language which is defined by the IDL constructs. Using IDL constructs we can construct a CORBA IDL interface. The CORBA IDL constructs defines a type called string. This type can be mapped to char* of a C function or string class of a Java function. And lo, we have solved the problem of language dependency. Now who does this mapping from IDL to a specific language? This is done by the IDL compiler. For each of the language where we want to use CORBA, we will have to use the IDL compiler to generate equivalent interfaces for our language. Now the language problem is solved. What about the platform and network dependency? CORBA solves this, by using specific protocols which have to be implemented by some body called an ORB vendor. CORBA defines something called, as an IIOP which works on TCP/IP. Since this is available with all the Opearting System, we have in effect solved the Operating System and Network dependency. With this CORBA has solved all our problems of language/platform/network dependency. Now what we typically come across as ORB is nothing, but a service or program which does all this stuff for us.

Two other RPC mechanisms, that should be mentioned is COM/DCOM and RMI. As we saw earlier, there are some limitations. COM/DCOM is popular among the windows programmers. But the main problem with this is, this cannot be used with Unix like machines. With Java as a platform independent solution, we can solve this problem of being dependent on Operating System platform by using RMI(Remote Method Invocation). But it fails to solve the problem related to different language. All RMI calls have to be made and written in Java only. This may not be a problem for fresh developement. But if we have legacy systems, we cannot overwrite everything from scratch and move all our huge code base, say for example from 'C' language to 'Java' language. The following table shows this.

'Mechanism'     'Language'      'Operating System' 'COM/DCOM'      'Yes'           'No' 'RMI'           'No'            'Yes' 'CORBA'         'Yes'           'Yes'

Now we can write our function in any language, publish its equivalent IDL, implement the IDL interface. Once this is done, then we can have this function being invoked by any langauge, across any Operating System.

i.e Our 'CORBA_printf' can now be written in C language and implemented on solaris Operating System and then we can have this method being called by a Java client from a windows Operating System.