Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Add the power of CORBA to our distributed whiteboard

Find out how to transport serialized Java objects to and from an applet client and a Java server using CORBA

By Michael Shoffner, JavaWorld.com, 03/01/98

You gotta be Java -- and 1.1-patched at that.

Play with the CORBAtized whiteboard!

Note: You must use Appletviewer 1.1 or an AWT 1.1-enabled version of Netscape to view and manipulate the whiteboard (see Resources for a link to the patch required to bring Netscape up to speed).

Whiteboard history -- from sockets, RMI, and servlets to CORBA The last installment of Step by Step illustrated how to use a servlet as the server element of the collaborative whiteboard system that we've been examining of late. Because the most natural and handy use for servlets is as Web server extensions, we developed a whiteboard communications layer that used the HTTP protocol to communicate between clients and an HTTP servlet.

The client, implemented as an applet, used URLs to HTTP POST a message to the servlet, which maintained the shared whiteboard state. The servlet responded with a message of its own during the response portion of the same HTTP POST. The messages passed over HTTP were actual Java objects, serialized using the 1.1 serialization mechanism.

The interesting thing about this communications implementation is that it's hidden within ObservableList, which is the client data structure that contains the actual list of whiteboard objects to be displayed. As far as the whiteboard is concerned, it doesn't matter whether we're using RMI, Berkeley sockets, or HTTP to effect communications. In fact, the servlet-based communications layer was substituted in place of a similar one using RMI, which in turn replaced a layer that used sockets.

How do these different communication mechanisms measure up? Sockets and HTTP have the advantage of being simple, flexible, and fast. Sockets allow realtime communication. HTTP solves the problem of communicating through firewalls. On the other hand, they share the disadvantage of being low-level mechanisms, which means that you -- the developer -- have to provide a lot of application-specific code if you want to use them to enable communications. In fact, you must provide a messaging protocol as well as the message transport.

What we're really looking for is a direct object-to-object communication mechanism that would allow objects to call others' methods directly. RMI provides this, and hides the mechanics of it from the developer. But what if we want to implement the server in C++ or some other non-Java language, or we want to connect to a legacy system of some kind? We'd be out of luck because RMI is for JVM-to-JVM communications only.

That leaves us with only one alternative: CORBA.

It turns out that CORBA solves these problems for us. CORBA provides a generalized way to "glue" objects together even if they're implemented in different languages and/or are physically distributed. A word of warning: CORBA is a very powerful and complicated beast. We'll only scratch the surface here, but with the techniques you learn in this column you'll have the fundamentals for using CORBA as a distributed computing mechanism for Java.

Crash course on CORBA

Common Object Request Broker Architecture, or simply CORBA, is a high-level integration technology for distributed applications. The CORBA standard is maintained by the Object Management Group (OMG), is currently in version 2, and enjoys widespread industry support.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.