This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:
  • Konstantinos Raptis, Diomidis Spinellis, and Sokratis Katsikas. Distributed object bridges and a Java-based object mediator. Informatik / Informatique, 2:4–8, April 2000. Green Open Access

This document is also available in PDF format.

The document's metadata is available in BibTeX format.

Find the publication on Google Scholar

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Diomidis Spinellis Publications

Distributed Object Bridges
and a
Java-based Object Mediator

Konstantinos Raptis, Diomidis Spinellis, Sokratis Katsikas

Department of Information and Communication Systems
University of the Aegean
Karlovassi, 83 200
Samos Island

{krap, dspin, ska}



Abstract: An important aspect of research on software objects, components, and component-based applications concerns their interoperation. Is their interoperation technically possible? Which elements are responsible for the software objects’ incompatibility? Is compatibility a responsibility of the objects or of their underlying architectures? In this article we discuss the object compatibility problems, we describe basic strategies for bridging the gap between the three basic middleware remoting technologies (CORBA, DCOM, and RMI), and present our approach for a Java-based Object Mediator architecture.

Keywords: software objects, components, midlleware, remoting, bridge, mediator.



The need to develop software based on existing code rather than development from scratch, led to the emergence of component-based software. Components are typically object-oriented, or at least used as objects. Szyperski1 defines a software component as: "A unit of composition with contractually specified interfaces and explicit context dependencies only that can be deployed independently and is subject to third-party composition".

Moreover, the need for interaction between the software components led to the specification of middleware remoting models. The Object Management Group’s Component Object Request Broker Architecture (CORBA)2, Microsoft’s Distributed Component Object Model (DCOM)3, and Sun Microsystems’ Remote Method Invocation (RMI)4 are three models that enable software components from different vendors, running on different machines, and on different operating systems, to work together.

In order for developers to use a component as part of an application, they must be able to distinguish its attributes. That is, the component must be identified by meaningful characteristics, which are: the component name, which provides the developer with the ability to identify it, the component interface, which identifies the operations fulfilled by the component, and the component model which specifies the semantics and context of the component.

When there is a need for two or more software components based on different technologies to interoperate the mission target is to make the components hide the fact that the other components are functioning under a different technology without changing their characteristics and behavior. This task may not always be possible due to technical or organizational constraints. An exemplar case involves two Java objects, each using the RMI and DCOM technologies respectively; the interoperation between them confronts the conflicts between the Java virtual machine and Microsoft Java virtual machine. In the last section of this article we present our research work on a generic architecture that allows bridging an RMI-based client application with a COM-based server application using the Java programming language as the basis for building an operational mediator.

As a component’s instance is typically an object and anything applying to objects has also apply on components, in the next paragraphs our discussion will focus on software objects. In the following section we present the compatibility problems between the software objects and representative attempts for bridging CORBA, DCOM and RMI technologies.


Object Incompatibility

For software objects to be able to interact with each other they must comply with the rules of their underlying technology. However, it is difficult, if not impossible, for two objects, hosted on different object architectures, to interact with each other. The incompatibility reasons stem from the differences of the underlying models and the way they present and use the software objects. We discern three basic incompatibility points.

Table 1 presents the basic differences of the three models in relation with the above incompatibility points.






Interface Approaches & Implementations




Object Identification

Identification through Object and Interface Names

Identification through a GUID (CLSID & IID)

Identification through a URL-based Object Name and Interface Name

Object Reference

Reference through an Object Reference (OR)

Reference through an Interface Pointer

Reference through a URL-based Object Reference

Object Storage

Storage in Implementation Repository

Storage in Registry

Storage in rmiregistry



Object RPC (ORPC)


Table 1: CORBA/DCOM/RMI basic differences in relation with incompatibility points.

