|
|
|
|
Abstract: This report investigates the use of Java in distributed computing. The report presents the methods that JDK 1.1 already provides, extensions in JDK 1.2 (currently in beta state) and Sun's research projects related to Java and distributed computing are also introduced shortly. |
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.
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:
To create a client for the server:
The following features of the CORBA 2.0 specification are missing:
Also, some of the features already published by the OMG are not implemented, for example:
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]
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.
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.
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.
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.
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. |
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.
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.