The Relationship Between CORBA and Enterprise JavaBeans

Remote Invocation Interoperability

Remote clients should be able to access session and entity beans that are deployed in an EJB container. Because the remote clients might be in a J2EE container provided by a different vendor, there must be a way to define the remote access based on a set of standards.

The remote invocation interoperability requirement describes the manner in which clients in one J2EE container are able to access enterprise beans in a different container. Specifically, the clients must be allowed to invoke operations on the EJBHome and EJBObject references from the client container.

GIOP and IIOP Protocols

The CORBA 2.4.2 Specification from OMG describes the General Inter-ORB Protocol (GIOP) and the Internet Inter-ORB Protocol (IIOP) and how these concepts are used by CORBA applications to send and receive messages between clients and servers.

Basically, GIOP describes how messages and data are structured so that CORBA implementations from different vendors are able to understand messages generated from each other. A GIOP message is structured so that certain pieces of information are located consistently within a byte-stream and any vendor, regardless of where the message was generated, can understand and service the request.

The IIOP protocol is an implementation that uses TCP/IP communications to exchange GIOP messages. IIOP is basically the standard wire protocol for CORBA communications. There can be other protocols that use GIOP messages, but Enterprise JavaBeans is concerned exclusively with IIOP.

RMI Over IIOP

The IIOP part of the CORBA specification is somewhat complicated to understand. It's even more complicated if you wanted to create your own implementation of it. You surely wouldn't want to have to write your own communication layer as part of your application.

The EJB 2.0 Specification uses RMI as an API layer for developers to send messages. As you read in Chapter 3, RMI is not specific to Java. Java Remote Method Protocol (JRMP) is a Java-dependent implementation of RMI, although other implementations are available. Many do not believe JRMP has enough industrial strength to handle the requirements of distributed communication for Enterprise JavaBeans. This is primarily why RMI has been complemented with a different implementation that uses IIOP as the wire protocol for inter-process communication between J2EE components .

All J2EE-compliant containers must be able to support the IIOP 1.2 protocol for remote invocations on EJBObject and EJBHome references.

Note

Based on the specification, vendors are allowed to support additional protocols other than the IIOP for clients to access EJB components within the container; however, these protocols might be vendor-specific and cause interoperability and possibly even portability problems.

Using Bidirectional GIOP

Prior to GIOP 1.2, the CORBA specification only allowed requests to be sent from clients that initiated the connection. Servers that accepted the connections were only allowed to receive the requests . The server could not then turn around and make a request on the same connection. It would have to open a new connection back to the client on a different port. This limitation made it very difficult for components to communicate through firewalls because only very specific ports were opened.

Bidirectional GIOP messages, which were introduced in version GIOP 1.2, relax this restriction and allow the same connection to be used in both directions, as long as both the client and server agree on it. Bidirectional support currently is not required by the EJB specification, but it might be in future releases. If a J2EE server receives an IIOP message from a client that has set the bidirectional flag, the container can decided whether or not to use the same connection for sending requests back to the client.

A complete and thorough discussion of CORBA is outside the scope of this book. You can find more information on the CORBA specifications at

http://www.omg.org

Remote Interfaces and CORBA IDL

When requests are made between EJB and CORBA systems, both sides must be able to understand the IIOP request and perform the necessary actions. For Java, information is extracted from the request and converted into the necessary RMI calls. On the other hand, CORBA uses an Interface Definition Language (IDL) to declaratively define interfaces in a portable way. IDL compilers produce native code for several languages so they can understand IIOP. For an EJB to communicate with a CORBA object, there must be a way to translate between these two.

The Java Language to IDL Mapping specification describes how the remote and home interfaces for an enterprise bean are mapped to IDL. The bean provider does not have the responsibility to map between these two systems. The bean provider uses the Java RMI API to call remote methods , and the deployment tools will take care of the rest.

More information on Java IDL can be found at the following site:

http://java.sun.com/products/jdk/idl/index.html

Stub and Client View Classes

When a container makes a request for an EJBHome or EJBObject reference, the client-side stub class (remote proxy) must be created in the container that made the request. Also, any view classes or client helper classes that are returned by a remote invocation must also be available to the client container. These stubs and client view classes normally are packaged with the client application so that they can be made available when they are needed.

Containers can also support automatic downloading of stub and view classes at runtime. The codebase URLs are either sent with the IIOP message, marshaled with the value type, or in the EJBHome or EJBObject information. The exact way that this procedure should work is specified in the OMG's CORBA specification and the Java to IDL Mapping specification.