JavaEnterprise JavaDistributed Object Application Development: The Java-CORBA Solution

Distributed Object Application Development: The Java-CORBA Solution content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

This is the third article in a four-part series to be concluded next week.
Part 1: “Best practices in distributed object application development: RMI, CORBA and DCOM.”
Part 2: Distributed Object Application Development: The Java-RMI Solution.”

The CORBA story

In the late 1980’s and early 1990’s, leading-edge technology firms were looking for competitive advantages in an increasingly volatile marketplace, and recognized distributed computing systems as a way to achieve that edge. What was missing from the equation was a uniform architecture for building distributed systems – a model for code reuse and code integration by which system developers could live. Companies understood the value of code reuse and code integration, but no company alone was able to realize the dream of a universally accepted, language independent standard to support complex multi-tier applications. Then, in May 1989, the Object Management Group was formed.

Originally consisting of eight corporations, the OMG was formed “to create a component-based software marketplace by hastening the introduction of standardized object software.” In 1992, the OMG unveiled The Common Object Request Broker Architecture (CORBA) to finally fill the void in the distributed-object development domain. Today, the OMG has over 800 members with the common goal of defining (and conforming to) specifications that propagate heterogeneous computing environments across all major hardware platforms and operating systems.

Companies like IBM, Netscape and Oracle have since joined the CORBA camp and are actively deploying technologies that are CORBA compliant. IBM has just introduced Component Broker, its new CORBA technology that is based on OMG standards and is 100% Java compliant. Component Broker is being marketed as IBM’s strategic CORBA platform — a complete solution for customers needing to connect multiple back-end systems to dynamic, new applications.

Netscape has a partnership with Visigenic, and is bundling the Java ORB runtime into the Navigator 4.x browsers1. They are also providing the Visigenic’s VisiBroker for Java object request broker technology with Netscape’s Enterprise Server 3.0. Reconfirming Netscapes position on CORBA and IIOP, Marc Andreesen wrote “IIOP will be integral to everything we do. Netscape Navigator will be able not only to browse content but also to browse objects. We expect to distribute 20 million IIOP clients over the next 12 months and millions of IIOP-based servers over the next couple of years. We’ll put the platform out there so that people can start developing for it.”

Oracle is using CORBA technology in an attempt to make its vision of Networked Computing (NC) a reality. The Oracle vision, in its most basic form, is to have light-weight clients download Java applets that communicate to server applications and databases by way of CORBA/IIOP. There is an excellent article in the February 1998 issue of Object Magazine that discusses Oracle’s strategy, including CORBA involvement, in great detail.

The pros and cons of CORBA

What makes CORBA an attractive architecture is its platform and language independence. Microsoft’s Distributed Component Object Model (DCOM) also supports multiple languages (Java, VB, C++), but is lacking platform independence since it was obviously geared toward the Windows environment. However, the CORBA platform independence advantage may soon fade away as Microsoft is combining efforts with other development firms in order to port DCOM to other platforms.

One of the major cons of the Java/CORBA environment is that only a few of the specified services have been implemented in the Java ORBS. For example, Visibroker 3.0 has only implemented the Naming and Event CORBAservices to date. Important CORBAservices such as Security, Query, Transaction and Concurrency Control are not yet available but could be mission critical requirements for some types of distributed applications.

A short list of the pros and cons of implementing a Java-CORBA solution is provided below.

The Future Of CORBA

CORBA’s major competitor is the Distributed Component Object Model (DCOM) created by Microsoft. Microsoft’s product saturation in the business market makes them a very real competitor, claiming that COM and DCOM are used in over 150 million systems worldwide. Since COM/DCOM systems are in such abundance, the technology is not going away anytime soon.

As a result, some CORBA product-based companies are taking a “if you can’t beat ’em, join ’em” approach toward the DCOM initiative. On January 26, 1998, Iona Technologies, manufacturer of the successful OrbixWeb ORB, announced that it has licensed Microsoft’s COM technology with the objective of creating CORBA/COM interoperability. Why has IONA chosen a path of CORBA/DCOM interoperability? Annraí O’Toole, Chief Technical Officer at IONA addresses this issue, “We are not in the business of dictating to our customers. COM is a very important technology in the market place and we need to make sure that everything we do with Orbix works well with COM. COM is just as important to IONA as CORBA and our customers are not interested in religious wars or incompatibilities.”

