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:
As in any new standard, interoperability between vendors is
- Use rmic, which comes with RMI-IIOP, to create idl files from your
EJB Home interface.
- Use a CORBA 2.3-compliant idl compiler to generate your stubs.
- Create your EJB CORBA client.
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
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.
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
For some packages using SOAP see
For a stable production solution, COM/EJB bridges provide
the best synchronous solution and are described below, leaving SOAP
for a future investigation.
COM to EJB
Many COM-to-Java bridges exist. Sun has an early access
Client Access Services (CAS) COM Bridge available at
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
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).
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
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
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.
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
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:
- Create a new directory and copy TestServer.dll into it (e.g.,
- Recompile com object
jview weblogic.comc -nothreads -register
- Copy the created directory weblogic to
- Add the interface, ItestInterface, to jvc /d %CLIENT_CLASSES%
ServerSideTestServer.java and write some code to use this interface
- Restart Web server after adding properties:
- Run the above ServerSideTestServer under the Microsoft
Virtual Machine, jvc examples.com. ServerSideTestServer
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
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
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.
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.
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.
Sirl Davis is an assistant director of IT at Dresdner Kleinwort Benson, London.
He has a bachelor's degree in electrical engineering/computer science and an MBA/finance with PhD-level work in information systems. His experience includes developing various
finance applications for trading risk, and data warehousing utilizing Java technology.
Download Assoicated Source Files (Zip format - 4.16 KB)