It's old news that Java has taken the world by storm. Even the recently computer-illiterate are out browsing the Web, and companies are all prototyping or even deploying Web-based client software to broaden their customer base and to compete effectively in the changing marketplace. However, many of these companies happen to have large existing software bases implemented in more conventional languages such as C or C++. Furthermore, Java is a relatively new language. Many companies are not yet willing to commit to Java-based development for key mission-critical software components.
How can these apparent contradictions be resolved? Some companies are looking at ad-hoc solutions for connecting these two software worlds, but many are looking seriously at using CORBA to make a more reliable connection. CORBA, the Object Management Group's Common Object Request Broker Architecture, was designed to provide a reliable inter-language inter-platform communication infrastructure (http://www.omg.org/corbask.htm). Thus, it is a likely choice to help bridge the gap between the dynamic Web-based Java world and the more static traditional programming world.
CORBA Interoperability: IDL
The key aspect of CORBA's interoperability is its use of IDL, the standardized Interface Definition Language, as the common language that connects all the different implementation languages together. All public interfaces are described in IDL, and all implementation languages supported by the CORBA infrastructure must have an unambiguous mapping defined between IDL and that language. This approach means that a CORBA program need know nothing about the existing set of implementation languages; it need only know the mapping between its own implementation language and IDL.
Once the shared representation is agreed on, it is then necessary to agree on a linearized format to be used for communicating data over the network. CORBA uses a standardized protocol, the Internet InterORB Protocol (IIOP), for communication over the wire. The combination of IDL and IIOP provide enough standardization to allow CORBA 2.0 compliant ORBs to communicate freely over the network independent of the language in which they are written or the hardware and software platforms on which they run.
As recently as last summer, the OMG-sponsored CORBAnet demo (http://www.corba.net) was perhaps the first application to publicly demonstrate over-the-wire interoperability among IIOP-compliant ORBs. Although the IDL Java mapping had not yet been standardized, the demo nevertheless included several Java ORBs written to independently developed mappings: Sun Microsystems' Joe (http://www.sun.com/sunsoft/neo), Visigenic's Visibroker for Java (
http://www.visigenic.com/prod/vbjpd.htl), and IONA's OrbixWeb (http://www.iona.com/Orbix/OrbixWeb).
The Implications of Java and the Web
Before the widespread availability of Java, interoperability implied a strong separation between local and remote. It was perfectly normal to assume that a particular program could depend on particular language and system environments, and interoperability was something that happened over the wire (often the network) to connect relatively static, separate worlds together in various ways. For example, a vendor wanting to provide client software to interface with its database would choose some small number of platforms to support, and provide distinct client applications for each (see Figure 1). Customers running unsupported base platforms would thus be unable to run the vendor's software.
The spread of Java has significantly changed that picture. How? The short answer is the combination of dynamic content and ubiquity. For pure Java applications the language has become a fixed point, and the portability of the Java Virtual Machine means that the underlying hardware/software platform has become a black box. Furthermore, the content that is being transmitted over the network is in many cases dynamic (bytecodes intended to be run at the destination) rather than static data. In this world, a Java programmer may have no idea on what platform a given applet or application may run- it should runanywhere, as long as the required Java API is supported both syntactically and semantically. This means that a vendor can now write a single version of its client software in Java and expect it to run on any hardware/software platform which supports Java (see Figure 2).
This picture explains why the compatibility of Java implementations is so crucial. For any kind of determinism to prevail, it is essential that the behavior of any particular Java program be the same on any Java implementation. As Java becomes embedded in key system components such as browsers and operating systems, it becomes virtually impossible for applet (or application) writers to have any control over the environment in which their code is run.
The current state has important implications for both CORBA and Java: the addition of a standardized IDL Java mapping to the CORBA specification bridges the gap between Web-based and traditional programming in a way that can enable applications to seamlessly encompass both.
Traditional CORBA, however, falls slightly short of the binary and potentially even source code compatibility required to play as a first-class citizen in the dynamic Java world. Because the traditional model was of communication between worlds, the CORBA specification does not define the APIs used by stubs and skeletons (the proxy objects used to isolate application programmers from the communication-specific part of the ORB infrastructure) to interface with the ORB. This means that the stubs and skeletons are ORB-specific: they must be generated by a tool affiliated with a particular ORB, and can only run correctly when used with that ORB.
Standardizing Full Interoperability: A Cooperative Approach
This was not a significant problem in a fairly static pre-Java world: IIOP enabled different applications to interoperate freely over the wire, and most environments would tend to choose one particular ORBvendor for their installations. In the current environment of ubiquitous Java programs, however, there is a strong desire for Java-based applications to be as ubiquitous as the Java virtual machine on which they run. In particular, as CORBA support makes its way into Web browsers and other key system components, application programs have less and less control over which ORB implementation they will be run against. It is critical to ensure that particular Java programs are not constrained to run only on a particular vendor's ORB.
Several vendors had prototype versions of Java ORBs and were already in the process of documenting their prototype IDL Java mappings in response to an OMG RFP. Realizing that traditional language mapping submissions would fail to address the level of compatibility required for ubiquitous Java environments, Sun decided to drive a multi-vendor submission in an attempt to avoid the kind of ambiguities that inhibit full interoperability. Working out mutually acceptable compromises as part of the submission development is a difficult and time-consuming process, but in the end it yields a more robust mapping with a strong base of acceptance. As an added advantage, it allows differences to be discussed and resolved in a more cooperative rather than competitive forum.
Although there were three official IDL Java mapping submissions (see http://www.omg.org/schedule/ORBOS_RFP3.htm), this article has focused only on the joint submission by Sun, Visigenic, IBM, Oracle, Digital, Expersoft, HP, Netscape, and Novell. This mapping attempts to strike a balance between convenience for Java programmers and convenience for CORBA programmers. Syntactically, there are many similarities to the existing C and C++ IDL language mappings; subject to this constraint,
there was an attempt to make the mapping choices as intuitive as possible for Java programmers.
Those interested in the details of the mapping should take a look at the Joint Submission at the URL mentioned in the previous paragraph. The submission document contains all the relevant details of the mapping as well as rationale for the design. Perhaps most notable are the explicitly-stated goals of source-code portability for both clients and servers, and binary compatibility between client stubs (and server skeletons) and all compliant ORBs. If the joint submission is approved and these goals are successfully met, CORBA programs written in Java will have access to all the benefits of Java ubiquity as well as providing the traditional CORBA multi-platform interoperability.
About the Author
Ellen Siegel is a member of the Joe development group at Sun Microsystems, Inc. Her technical interests focus on communication infrastructure and distributed systems. She holds B.S. degrees in Chemistry and Computer Science from MIT, and M.S. and Ph.D. degrees in Computer Science from Carnegie-Mellon. Ellen can be reached on the Net at firstname.lastname@example.org