For CORBA to really set itself apart from DCOM and emerge as the industry standard, it needs to forge a tighter relationship with Java. The technologies complement each other well, with CORBA providing network transparency and Java providing implementation transparency2. Java enables CORBA clients to be easily distributed to remote machines, regardless of platform, via applets and browsers. CORBA reciprocates by enabling Java to interface with different programming languages and extends Java by providing a framework for distributed object communications.

And fortunately for the CORBA backers, JavaSoft’s Remote Method Invocation (RMI), which formerly was thought of as a competitor to CORBA, is fast becoming one of CORBA’s main allies. This is supported by an announcement in the Java Spot News, dated February 18th, 1998, when the Object Management Group (OMG) publicly declared that it had finalized modifications of its IIOP communications protocol so that it could support most of the JDK1.1 functionality of the Java programming language’s RMI. This press release, found on JavaSoft’s site (, maintains that IIOP allows distributed objects to conform to OMG’s CORBA specification, thus by enabling RMI to run on top of IIOP, Java objects can now easily also conform to CORBA. JavaSoft also stated that support for running RMI over IIOP will be available as a standard extension to the next version of the Java Development Kit.

Good news indeed for CORBA/Java developers.

Sample CORBA/Java projects & applications

  1. TITLE: Pratt & Whitney
    URL: case.studies/prattwhit.html
    INFO: At Pratt & Whitney, a Java front-end and the DataBroker™ layer of intelligent CORBA objects from I-Kinetics transformed a legacy mainframe system into a three-tier computing architecture.

  2. TITLE: Home Depot
    URL: N/A
    INFO: The Home Depot IT team is designing the new customer service applications using tools and infrastructure that gives them the flexibility they need for deployment. Unix servers, RDBMS databases, CORBA/IIOP transport and a LDAP directory forms the basis of the application framework. Java was selected for the portability of the Java Virtual Machine to heterogeneous platforms including hand-held and kiosk type devices.

  3. TITLE: Nations Bank
    URL: Item/0,4,16179,00.html
    INFO: Nations Banks is building Internet banking application utilizing reusable software objects based on the CORBA specification.

  4. TITLE: UCLA Medical Center
    URL: enterprise/storyucla.html
    INFO: A Java/CORBA Internet application that will enable physicians, students, and ultimately, patients to view medical files and high resolution images over the Internet.

To help facilitate a general understanding of a Java/CORBA implementation, a step-by-step illustration of how to implement a working Java/CORBA solution using JDK1.1.4 is provided below.

The CORBA “TimeStamp” example

The TimeStamp sample application is a basic implementation of a Java/CORBA application using static invocations. A static invocation is when a client is aware of what interfaces and methods are available at compile time. Note: CORBA also provides a dynamic invocation capability where clients can discover the interfaces on-the-fly.

The Java/COBRA development process for the TimeStamp example application is broken down in to ten manageable steps:

  1. Download and install a Java ORB
  2. Create IDL file
  3. Compile IDL file
  4. Create the client
  5. Create the server
  6. Create the interface implementation
  7. Compile the client
  8. Compile the server
  9. Compile the interface implementation
  10. Start the naming service (OSAgent)
  11. Start the server
  12. Start the client.

Step 1. Download and install a Java ORB.

An ORB is the basic building block for client/server objects to communicate with each other. A Java ORB allows clients and servers written in Java to use the CORBA implementations. Since the client and server objects let the ORB handle all their distributed method invocations, neither the client nor server have any working knowledge of the makeup or the location of other objects in the system. For more information about CORBA ORB’s and to see more examples of ORBs at work, visit

For the purpose of this demo, Visibroker by Visigenic was implemented. Developers can download a trial version of Visibroker at (Note: Visibroker was the ORB of choice in Orfali-Harkey’s “Client/Server Programming with Java and CORBA”3 and also got an excellent review in the January 1998 edition of the JAVA ADVISOR.)

Step 2. Create IDL File.

The Interface Definition Language file (TimeStamp.IDL) is used to create a language independent definition of all the objects that will be implemented on the server.

Listing 1. The CORBA IDL File: TimeStamp.IDL
	module TimeStamp {    interface TimeStampIF {      string getTimeStamp();    };};

In the above example, there is only method contained in the interface, ‘getTimeStamp’, that returns a string value. Also, note that the term module is comparable in functionality to the Java package naming construct4.

Step 3. Compile the IDL file.

Compile the TimeStamp.idl file using the Visibroker IDL compiler. idl2java TimeStamp.idl

The purpose of this compilation is to map the IDL file to native Java code for use by Java based client and servers. Visibroker’s IDL2JAVA compiler creates a package containing the following files 5:

  • – The TimeStamp interface declaration.

  • – Declares the TimeStampIFHelper class, which defines helpful utility functions.

  • – Declares the TimeStampHolder class, which provides a holder for passing parameters.
      Note: The _var class has been removed because of changes in VisiBroker to comply with the new OMG IDL to Java language mapping specification. This class has been split in two. The new names are Helper and Holder.

  • – Stub code for the Account object on the client side.

  • – Skeleton code (implementation base code) for the TimeStampIF object implementation on the server side.
      Note: The _sk_ class has been deprecated because of changes in VisiBroker to comply with the new OMG IDL to Java language mapping specification. The new name is _ImplBase. While the old format, _sk_ will still be generated for backward compatibility, the new format _ImplBase should be used when implementing new objects.

  • – Class used to implement the TimeStamp object on the server side using the tie mechanism.

  • – The Operation classes work together with the tie classes to provide the tie mechanism.

  • – Code you can fill in to implement the TimeStamp object on the server side.

Step 4. Create the client.

Listing 2. The CORBA client:

Step 5. Create the server.

The TimeStampServer initializes the CORBA ORB and waits for incoming requests using the Basic Object Adapter (BOA) mechanism.

Listing 3. The CORBA server:
public class TimeStampServer {  public static void main(String[] args) {     // Initialize the ORB.     org.omg.CORBA.ORB orb = [break in code]     org.omg.CORBA.ORB.init(args,null);           // Initialize the BOA.     org.omg.CORBA.BOA boa = orb.BOA_init();           // Create the TimeStamp object.     TimeStamp.TimeStampIF TimeStampObject =     new TimeStampImpl(“TimeStampService”);          // Export the newly created object.     boa.obj_is_ready(TimeStampObject);     System.out.println(TimeStampObject + ” is ready.”);           // Wait for incoming requests     boa.impl_is_ready();     }}

Step 6. Create the interface implementation.

In addition to the server (, a Java implementation of the initial interface/IDL file is necessary. The implementation file,, contains the actual code of the one remote method provided by this CORBA example: getTimeStamp()

Listing 4. The Interface Implementation:
import java.util.*;import java.lang.*;public class TimeStampImpl [break in code] extends TimeStamp._TimeStampIFImplBase {  	     // Construct a persistently named object.     public TimeStampImpl(java.lang.String name) {   		 super(name);     }       /** Construct a transient object. */     public TimeStampImpl() {    		super();     }     public java.lang.String getTimeStamp() {          // implement operation…          Calendar exactTime = Calendar.getInstance();          String exactTimeStr =	         (String)(exactTime.getTime()).toString();          return exactTimeStr;     }}

Step 7. Compile the client.


Step 8. Compile the server.


Step 9. Compile the interface implementation.


Step 10. Start the naming service (OSAgent).


Step 11. Start the server.

vbj TimeStampServer

Step 12. Start the client.

vbj TimeStampClient

And with any luck, the server will return the current date and time to the client.


  1. Mickey, Sean; “Find What’s Missing in the CORBA Equation”; JAVA Advisor; January 1998.
  2. Orfali, Robert; Harkey, Dan; Edwards, Jeri; CORBA, Java, and the Object Web; Byte Magazine;
  3. Soley, Richard; The Java-tization of CORBA; Java Developer’s Journal; Vol II, Issue 11
  4. Orfali, Robert and Harkey, Dan; Client/Server Programming with Java and CORBA; John Wiley & Sons; 1997
  5. Visibroker Documentation,
  6. Vogel, Andreas; Duddy, Keith; Java Programming with CORBA; John Wiley & Sons; 1997
  7. Mowbray, Thomas J.; Ruh, William A.; Inside CORBA; Addison Wesley; 1997

Talk about distributed object application development in the Discussions area.

Tom Albertson is a senior associate at Coopers & Lybrand Consulting, Government Services Practice in Washington, D.C. He has four years of extensive Internet development experience enhanced by seven years of parallel experience in systems design and engineering, application/GUI development, computer programming and database management. You can reach Tom via email:

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories