Funcionamiento

CORBA

CORBA, the Common Object Request Broker Architecture, is a powerful tool for distributed programming. It is a language-independent standard specified by the Object Management Group (OMG). Many CORBA implementations, both free and commercial, exist for a wide variety of languages (e.g., C, C++, Java, Perl, Python, and Smalltalk). CORBA allows communication between software written in any programming language running on any operating system on any hardware architecture. It handles all serialization and de-serialization of objects and method parameters so that programmers do not have to worry about endian issues and other system incompatibilities.

Overview

CORBA is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network). Version 1.0 was released in October 1991. CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a mapping from IDL to a specific implementation language like C+

+ or Java. Standard mappings exist for Ada, C, C+

+, Lisp, Ruby,Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.

The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (and reference) instantiation policies, object lifetime policies, etc. The Object Adapter is used to register instances of the generated code classes. Generated code classes are the result of compiling the user IDL code, which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user process for interfacing with the CORBA infrastructure.

Some IDL language mappings are "more hostile" than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather straightforward and makes usage of CORBA very simple in a Java application. The C++ mapping is not trivial, but accounts for all the features of CORBA (e.g.

exception handling). The C mapping is even stranger (since C is not an object-oriented language), but it does make sense and properly handles the RPC semantics.

A language mapping requires the developer ("user" in this case) to create some IDL code that represents the interfaces to his objects. Typically, a CORBA implementation comes with a tool called an IDL compiler which converts the user's IDL code into some language-specific generated code. A traditional compiler then compiles the generated code to create the linkable-object files for the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:

Illustration of the autogeneration of the infrastructure code from an interface defined using the CORBA IDL

This figure illustrates the high-level paradigm for remote interprocess communications using CORBA.

Issues not addressed here, but that are accounted-for in the CORBA specification include: data typing, exceptions, network protocol, communication timeouts, etc. For example: Normally the server side has the Portable Object Adapter (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts often have interceptors that are described below. Issues CORBA (and thus this figure) does not address, but that all distributed systems must address: object lifetimes, redundancy/fail-over, naming semantics (beyond a simple name), memory management, dynamic load balancing, separation of model between display/data/control semantics, etc.

In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.

Interoperability

Different objects, written in different programming languages, can interact with each other by using CORBA. ORB (Object Request Broker) provides common services to objects written in different languages. For example, Visibroker provides a common nameserver for C++/Java Technology CORBA objects. In some cases, two different ORBs may need to interact, such as a C++; CORBA object that uses the ORBIT ORB; to talk to a Java Technology object that uses the Java Technology ORB.

CORBA objects use IOR (Interoperable Object Reference) to communicate. ORB makes the IOR transparent to the programmers. In general, for object A to talk to object B, A uses the IOR of object B. IOR is the object's address that other objects can refer to. CORBA specification provides detailed information on the fields of the IOR. There are three ways to obtain the IOR of an object:

1. string_to_object

You can obtain a stringified object reference (Email, disk, file, etc.) and use the string_to_object call to convert

it into an object reference.

2. resolve_initial_references

You can use this call to get IORs to a small set of well known services.

For example, to use the nameserver in a single ORB environment, you make the following call:

resolved_initial_references("NameServer");

The ORB returns the IOR to the name server.

3. Lookup

You can look up the IOR in the naming service. Once you have the IOR, you can convert it into an active object reference by using the string_to_object call and then invoke methods on it. In an ORB environment that supports binding for multiple languages (e.g. Visibroker and ORBacus support C++ and the Java Programming Language), the ORB provides an uniform naming service to objects of all the languages it supports.

The naming service holds information about all the objects in the ORB. In a single ORB environment, the naming service is transparent.

If you want objects located on two different ORBs to interact and they share a common nameserver, you would use the Lookup method. However, if the objects are located on different ORBs, then the client needs to get the IOR from the server objects. There are two ways to get the IOR from the server objects:

1. You can use a stringified reference for Object B. B writes its reference in a location that is accessible by Object A (such as on a shared NFS drive). A then performs the following:

try {

BufferedRead in=

new BufferedReader( new

FileReader( "account.ref" ) );

ref = in.readLine();

} catch( IOException ex) {

System.out.println( "Could not open file 'account.ref'" );

System.exit( -1 );

}

org.omg.CORBA.Object obj = orb.string_to_object( ref );

2. You obtain an IOR for the nameserver of the ORB in which the other object resides. You then use the nameserver to get the reference to Object B. To get the IOR for the nameserver of the target ORB, you can use well known (published) IORs or stringified IOR. For example, you can use the -ORBNamingIOR argument to provide the NamingService IOR to the calling object.

Here is an example of Interoperability between the Java Technology 2 ORB and Mico, a GPLd 2.3 CORBA compliant ORB. This section explains how a C++ object talks to a Java Technology object, and more specifically how a C++ client makes calls to a JavaTechnology Server. The easiest way is for the Java Technology object to store its IOR in a publicly available location. Then the C++ client reads it and requests services from the Java Technology object.

Another method is to use the name server. For example, in one window, you type:

tnameserv -ORBInitialPort 1050 tnameserv prints out its IOR to the terminal.

In another window, you run the Java object:

java HelloServer -ORBInitialPort 1050 Now you can run the C++ client:

./client -ORBNoCodeSets -ORBNamingIOR IOR:010000...

You do not need to change any of the codes. Here are some of the benefits of using nameserver instead of using plain IORs:

1. You can dynamically discover services and bind to them.

2. You need only one IOR, that of the NameServer, to make calls to all objects.

3. You can browse through all the names that are in the NameServer and choose the calls you need to make.