The differences presented in table 1, are not the only ones between these three architectures and the only reasons for objects’ incompatibility. If we made a detailed comparison between these models we would see many more differences and we could find many more reasons. The differences, we described, are the prime causes. As we will see in the next paragraphs all attempts that have been made for bridging these object middleware architectures focus their attention on these points.


Bridging the Gap

Nowadays, discourse about software objects, components, and component-based applications is about ActiveX controls, JavaBeans (JBs), Microsoft Transaction Server (MTS), and Enterprise JavaBeans (EJBs) and how they can interoperate each other. The common point is that all the above are software component models, i.e. all of them are not independent models; they all depend on the underlying architecture that each has as a basis for its construction.

In the next paragraphs of this section we provide some of the attempts that have been done for bridging CORBA, DCOM, and RMI, the most widespread commercial middleware remoting technologies.


CORBA and DCOM, as extension of COM, are the two most important middleware remoting technologies. Their importance stems from their ancestry. CORBA is a child of the Object Management Group an association including Sun Microsystems, Compaq, Hewlett-Packard, IONA, Microsoft and others, while DCOM comes from Microsoft which enjoys the highest share in the desktop operating system market. Although COM and its extension DCOM are built-in in Microsoft’s OSs and there are no other providers of these technologies, the widespread adoption of Microsoft’s OSs and the development of programming languages which support rich COM/DCOM frameworks, led to the production of many components based on Microsoft’s architecture. On the other side, the fact that the OMG provides CORBA as specifications for ORBs instead of a product led many companies to create their own CORBA compliant request brokers providing the developers and the users with a range of ORBs capable to satisfy various demands.

The OMG understanding the need for bridging their differences, and after the first OLE/CORBA bridge from IONA Technologies in 1995, decided to include as part of its updated revision 2.0 of CORBA architecture and specification the Interworking Architecture which is the specification for bridging OLE/COM and CORBA. The Interworking Architecture addresses three points:

The OMG does not provide an implementation of a COM/CORBA bridge but only specifications. The implementation task belongs to commercial companies which have released many bridge tools compliant with OMG’s specification. Some of these products are PeerLogic’s COM2CORBA, IONA’s OrbixCOMet Desktop, and Visual Edge’s ObjectBridge. All the above products realize one of the interface mappings that OMG specifies. Their main goal is to provide a two-way interworking between COM and CORBA applications.


The widespread deployment of the Java language and its use in the development of Web-based applications in combination with the presence of CORBA as a mature middleware technology quickly led to the combination of these two. As a first step Java was included in the languages with mappings to OMG IDL. Although Sun provided its own model for remote Java-object interactions, the Java Remote Method Protocol (RMI), the effective combination of Java language with the CORBA architecture led OMG and Sun to think for the marriage of RMI with CORBA. According to Sun6 Java developers would be able to use RMI-based Java objects and interoperate with CORBA-based remote objects. In June of 1999, Sun and IBM announced the release of the RMI architecture over the IIOP protocol. According to RMI-IIOP any RMI-based object can be accessed by a CORBA one and vice versa. In order for this goal to be achieved, OMG has adopted two standards for Object By Value and the Java-to-IDL mapping. Moreover Sun made some changes in RMI to work under the new requirements.

Apart from the adoption of IIOP as RMI’s alternative protocol, a new version of the rmic compiler has been developed in order to generate IIOP stubs/ties and IDL interfaces. Furthermore, the use of new commands and tools, for example for naming and storing in registry the RMI-objects and for ORB activation, is required in order for the RMI-IIOP-based objects to be accessed by the corresponding CORBA-based ones.


No special work has been done for bridging COM/DCOM with RMI. In this field the attention is focused on the attempts for integrating Java language and COM and on the bridging of JavaBeans with ActiveX.

Microsoft supports COM/DCOM under its own edition of the Java language. In order for users of the native Java language to use the COM technology, Microsoft supports the Microsoft Virtual Machine (MSVM). According to Microsoft7, the MSVM provides all the mechanisms required for a Java object to be viewed like a COM object and for a COM object to be accessible like a Java object.

