Java in Distributed Computing

Table of Contents

1. Introduction
2. Java IDL
2.1 Java IDL Features
2.2 Evaluation
3. Remote Method Invocation (RMI)
3.1 What is RMI
3.2 Implementation
3.3 Peer-to-peer communication
4. JavaSpace
5. RMI versus Java IDL
6. Conclusions

References

Demonstrations

1. Introduction

The introduction of Java has had a significant impact on distributed computing. Some people see Java as the "last resort" on Object Management Group's (OMG) battle against Microsoft's DCOM. Some people are more excited over the possibilities introduced by Java such as ease of dynamic code loading, security features etc.

There are different mechanisms which can be used for distributed computing over a network. Traditionally sockets and custom protocols have been used as a solution for inter-object communication. Remote Procedure Calls (RPC) have also been a popular communication mechanism for the past few years. Java provides additional mechanisms for remote object-to-object communication. In this paper we introduce Remote Method Invocation, JavaSpace and CORBA IDL for Java.

2. Java IDL

Java IDL [2]  adds CORBA  [3] (Common Object Request Broker Architecture) capability to Java, providing standards based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP (Internet Inter-ORB Protocol) defined by the Object Management Group. Runtime components include a fully compliant Java ORB for distributed computing using IIOP communication. The following figure shows the architecture of CORBA compliant system.
 

2.1. Java IDL features

The JavaIDL runtime is referred to as an Object Request Broker (or an ORB). The ORB is responsible for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request.

The IDL compiler included in the Java IDL package conforms to the OMG IDL to Java mapping [1] . The compiler produces stubs and skeletons required by the Static Invocation Interface (SII).  Java IDL supports both Static and Dynamic invocation interfaces, where the requests are generated on the fly.

The Java IDL reference implementation uses IIOP as a network protocol, but can also accommodate other network protocols.

To use Java IDL to create CORBA comformant servers requires the following steps:
 

1. Write the IDL describing the interface.
2. Use the IDL compiler to generate skeletons.
3. Implement the servant.
4. Write the server.
5. Compile.

To create a client for the server:
 

1. Use the IDL compiler to create stubs.
2. Write the client code.
3. Compile.
 

2.3. Evaluation

Important part of the CORBA specification are the services [4] . Java IDL's biggest problem is the lack of services. Java IDL only provides a naming service. Java Transaction Service (JTS), OMG compliant OTS,  has also been specified and it should be a part of Enterprise Java [6] . Other services like trader and event service would be a nice benefit.

The following features of the CORBA 2.0 specification are missing:

• No support for Dynamic Skeleton Interface (DSI),
• Multiple Dynamic Invocation Interface request operations are not supported,
• Unions inside Any and Unions with boolean discriminators.

Also, some of the features already published by the OMG are not implemented, for example:

• New IDL types (except signed and unsigned longlong),
• Portable Object Adapter (POA) [5] .
 

2.4. Future of the Java IDL

Java  IDL is going to play an important role in the Enterprise Java Beans (EJB), since Java IDL is used in ensuring the interoperability of the multivendors EJBs. The CORBA mapping will include:
• The mapping of clients interfaces to CORBA IDL
• Propagation of transaction context
• Propagation of security context
   
Java IDL seems to have a strong position especially in the enterprise due to huge volume of legacy systems that could be operated from thin clients. What remains to be seen is the reaction of other ORB vendors like Iona and Visigenic when Sun is giving away ORB implementations for free.

There hasn't been any announcements of future enhancements for Java IDL. It would be quite natural and useful to see implementation of other CORBA services, especially security and trader. It is also interesting to see how Java IDL and RMI co-exists [7]
 

3. Java RMI

3.1 What is RMI

RMI [8] is a relatively simple distribution mechanism which is included in the Java language (JDK 1.1). It allows client Java objects to invoke methods in server Java objects, no matter if they reside in the same JVM or even in the same host. RMI can be be thought as the object equivalent of RPC. It is quite natural way of implementing distribution when all participants are written in Java, because no extra burden of additional communication protocols or handling of underlying connection mechanisms (like sockets) is needed in the distributed objects themselves but they can invoke the remote objects almost like local ones.

The limitations of RMI are that it uses synchronous method invocation and it can be used only in Java-to-Java environment. One weakness is also that it cannot optimize the situation where both the client and the server are running in the same host.

3.2 Implementation

JDK includes all the required classes (java.rmi.*) for RMI implementation. The implementation is straightforward, one has to do the following:
• Define remote interface(s) for the Java server object(s)
• Create implementation class(es) for the interface(s)
• Write Java client(s)
• Generate Stub(s) and Skeleton(s) for the server(s) using rmic
• Compile the server(s) and client(s)
• Start the Naming Server (rmiregistry)
• Start the Java server(s)
• Run the client(s)
Figure 1. RMI implementation

