Distributed Object Computing in Java

Sun Microsystems has added a native DOC facility to Java called Java Remote Method Invoca-tion (Java RMI) [Sun96d]. Java RMI supports seamless invocaInvoca-tion of methods in objects resid-ing in different virtual machines. Java RMI servers implement so-called remote interfaces that must extend the (empty) interface Remote. In Java RMI 1.0, the implementation class must extend the class java.rmi.server.UnicastRemoteObject which provides basic func-tionality for singleton servers. Future versions of Java RMI will provide other server base classes, for instance one that supports replicated servers. A remote interface must be compiled with the rmic interface compiler, which generates client stub and server skeleton code. The client stub contains the definition of a proxy class with a name identical to the one of the remote interface. Java RMI clients create proxy objects and bind them via a name service to remote implementations before accessing their methods. The methods of the proxy object for-ward invocations to the respective implementation of the remote interface. Clients may pass both local and remote objects as parameters in remote invocations. Passing a local object as parameter results in a copy of the object from the virtual machine of the client to the one of the server. This is only possible if the local object is serializable, i.e., if it implements the (empty) java.io.Serializable interface or thejava.io.Externalizable interface². It is pos-sible that the class code for the copied object is not available at the server side. In this case the server may dynamically load this code from the client via the so-called RMIClassLoader. Pass-ing a remote object as a parameter results in a copy of the client stub and the creation of a proxy at the remote side. The automatic transfer of client stub code and class code is one of the strong points of Java RMI. Given this possibility there is no need in Java RMI to define some-thing like CORBA’s Dynamic Invocation Interface.

1. This does not preclude the use of OLE and COM. OMG is about to issue a standard for the interworking between COM and CORBA, which allows to access OLE controls via the CORBA object bus. Major CORBA vendors already offer proprietary gateways to COM.

2. These interfaces are defined in the Java Object Serialization Specification [Sun96c].

Java RMI may play an important role in Java Beans [Sun96a], Sun Microsystems’ compo-nent framework for Java. Java Beans defines a set of interfaces that allow the Java classes that implement them to be integrated into visual application builder tools. These interfaces provide support for introspection, customization, events, properties and persistence. The most impor-tant features of a Java Bean are the methods it provides, the events it generates, and the proper-ties it allows to set. Every Java Bean may be accompanied by aBeanInfo class that allows to introspect the Bean, and a customizer class that can provide substantial comfort for the cus-tomization of the Bean. The upcoming Java Media API [Sun96b], which will provide standard programming interfaces for 2D and 3D graphics, audio and video, collaboration, telephony, speech and animation, will probably be based on Java Beans. Future versions of the Java Abstract Window Toolkit (AWT) will be compatible with Java Beans.

Assessment

Java RMI 1.0 does not provide much more than remote method invocation, object passing and dynamic class loading. Additional features that need to be mentioned are distributed garbage collection, and the definition of a basic name service for client bootstrapping. Java RMI is therefore far from providing a distributed computing environment similar in scope to CORBA.

However, what really keeps it from being the DPE of choice for the MMC platform is its dependency on a single programming language. This relieves it from a lot of ballast and makes programming with it easy, but it has to be realized that it can only be used for distributed appli-cations that are entirely written in Java. It can nevertheless be imagined that Java RMI is used in a MMC platform for communication on application level, i.e., in addition to CORBA. An MMC platform that integrates mobile code written in Java will profit from the Java Beans com-ponent framework, and may therefore also support Java RMI for communication among Beans in Java applets and applications.

OMG has issued an RFP for the transparent use of IIOP in Java applets and applications that want to access CORBA servers, or that want to make objects available to CORBA clients [OMG97c]. The basic idea behind this is to take a Java interface definition and to compile it into an OMG IDL definition, from which stub and skeleton code can be generated in a second step. The result of this is that it will be as easy for a programmer to use CORBA as it is to use Java RMI. Proposals to the RFP are required to provide the same amount of functionality as Java RMI. Initial submissions are due in September 1997, with the adoption of a standard being scheduled for the beginning of 1998.

3.5 Conclusion

This chapter introduced CORBA, and justified the choice of CORBA as the DPE of the MMC platform proposed by this thesis. CORBA is not perfect, but it is unrivaled at the time of writ-ing, and with its integration into the Web it may well become as ubiquitous as HTTP is today.

In the MMC platform it will be used for all control communication among platform compo-nents. Interfaces defined in IDL and a single network level protocol, IIOP, provide the func-tionality that in the past would have required a multitude of message-based application-level protocols. In the long run, CORBA may also provide for the transparent streaming of multime-dia data over the network.

4.1 Introduction

In Chapter 2 it was stated that an MMC platform must be built on top of a general distributed processing environment (DPE) so that platform design and implementation may concentrate on MMC specific problems. Chapter 3 presented OMG’s CORBA as the distributed computing platform of choice for the DPE. CORBA is object-oriented and language independent and offers a wide and ever growing range of distributed processing functionality that can be readily integrated into applications. Object-orientation is the key to component frameworks, which are in turn the key to extensible application platforms. The suitability of CORBA for component frameworks has been demonstrated with the OpenDoc component model that is based on IBM’s System Object Model (SOM), a CORBA-compliant ORB. An application platform based on a component framework has the advantage that it is extended with every component that is developed for it. Applications developed on top of such a platform communicate with a multitude of objects that behave according to some predefined rules, rather than with a single entity that implements an extensive programming interface. This thesis distinguishes between MMC platforms that are based on a component framework, and others that export a monolithic programming interface. The internal structure of platforms that export a monolithic program-ming interface is usually static, which means that the objects of which it is composed are put into a static relationship, making it difficult if not impossible to plug in new functionality.

Component frameworks on the contrary promote dynamic binding and have to be regarded as a meeting place for objects that are able to discover themselves and to collaborate. In the follow-ing, MMC platforms with monolithic programming interfaces are simply referred to as mono-lithic MMC platforms, alluding to both the monomono-lithic API and the static internal structure of such platforms. Monolithic MMC platforms are being superseded by platforms based on com-ponent frameworks, but they are still relevant given that the platform approach for MMC appli-cations has not yet prevailed over the stand-alone application approach. Platforms in general, and therefore also monolithic MMC platforms, have to be considered as a substantial progress with respect to the stand-alone application.

This chapter presents examples for monolithic MMC platforms, and exposes some of the problems with them for which component frameworks are a natural solution. This chapter is thus a motivation for the remainder of this thesis, which is dedicated to component frame-works. The platforms that are discussed here are Bellcore’s Touring Machine, Eurecom’s Beteus platform, and IBM’s Lakes platform. The Touring Machine was the first platform with an API that was deployed on a large scale. The Beteus platform is the contribution of this thesis in the area of monolithic platforms. It features a high-level connection management API that significantly facilitates application development. The Lakes platform finally offers some fea-tures that place it at the border between monolithic MMC platforms and component frame-works.