EJB

In EJB/CORBA integration, complexity can range from simple to complex and depends in part on the direction of the communication. From EJB to CORBA, communication is relatively simple because the EJB bean invokes CORBA as it does any external resource. CORBA-to-EJB communication, however, depends on the application server's support of RMI-IIOP. If the application server doesn't support RMI-IIOP, then it's best to create a wrapper or adapter class that redirects or delegates the function calls from the client via a CORBA servant, which then calls the EJB.

Part 1: EJB/CORBA Integration
Communicating from EJB to CORBA is the simplest case. The EJB will require an ORB and some means of looking up the remote CORBA object, the servant, in a directory service that could be CosNaming or JNDI over CosNaming. Note: It isn't necessary to use CORBA 2.3, which is required by RMI-IIOP (see below). Like any external resource, such as a socket or file descriptor, any ORB can be initialized and used by the EJB.

ORB initialization should be performed once using the singleton design pattern that can act as a factory for looking up remote CORBA servants. A suitable design to ensure this scenario requires the use of a stateless session bean, which is never passivated. Entity or stateful session beans may be passivated and reactivated and would require the disposal and cleanup of the ORB, which has a high performance cost as well.

Using the stateless session bean fits the EJB model best, and the ORB can be a static data member in the bean or in the above mentioned singleton support class to help ensure one instance. A deployment descriptor can also be set, for example, in WebLogic, which allows the container to create only one stateless session bean.

Currently, there's no standard mapping between EJB and CORBA for passing user identity and transaction propagation. So, if transaction and security services are required in your implementation, then the EJB bean wrapping this CORBA call should invoke the appropriate CORBA services in the desired way. In other words there's no automatic solution, and transaction and security will need to be customized for your situation.

