Student Number: 423566
CECS 400: Problems (CORBA)
Summer Semester 2000
August 1, 2001
Providing Access to DCE Services from CORBA Clients
I originally perceived a need in my Ph.D. program of study for some exposure to CORBA, and planned to fulfill this need via a problems course. I had previously done work with various distributed computing technologies in my master’s thesis (DCE), in University of Missouri coursework (JAVA RMI), and in my professional career (DCOM). It seemed to me a glaring weakness to ignore CORBA, and thus I enrolled in CECS 400 – CORBA in Summer 2000.
Over Summer Semester 2000, I read, about CORBA and dabbled with some sample programs. I downloaded and installed a couple of ORBs (ORBACUS, omniORB), finally settling on omniORB. However, I never developed a project to drive my exploration of the technology and so shelved my work at the end of the semester with the intention of picking it up again soon.
I finally returned to this work during the summer of 2001. In an effort to leverage previous work our group has done with the Distributed Computing Environment (DCE), I determined to explore ways in which CORBA and DCE can interoperate. This document describes the result, an example bridge program that can provide DCE services to CORBA client programs.
The Common Object Request Broker Architecture (CORBA) is a standard promoted by the Open Management Group (OMG) for doing heterogeneous distributed object computing. CORBA relies on an Object Request Broker (ORB) to route requests for service from clients to servers, and to provide a number of infrastructural services. These services include Name Service (which provides a mapping between human readable strings and machine readable object identifiers), and Trading Service (which provides a mechanism for finding services based on categorization rather than specific name). Many other standard services have been defined and are available in a given ORB based on its compliance level (e.g., CORBA 2 versus CORBA 3 standard).
Each machine that participates in a CORBA communication must have an ORB. An ORB may be composed of dynamic link (shared) libraries, static libraries, and/or executables – the details are left to the vendor implementing the ORB. The following diagram from the OMG website provides an overview of the interaction of an ORB with a client and an implementation (server).
Note that implementation of each portion of an ORB is left completely to the vendor. For example, in omniORB, the core ORB services that provide transport from the client to the implementation (server) are implemented as library calls that are either dynamically or statically linked into each executable. Other ORBs implement the ORB core as a separate process, and clients and servers communicate with this process via any of various inter-process communication (IPC) mechanisms.
In addition to allowing communications between clients and servers that utilize the same ORB, CORBA provides for interoperation of components across ORB boundaries. This is implemented via General Inter-ORB Protocol (GIOP). GIOP is a standard for inter-ORB communication, but leaves specific low-level protocol details to implementation. For this reason, OMG has also specified a specific implementation of GIOP for communicating across the Internet via TCP/IP called Internet Inter-ORB Protocol (IIOP). IIOP has become the defacto standard for inter-ORB communication. The following diagram, also taken from the OMG website, illustrates the communication between a client and server via two ORBs.
As mentioned, my goal in exploring CORBA was to find methods for interoperation of CORBA and DCE. To this end, I examined several schemes for making our favorite DCE service, BINOP, available to the CORBA world.
My initial attempt was to create a CORBA server that implemented a skeletal BINOP interface. The actual work of the methods in the BINOP interface was done by acting as a DCE client. That is, the methods inside the CORBA BINOP server were simply RPC calls into a DCE server that in turn did the real work.
I implemented and tested this solution. However, it was difficult to use since one had to copy the stringized version of the object identifiers from the server (after it was up and running) to the command line of the client in order for the client to find the server. I improved this solution by adding support for CORBA Name Service.
This is really just an enhancement to the above solution, but incorporating Name Service support. Here, the CORBA server registers itself with a well-known Name Service (running on darwin.rnet.missouri.edu in the example below). Thus, the server comes up, registers with Name Service and awaits connection from clients. The clients come up, look for an appropriate server in Name Service, and (if an appropriate server is found) connect to the server.
In omniORB, the CORBA Name Service is implemented as a stand-alone executable program called omniNames. Figure 3 below shows omniNames being executed on darwin.rnet.missouri.edu. Both the client (binop_clt) and the server (binop_impl) communicate with omniNames.
Figure 3 : Name Server (omniNames) running on darwin
In this example, CORBA clients and servers on Darwin are configured to find the Name Service running on Darwin on port 2809 via a configuration text file, which is specified via an environment variable at runtime. CORBA clients and servers running on riesj.rnet.missouri.edu are configured to find the same Name Service running on Darwin, but using the Windows Registry rather than a text file.
Figure 4 shows the server (binop_impl) running on Darwin and configured via command line argument to look to Condor as the DCE BINOP server. Since the bridge machine (Darwin) has a full complement of DCE services, I could have utilized the existing code in binopdemo to lookup an appropriate server through Cell Directory Service (CDS), but left this as an open item due to time constraints.
Figure 4 : binop_impl (server) running on darwin
Figure 5 shows the client (binop_clt) running as a Windows 2000 console application on riesj.rnet.missouri.edu. The middle parameter is shown to be empty (“”) and can optionally be used to specify a particular server object identifier. Without the identifier as shown, the client utilizes the Name Service on Darwin to discover an appropriate server (in this case, also running on Darwin). The standard suite of BINOP requests are sent to the server, which in turn forwards them to a DCE server and relays the results back.
Figure 5 : binop_clt (client) running on riesj (Win2K)
Thus, in this example, communication proceeds as follows:
I looked for previous work in bridging CORBA and DCE, but found only Borland’s commercial solution. Like the example program I implemented, this solution goes only from CORBA clients to DCE servers; not in the complimentary direction.
The Entera DCE-CORBA Bridge is a product from Borland that provides the capability for DCE services to be called from CORBA clients. Although I did not attempt to acquire the product for investigation, the white papers on the Borland website indicate that this solution requires conversion and compilation of existing DCE IDL files for the servers that are to be exposed to CORBA clients. This would seem to indicate that the Bridge simply uses the resultant stubs/skeletons to achieve communication. Such a scheme is essentially equivalent to the work I did for BINOP, though somewhat more automated.
Figure 6 : Entera DCE-CORBA Bridge
COMet uses CORBA’s Dynamic Interface Invocation (DII) to discover and call previously unknown interfaces at runtime. Thus, a COM client might invoke a CORBA server, though COMet had no prior knowledge of either. Although DCE provides no mechanism for dynamically discovering interfaces (which would in essence require on-the-fly building of marshalling stubs), one can imagine a bridge that works in the opposite direction. That is, one could create a DCE server that searches CORBA Name Service at runtime to find compatible interfaces for a requested service and then uses DII to call that service.
Figure 7 : COMet
Accessing DCE services from the CORBA world is both possible and reasonably straightforward. The major difficulties I encountered were primarily related to developing a build environment that would work for all permutations of CORBA C++ source code, DCE C source code, and two compiler platforms (Win32 and True64 Unix). Having surmounted these obstacles, supporting any given DCE server should be clear-cut. In fact, it may be possible to automate the process of building specific server bridges in a fashion similar to the strategy employed by the Borland DCE-CORBA Bridge product.
It may also be useful to create a bridge which works in the opposite direction from that discussed. That is, it should be equally possible to create a DCE server that is also a CORBA client. Such a program could act as a bridge providing access to CORBA services to the DCE world. This process too could be automated somewhat so that arbitrary CORBA services could be made available. Moreover, bridging in this direction might not require up-font compilation of CORBA stub code if DII could be used to dynamically call CORBA servers.
 Henning, M., Vinoski, S. Advanced CORBA Programming with C++. Addison Wesly Longman, Inc. 1999.
 Schmidt, D. CORBA Overview. http://www.cs.wustl.edu/~schmidt/corba-overview.html
 AT&T Laboratories. Cambridge, England. omniORB. http://www.uk.research.att.com/omniORB/omniORB.html
 Iona Corporation. Introduction to OrbixCOMet 2000. http://www.iona.com/docs/orbix2000/1.2/comet/html/intro.html
The following pages contain source code for the BINOP bridge example program discussed in the text.