Class version issues with RMI-IIOP

Remote Method Invocation over IIOP (RMI-IIOP) is the communication protocol used, in CICS, by both enterprise beans and CORBA stateless objects. The information in this section therefore applies to both enterprise beans and CORBA stateless objects.

Java RMI is an object-by-value protocol. This means that whenever a Java object is used as a parameter on a method call what actually gets sent on the wire is the object state. The same is true of return types and exceptions. This state is a “serialized” Java object. The state can be de-serialized by the remote JVM to create a new copy of the original object in the remote JVM. The serialized state contains, among other things, a version number to indicate the version of the class that the state represents. In order for the serialized object to be de-serialized by the remote JVM, it is necessary for the same version of the class file to be present at each end of the IIOP connection. If the remote JVM cannot understand the object state, it will probably cause the following exception to be thrown:
java.rmi.MarshalException:unable to read from underlying bridge
(This exception may be thrown for other reasons too.)

When you create a class in Java it is possible to provide your own customised serialization mechanism. Using this mechanism, you can handle versioning of your classes explicitly, rather than rely on Java's default serialization process. Moreover, if you provide a custom serialization mechanism you can achieve significant performance savings over the default mechanism. If you want to take advantage of custom serialization, your objects must implement the java.io.Externalizable interface.

Often the objects that must be serialized are instances of classes from the standard Java class library. These usually do not change from one version of Java to the next, but if they do it can lead to the kind of problem described above. In order to minimize these problems, it is recommended that you use the same version of Java on the partner machines as CICS uses. For example, between Java 1.3.1 and Java 1.4 the java.lang.Throwable class changed significantly. This class is the super-type of all exceptions in Java and thus many exceptions serialized by Java 1.4.1 and later cannot be de-serialized by older versions of Java.

There is a mechanism in CORBA that is used by many ORBs to get around the problem of version changes in classes. Unfortunately, that mechanism does not fully work in CICS because it involves affinities between the partner ORB and the JVM in CICS. Multiple RMI-IIOP calls to the same CORBA object in CICS are likely to be processed in different JVMs. This means that affinities are not supported and that the mechanism for avoiding class versioning issues does not work in CICS. CICS applications suffer from this problem only when sending serialized objects to a remote JVM. If a remote JVM sends a serialized object to CICS, CICS can use the standard CORBA mechanism to cope with any version incompatibilities.

If you experience this kind of problem and are unable to change the version of Java in use at the partner platform, it is recommended that the application be changed to use a datatype that does not cause versioning issues.