Building Distributed Applications with Java and CORBA

Bryan is a senior member of the technical staff with TASC Inc. He can be reached at [email protected].

The Object Management Group (OMG) was formed to help define product-independent object standards in the form of a distributed object architecture -- the Common Object Request Broker Architecture (CORBA). CORBA is a vendor-independent operating system. In addition, CORBA is a distributed architecture that currently specifies a total of 18 services (known as "CORBAServices") for handling transactions, security, naming, object-lifecycle management, and other tasks. In short, CORBA is a specification that defines how objects interoperate over a network. The actual implementation of this architecture is left to individual software vendors. (For specific information on the OMG and its activities, visit http://www.omg.org/.)

Although it's been around since 1991, interest in CORBA is growing due to ntiered client/server development efforts. n-tiered development separates the user interface from the application logic and the underlying data. In this manner, individual tiers can be modified or scaled without requiring changes to other tiers. Because CORBA is inherently object based, it works well as an architecture for building n-tiered client/server systems.

Java, however, brings forward the concept of platform-independent, object-oriented applications or applets that can be mobile and dynamically loaded from a remote server. Using Java applets, code doesn't actually even need to be installed on a user's machine. Instead, code can be loaded dynamically to users as required. In theory, an n-tiered web application written in Java eliminates the problems of code distribution and versioning. Each time users hit your site, they receive a new version.

A CORBA Backgrounder

CORBA objects are accessed through the use of an interface, which is like a Java interface in that it is used to describe -- not implement -- an object's attributes and methods. CORBA interfaces, regardless of the programming language to be used, are first described using the OMG's Interface Definition Language (IDL). IDL can only be used to define attributes, methods, and parameters to those methods within an interface. Once the IDL has been constructed for a interface, it is compiled using a vendor's IDL-to-some-language compiler. (For instance, Visigenic includes an IDL-To-Java compiler with its VisiBroker For Java.) In addition, the OMG also defines mappings between IDL and languages such as C++, Java, and Cobol. Once an official mapping has been defined, IDL compilers will produce code that can be used with any vendor's product. This means that you could use the VisiBroker IDL compiler to produce Java code for use with Iona Technologies OrbixWeb Object Request Broker (ORB).

One CORBA application never talks directly to another. Instead, an application issues requests for interfaces to the ORB -- the most important piece of the software architecture -- running on the local machine. The local ORB then passes the request to an ORB on a remote machine. The remote ORB then locates the appropriate object and passes an object reference back to the requester. In short, a CORBA 2.0-compliant ORB can:

• Lookup 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.
• Auto-start objects that aren't currently up and running.
• Route callback methods to the appropriate local object being managed.
• Communicate with other ORBs using the Internet Inter-ORB Protocol (IIOP).

Important functional pieces within an ORB include:

• The Basic Object Adapter (BOA), which provides policies for activating object implementations (shared server, unshared server, server-per-method).
• The Implementation Repository, which stores information about each object located on the server.
• The Object Activation Daemon, which is responsible for activating a server upon receiving a client's request for an object.
• The Interface Repository (IR), which is an online database of metadata about ORB Object types.
• The Dynamic Invocation Interface (DII), which allows client programs to dynamically construct requests for objects based on information contained in the IR.

All implementation details of the ORB are hidden from you. To use an ORB to access remote CORBA objects, the application obtains a reference to the ORB object, and calls the appropriate methods to access remote objects.

IIOP is another interesting feature of CORBA 2.0. IIOP is a wire-level protocol that resides on top of TCP/IP. It lets one vendor's CORBA 2.0-compliant ORB exchange objects with another's. Before IIOP, each vendor's ORB spoke a proprietary protocol and would only interoperate with other ORBs of the same type. Obviously, for objects to coexist and work together on something like the Internet, a standard protocol was required so that CORBA could move beyond its initial status as a niche technology.

A CORBA application that is written using Java would have the advantages of being platform-independent, object-oriented, and dynamically loaded, while including support for legacy systems written in C++, Smalltalk, Ada, or Cobol, and supporting scalability from the level of an NT server all the way up to a mainframe running MVS. In addition, this application could have full access to the variety of CORBAServices and support for the access of distributed objects running under real-time embedded operating systems.

Here, I'll examine the concepts behind CORBA application development in Java, using Borland's JBuilder 1.0 and Visigenic's VisiBroker For Java 3.0, a CORBA 2.0-compliant Object Request Broker (ORB). Borland's JBuilder client/server version includes a copy of the VisiBroker For Java ORB. All the code I present can be compiled using the Java Development Kit 1.1 (http://www.javasoft.com/).

Computing with Distributed Objects

Distributed applications can currently be built using Java in either a two-tier (client and server) or a multiple-tier architecture. If the size of the application is fairly small, little code will ever be reused, and if the number of users is small (less than 30), a two-tier architecture will work fine and you are free to consult another source on how to construct a Java client/server application using JDBC. However, if one or more of those requirements are not met, you should probably look into examining a three-tiered solution. The first tier will contain the user interface and some basic logic for handling interactions with the user. It will instantiate and use objects located on the middle tier (the object layer) using some type of object model. Since many applications use some type of relational database, assume the third tier will be the database server containing all data, and any necessary triggers and stored procedures.

Java Development with Borland JBuilder

JBuilder is a Java 1.1-only tool that includes support for JDBC, the 1.1 delegation-based event model, Java RMI, and JavaBeans. The JBuilder development environment is similar to that of Delphi: User interfaces can be built simply by dragging and dropping components onto a form. As this is done, Java code is generated behind the scenes. Event handlers can also be created by simply pointing and clicking with the mouse. JBuilder is unique in that it supports two-way editing. While many environments generate code based on your actions in the design environment, JBuilder actually modifies the visual form as you modify the code. This lets you avoid "sacred" areas in the code (to avoid confusing the development environment, such areas traditionally cannot be modified).

For the purpose of illustration, I'll build a Java application for viewing and editing human-resources information on employees of AlphaBeta Technologies, a fictional software company (the complete source code and related files are available electronically; see "Resource Center," page 3). The distributed architecture could be a "standard" two-tier client/server system using an Oracle database server, or a large-scale telecommunications project that requires dozens of computers to interoperate and share information in a real-time manner. The client application will be written in Java and will access an HR object server via CORBA. For simplicity, the object server will hardwire all data into memory, although in a production application, it could use JDBC to query a database server. Users will be allowed to query for specific employees and can modify data on employees before saving the information back to the server.

After creating a new project, selecting the File|New menu option will let you invoke the New Application Wizard (see Figures 1 and 2). Filling in the appropriate information in the Wizard's two dialog boxes creates a Java application class (containing the main() method) and Java frame. By dragging and dropping a few components onto the created frame (see Figure 3), you complete the layout of a basic employee information form. As you can see, the application supports several operations: First Record, Next Record, Previous Record, Last Record, Update, Delete, and New Employee. Because these buttons represent actions within this application, each ButtonDown event triggers the calling of an appropriate method on the remote Employee object.

Building CORBA Objects Using VisiBroker for Java

VisiBroker For Java 3.0 is a CORBA 2.0-compliant ORB from Visigenic Software. This ORB has been licensed by Netscape, Borland, Oracle, and Novell (among others). Because VisiBroker is included with the Client/Server version of Borland's JBuilder, I'll use it to build the CORBA application. There are only a few basic steps involved in building the CORBA objects. These steps are required in every Java/CORBA application that uses any ORB, no matter how simple or complex the application.

1. Set up the development/run-time environment by modifying the PATH and by setting the appropriate environment variables.
2. Write a definition for each object using IDL.
3. Compile the IDL code to produce client stub code and server skeleton code.
4. Write the client application code.
5. Write the server object code.
6. Compile the client and server code.
7. Start the server.
8. Run the client application.

The specific tasks required for setting up your environment (step 1) are detailed in the VisiBroker documentation. Once completed, you design the object's interfaces using the IDL. Just as related classes are grouped into packages in Java, IDL groups these related interfaces into modules. Listing One is an IDL module (TheModule) that contains the interface (TheInterface), which contains a single attribute (TheAttribute) defined to be an integer value.

Compiling this IDL module using an IDL-to-Java compiler (such as Visigenic's idl2java) results in the Java interface in Listing Two. Each Java data type maps to a specific IDL data type (see Table 1). Variables are declared in IDL using the IDL data type you want to correspond to the resulting Java data type. IDL also supports user-defined data types and constructed data types (such as enums, structs, unions, sequences, and arrays), which are converted to Java.

Methods can be declared in IDL as well. The way in which parameters are passed to these methods is controlled by the use of the in, out, and inout keywords. The in keyword specifies that the parameter is to be passed from the caller to the object; out specifies that the parameter is to be passed from the object to the caller; and inout specifies that the parameter is to be passed in both directions.

Because the server will store the sample data set in memory (in the form of multiple Employee objects), you need to define:

• A struct representing a single Employee containing information about an employee.
• A sequence representing a list of Employee objects that can be iterated.
• An EmployeeInfo interface representing all data and methods required by our server object.

You already know (from the requirements of the user interface) that you need methods that retrieve individual Employee objects, iterate through the available Employees, and modify (add/update/delete) the Employee list. Listing Three contains the IDL necessary to satisfy these requirements.

After running the Visigenic idl2java tool, a set of 14 Java files are created. These files represent what, in CORBA-speak, are known as client stubs and server skeleton files. The client stubs represent the interface from the client application to the client ORB. No implementation details take place within these classes. The server skeletons, however, are where your actual programming will take place. Before implementing the server class (EmployeeInfoImpl), look at Listing Four, which is generated by the idl compiler and represents the Java representation of the EmployeeInfo interface and associated structures and sequences.

The next step is to rename the _example_EmployeeInfo.java file (and the _example_EmployeeInfo class contained within) to EmployeeInfoImpl. The _example_EmployeeInfo file contains a skeleton implementation class to be filled in with details. This server class actually manages the employee information in a private Java Vector object. Methods within this class will be called remotely from a client. Listing Five is the completed EmployeeInfoImpl class.

To have a fully functional CORBA server, you need to register this server class with the server ORB. To do so, a CORBA application initializes the ORB and its BOA, then registers the EmployeeInfoImpl object with the ORB. Once this has been completed, this object can be retrieved from any remote CORBA client. Listing Six shows the basic statements required to do this using VisiBroker.

Because of the seamless nature of Java and CORBA integration, nearly all code on the client looks like standard Java. Once the CORBA object has been obtained, it can be used within a Java application just like any normal Java object. The trick lies in obtaining that object. To do so, you need only initialize the client ORB, then retrieve the object from the server. Listing Seven shows the code required to do this.

The infoObject variable is a private variable within the EmployeeFrame class. (EmployeeFrame was generated by JBuilder when we designed the form.) Once you have a valid object, its methods can be called in response to user events.

Running the Application

To get the server application up and running, execute the osagent command. OSAgent (also called the "VisiBroker Smart Agent") provides a fault-tolerant object location service. Its job is to locate and return an object when it is requested. After osagent is up and running, start up the server application using the Visigenic Java interpreter, vbj. This can be done by executing: vbj Server. Finally, start the client application using vbj as well: vbj EmployeeApp. Figure 4 shows the EmployeeInfo application running.

Conclusion

To get started with Java and CORBA development, visit one of the ORB vendor's web sites and download a trial version of its ORB. For a complete listing of commercial CORBA vendors, visit the OMG at http://www.omg.org/.

DDJ

Listing One

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

Back to Article

Listing Two

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

Back to Article

Listing Three

// EMPLOYEE represents a single employee's personal informationmodule EmployeeServer
{
    struct Employee
    {
        string Name;
        string Address;
        string City;
        string State;
        long long SSN;
        float Salary;
       string Title;
    };
    typedef sequence<Employee> EmployeeList;
    interface EmployeeInfo
    {
        attribute EmployeeList theList;
        readonly attribute long Count;


</p>
        Employee getEmployee(in long index);
        void deleteEmployee(in long index);
        void newEmployee(in Employee newPerson);
        void updateEmployee(in long index, in Employee newData);
    };
};

Back to Article

Listing Four

// Employee.java - Java version of IDL struct Employeefinal public class Employee {
  public java.lang.String Name;
  public java.lang.String Address;
  public java.lang.String City;
  public java.lang.String State;
  public long SSN;
  public float Salary;
  public java.lang.String Title;


</p>
  public Employee() 
  {
  }
  public Employee(java.lang.String Name, java.lang.String Address,
    java.lang.String City, java.lang.String State, long SSN, 
    float Salary, java.lang.String Title)
 {
    this.Name = Name;
    this.Address = Address;
    this.City = City;
    this.State = State;
    this.SSN = SSN;
    this.Salary = Salary;
    this.Title = Title;
  }
  public java.lang.String toString() 
  {
    org.omg.CORBA.Any any = org.omg.CORBA.ORB.init().create_any();
    EmployeeServer.EmployeeHelper.insert(any, this);
    return any.toString();
  }
}
// EmployeeInfo.java - Java interface version of IDL interface EmployeeInfo
public interface EmployeeInfo extends org.omg.CORBA.Object {
  public void theList(EmployeeServer.Employee[] theList);
  public EmployeeServer.Employee[] theList();
  public int Count();
  public EmployeeServer.Employee getEmployee(int index);
  public void deleteEmployee(int index);
  public void newEmployee(EmployeeServer.Employee newPerson);
  public void updateEmployee(int index,  EmployeeServer.Employee newData);
}

Back to Article

Listing Five

package EmployeeServer;public class EmployeeInfoImpl extends EmployeeServer._EmployeeInfoImplBase {
  private java.util.Vector Employees;
  /** Construct a persistently named object. */
  public EmployeeInfoImpl(java.lang.String name)
  {
    super(name);
    Employees = new java.util.Vector();
  }
  /** Construct a transient object. */
  public EmployeeInfoImpl()
  {
    super();
    Employees = new java.util.Vector();
  }
  public EmployeeServer.Employee getEmployee(int index)
  {
    if (index <= (Employees.size() -1))
        return (EmployeeServer.Employee)Employees.elementAt(index);
    else
        return null;
  }


</p>
  public void deleteEmployee(int index)
  {
    Employees.removeElementAt(index);
  }
  public void newEmployee(EmployeeServer.Employee newPerson)
  {
     Employees.addElement(newPerson);
  }
  public void updateEmployee(int index, EmployeeServer.Employee newData)
  {
    Employees.setElementAt(newData, index);
  }
  public void theList(EmployeeServer.Employee[] theList)
  {
    // implement attribute writer...
  }
  public EmployeeServer.Employee[] theList()
  {
    // implement attribute reader...
    return null;
  }
  public int Count()
  {
    return Employees.size();
  }
}

Back to Article

Listing Six

public class Server{
       public static void main(String[] args)
       {
              //Initialize the ORB
              org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
              //Initialize the BOA
              org.omg.CORBA.BOA boa = orb.BOA_init();
              //Create the EmployeeInfo object
              EmployeeServer.EmployeeInfo info = 
                       new EmployeeServer.EmployeeInfoImpl("EmployeeInfo");
              //Export the object
              boa.obj_is_ready(info);
              System.out.println(info + " is ready.");
              //Wait for incoming requests
              boa.impl_is_ready();
       }
}

Back to Article

Listing Seven

// Initialize the ORBorg.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
// Locate and retrieve EmployeeInfo object from server
EmployeeFrame.infoObject = 
          EmployeeServer.EmployeeInfoHelper.bind(orb, "EmployeeInfo");



Back to Article


Copyright © 1998, Dr. Dobb's Journal