DISTRIBUTED DEVELOPMENT & MIDDLEWARE
The Pairing of CORBA & Java
A logical move toward building more scalable, fault-tolerant distributed applications
David S. Linthicum
David S. Linthicum is the CTO of SAGA in Reston, VA. He is the author of David
Linthicum's Guide to Client/Server and Intranet Development from Wiley. You can reach
him at linthicum@worldnet.att.net.
As the Java revolution begins to settle down, we're seeking a place for Java in the world of true enterprise computing. While Java is a truly portable application development language riding on top of a truly portable environment (the JVM), its ability to assimilate into traditional client/server and distributed applications is limited by the features of the technology. To add to the confusion, Java seems to be creating its own native distributed infrastructure which competes with traditional distributed computing architectures such as CORBA and DCOM.
Enter CORBA and the elegance of CORBA architecture which, when partnered with the features of Java, makes for a healthy combination. The marriage of Java and CORBA, given the current infrastructure of tools and technology, seems to be a logical move. However, as with any new technology, there are limitations to consider in addition to the choice between CORBA and competing architectures such as DCOM. What's more, technology is only as good as the vendors who sell it. While there are a handful of CORBA/Java vendors, they are small. The market has yet to take off.
The Architecture
CORBA brings several things to the table for Java integration. First, CORBA is a true distributed computing architecture, providing many key technologies, including distributed management, a common pipe (IIOP), bindings for several languages other than Java, and native heterogeneity. Moreover, if we think of CORBA as already in second grade, then Java has yet to finish preschool.
|
|
For example, CORBA is able to extend the distributed features of Java using the infrastructure of CORBA. Java applets were never really designed to communicate across application address spaces using the remote method invocation mechanism, despite the integration of RMI (see the section called "RMI and CORBA"). RMI, in many respects, provides an easy-to-use approach to distributed computing, but it does not support the advanced architectural features of CORBA-compliant ORBs. CORBA allows Java applets to communicate with other objects written in different languages across different address spaces using the common pipe of IIOP. Thus, developers can create truly distributed applications using any number of languages. CORBA provides a rich set of distributed object services that are built on top of the power of the Java language. For example, a developer may create client-side ORBs using Java, and business logic at the middle tier using C++.
In many respects, Java brings little to the distributed computing world other than a very nice object-oriented programming language and a very nice common binary application distribution mechanism. Still, Java is a good match with CORBA. For one thing, the Java infrastructure seems to begin where the CORBA infrastructure ends. CORBA does what CORBA does, providing a distributed object infrastructure that allows applications to extend their reach across networks, component boundaries, operating systems, and programming languages. Java does similar things using simple technology, but Java itself is not a true ORB. In short, CORBA deals with network transparency and Java deals with implementation transparency.
The integration of Java and CORBA allows developers to do things like move intelligent behavior from one ORB to another using the common infrastructure and interfaces of CORBA. This means that both clients and servers are able to gain behavior dynamically as it is required for the application development effort. CORBA also provides a language-independent partitioning technology, and applications can run on a client or server without having to recompile (although there are adaptations that you must make for each platform).
There is a management story to tell here as well. Java code can be deployed and managed centrally from the server. It's a simple matter of updating your code once on the server, and then allowing the clients to receive the new code when and where it is needed.
Of course, the best story with Java and CORBA is the Web. In a sense, Java has pumped new life into the CORBA infrastructure. Java not only lets developers add behavior through existing CORBA bindings, it provides a built-in distribution mechanism as well. For instance, you can distribute binary objects using the traditional Java features. Netscape has seen the power of the marriage of CORBA and Java firsthand, since it is now delivering ORBs with every browser it ships. The notion is that Netscape can provide a truly distributed application architecture using the ORB as a binder for an application, and as a plumbing mechanism to other Java-enabled or non-Java-enabled ORBs within the Internet or the enterprise (see Fig. 1).
The marriage of Java and CORBA brings the advantages of three-tier client/server architecture to the game as well. Java developers now have a mechanism to create server-side applications that can communicate directly with a resource server as well as a Web server, or communicate back to the interface processor at the client (see Fig. 2). This means that we can build distributed applications using Java and CORBA that are much more fault-tolerant, scalable, and just plain easier to maintain than traditional applications built only in Java; and employ native Java IPC mechanisms.
Java ORB
A Java ORB, simply put, is an ORB that supports a Java language mapping of the IDL. In most cases, Java ORBs are implemented in Java itself. The language mapping, or language binding, allows CORBA-compliant ORBs to be implemented using Java. However, not all Java ORBs available on the market today support the complete CORBA functionality. For instance, some ORBs, such as Sun's JOE, only allow the implementation of client-side, Java-enabled, CORBA-compliant ORBs.
|
|
In the simplest form of the Java-enabled CORBA ORB architecture, the client and the server are both implemented in Java. Using this architecture, the Java Virtual Machines on each platform allow each applet or application to execute. The applet or application shares a common ORB that provides interprocess communications services. The client communicates with the ORB to transmit a request for an operation invocation to the server. The server, in turn, sends the results of ORBs back to the client. These interfaces, of course, are defined by the CORBA standard and by the application-specific IDL definitions created by the developer. Naturally, few distributed systems are that simple. Most applications consist of a client-side ORB that handles the interaction with the user, a server-side ORB that processes the requests coming from the interface, and another set of ORBs that interface with a variety of resource servers.
The development process is almost exactly the same as the one used to implement CORBA-compliant ORBs using more traditional languages like C++. The IDL compiler generates a number of Java classes, known as stub classes, for the client, and skeleton classes for the server. The stub classes provide proxy objects that clients can use for the invocation of methods. The proxy object method implementations invoke operations on object implementations, which, in the case of CORBA, may actually exist on a remote server. If the object implementation does exist on a remote server, the proxy object marshals and transmits the invocation request.
The skeleton code serves as the glue between the object implementation (the CORBA server) and the ORB. The problem here is that the CORBA specification leaves many of the interfaces between the ORB's core and server programs undefined. Thus, many CORBA-compliant vendors use different mechanisms for communicating, and this causes incompatibilities. The skeleton class implements the mechanisms by which invocation requests moving into a server can be directed to the right method of the right implementation object. The programmer, of course, is responsible for creating the methods.
The architecture, however, gets even more complex. A Java applet can also be a CORBA client. Within CORBA there is no distinction made between a Java applet or application invoking CORBA objects. However, you must consider the security limitations of Java's sandbox when using this architecture. A server may also be implemented as an applet, as long as the ORB provides a server-side mapping. Remember that applets running in the Java sandbox are not allowed to access resources on the host machines. Therefore, applet objects cannot be persistent, nor can they store data. One hopes that both OMG and JavaSoft are working to correct this problem. The current releases of the JVM are already providing developers with better mechanisms to handle access to native devices.
The Players
So, who are the vendors creating products that support both Java and CORBA? The list is growing, but for now the key players are Visigenic, Expersoft, and Iona.
Visibroker from Visigenic (just acquired from Borland) is a Java ORB that has been available for almost two years. Visibroker supports a full language mapping incomplete Java implementations of all mandatory CORBA features. Visibroker is very much like its sister product, Visibroker for C++. Both ORBs leverage IIOP as the native transport mechanism, allowing it to interoperate with other CORBA-compliant ORBs. What's more, Visibroker provides an HTTP tunneling mechanism, known as Gatekeeper, to bypass Java's native network security restrictions. Visibroker has been receiving a lot of press lately because it is the ORB of choice for Netscape and it is built into the Netscape ONE browser and server.
OrbixWeb from Iona is almost as old as Visibroker; it was released in July 1996. OrbixWeb provides full client-side mapping as well as server-side mapping. It provides developers with an ORB that is location transparent and provides a Gatekeeper-like product known as Wonder Wall. OrbixWeb provides protocol support for both native and Iona ORBs and IIOP for access to ORBs from other vendors. In addition to Java, Iona provides language bindings for both C++ and Smalltalk.
CORBAplus Java Edition, from Expersoft, is the latest to combine Java in CORBA. CORBAplus Java Edition enables interoperability with distributed object applications for both Internet and intranet application development, as well as proprietary enterprise computing environments through implementation of Java IIOP. Expersoft is the newest player and commands the smallest market share.
RMI and CORBA
RMI allows developers to create remote objects using standard Java interfaces, and relieves them from having to deal with the type differences between CORBA and Java or the CORBA IDL.
Since the advent of RMI as an intra- and inter-machine IPC mechanism for Java applets and applications, many are asserting that RMI and CORBA provide the same value. While it's easy to see that RMI and CORBA are able to solve the same set of problems, choosing between them really depends on the requirements of the application.
There are many things to consider when comparing RMI to CORBA. First, RMI-enabled applets or applications can only communicate with other RMI-enabled objects. Thus, you can't count on invoking methods written in other languages like C++. Furthermore, RMI does not provide a language-neutral messaging service. Unlike Java, RMI does not provide support for a wire-protocol for security, nor does it support the notion of transactions. Moreover, RMI is unable to provide support for self-describing objects or dynamic invocations.
Again, it really depends on the application. If the application is Java and nothing but Java, and there is no requirement to link external resources, or a wire-level security requirement, then RMI is fine. However, you need to understand that you're giving up access to features you may need as the application matures.
The point is that RMI is a technology that's both lightweight and bound to Java, while CORBA is more robust and language-neutral. RMI lacks the basic features of IIOP, and Java is not yet providing the features you'll find in most ORBs.
Of course, while the RMI and the CORBA crowd can't seem to agree on the proper uses of their respective technologies, OMG is looking to incorporate RMI into CORBA. Just as the marriage of Java and CORBA has added value to each technology, the integration of RMI and CORBA will do the same.
For now, those looking to incorporate both CORBA and RMI can look to Caffeine. Caffeine comes from Netscape and Visigenic, and it allows developers to write distributed objects using pure Java. Caffeine is able to process the bytecode to generate VisiBroker for Java IIOP stubs and skeletons. Caffeine is also able to generate CORBA IDL directly from Java bytecode, providing the developers with all of the benefits of using CORBA without having to give up pure Java. At this point RMI becomes what RMI really is, a good IPC mechanism from Java that's going to add value to the traditional world of CORBA.
The future of both Java and CORBA, however, is really dependent upon the success of Microsoft's Component Object Model ORB. While Java and CORBA can team up to add value to each other, and hopefully find their way into many distributed applications, COM is already a part of the infrastructure of the Windows operating systems. With a 90% penetration in the workstation marketplace, COM is, at the very least, the ORB of convenience. It certainly saves the developer from the struggle of integration. What's more, CORBA vendors are providing both DCOM and CORBA features, which adds to the confusion.
