Distributed Object Model for the Java System
We show a distributed object model for the Java1 System (hereafter referred to simply as “Java”) that retains as much of the semantics of the Java object model as possible, and only includes differences where they make sense for distributed objects. The distributed object system is simple, in that a) distributed objects are easy to use and to implement, and b) the system itself is easily extensible and maintainable. We have designed such a model and implemented a system that supports remote method invocation (RMI) for distributed objects in Java. This system combines aspects of both the Modula-3 Network Objects system and Spring’s subcontract and includes some novel features. To achieve its goal of seamless integration in the language, the system exploits the use of pickling [14] to transmit arguments and return values and also exploits unique features of Java in order to dynamically load stub code to clients 2 The final system will include . distributed reference-counting garbage collection for distributed objects as well as lazy activation . 1Introduction Distributed systems require entities which reside in different address spaces, potentially on different machines, to communicate. The Java™ system (hereafter referred to simply as “Java”) provides a basic communication mechanism, sockets [13]. While flexible and sufficient for general communication, the use of sockets requires the client and server using this medium to engage in some application-level protocol to encode and decode messages for exchange. Design of such protocols is cumbersome and can be error-prone. 1. Java and other Java-based names and logos are trademarks of Sun Microsystems, Inc., and refer to Sun’s family of Java-branded products and services. 2. Patent pending An alternative to sockets is Remote Procedure Call (RPC) . RPC systems abstract the communication interface to the level of a procedure call. Thus, instead of application programmers having to deal directly with sockets, the programmer has the illusion of calling a local procedure when, in fact, the arguments of the call are packaged up and shipped off to the remote target of the call. Such RPC systems encode arguments and return values using some type of an external data representation (e.g., XDR). RPC, however, does not translate well into distributed object systems where communication between program-level objects residing in different address spaces is needed. In order to match the semantics of object invocation, distributed object systems require remote method invocation or RMI. In such systems, the programmer has the illusion of invoking a method on an object, when in fact the invocation may act on a remote object (one not resident in the caller’s address space). In order to support distributed objects in Java, we have designed a remote method invocation system that is specifically tailored to operate in the Java environment. Other RMI systems exist (such as CORBA) that can be adapted to handle Java objects, but these systems fall short of seamless integration due to their inter-operability requirement with other languages. CORBA presumes a heterogeneous, multi-language environment and thus must have a language neutral object model. In contrast, the Java language’s RMI system assumes the homogeneous environment of the Java Virtual Machine, and the system can therefore follow the Java object model whenever possible. We identify several important goals for supporting distributed objects in Java:
Free download research paper
CSE PROJECTS