Jim
Ries
Student
Number: 423566
CECS
400: Problems (CORBA)
Summer
Semester 2000
August
1, 2001
Providing Access to DCE Services from CORBA Clients
Introduction
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[1],[2]
about CORBA and dabbled with some sample programs. I downloaded and installed a couple of ORBs (ORBACUS, omniORB[3]),
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.
CORBA Overview
The
Common Object Request Broker Architecture (CORBA)[4]
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.
CORBA / DCE Bridging
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.
Static bridge to a given DCE host
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.
Static bridge to a given DCE host via 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:
- binop_clt on RiesJ uses
Name Service on Darwin to find CORBA BINOP server (binop_impl) on Darwin.
- binop_clt on RiesJ uses
CORBA over TCP/IP transport to send requests to binop_impl on Darwin.
- binop_impl on Darwin
uses DCE (probably over TCP, but can fall back to UDP) to send requests to
DCE BINOP server (binops) on Condor.
- Results come back from
binops on Condor to binop_impl on Darwin.
- Results are relayed
back from binop_impl on Darwin to binop_clt on RiesJ.
Commercial Solutions to Bridging
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.
Entera DCE-CORBA Bridge
The
Entera DCE-CORBA Bridge[5]
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
Iona COMet
Iona, a major ORB vendor, has a
solution called COMet[6],
which can be used to bridge between CORBA and Microsoft’s Component Object
Model (COM). Although not strictly
relevant to this discussion of bridging CORBA and DCE, the technique used by
COMet is interesting and possibly could be applied here.
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
Conclusions
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.