The finger applications in this chapter and Chapter 22are similar. This was achieved due to the relative simplicity of the server application. The finger server exposes only one operation, and that operation accepts only a string as a parameter. When you’re mapping Java interfaces into IDL interfaces, the translation is rather simple, assuming that all method parameters and public member variables translate directly into IDL types. The obvious problems arise when method parameters and public member variables do not have a direct IDL counterpart—for example, the class java.util.Vector .
As we continue looking at the Caffeine environment, we’ll cover the manner in which translations are made from Java code directly into IDL. Starting with the base type translations, Table 27.1 shows the Java constructs with direct IDL counterparts.
TABLE 27.1 JAVA-TO-IDL MAPPING
Java Type IDL Type
package module boolean boolean char char byte octet String string short short int long
long long long
float float double double org.omg.
CORBA.Any any
org.omg.
CORBA.TypeCode TypeCode
org.omg.
CORBA.Principal Principal org.omg.CORBA.Object
Object
What Table 27.1 does not cover is the more difficult translation of general Java objects into some IDL entity. Because IDL represents a subset of all that’s available to Java developers, it is therefore impossible to have an easy direct translation for everything out there. To work around this limitation, Inprise introduced a nonstandard entity to the IDL called the extensible struct.
Extensible Structs
An extensible struct allows any Java object that implements the interface
java.io.Serializable to be broken down into a byte stream and sent through the Object Request Broker (ORB). At the receiving end of an extensible struct, the ORB reassembles the object and presents it to the server. Objects passed in this manner are passed by value, instead of the traditional method of passing all objects in CORBA by reference. Although it’s a rather big benefit to the CORBA developer if he can throw any Java object into the ORB, it’s not a silver bullet. Because extensible structs are a non- standard extension to the IDL, their use is limited to applications developed for Inprise Visibroker for Java ORB.
In the next example, we look at how an extensible struct is used to allow the passing of java.util.Vector objects through the ORB. Starting the example, the interface VectorReceiverI is contained in Listing 27.4.
LISTING 27.4 THE VectorReceiverI INTERFACE
import java.util.*;
public interface VectorReceiverI extends org.omg.CORBA.Object {
public void receiveVector(Vector vec);
}
Although it’s rather simple, the interface does contains the receiveVector()
operation, which accepts a Vector object as a parameter (this is a red flag for problem generation). In a traditional CORBA environment, it’s not possible to pass a Vector object due to the fact that it violates IDL’s lowest common denominator rule—meaning that a Vector object could not be understood by a language such as COBOL. The class that implements the VectorReceiverI interface, VectorReceiver , is contained in
Listing 27.5.
LISTING 27.5 THE VectorReceiver CLASS
import java.util.*;
import org.omg.CORBA.*;
public class VectorReceiver extends _VectorReceiverIImplBase { public VectorReceiver() {
super("VectorReceiver");
} /**
* Invoked when a client object wishes to send over * a Vector object. The method simply prints out the * contents of the Vector.
*/
public void receiveVector(Vector vector) { Enumeration e = vector.elements();
while(e.hasMoreElements()) {
System.out.println(e.nextElement());
}
}
public static void main(String[] args)) {
// obtain references to the ORB and the BOA ORB orb = ORB.init();
BOA boa = orb.BOA_init();
// create a new VectorReceiver object
VectorReceiverI server = new VectorReceiver();
// notify the ORB that the VectorReceiver object is ready boa.obj_is_ready(server);
// wait for an incoming connection boa.impl_is_ready();
} }
Finishing up the extensible struct example, Listing 27.6 contains the code for a simple client that interacts with the FingerServer application.
LISTING 27.6 THE VectorSender CLASS
import org.omg.CORBA.*;
import java.util.*;
public class VectorSender {
public VectorSender() {
// bind to a VectorReceiverI object
ORB orb = ORB.init();
VectorReceiverI receiver = VectorReceiverIHelper.bind(orb);
// create a Vector object Vector vec = new Vector();
vec.addElement("String 1");
vec.addElement("String 2");
vec.addElement("String 3");
vec.addElement("String 4");
vec.addElement("String 5");
// ask the VectorReceiverI object to print // out the contents of the Vector object receiver.receiveVector(vec);
}
public static void main(String[] args)) { VectorSender sender = new VectorSender();
} }
To get this application up and running, start off by compiling the interface VectorReceiverI first using the Java compiler and then using the java2iiop
application. Now you need to compile the client and server applications. Start the server by entering
java VectorReceiver and the client by entering java VectorSender
Developers who are familiar with Java’s Remote Method Invocation—covered in Chapter 15, “Remote Method Invocation (RMI)”—will likely draw parallels between extensible structs and RMI itself. Both technologies allow for Java-only distributed object
development, both pass objects by value, and both require that objects implement the java.io.Serializable interface. Although these similarities do exist, the major difference is that by working in the CORBA universe with extensible structs, you are able to leverage all technologies made available to the CORBA developer. For example, your application could still take advantage of the CORBA Naming Service to locate objects, or you could use the load-balancing capabilities of the Visibroker ORB to ensure that one extensible struct is not passed to too many clients.
Given all of the advantages developers can leverage by using extensible structs and CORBA, one might begin to wonder why anyone would use RMI at all. The decision to use one technology over another is not something that can be dictated on a global basis—all applications have different needs. If your application is served well by an allJava environment, where objects are passed by value and no CORBA services are needed, RMI might be a silver bullet. If, however, you need mixed language support, the ability to pass by reference, and the ability to leverage existing CORBA code, CORBA should be utilized. Making the decision about the proper distributed technology to use for a given application is critical to the success of that application. As you read this book, pay attention to the chapters that implement the Airline Reservation System usecases, because each implements the same use-cases using a different technology. By studying the system design decisions that each is forced to make, you’ll be able to make solid decisions about the proper technology to use when implementing your own software.
Struct Mapping
Thus far in our look at mapping Java into IDL/IIOP, we have seen how standard types easily convert over, as well as how general objects are mapped over. The last aspect of mapping not yet covered involves Java entities that map into traditional CORBA structs.
During the process where java2iiop parses Java code, it converts a class into a struct if the following tests all evaluate to true:
• The class is final.
• The class is public.
• All member variables of the class are public.
• The class contains no operations.
• The class does not inherit from any other class besides java.lang.Object . As an example, Listing 27.7 contains a Java class, and Listing 27.8 contains the IDL struct that the class maps into.
LISTING 27.7 THE StructClass CLASS WILL MAP INTO AN IDL STRUCT
import java.util.*;
public final class StructClass { public String sData;
public Vector vecData;
public int iData;
}
LISTING 27.8 THE StructClass CLASS MAPS TO THE IDL STRUCT, StructClass