In Listing 1 (see www.JavaDevelopers Journal.com for listings) the Call CorbaBean is a stateless session bean implementation that makes a call to an object R which initializes the ORB (if it's not initialized) and calls the CORBA servant. The idl is also shown; the servant CORBA implementation isn't included but follows standard CORBA. More important, the R class shows the encapsulation of the CORBA processes in a singleton and as a cascade pattern to ensure single initialization and a simple interface - actually too simple, as an actual implementation would more likely provide factories for different types of objects as required by the application. A client would look up the home interface, CallCorba, and create a CallCorba bean to call the remote function "call."

CORBA to EJB
Ideally, communication from EJB to CORBA should be over RMI-IIOP. However, RMI-IIOP requires a CORBA 2.3 ORB and an EJB container that supports RMI-IIOP. Because the EJB 1.1 specification only recommends RMI-IIOP but doesn't require it, many of the application servers currently available are in compliance with the EJB1.1 specification and don't fully support RMI-IIOP. In EJB 2.0, released in July 2000, RMI-IIOP is required, and interoperability will eventually be available in all the major container vendors.

Nevertheless, it's still possible to use RMI-IIOP in some application servers, although it's likely to range in complexity from easy to perhaps impossible. For example, Inprise's Application Server product allows easy interoperability with CORBA because it's built on RMI-IIOP as would be expected, as Inprise has integrated it with their Visigenic product. On the other hand, other application servers may not provide RMI-IIOP easily for EJBs and will require creating CORBA idl stubs for all the EJB objects, then successfully compiling the resulting idl with an idl compiler. Sometimes the resulting idl must be tweaked or modified. To create RMI-IIOP between a CORBA client and EJB, follow these steps:

1. Use rmic, which comes with RMI-IIOP, to create idl files from your EJB Home interface.
2. Use a CORBA 2.3-compliant idl compiler to generate your stubs.
3. Create your EJB CORBA client.

As in any new standard, interoperability between vendors is particularly difficult.

Even if the above steps can be accomplished with your application server, there's no standard for passing user identity and the transaction propagation over RMI-IIOP to the client. EJB transaction and security services aren't accessible over RMI-IIOP; consequently, these services will lack any current RMI-IIOP solution.

So although RMI-IIOP is the preferred solution for interoperability between EJBs and CORBA and will certainly be the better solution in the future, it may be required to communicate without RMI-IIOP. One flexible solution is to provide a CORBA wrapper servant that directs CORBA calls to the EJB object. Because this solution can easily be replaced with RMI-IIOP in the future, it will provide a design that evolves.

First, check your CORBA and EJB products. If they easily support RMI-IIOP interoperability, then use that approach. If not, the example code demonstrates a wrapper that delegates CORBA calls to EJB.

In Listing 2, the call.idl is the idl for the call to the EJB. The EJBWrapper wraps the EJB and allows the CORBA client, WrapperClient, to access the EJB though the EJBWrapper. The EJBWrapper follows the standard adapter or wrapper pattern and simply delegates the calls from the client to the EJB. Note that we're actually using the same session stateless bean used in the previous example for simplicity, although one would never make a call from CORBA through EJB to CORBA; the example is heuristic.

Design Issues
The design issues regarding communication from CORBA to EJB concern the usage of RMI-IIOP where possible, and where not possible the usage of the adapter design pattern, which ensures that the external resource, the ORB, is carefully handled. The stateless session bean offers the best EJB for EJB-to-CORBA communication because it allows easy management of the ORB. In addition, because the future J2EE software will evolve to support CORBA-EJB interoperability more fully, any effective design must be able to easily absorb future changes.

Part II: COM/EJB Integration
Before looking at COM-EJB communication, it's worth pointing out that SOAP is a strategic direction Microsoft is taking for interoperability. Consequently, SOAP should be considered for communication between EJB and COM. However, it would be a custom solution without the support of current application servers or J2EE technology. In addition, SOAP is relatively new, and not many stable implementations exist.

For some packages using SOAP see www.alphaworks.ibm.com/tech/soap4j or http://msdn.microsoft.com/xml/default.asp. For a stable production solution, COM/EJB bridges provide the best synchronous solution and are described below, leaving SOAP for a future investigation.

Bridges

• www.linar.com/: J-Integra is a bidirectional, pure Java-COM bridge.
• www.alphaworks.ibm.com: Bridge2 Java allows ActiveX objects to be used in Java.
• http://developer.java.sun.com/developer/earlyAccess/j2eecas/: Allows COM clients to access EJBs.
• WebLogic's COM Bridge in WebLogic Server: Allows bidirectional COM/ RMI interaction.

COM to EJB
Many COM-to-Java bridges exist. Sun has an early access Client Access Services (CAS) COM Bridge available at http://developer.java.sun.com/developer/earlyAccess/j2eecas/, that will allow any COM-enabled client to access any EJB object. In addition, bridges such as J-Integra (see www.linar.com/) and WebLogic provide bidirectional communication. Below we look at WebLogic's COM bridge; it's a popular application server that simplifies the aspect of bridging between COM and EJB.

Communicating from COM to EJB usually means that Visual Basic clients are accessing EJBs. WebLogic, for example, supports the ability of Visual Basic clients or other Microsoft services to access EJBs. Because bridges support this communication rather well, it won't be addressed in any more detail, and the remaining discussion will be on communicating from EJB to COM, which is more difficult.

EJB to COM
Communication from EJB to COM is necessary if services in Microsoft are required by EJBs. WebLogic's COM solution hosts the COM object as an RMI object. As a representative example, we'll address this bridge in detail.

WebLogic Wraps COM
Note that the WebLogic Server wraps the COM object, Test.dll, and provides an RMI interface any Java client on NT can access. WebLogic provides a "com compiler," which takes a dll file and produces the Java classes, including the interface used by RMI clients. No programming is required, as the code is automatically generated. The command is

jview weblogic.comc -nothreads -register
c:\weblogic\examples\com\testser\TestServer.dll

Unfortunately, because the standard (Sun) Java Virtual Machine differs from the Microsoft Java Virtual Machine in serialization across RMI, any network connection between the two JVMs is incompatible. Sun Microsystems is suing Microsoft over this and other differences. Consequently, WebLogic certifies that COM will work only if the WebLogic server is run on the Microsoft VM, and only Java clients running under the Microsoft VM will be able to connect to the WebLogic server, so the COM bridge will work only on NT and using only the Microsoft VM. Note: Even if the Sun and Microsoft JVMs were interoperable, C++ clients still couldn't connect to WebLogic's RMI. Therefore, the second CORBA wrapper is needed to provide true interoperability (see COM/CORBA/ EJB Integration below).

Tests Performed
Three tests of increasing complexity were performed using the above bridge. The first was a simple function that returned void. The second returned a String. The third test returned various Microsoft COM objects that dealt with the data access (DAO) directly. Both the void and String functions worked successfully, but the more complex test hung after processing one database record and suggests not making Microsoft's Data Access Layer remote. In addition, even if making these COM objects worked easily in Java, the training issue for a Java developer to learn the COM API for data access is knowledge unlikely to be found in one person. Consequently, the best design approach is to return Strings or perhaps XML, simple objects where possible, or domain business objects that encapsulate and hide Microsoft's data access classes. Other bridges may suggest other approaches.

Risks and Disadvantages
One risk to the above approach is the dependence on the COM-Java bridge that's affected by the current lawsuit. Microsoft plans to not support Java in the future and will give Rational the development of the virtual machine (see "Microsoft, Rational strengthen ties on Java development front," www.zdnet.com/ eweek/stories/general/0,11011, 1015701,00.html). Nevertheless, WebLogic's support of the bridge provides insurance from a major vendor, and there are bridges not bound to the Microsoft VM (see www.linar.com/). Another disadvantage is that some of the features of the WebLogic Server can't be used. Because the Microsoft Java Virtual Machine must be used in order to use COM, clients can't be standard Java clients, which run on standard VMs, although wrapping the EJBs as CORBA objects would allow any client to access them (see COM/ CORBA/EJB Integration below). Note: JSP technology can't be used because it requires a standard usage of the classpath, that isn't available on the Microsoft Virtual Machine.

AdvantagesK
The WebLogic wrapper provides a simple way to bridge COM and Java with little or no programming. It provides a stable application server, which provides facilities for hosting distributed objects and easing distributed development.

Detailed Implementation Steps
To provide the above solution, WebLogic must run on the Microsoft Java Virtual Machine. In addition, the Microsoft SDK for Java ( http://www.microsoft.com/java/default.htm) must be installed on the machine. After installation, setting its classpath can be tricky, so it's worth noting that this is done in the registry (HKEY_LOCAL_MACHINE\ Software\Microsoft\JavaVM\Classpath). Some files can be automatically added to the classpath and break the WebLogic compiler. To correct the problem if it occurs, simply edit the registry to remove these files from the classpath.

Configure the WebLogic environment file, setEnv.cmd, to use the Microsoft compiler, then:

1. Create a new directory and copy TestServer.dll into it (e.g., C:\weblogic\ examples\com\testser)
2. Recompile com object

   jview weblogic.comc -nothreads -register
   c:\weblogic\examples\com\testser\TestServer.dll

3. Copy the created directory weblogic to C:\weblogic\myserver\serverclasses
4. Add the interface, ItestInterface, to jvc /d %CLIENT_CLASSES% ServerSideTestServer.java and write some code to use this interface
5. Restart Web server after adding properties:

   weblogic.system.startupClass.testsertest=weblogic.com.remote.testserver.ITestInterfaceImpl
   weblogic.system.startupArgs.testsertest=TestServer

6. Run the above ServerSideTestServer under the Microsoft Virtual Machine, jvc examples.com. ServerSideTestServer

Design Issues
The above can provide a simple way of integrating COM. Especially by using String-level interfaces, XML can be passed as a parameter thereby significantly reducing program effort and debugging. Restrictions exist because of the need to use the Microsoft Virtual Machine, making it more difficult to use the full feature set of J2EE. Also, the possibility that SOAP may become a better interface is worth noting. Nevertheless, the need for a production quality solution currently favors a bridge.

Part III: COM/EJB/CORBA Integration
In summary, these solutions can be used together to provide a complete COM-to-EJB-to-CORBA solution useful in those situations where these three object models need to be combined in one solution. Each model provides particular benefits and may be linked to certain legacy solutions in any given environment.

Certainly, COM allows easy integration with Microsoft, EJB provides ease of development and portability, and CORBA provides integration benefits. More importantly, in any environment there may be the presence of each model, and there may be a requirement to integrate them all. So, it's worthwhile creating a framework for integrating each model because some loss of performance will be outweighed by development and maintenance benefits.

Performance is a problem with integrating COM and CORBA through EJB. However, although two servers exist between the COM object (e.g., Test.dll) and the Client objects, both components are easily produced as described below. Certainly, this trade-off favors ease of development over performance. But this solution then provides a bridge between COM and any CORBA client that's highly flexible and can evolve with future changes. Only environments with all three of these technologies will benefit from this integration, but by placing EJB as the central standard, it simplifies the other two integrations. Furthermore, when RMI-IIOP becomes a standard, the server hosting the CORBA wrapper can be removed.

CORBA to COM
To enable CORBA to COM, a CORBA client calls a wrapper or adapter to access an EJB, which then calls COM. Note that RMI-IIOP could be used between CORBA and EJBs, but a more versatile yet performative solution is to utilize the wrapper. The CORBA wrapper delegates any CORBA calls to the RMI interface hosted by WebLogic and provides a fully interoperable solution. The wrapper is essentially a client of WebLogic and looks up the RMI interface of the COM component and provides a remote interface to clients on UNIX or NT. The CORBA interface or idl can be developed manually by creating a matching CORBA interface or by using an automatic tool provided by Visigenic, which can take a Java interface and produce idl (i.e., java2idl). Once the idl is provided the delegation must be coded directly, although this programming is straightforward and could be generated automatically if such a generator were written. Note that by writing a simple code generator that automatically generates the CORBA wrapper, no code would need to be written for the bridge software, which would improve the speed of development and improve quality.

COM to CORBA
COM-to-CORBA communication can be achieved by using the soon-to-be-released CAS, COM to J2EE bridge being developed by Sun, and then having the EJBs call CORBA. Or WebLogic's bridge from COM to EJB can be used and have the EJBs call CORBA. COM to CORBA is in fact simpler than the opposite direction, as would be expected from details discussed above.

Design Issues
COM-to-CORBA communication is enabled by having the COM object presented as an RMI/EJB object by the WebLogic bridge, then a CORBA server is written that wraps the RMI object and provides a CORBA interface to any client. CORBA-to-COM communication is provided easily by having EJBs invoke CORBA directly and by having a bridge between EJB and COM.

The complexity of the interface can be a critical factor in the above approach because a complex interface requires larger amounts of code in the CORBA wrapper. One possibility is to pass XML back from the COM server through the CORBA wrapper, perhaps a hybrid SOAP solution. Automating the creation, the CORBA wrapper can speed development. A second solution is to build common domain business objects and pass them through to WebLogic and Java.

The selection of a particular bridge will be dependent on platforms and overall configuration. If WebLogic's bridge is used, then the Microsoft VM will be required, as it runs only on Windows NT. Other bridges will have different requirements. However, an EJB container does simplify many of the interoperability issues by providing one standard to map both CORBA and COM rather than mapping each standard to the other, which would create six mappings: CORBA to COM, CORBA to J2EE, and so on.

Conclusion
EJB, CORBA, and COM are different technologies and are likely to persist in production environments. Maintaining interoperability is essential for environments that have these technologies. A number of issues have been discussed that show many of the choices required for integrating these technologies. Various trade-offs and advantages exist for different approaches and tools, and any particular environment or configuration of software will favor a different combination of these solutions.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...