Remote Invocation Interoperability

Transaction Interoperability

Transactional interoperability has to do with how multiple J2EE containers can participate together in a distributed two-phase commit protocol. The EJB 2.0 Specification does not make it mandatory that a J2EE container support transactions between different vendors , although there are still some core requirements that a container must adhere to even if it doesn't.

CORBA's Object Transaction Service

Similar to the remote invocation interoperability requirement from the previous section, the transactional interoperability requirements for EJB are based on specifications from the CORBA world. The OMG's Object Transaction Service (OTS) 1.2 specification describes in detail how transaction context information should be propagated from client to server.

The OTS describes two different methods for propagating transaction context: implicit and explicit. Implicit propagation is handled by the system and is not specified in the operation's signature. There's no need to pass the transaction context around as a parameter or return type. Explicit propagation is just the opposite . It's handled by the application and typically is passed as a parameter or return type from container to container. Implicit transaction propagation is described by the OTS specification. The transaction context is specified in the IIOP message and must adhere to the proper format, which is specified in the CosTransactions::PropagationContext structure described in the OTS specification.

For an EJB container that supports transaction interoperability, it must be able to produce and consume transaction context information to and from IIOP messages in the format described by the OTS specification. Other containers that might only initiate a transaction, such as a Web container, should be able to create the transaction context information in the IIOP message.

Requirements for a Container not Supporting Transaction Interoperability

The specification does not mandate complete support for transaction interoperability by J2EE containers. It probably will be required in future releases of the specification. However, there are still some requirements placed on the containers.

Even when the container doesn't support using the propagated transaction context, the container should fail in a consistent manner. The minimal way of handling this situation is for the container to throw a system exception, in particular java.rmi.RemoteException , and cause the transaction to roll back.