1. INTRODUCTION
CORBA (Common Object Request Broker Architecture) is a specification that describes how heterogeneous objects can interoperate. CORBA objects can be created/accessed using virtually any programming language (such as Java, C, C++, Smalltalk, Ada) and can exist on any platform (such as Windows, Unix, Linux, Solaris). This means that a Java application running under Windows can transparently access C++ objects created on a Unix platform.
Developers need not know what language a CORBA service is written in, or even where it is located physically making CORBA systems extremely versatile. A CORBA object may be shutdown, restarted on a different location and then re-registered with a name server. Clients can simply find the object by looking up the service and then continue to make requests.
The CORBA is specified and controlled by the well-known Object Management Group (OMG), which is a consortium of more than 700 companies that work together to create standards for object computing.
2. CORBA ARCHITECTURE
The OMA defines four major parts a CORBA-compliant system should have:
- An Object Request Broker (ORB)-This acts as a software bus for intercommunication of heterogeneous objects.
- CORBAServices—This defines additional system-level services the ORB may provide, such as Security, Naming, and Transactions.
- CORBAFacilities—This part defines application-level services, such as compound documents and other vertical facilities.
- Business Objects—This describes real-world objects and applications, such as a Book or a BankAccount.
2.1. IDL
A key feature of CORBA is IDL, a language-neutral Interface Definition Language. Interfaces to CORBA objects are written using IDL. This allows CORBA application developers to describe the service structure of an object without any language specific syntax. IDL interfaces are converted to or obtained from the language specific code using tools provided by the CORBA S/W provider. For example, Java provides a compiler idij for this purpose.
2.2. ORB
CORBA objects communicate through a broker called Object Request Broker (ORB). It is a library that enables low-level communication between CORBA compliant applications written in different programming languages. An application, during it life cycle, can ask ORB to do the following:
- Register and look up objects
- Marshal and un-marshal parameters from one programming language to another language
- Publish and retrieve metadata on objects on the local system for another ORB
- Handle security across your machine’s local boundary
- Invoke methods statically on a remote object using downloaded stub
- Invoke methods on a remote object using dynamic method invocation
- Automatically activate objects if they are not currently active
- Forward callback methods to appropriate local objects registered with the ORB
However, a developer need not know how those facilities are implemented. They simply use some hooks to use those facilities. This transparency makes CORBA the first choice for writing heterogeneous distributed applications.
2.3. IIOP
Communication between ORBs takes place using a TCP/IP-based protocol called Internet InterOrb Protocol (IIOP), which defines how CORBA-compliant ORBs pass information back and forth. It is also standardized by OMG.
2.4. IOR
CORBA provides several ways to locate CORBA objects. However, the most flexible one is Interoperable Object References (IORs). An IOR contains enough information required for a client ORB to connect to a remote server object or servant. IOR represents a reference to any CORBA object including naming service, transaction service, or customized CORBA servant. It contains the following information:
- IIOP version number
- Host and port number of the server, a request to be forwarded
- Class name and instance data required to create a local proxy (stub)
- A key that uniquely identifies the servant to the ORB exporting the servant
- Other information necessary for method invocations, such as supported ORB services and proprietary protocol support, etc.
A programmer need not know the information contained in an IOR. CORBA provides facilities to convert an IOR to a string (called stringified object reference). This string can then be transferred to other locations. CORBA also provides functions to reconvert the string to remote servant reference (essentially a reference to a local proxy/stub). The process of converting an IOR to a string or a string to a reference is known as stringification.
The CORBA standard, for stringification, defines the following two methods on org.omg.CORBA.ORB:
String object_to_string(org.omg.CORBA.Object o)
org.omg.CORBA.Object string_to_object(String ior)
The first one converts the given CORBA object reference to a stringified IOR, whereas the latter converts a stringified IOR produced by the method object_to_string() back to a CORBA object reference.
The representation of IOR is also ORB-implementation independent. So stringified object reference works across different CORBA vendors.
3. JAVA IDL
Java SDK provides an API (popularly known as Java-IDL) to support CORBA specification. This means Java-IDL enabled applications can interact with other applications that also support CORBA. The API consists of primarily the following packages: org.omg.CORBA, org.omg.CosNaming, org.
omg.PortableServer, org.omg.PortableInterceptor and org.omg.DynamicAny.
Source: Uttam Kumar Roy (2015), Advanced Java programming, Oxford University Press.