Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

CORBA meets Java

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

By Bryan Morgan, JavaWorld.com, 10/01/97

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.

1 | 2 | 3 |  Next >
Resources
  • The Object Management Group provides comprehensive information on CORBA and IDL http://www.omg.org
  • For another detailed look at CORBA, read Jon Siegel's CORBA Fundamentals and Programming (Wiley Computer Publishing Group, ISBN0-471-12148-7)
  • Another excellent reference on CORBA and Java is Client/Server Programming With Java and CORBA by Robert Orfali and Dan Harkey (Wiley Computer Publishing Group, ISBN 0-471-16351-1)
  • Visigenic VisiBroker for Java http://www.visigenic.com/
  • IONA Technologies OrbixWeb http://www.iona.com/
  • Sun Microsystems Neo http://www.sun.com/
  • Expersoft PowerBroker http://www.expersoft.com
  • IBM ComponentBroker http://www.software.ibm.com/ad/cb
  • Regular JavaWorld columnist Michael Shoffner provides an in-depth look at how RMI is used for cross-network communications http://www.javaworld.com/javaworld/jw-10-1997/jw-10-step.html
  • Download this article and the complete source code as a gzipped tar file http://www.javaworld.com/javaworld/jw-10-1997/corbajava/jw-10-corbajava.tar.gz
  • Download this article and the complete source code as a zip file http://www.javaworld.com/javaworld/jw-10-1997/corbajava/jw-10-corbajava.zip