Technical Note DHPC-033
February 1998
Services within the DISCWorld system can be represented by objects. These services may be distributed on nodes of a heterogeneous system, with communication between clients and these services and also between the services themselves, provided by a suitable middleware system. As well as managing communication, a middleware system has to provide for locating and activating services, gathering performance data and security. We describe how the CORBA 2.0 specification, developed by the OMG, and CORBAServices can be used as a basis for a middleware system to manage DISCWorld Services. We also describe how Java and Java RMI can be used in combination with CORBA and what benefits this brings. We discuss some of the problems with the mapping of the CORBA interface definition language, IDL, to Java.
The DISCWorld infrastructure [8] requires the
development of a middleware system for managing distributed objects or
services. This middleware system must handle the management of objects,
specifically locating, activating and selecting object services. These
services may be written in different programming languages and run on different platforms
with this heterogeneity managed in a transparent fashion by the middleware
system.
The CORBA 2.0 specification [1,6], released by the Object Management Group
[4], describes a middleware solution based around encapsulating code in
objects and providing a brokering service and protocols to support communcation
and invocation between these objects. CORBA acts as a standard
for distributed system support. The CORBA 2.0 specification also describes
an interface definition language (IDL) and standard services, such as the naming,
event and trading services which provide higher-level functionality.
Java [2] is a portable language and environment which provides its own invocation mechanism
for distributed objects known as Java RMI [10]. There exist several implementations
of the CORBA 2.0 specification for Java [7,11,12] and a standard IDL to
Java mapping. Java can be used as the implementation language for CORBA
to produce a portable middleware system and has been done so by Iona [7]
and Visigenic [11].
We discuss the suitability of CORBA as a middleware basis for managing
services within the DISCWorld infrastructure. We shall describe how many
of the features of a middleware system can be implemented using CORBA and
CORBAServices and also potential problems with mapping IDL to target languages,
specifically Java.
We discuss how Java RMI and CORBA can be combined and the resulting
benefits from this combination, including performance gains and ease of
programming. We focus on a specific implementation of the CORBA specification, OrbixWeb
from IONA [7].
CORBA has been
developed with the aims of allowing objects written in any langauge to
communicate and to provide for the inclusion of legacy objects through
specifying a matching CORBA interface.
The CORBA 2.0 specification describes an Object Model and presents several
interfaces which allow clients to invoke and find information about CORBA
registered operations. Also described are several services which are used
by CORBA clients and servers to manipulate and find CORBA objects at a
higher level.
Client-server communication is performed in CORBA using an Object Request
Broker (ORB) to provide references to services and a proxy service which
performs any necessary translations required between the two objects. This
protocol is used to allow seamless communication between objects written
in different languages and requires packing and unpacking of any parameters
which adds considerable overhead to the CORBA communication constructs
[9].
Services in DISCWorld may be written in different languages and for different platforms indicating that the possible use of both CORBA and Java is desirable. DISCWorld services are described in [13].
IDL can be used to specify the interfaces of services
within DISCWorld. OMG's IDL is based loosly on C++ and is object oriented.
Specifying an object using IDL requires the development of an interface
which contains all attributes and methods that are required. IDL contains
simple types as well as C++ based constructs to create structured types
including typedef and enum. IDL also allows for the development
of modules so that interfaces and structured types can be grouped
into one package.
Due to the WWW interface requirements of DISCWorld services, Java is a
potential implementation language. Java to IDL mappings exist and due to
Java's object oriented nature, IDL interfaces can be simply a translation
of a Java interface.
The potential requirements to manage a service within DISCWorld are:
Consider the simple example of a distributed calculator. This might
support some well-defined operations such as plus, multiply, add and
divide on one or more well-defined data types such as floating point
or integer. By way of illustration of the DISCWorld concept, these
operations might be distributed in the sense that they are provided as
services by a participating set of servers - all operating as peers in
a serverless architecture model.
A user query is injected into the system, in the form of a one or more
data entities and a sequence of operations to be applied to them. The
DISCWorld model is for the (possibly complex) user query to be broken
up into components that can be matched against the well defined
pre-existing services and farmed out appropriately to a subset of the
participating service providers on the basis of some cost estimation.
The data entities need to be appropriately marshalled, and the services
brokered to obtain a result that is finally delivered to the user.
This is a contrived example and would perform poorly since the
operation granularity is very low on a realistic distributed suystem.
However in a more realistic case, operations might be significantly
more costly ones such as image processing operations, and the relevant
data entities might be large data images or sets of images.
CORBA systems provide through a trading service the ability to obtain
a list of operations which are registered with an ORB. There is also a
_bind() operation which allows clients to obtain a reference to
a specific instance, an instance of a particular class or any instance.
All of these operations require access to an ORB.
A client can use one of the several vendor provided communication methods
which are similar to IIOP or it can use the CORBA standard IIOP. Vendor
specific protocols may require a node to be specified when contacting an
ORB. IIOP requires that either a ORB identifier or a hostname or some suitable
identifying information be given in the Orb_Init() method call.
As a client does not require an ORB at its end, it makes sense that a client
can run on any platform that supports the client implementation language
and the basic protocol implementation method (eg. sockets).
The problem of how ORBs find each other or how clients find ORBs is still
to be addressed, Any service request requires at least an initial reference
to an ORB. This issue is discussed further in [13].
Java RMI can be used as a communication mechanism
for remote Java objects, however Java RMI alone does not have all of the
services that CORBA provides. There exists pure Java CORBA implementations
that have the benefits of Java programming (portability, JDK facilities,
WWW access) although they are currently still implementation dependant.
These implementations could be combined with Java RMI to produce objects
that could communicate by both methods. This would allow greater flexibility
in object development and integration to the CORBA environment.
Experimentation has been performed using OrbixWeb and Java RMI which shows
that both communication mechanisms can be used at once with minimal alteration
to the service code. The Java interface generated by the compilation of
IDL to Java can be used as the remote interface required by Java RMI. A
compiler has been proposed which takes generated CORBA service code and
adds the required code for compliancy with Java RMI. This is discussed
in more detail in Section 5.3. Section 5.1 presents a discussion of problems
with the IDL to Java mapping for OrbixWeb which does effect communication
using Java RMI.
OrbixWeb [7] is Iona's implementation of the CORBA
2.0 specification for Java. Iona also have C++, Ada 95 and Smalltalk mappings
for IDL which use their product Orbix. OrbixWeb objects are able to communicate
to Orbix objects using the IIOP protocol.
OrbixWeb 3.0 is a pure Java implementation of the CORBA 2.0 specification
although it is not completely implementation independant. A Daemon must
be set up on the service node which handles all requests and activation.
Clients can be on any node within the network with client nodes only required
to be able to run the Java Virtual Machine.
OMG's interface definition language, IDL, contains
several language concepts that do not translate in a one-to-one manner
to Java. This is also the case for other languages, such as C++ [5]. This
issue has been tackled in OrbixWeb by additional classes that must be used
when programming in Java. An example of this is the problem of passing
parameters by value. In IDL, parameters have a mode specified as one of:
in, out and inout. This problem is also discussed
relative to the C++ mapping of IDL in [5].
OrbixWeb introduces the concept of holder classes, where a class
is built for every standard typein Java and for every user defined type
built in the IDL. The use of these classes, however, is OrbixWeb specific
and not a standard part of the JDK. This causes problems when combining
pure Java classes with Java-CORBA classes using RMI, as the holder classes
are unknown and are at this stage not serialisable. A serialisable
class is one that knows how to pack and unpack itself so that it can be
correctly sent in an unstructured form. A RMI client requires
an object to be serialisable to be passed correctly to a remote method.
A simple example of a calculator has been developed to explore how OrbixWeb
deals with these issues. By implementing a wrapper class, which is serialisable,
around the required holder class we are able to invoke methods using both
communications methods.
The use of holder classes also causes a problem when trying to integrate
legacy objects into a CORBA environment. These legacy objects will have
no concept of holder classes and so IDL specifications must be written
to limit use of these features.
Only some of the CORBAServices are implemented in OrbixWeb which is not in final release form. It provides facilities for locating and searching for objects and for adding services to the repository. It supports the _bind() and Orb_Init() services described in Section 3.2. Services can be located by enabling the ORB with the appropriate classpath. This classpath includes all services that we wish the ORB to automatically find and activate as well as other code that the ORB requires. By placing services within this classpath we do not have to explicitly register the service with the ORB. Services that exist outside of the ORB's classpath can be registered by using the putit command.
In Section 4 we describe combining CORBA communication
methods with Java RMI. This can be sucessfully performed using the OrbixWeb
implementation of CORBA and their IDL to Java compiler.
When an IDL specification is compiled into Java, several automatically
generated Java classes are created which perform the roles of interface
specification, method packing and unpacking and communication definition.
The programmer then has to write an implementation for the service and
compile it with the generated classes. To enable use of the service, the
programmer has to write a server class which instantiates a service. The
client, unless using DII or DSI, must create a reference to the server
implementation by interrogating the ORB and using the generated classes.
The service will not actually start execution until the first client reference
is made.
Using Java RMI, the programmer has to write a Java interface which extends
java.rmi.Remote and throws the appropriate exceptions. An implementation
for the interface is then written and the class is compiled and registered
with the rmiregistry. A client can communicate with the service
by interogating the registry for a reference to the service. More information on
this can be found in [14].
CORBA can be used effectively to support a distributed
middleware system on a small scale. It is probably more useful as a service manager
on a node than as a distributed service manager. CORBA does provide some
facilities that could be useful in a distributed sense, such as being able to search for
certain types of services and dynamically altering the services on a particular node.
However, CORBA does not provide any means for locating ORBs or for searching a CORBA network
for services.
CORBA combined with Java may produce an environment where these issues can be
solved. We can use CORBA as a node manager and to handle service requests
and client queries whilst using locator services built using Java. Being
able to combine Java and CORBA easily is a requirement of such a system and
a requirement that we have shown to be fulfilled.
This work is being carried out as part of the Distributed High Performance Computing Infrastructure (DHPC-I) project of the Research Data Networks Cooperative Research Center (RDN CRC) and is managed under the On-Line Data Archives Program of the Advanced Computational Systems CRC. RDN and ACSys are established under the Australian Government's CRC Program.
[1] Ben-Natan,R., "CORBA: A Guide To Common
Object Request Broker Architecture", McGraw-Hill, 1995.
[2] Vogel, A., Duddy, K., ``Java Programming with CORBA'', Wiley Computer
Publishing, John Wiley and Sons, Inc. 1997.
[3] Gosling, J., Joy, B., Steele, G., ``The Java Language Reference'',
Pub. Addison-Wesley, 1996, ISBN 0-201-63451-1.
[4] Object Management Group: http://www.omg.org.
[5] Grasso, E., "Passing Objects by Value in CORBA", Trends in
Distributed Systems: CORBA and Beyond, LNCS 1161, Proceedings of TreDS
'96, Germany, 1996.
[6] Mowbray, T.J., Zahavi, R., "The Essential CORBA: Systems Integration
Using Distributed Objects", John Wiley & Sons, Inc., 1995.
[7] Iona Technologies PLC.: http://www.iona.com.
[8] Hawick, K.A., Brown. A.L., Coddington, P.D., Hercus, J.F., James, H.A., Kerry, K.E., Maciunas, K.J., Mathew, J.A., Patten, C.J., Silis, A.J., Vaughan, F.A., "DISCWorld: An Integrated Data Environment for Distributed High-Performance", Technical Note DHPC-027, Department of Computer Science, University of Adelaide, 1998.
[9] Gokhale, A., Schmidt, D.C., ``Measuring the Performance of Communication
Middleware on High-Speed Networks'', Proceedings of SIGCOMM'96, August,
1996, pp 306-317.
[10] Schneider, J., Arora, R., "Using Enterprise Java", Que Corporation, 1997.
[11] Visigenic Software, Inc.: http://www.visigenic.com/
[12] Distributed Systems Technology Centre: http://corbanet.dstc.edu.au/
[13] Silis, A., Hawick, K.A., "The DISCWorld Peer-To-Peer Architecture",
Technical Note DHPC-028, Department of Computer Science, University of Adelaide, 1998.
[14] SIlis, A., Hawick, K.A., "World Wide Web Server Technology and Interfaces for Distributed, High-Performance Computing Systems", Technical Note DHPC-017, Department of Computer Science, University of Adelaide, 1997.