CORBA meets Java

We’ve all accessed Web sites that allow us to interact with a server script via the use of HTML forms and the Common Gateway Interface (CGI). Sites often use this technique to prompt a person to enter a username and password to log in to a site. The Username and Password variables are passed to a server script that verifies that a given user indeed can access certain portions of a site. This process is done via HTTP, which (as you may or may not know) is a stateless protocol. Each time a new page is loaded, you are effectively disconnected from the server and it has no knowledge of who you are and what you are currently doing. Thus, even after logging into such a site, each page accessed from that point on must pass the username and password back to the server to verify the user’s right to access the page. In other words, your client application (the Web browser) and the server application (the Web server) have no concept of local variables, local method calls, or objects.

Just after the software development community’s decades-long struggle to encapsulate code as objects appeared to finally be succeeding, we found ourselves tumbling backward in time to a stateless, “batch”-mode of computing.

However, it’s not all bad. The Web has provided us with the revolutionary advantages of standards-based, open protocols and platform independence. While tens of thousands of sites use HTTP and CGI to retrieve user information, run a script on the server, and possibly return additional information to the user, these sites cannot be thought of as actual “applications,” in the traditional sense of the word. In addition, all code for these sites had to be written from scratch because of the new technologies used (HTTP and CGI). To retrofit existing software applications to the Web, or to build truly powerful new applications using the Internet/intranet as a communications backbone, a technology must be used that possesses the following “Holy Grail” of attributes:

• Support for legacy code currently existing in C, C++, and COBOL (among other languages)
• Java support in order to allow mobile, platform-independent, object-oriented applications to be built
• Vendor-neutrality, so that applications can be maintained and can flourish over time
• Scalability to handle large numbers of users
• Wide platform support to avoid platform “lock-in”
• An object-oriented development paradigm (because of the many advantages inherent in OOP)
• End-to-end security
• Broad industry support

Enter CORBA.

Through the course of this article you will see that only one technology, CORBA, truly fulfills our wish list (and then some). In addition, you will see that because Java and CORBA are very complementary technologies, you can quickly and cost-effectively begin CORBA development in Java.

A brief introduction to CORBA

CORBA is a specification that defines how distributed objects can interoperate. Until the explosion in popularity of the World Wide Web, and in particular, the Java programming language, CORBA was basically a high-end, distributed-object solution primarily used by C++ developers.

The actual CORBA specification is controlled by the Object Management Group (OMG), an open consortium of more than 700 companies (including my employer) that work together to define open standards for object computing. CORBA objects can be written in any programming language supported by a CORBA software manufacturer such as C, C++, Java, Ada, or Smalltalk. These objects can also exist on any platform that is supported by a CORBA software manufacturer such as Solaris, Windows 95/NT, OpenVMS, Digital Unix, HP-UX, and AIX, among others. This means that we could have a Java application running under Windows 95 that dynamically loads and uses C++ objects stored across the Internet on a Unix Web server.

Language independence is made possible via the construction of interfaces to objects using the Interface Description Language (IDL). IDL allows all CORBA objects to be described in the same manner; the only requirement is a “bridge” between the native language (C/C++, COBOL, Java) and IDL. CORBA objects communicate with each other using an Object Request Broker (ORB) as an intermediary, and can communicate over many popular networking protocols (such as TCP/IP or IPX/SPX). ORBs from different vendors communicate over TCP/IP using the Internet Inter-Orb Protocol (IIOP), which is part of the CORBA 2.0 standard (the latest version).

Currently, third-party ORBs are available for the more popular programming languages (including C++, Smalltalk, Java, and Ada95). As other languages grow in popularity, CORBA vendors undoubtedly will release ORBs for those languages, as well.

The OMG originally defined the Object Management Architecture (OMA) in 1990 to describe how applications could interoperate. As a subset of this goal, a standard needed to be set to articulate how the pieces, or objects, within applications could interoperate — thus the birth of CORBA. The OMA defines four major parts that can make up a CORBA installation:

