Introducing CORBA

The Object Management Group (OMG) defines the Common Object Request Broker Architecture (CORBA), an architecture that allows you to build distributed objects and services. The architecture is independent of any particular language implementation or system architecture. Thus, you can produce remote objects in one language, say C++, and then consume them from a client object written in another language, such as Java. Because the CORBA standard allows communication between disparate languages, applications, and systems, it is necessarily extensive. However, to understand how CORBA works, there are four main aspects of the architecture that you should appreciate:

• Object Request Broker (ORB)

• The Naming Service

• Inter-ORB communication

• Interface Definition Language (IDL)

All communication among objects and clients occurs through the Object Request Broker (ORB). An ORB runs on both the client and the server. Figure 19.5 shows the roles of the ORBs in client-server communication. You can see that a client application makes a request on a stub that exposes the methods of the remote object. The client ORB forwards that request to the remote ORB and, in turn, this ORB forwards the request through the skeleton to the remote object.

CORBA defines a number of transport protocols that allow distributed ORBs to communicate. The most popular of these is the Internet Inter-ORB Protocol (IIOP), which is based on TCP/IP. Although you will learn more about this protocol later in today's lesson, it is very unlikely that you will have to work with it at a low-level.

The CORBA Naming Service allows you to register an instance of a class, so that a client can look up this instance and gain a reference to it. You will learn more about how this works later in today's lesson in the “Using RMI over IIOP” section.

CORBA IDL

CORBA-compliant remote objects expose interfaces that are defined in Interface Definition Language (IDL). IDL syntax is based on C++ but should be relatively easy to follow by someone familiar with Java.

The following Java interface extract taken from the Agency bean in the case study

public interface Agency extends javax.ejb.EJBObject
{
    String getAgencyName() throws java.rmi.RemoteException;

    Collection findAllApplicants() throws java.rmi.RemoteException;
    void createApplicant(String login, String name, String email)
             throws java.rmi.RemoteException, agency.DuplicateException,
                    javax.ejb.CreateException;
    void deleteApplicant (String login) throws java.rmi.RemoteException,
                                                   agency.NotFoundException;
...
}

is equivalent to the following IDL module:

module agency {
    interface Agency: ::javax::ejb::EJBObject {

        readonly attribute ::CORBA::WStringValue agencyName;
        ::java::util::Collection findAllApplicants( );
        void createApplicant(
            in ::CORBA::WStringValue arg0,
            in ::CORBA::WStringValue arg1,
            in ::CORBA::WStringValue arg2 ) raises (
            ::javax::ejb::CreateEx,
            ::agency::DuplicateEx );
        void deleteApplicant(
            in ::CORBA::WStringValue arg0 ) raises (
            ::agency::NotFoundEx );
...
};

As you can see, there is a strong similarity between the syntax of the two definitions; this similarity has been emphasized by using the full Java class names in the first extract. For example, the Java class javax.ejb.EJBOject maps onto the IDL class javax::ejb::EJBOject.

After you have an IDL interface, you compile it to produce a client stub and an object skeleton. It is through the stub and skeleton that clients and objects communicate. The OMG provides a number of standard mappings that map CORBA IDL to other programming languages. Examples of these languages include

• Java

• Python

• Smalltalk

• COBOL

• C++

Using the Sun Microsystems' Java IDL tools, you can write, instantiate, and consume distributed objects that comply with CORBA. The J2SE SDK provides tools for mapping between IDL and Java interfaces so you do not have to write or even understand IDL files.

If you want to use CORBA to access a service, the service provider will supply the IDL file for the interface to that service. Once you have an IDL definition of a service, you can use the J2SE supplied idl2j utility to generate an equivalent Java interface definition for that service.

With the Java interface for the service, you can write client programs to communicate with the server, as described next in the “RMI over IIOP example” section.

The opposite is also possible. If you have a Java service, you can make this available to non-Java clients by supplying an IDL file for your service's interface. The rmic compiler supplied with the J2SE SDK can be run with the –idl option to generate an IDL file from a Java interface. The rmic compiler is discussed further in the section “Using RMI over IIOP” but as an illustration of its use, the following command

rmic –idl agency.Agency

was used to generate the previous IDL example.