Java Enterprise in a Nutshell, Second Edition

Chapter 4. Java IDL (CORBA)

The Java IDL API, introduced in Version 1.2 of the Java 2 platform, provides an interface between Java programs and distributed objects and services built using the Common Object Request Broker Architecture (CORBA). CORBA is a standard defined by the Object Management Group (OMG). It describes an architecture, interfaces, and protocols that distributed objects can use to interact with each other. Part of the CORBA standard is the Interface Definition Language (IDL), which is an implementation-independent language for describing the interfaces of remote-capable objects. There are standard mappings defined by the OMG for converting IDL interfaces into C++ classes, C code, and Java classes, among others (a complete list is provided later in the chapter). These generated classes use the underlying CORBA framework to communicate with remote clients and give you the basis for implementing and exporting your own distributed objects. Java IDL is Sun’s implementation of the standard IDL-to-Java mapping and is provided by Sun with the standard Java SDK in the org.omg.CORBA package, the org.omg.CosNaming package, and other org.omg.* packages.

Like RMI, Java IDL gives you a way to access remote objects over the network. It also provides the tools you need to make your objects accessible to other CORBA clients. If you export a Java class using Java IDL, it’s possible to create an instance of that class and publish it through a naming/directory service. A remote client can find this object, call methods on it, and receive data from it, just as if it were running on the client’s local machine. Unlike RMI, however, objects that are exported using CORBA can be accessed by clients implemented in any language with an IDL binding (not just Java).

The CORBA standard is extensive, to say the least. In addition to the basic remote object architecture and the syntax of IDL, it also includes specifications for several distributed object services, like an object naming service, a security policy service, and persistent object services. It would be foolhardy to attempt to cover all these topics completely in one chapter, so we won’t. Instead, we’ll just cover the basic features of the CORBA architecture and the IDL syntax. We’ll also look at the Naming Service, which is key to almost every CORBA application because it provides a standard way to find remote CORBA objects on the network. After that, we’ll take a look at the Java IDL API and the idlj compiler and how they work together to give you an interface from your Java code to CORBA objects and services. They also provide the tools you need to create your own CORBA objects, implemented in Java.

The rest of this chapter is broken down roughly into three parts. In the first part, we’ll look at an overview of the CORBA architecture and how it allows you to create, export, access, and manage remote objects. In the second part, we’ll explore the details of creating your own CORBA objects. Finally, we’ll look how clients can remotely access your CORBA objects.

A Note on Evolving Standards

At the time CORBA support was first made part of the core Java API (with the introduction of Java 2 Version 1.2), the CORBA specification and the IDL-to-Java binding for CORBA were in a bit of flux. The server-side object adaptor interface (the interface between remote object implementations and the core CORBA object services) had been altered significantly by the OMG in Version 2.3 of the CORBA specification. The Basic Object Adaptor (BOA) interface had been replaced by the Portable Object Adaptor (POA), which, as the name suggests, provides a portable implementation interface for CORBA server-side objects. This filled a gap in the specification left by the BOA that led to vendor-specific extensions and, therefore, CORBA server objects that were dependent on particular vendor ORB implementations. The standard IDL-to-Java mapping, however, took some time to be updated to support the new POA; and JDK 1.2 was released before the new version of the Java mapping. As a stopgap measure, the first version of Java IDL in JDK 1.2 used a server-side object adaptor interface based on an ImplBase scheme (described in detail later in this chapter). By the time JDK 1.4 was introduced in beta in 2001, the POA-compatible version of the IDL-to-Java mapping had been released, and the Java IDL packages, as well as the IDL-to-Java compiler in JDK 1.4, were based on this mapping.

Another recent addition to the CORBA specifications is the Interoperable Naming Service (INS) interface, which adds new utilities and functionality on top of the standard CORBA Naming Service. INS was incorporated into the CORBA 2.3 specification, and support for it in Java IDL was introduced in JDK 1.4.

In this chapter, we will discuss both the POA and “pre-POA” versions of Java IDL. If you are using JDK 1.4 or later, you are using a POA-compatible mapping of the CORBA interfaces. If you are using JDK 1.3 or JDK 1.2, you are using the “pre-POA” version of the IDL-to-Java mapping that Sun used prior to adding the POA support. Most of the examples in the chapter will be shown in both their POA and pre-POA versions -- examples labeled as POA-compatible is usable in JDK 1.4 or later, while examples labeled pre-POA can be used in JDK 1.3 or 1.2 environments. We will also discuss both the original Naming Service interface and the new Interoperable Naming Service (INS) interface. Again, if you are using JDK 1.4 or later, you have access to the INS interface and the Naming Service provided with the Java IDL. The Object Request Broker (ORB) supports these extended features. If you are using a prior version of the JDK, you have to use the original Naming Service interface.