1. The Object Request Broker acts as a software bus for objects to intercommunicate.
2. CORBAServices define system-level services that are added on to the ORB, such as Security, Naming, and Transactions.
3. CORBAFacilities define application-level services, such as compound documents and other vertical facilities.
4. Business Objects describe real-world objects and applications, such as an Airplane or a BankAccount.

Hands on: CORBA development in Java

To build a distributed Java applet that accesses server objects using CORBA, we will make use of a popular commercial ORB and will use the IDL to define interfaces to our objects. The

Resources

section at the end of this article provides the contact information for several popular CORBA vendors. For the example applet we will build, I have chosen to use the Visigenic VisiBroker for Java. This ORB has been licensed by several different companies, including Oracle, Netscape, and Novell, and is included with Netscape Navigator 4.0.

Note: You can run this applet in a browser other than Netscape Navigator 4.0. The applet will start a little slower because several extra Java class files must be downloaded to the client.

We will build a simple Java applet that instantiates a server object using CORBA. For the sake of simplicity, this server object also will be written in Java. The server object will store an array of information about various CORBA ORB vendors and their products. The client applet will instantiate the object and query the array in order to update the screen. A more complete example (and one I encourage you to consider) would be to store the ORB information in a relational database and use JDBC (or some other means of database access) on the server to retrieve the requested information. This approach would create a true three-tier application using CORBA.

Before beginning the construction of the application, we’ll examine in more detail the ORB and the IDL used to define the interface to the object.

The Object Request Broker in detail

The most important piece of the Object Management Architecture is the ORB. The ORB is the only portion of CORBA that must be present in order to build a CORBA-compliant application. Many ORBs ship without any of the CORBAServices or CORBAFacilities, and you must create (or purchase) the Business Objects yourself. However, without the ORB, a CORBA application cannot function.

The most visible function of a CORBA ORB is to respond to requests from your application or from another ORB. During the life-cycle of your running CORBA application, your ORB may be asked to do many different things, including:

• Look up and instantiate objects on remote machines
• Marshal parameters from one programming language (such as C++) to another language (such as Java)
• Handle security across your machine’s local boundary
• Retrieve and publish metadata on objects on the local system for another ORB
• Invoke methods on a remote object using static method invocation described by a downloaded stub
• Invoke methods on a remote object using dynamic method invocation
• Automatically start objects that aren’t currently up and running
• Route callback methods to the appropriate local object that it is managing

The great thing about the ORB is that nearly all of the implementation details for all of these duties are hidden from the software developer. Simply providing the appropriate “hooks” in your code to initialize the ORB and register your application with the ORB opens your application up to a vast galaxy of distributed objects.

Describing objects using IDL

In order for CORBA to maintain its vendor-neutral and language-neutral position, there must be some intermediary between C++ CORBA server code, for example, and a Java CORBA client. This intermediary, as you know, is the IDL. Related methods and properties supported by an underlying object are grouped together into a single interface using IDL. Once the IDL interface is complete, it can be compiled into the language of your choice in the form of both stub and skeleton code. IDL compilers are included with all ORBs. For instance, a Java/IDL compiler is included with the Visigenic VisiBroker for Java ORB, while a C++/IDL compiler is included with the Visigenic VisiBroker for C++ ORB.

Note that it is much easier to work with IDL than a standard object-oriented programming language because IDL cannot be used to specify actual implementation of classes or the methods within them. Instead, IDL is used only to describe the interface to the underlying objects.

After reading this section you will be familiar enough with the language to understand the examples presented later in the article. For a more thorough presentation on IDL, visit the OMG Web site. (See the Resources section below.)

Just as properties and methods are grouped together into related classes in Java, these items are contained within modules in IDL. There can be one or more interfaces defined within each IDL module. Listing 1 shows a simple IDL module named TheModule that contains a basic interface named TheInterface. This interface contains a single variable (TheVariable, of course) defined to be an integer value.