As for bridging JavaBeans and ActiveX, a number of companies, including Microsoft and Sun, provide bridges for JavaBeans and ActiveX components to interoperate with each other taking advantage of the JavaBeans architecture flexibility in connection with protocol usage. Moreover, a lot of the work concerns the possibility of using a JavaBean component in an ActiveX-component based environment like the Microsoft Office or Visual Basic.


Java-based Object Mediator

We have approached the bridging of the three middleware remoting technologies under a different view than those we have described. Our intention was to exploit the Java language, its capability to run irrespective of the operating environment and its acceptance from all the three technologies, as a tool for the creation of a mediator mechanism for bridging all the three technologies together. We are using the Java language as a "general-purpose object glue". Our target was to allow a server object, which may be CORBA, DCOM, or RMI compliant, to expose its methods to CORBA-, DCOM-, and RMI-based clients. In the next paragraphs we will present an example of our approach involving bridging an RMI-client with a COM-server.

The tools we were using in our research include:

Moreover, the resulting programs can operate under the Microsoft's Windows 98 operating system.

Our intention was to enable an RMI-client program to request methods exposed by a COM-server. Before proceeding with the bridge of the RMI-client with the COM-server we had successfully bridged an RMI-client with a CORBA-server and a CORBA-client with a COM-server by developing a mediator program using the Java language. We will briefly discuss the way we have bridged the RMI-client with the CORBA-server. The bridge between CORBA-client and COM-server follows the same architecture.

We first developed in Java a CORBA-server application, which exposed some methods through its IDL interface. When running the server application, it can receive calls from a CORBA-client application. We then created an RMI-based client/server application where the server exposed, through an RMI-interface, the same methods as the CORBA-server.

In the RMI-server application we added all the necessary attributes to make it act like a CORBA-client application in parallel with its action as an RMI-server. When the RMI-server receives the RMI-client's request, instead of implementing the requested methods, it actually forwards the request, as a CORBA-client, to the CORBA-server application. The CORBA-server application then responds to the virtual CORBA-client which then acts like an RMI-server and forwards the response to the RMI-client application. Figure 1 presents the class diagram of this RMI-client / CORBA-server interaction.

In the same way we developed another Java mediator allowing a CORBA-client application to request methods exposed by a COM-server application. In this interaction our mediator had to satisfy the demands of a CORBA-server application in parallel with the demands of a COM-client application.

When one tries bridge an RMI-client application directly with a COM-server application it is impossible for a mediator to function as an RMI-server application and as a COM-client simultaneously. Although we had no errors during compilations, we could not succeed our mediator, at the run time, to implement simultaneously the appropriate classes of JDK's java.rmi package and Microsoft's VM @com directives through which a Java object may be presented as a COM object.

For the interaction between the RMI-client application and the COM-server application to succeed, we used the previous two mediators for bridging RMI-client with CORBA-server (mediator A) and CORBA-client with COM-server (mediator B). Thus, the RMI-client's request was forwarded to the COM-server through mediator A and mediator B. Similarly, the RMI-client receives the COM-server's response through mediator B and mediator A.

From the above discussion it is obvious that in order for the mediator to function properly two basic rules must be followed:

  1. The mediator must comply with the client's and server's side architectures. That is, the mediator must have a double role. It must act like one's architecture server application and like the other's architecture client application.
  2. The environment were the mediator is hosted must support all the necessary technologies. That is, for the mediator to operate properly on his double role its environment must support simultaneously, at run time, the different architectures.

When trying to bridge directly the RMI-client with the COM-server the second rule could not be satisfied because of conflicts between the Sun's and Microsoft's Java editions related with the support of the RMI and COM technologies.