The only change to the client is to locate the remote server. This is done by the static lookup method of java.rmi.Naming class. After that the invocations to the remote server are made same way as to local objects. Also the implementation of the server is almost like traditional classes. The server has to set a securityManager and bind itself to the local rmiregistry in order to be available for its clients. The methods that can be invoked remotely have to throw RemoteException to illustrate problems in the remote connections.

Object's stub (generated by the rmic) is a remote view of that object. It contains only the remote methods of the object and it runs on the client side as the representative of the remote object. It is like a client-side proxy which takes care of invoking the right server object in the right location. The skeleton for a remote object is a server-side entity that contains a method which dispatches calls to the actual remote object implementation.

The actual implementation of RMI is based on transparent transmission of objects from one address space to another utilizing the object serialization. Another technique, called dynamic stub loading, is used to support client-side stubs. This technique is used when a stub is not already available to the client and it allows the client to use the built-in operators for casting and type-checking in Java.

3.3 Peer-to-peer communication

Pure client/server model fits systems quite well if the clients always initiate requests and the server handles them and just passes the result. Anyway, in other applications, the server has to be able to invoke methods in the client as well. This is called peer-to-peer since both objects act as client and server.

RMI allows the peer-to-peer communication using stubs. (Original) client object invokes a method of the server object and passes a stub which points back to the client, and the client becomes a server.

4. JavaSpace

RMI as it is today (JDK1.1) does not make distributed systems easy to design - they merely make them possibly to approach. JavaSpace model [9] is an advanced research topic of Java Systems East (part of javaSoft). It provides distributed persistence and object exchange mechanism.
Figure 2. JavaSpace architecture

Clients perform operations that map entries or templates onto JavaSpaces. These can be singleton operations (as with the upper client), or contained in transactions (as with the lower client) so that all or none of the operations take place. A single client can interact with as many JavaSpaces as needed. Notifications go to event catchers, which may be clients or proxies for clients.

5. RMI versus Java IDL

This section will compare RMI and Java IDL based on properties that might have effect on selecting a specific distribution mechanism.
 
 

Table 1. Comparing RMI and Java IDL 

Property	Java RMI	Java IDL
Heterogenity	Java only	Support for multiple programming languages that have IDL mapping
Speed of evolution	Fast. Controlled by JavaSoft East.	Controlled by OMG, a consortium of 600 companies -> slow. How fast Java IDL will adopt new CORBA features is unknown.
Transport	RMI proprietary transport protocol. JavaSoft has agreed to support IIOP in the future releases. Whether this happens or not is something that remains to be seen.	Standard CORBA IIOP.
Performance	The RMI in JDK 1.1 had quite poor performance, but this should be improved in JDK 1.2.	Moderate, a place for enhancements.
Services	Only trivial naming service (Registry).	Only naming service. Could use CORBA Services provided by other vendors.
Security	SSL included in JDK 1.2	No security at the moment. Could implement CORBA security, or at least Secure IIOP.

 

6. Conclusions

Java has created interesting turbulent to the field of distributed computing. OMG has been quick to adopt Java and JavaSoft has been active to produce tools for distributed computing. It is interesting to see what will happen in the battle between DNA-RMI-CORBA.

Java the language also brings something new to distributed computing. The possibility to utilize the dynamic code loading and the strong security could give the implementations new opportunities. For example, various agent platforms have started to blossom, mainly due to Java.

Hopefully, as the performance of Java increases, the quality of the tools will also increase. For example, in RMI it would be nice to see support for different quality of services, such as provided by replicated services.

References

[1] OMG IDL-Java mapping submission. http://www.omg.org/library/schedule/IDL_to_Java_RFP.htm
[2] Java IDL home page. http://java.sun.com/products/jdk/idl/index.html
[3] CORBA 2.1 specification 1997. http://www.omg.org/corba/corbiiop.htm
[4] CORBAService specification 1997. http://www.omg.org/corba/csindx.htm
[5] ORB Portability Enhancements 1997. http://www.omg.org/library/schedule/Technology_Adoptions.htm
[6] Enterprise JavaBeans Draft Specification Version 0.90. http://java.sun.com/products/ejb/index.html
[7] David Curtis, Java, RMI and CORBA White Paper, 1997. http://www.omg.org/news/wpjava.htm
[8] RMI home page.
http://java.sun.com/products/jdk/rmi/index.html
[9] Sun, JavaSpaces API.
http://chatsubo.javasoft.com/javaspaces

Demonstrations

RMI

The RMI demonstration consists of a set of RMI servers and a generic client which can use all of them. The RMI servers are running on a dedicated host (tammi.hut.fi). The client is a RemoteObjectBrowser which can be started in any Internet node and it can connect to any host running the rmiregistry.

The servers implement the java.rmi.Remote interface and register themselves in the rmiregistry in the startup. The client is a (G)UI which lets the user select a host and browses all the active RMI servers on that host. Furthermore, the RemoteObjectBrowser lets the user click on a RMI server and dynamically discover the remote methods implemented by that server. Then the user can click on any method and a dialog, that lets the user enter parameters and invoke the method, will come up. The result is showed in the dialog too.