CORBA meets Java

Learn to build a distributed Java applet that accesses server objects using CORBA

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


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,


, 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:,,,,,,, and As you might have guessed, the file contains the Java version of the ORBInfo interface declaration, but what do the other Java classes do?

The 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

1 2 Page 1
Page 1 of 2