Listing 1: The simplest IDL module possible

Module TheModule
{
     interface TheInterface
     {
          long TheVariable;
     };
};

If you compile this IDL module using an IDL-to-Java compiler (such as Visigenic’s idl2java), you will get the Java interface shown in Listing 2.

Listing 2: The Java equivalent of TheModule

package TheModule;
public interface TheInterface
{
     public int TheVariable;
}

The ORBQuery applet

Now that you have a basic understanding of an ORB and IDL, we are ready to construct our ORBQuery applet. The client applet will consist of a standard Java GUI and will instantiate a remote CORBA object. Once this object has been instantiated, its methods can be called to determine information about a specific CORBA ORB. On the server side, we need to define five methods in order to retrieve the following information about a particular ORB: Name, Vendor, Operating System, Languages, and URL. Therefore, we must construct an IDL interface that defines five methods to retrieve this information. This interface,

ORBInfo

, is defined in Listing 3.

Listing 3: The ORBInfo IDL interface

module ORBQuery
{
     interface ORBInfo
     {
          string GetName(in long index);
          string GetVendor(in long  index);
          string GetOS(in long index);
          string GetLanguages(in long  index);
          string GetURL(in long  index);
     };
};

The VisiBroker installation includes an IDL compiler, idl2java, that you can use to generate the necessary Java code required to implement this interface. Once you’ve installed the package, simply execute the following command to generate the code:

idl2java ORBInfo.idl

This operation will create a subdirectory named ORBQuery (corresponding to the ORBQuery Java package). Within this directory, there are eight files: ORBInfo.java, ORBInfoHolder.java, ORBInfoHelper.java, _st_ORBInfo.java, _sk_ORBInfo.java, ORBInfoOperations.java, _tie_ORBInfo.java, and _example_ORBInfo.java. As you might have guessed, the ORBInfo.java file contains the Java version of the ORBInfo interface declaration, but what do the other Java classes do?

The ORBInfoHolder.java file contains a holder class used when passing parameters, while the ORBInfoHelper class defines various utility functions. The _st_ORBInfo class defines the client stub, while the _sk_ORBInfo class defines the server skeleton class. The ORBInfoOperations and _tie_ORBInfo classes are used to implement a tie mechanism, a VisiBroker feature designed to allow the implementation class to inherit from a class other than the skeleton class. We will not use these classes directly within this example. Finally, _example_ORBInfo contains a sample server object that can be extended to build the server application.

If you haven’t yet put it together, the eight Java classes created by the IDL compiler have given us a framework (in the form of helper classes, a stub, a skeleton, and an interface) to construct our own client/server CORBA application in Java.

Building the server application

Next we need to create a server application that registers a ORBInfo object with the server ORB. This new object will extend the skeleton class and also will implement the ORBInfo interface. Therefore, two new classes are required for the server: one to define the server object and implement the ORBInfo interface and another to register this object with the server ORB. The ORBQuery class contains standard Java code that retrieves a specific element from an array and returns it. The Server class is where the CORBA-specific functionality is located.

In the following example, we first initialize the ORB. Next, we register our class with the ORB using the ORBInfo string, which is the string that the client will use to retrieve an object. When all of these operations have been completed, we tell the ORB we’re ready by calling boa.obj_is_ready().

Listing 4 shows the Server class, which registers the ORBInfo object with the ORB.

Listing 4: The Server class

public class Server {
  public static void main(String[] args) {
    try {
      // Initialize the ORB.
      org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
      // Initialize the BOA.
      org.omg.CORBA.BOA boa = orb.BOA_init();
      // Create the ORBQuery.
      ORBQuery serverQuery = new ORBQuery("ORBInfo");
      // Export the newly create object.
      boa.obj_is_ready(serverQuery);
      System.out.println(serverQuery + " is ready.");
      // Wait for incoming requests
      boa.impl_is_ready();
    }
    catch(org.omg.CORBA.SystemException e) {
      System.err.println(e);
    }
  }
}