Except the above two rules our mediator does not have to support the three incompatibility points we presented in the second section. That is, the different interface approaches and implementations, the different object references and storage, and the different protocols. This goal was achieved by using the Java programming language and our mediator architecture in order to construct our system. By using the Java programming language, which is supported by all the three technologies, and by the mediator's architecture, which includes the attributes of all the interacting technologies, we overcome these incompatibility points.

The fact that we were using the Java language to construct our mediator provided us the advantage that the attributes of our mediators would be understandable through the mappings between the Java language and the different interface definition languages. The architecture of our mediators gave us the ability to name and store the mediator object according to the principles of the client's technology in parallel with searching and retrieving the server object according to the principles of the server's technology. In the same way the mediator's architecture allowed us to use the client's technology protocol in the client-mediator interaction and the server's technology protocol in the mediator-server interaction.



The interoperation between different technology objects is in practice much more complex and difficult than in theory. Although many attempts have been undertaken to bridge the gap between the objects’ underlying architectures, they are not enough at the time to provide true vendor-, language-, and technology-independent interoperation between different software objects. Unfortunately, until now the use of a single middleware product is the most reliable solution. Compatibility problems between different vendors’ products persist even if the products are compliant with the same technology12. Even for the available bridge tools their "fully compliant" statements many times refer to a single vendor’s products selection which does not support the vendor’s independence theory.

Our research concerns the development of an architecture capable to provide an independent context for building mediators capable to integrate multi-technology distributed objects. We are using the Java language as the programming tool for the creation of a mediator mechanism. We are using the language as a "general-purpose object glue". The results, of our work until now, have proven that the integration of different middleware remoting technologies is possible.

Up to now our architecture allows the interoperation between an RMI-client and a CORBA-server, a CORBA-client and an RMI-server, a CORBA-client and a COM-server, and an RMI-client and a COM-server. Our interoperation between RMI and CORBA does not depend on the support of the IIOP protocol in the RMI architecture. In the future we plan to complete the circle of the interoperations between the RMI, the CORBA and the COM technologies. Moreover, we plan to create a tool through which a developer will automatically create the needed mediator mechanism. The integration and the application of the Java Object Mediator can provide truly vendor-, language-, and technology-independent interoperation between different software objects.



1. Clemens Szyperski, "Component Software: Beyond Object-Oriented Programming", Addison-Wesley Publishing Company, Inc., 1998.

2. Object Management Group, Inc., "The Common Object Request Broker: Architecture and Specification", Revision 2.0 (Updated), Object Management Group, Inc., July 1996.

3. Microsoft Corporation, "DCOM Architecture, White Paper", Microsoft Corporation, Redmond WA USA, 1998.

4. Sun Microsystems, Inc., "Java Remote Method Invocation Specification", Beta Draft Revision 1.2, Sun Microsystems, Inc., Mountain View, California USA, December, 1996.

5. Ronan Geraghty, Sean Joyce, Tom Moriarty, and Gary Noone, "COM-CORBA Interoperability", Prentice-Hall, Inc., 1999.

6. Sun Microsystems, Inc., "Java-Based Distributed Computing, RMI and IIOP in Java", Sun Microsystems, Inc., Mountain View, California USA, June 26, 1997.

Available online:, September 1999.

7. Microsoft Corporation, "Integrating Java and COM, A Technology Overview", Microsoft Corporation, Redmond WA USA, January 1999.

8. "Java 2 Platform, Standard Edition", Sun Microsystems, Inc., Mountain View, California USA, June 26, 1997.

Available online:, November 1999.

9. "ORBacus for C++ and Java", Object Oriented Concepts, Inc., Billerica Ma USA. Available online:, November 1999.

10. "Microsoft Software Development Kit for Java 3.2", Microsoft Corporation, Redmond WA USA. Available online:, November 1999.

11. "Microsoft Virtual Machine build 3188", Microsoft Corporation, Redmond WA USA. Available online:, November 1999.

12. John Charles, "Middleware Moves to the Forefront", IEEE Computer, Vol. 32, No 5, pp. 17-19, May 1999.