Friday 20 May 2016

OmniORB finally worked

It took me nearly a week to get a basic idea of CORBA.

The Definition

In summary of it CORBA stands for Common ORB Architecture.Common Architecture means a technical standard. ORB stands for object request broker.It is an object oriented version of Remote Procedure Call.An ORB is basically a mechanism for invoking operations on an object in a different process. Basically CORBA is a technical standard that governs the behavior of an ORB - how it should go about doing its work.

The ORB definition looks pretty normal - different process- no big deal. But what make it special is that the different process can reside in an entirely different address space ,on a different network on a different operating system and even in a different language too.This is where distributed computing comes into play,i.e. two entirely different systems (different processor,different memory) working to solve the same problem communicating with each other via Inter Process Communication channels.

For CORBA to come into play, there needs to be a server, a process which contains objects and client, a process which wants objects ( Do not confuse this with the regular definitions of server and client!). The objects involved in the process are written in a different language called as IDL (Interface Definition Language). It is  another object oriented language very similar to C++ and JAVA. And coding with IDL should not be difficult for anyone who has a good hand over any object oriented language.

How does CORBA work?
 CORBA objects are written in IDL.The IDL code is however not used by itself. The IDL code needs to be passed through an IDL compiler to generate the language mapping to any of the popular object oriented languages of your choice. It basically depends on the vendor od the ORB. But language mapping are there for most popular languages e.g. C++, Python, JAVA,COBOL etc.

CORBA generates two major codes a stub code for the client and a skeleton code for the server. The client process invokes operations on the stub code which gives output to it. The stub code has the mechanism to marshal the details of the invocation via a stringified object reference (IOR - Inter Operable Object Reference)and communicate via IPC channels with the skeleton code. The skeleton code also does not contain the real language implementation of the object. The skeleton code unmarshals the details of invocation and passes it to the server mainline code which produces the real implementation of the object known as servants and thus the operation is invoked.

 This is a very high level overview of CORBA. For more details please refer to

http://www.ciaranmchale.com/corba-explained-simply

And for an even better understanding please do download any ORB and run a few tutorial example. For C++ programmers, Omni ORB is god to start. It has got a very easy to understand documentation and a tutorial example called echo.I highly recommend this for beginners who do not have any experience with CORBA.

http://www.omniorb-support.com/

I have setup an Omni ORB environment and tested the echo example to verify its working correctly.

My next step would be to directly analyze the scripts from the previous port and make the necessary changes. I would go over RTT in detail if required later. For now it is really important to maintain focus on the real work at hand. I have done the Rock tutorials which serves as a good enough introduction to RTT. So i don't think I should face much problems in the work ahead.







No comments:

Post a Comment