Listing 5 shows the ORBQuery class, which implements the interface and, therefore, the five helper methods.

Listing 5: The ORBQuery class

import java.util.*;
class ORBQuery extends ORBQuery._sk_ORBInfo {
  String[][] ORBVendors =
      {{"PowerBroker","Orbix","VisiBroker","ComponentBroker","Solaris NEO"},
      {"Expersoft Corp.","Iona Technologies","Visigenic Software","IBM","Sun"},
      {"OLE and ActiveX Bridges; Windows95/NT; Solaris; HP-UX; AIX; JDK 1.0.2",
      "Windows95/NT, MVS, OS/2, QNX, VxWorks, Solaris, HP-UX, Irix, AIX, Digital UNIX, OLE Bridge",
      "Windows95/NT, Sun OS, Solaris, HP-UX, AIX, Irix",
      "Windows95/NT, Solaris, HP-UX, AIX, OS/390, OS/2, AS/400",
      "Solaris (Client & Server), Windows95/NT (client), JDK 1.0.2"},
      {"C++, Java", "Java, Smalltalk, Ada95, C++", "Java, C++", "Java, C++", "Java, C++"},
      {"http://www.expersoft.com", "http://www.iona.com", "http://www.visigenic.com",
      "http://www.software.ibm.com/ad/cb", "http://www.sun.com/solaris/neo/solaris_neo/index.html"}};
  ORBQuery(String name) {
    super(name);
  }
  public java.lang.String GetName(int index)
  {
    String Name;
    Name = ORBVendors[index][0];
    return Name;
  }
  public java.lang.String GetVendor(int index)
  {
    String Vendor;
    Vendor = ORBVendors[index][1];
    return Vendor;
  }
  public java.lang.String GetOS(int index)
  {
    String OS;
    OS = ORBVendors[index][2];
    return OS;
  }
  public java.lang.String GetLanguages(int index)
  {
    String Languages;
    Languages = ORBVendors[index][3];
    return Languages;
  }
  public java.lang.String GetURL(int index)
  {
    String URL;
    URL = ORBVendors[index][4];
    return URL;
  }
}

Now that we’ve created all of the necessary server code, our next step is to build a client applet that initializes the client ORB, which then instantiates and uses the server object we just created.

Building the CORBA applet

Just as the server object needs to be registered with the server ORB, client applets or applications need to register themselves with the client ORB, as well. When the client would like to retrieve remote CORBA objects, it doesn’t do so directly. Instead, it notifies the client ORB of the object it would like to instantiate, and the ORB handles the ORB-to-ORB communications. This request is done with the following two lines of code (when using VisiBroker for Java):

// Initialize the ORB (using the applet).
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(this);
// Retrieve an ORBInfo interface object for use by the applet
ORBInfoQuery= ORBQuery.ORBInfoHelper.bind(orb, "ORBInfo");

After calling the bind() method, our ORBInfoQuery local variable becomes “bound” to the server ORBInfo object. Once this operation has been completed, we can call the helper methods to populate our applet. Keep in mind that although this example was implemented totally in Java, the server object could have been implemented in COBOL, C++, Ada, or Smalltalk.

Note: Because the Java ORB classes are dynamically downloaded with the applet, it may be slow to display.

A more detailed introduction to CORBA would also introduce CORBAServices and different object activation schemes available within the CORBA standard. For more information on these topics, visit the OMG Web site or consult the documents referenced in the Resources section at the end of this article.

Conclusion

As we have seen, building a CORBA Java applet requires a few more steps and is somewhat more complicated than building a basic Java applet. In fact, it is also more difficult than building a pure Java distributed object application using RMI. However, the combination of Java and CORBA allows you to build more scalable and more capable applications than can be built using the JDK alone. In addition, the reality is that very few Java applications currently exist in the enterprise today. The ability to reuse and extend existing legacy code using CORBA allows developers to protect their existing investment, while taking advantage of the Java programming language.