A distributed computing system consists of a number of autonomous machines connected by some underlying communication mechanism. The machines in a distributed system may have different hardware architectures and operating systems. Middleware technologies exist to mask the underlying differences that may exist in a distributed system. Middleware technologies provide additional services that help to solve some of the problems associated with programming in a distributed environment, such as naming, transactions, security and reliability.

Open Software Foundation (OSF) Distributed Computing Environment (DCE) and Object Management Group (OMG) Common Object Request Broker Architecture (CORBA) are two such middleware technologies that support the construction and integration of client-server applications in heterogeneous distributed environments. CORBA is an emerging standard that enhances application flexibility and portability by automating many common development tasks such as object location and parameter marshaling. A large number of distributed applications are being developed using the CORBA technology. However, a significant number of complex distributed applications that were developed before CORBA, use the DCE technology. The underlying middleware components of the two platforms are incompatible. It is not cost-effective to re-implement the applications built using DCE, from scratch using CORBA. Since most of the future client/server applications will be developed using CORBA, it is essential to have a CORBA front end for existing non-CORBA applications.

In this project the performance of interoperability between CORBA and DCE was analyzed using the Inprise DCE- CORBA bridge. The bridge can be used to enable CORBA applications to use IIOP (Internet Inter-ORB Protocol) to seamlessly and securely access data and transactions from DCE applications. Bridge objects are CORBA objects that represent DCE servers. These objects are the means by which CORBA clients invoke operations on DCE servers. The bridge acts as a standard DCE client when talking to any DCE server. Thus, bridge objects act simultaneously as CORBA servers and DCE clients. In its role as a CORBA server, the bridge encapsulates DCE systems in an object wrapper that enables the object-oriented CORBA clients to access DCE data and transactions using object semantics.

The feasibility of using the bridge to interoperate between DCE and CORBA middleware is proved by the performance analysis conducted in this project. The timing results for various client/server scenarios using the bridge are given below. The timings indicate the average time for the client to ping the server. To simulate various environments, the server, bridge and client were run in different configurations ranging from all three being on the same machine to all being on different machines. To identify the impact of the programming language used, timing results for each configuration were collected using both C++ and Java as the languages used to implement the CORBA client. To evaluate the performance of the bridge for Web applications, timing results were also collected using a Java applet as the CORBA client.

In this project, timing results for CORBA and OODCE were also collected to compare the performance of the bridge with DCE which is based on the procedural language C against that with OODCE which is based on the object-oriented language C++. In summary, the performance of the bridge with DCE or OODCE on the server side is approximately the same as indicated by the average times for the CORBA client to ping a OODCE server shown below:

To sum up, the overhead incurred in using the Inprise DCE-CORBA bridge to interoperate DCE and CORBA frameworks is approximately a few milliseconds for various client/server configurations. This is an acceptable overhead when leveraging legacy applications implemented using DCE or OODCE. An existing DCE framework can be utilized without any modification to the server code or the deployed configuration.

The complete report is given (in PDF) here.