JavaDistributedObject-Waldo - The following paper was...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: The following paper was originally published in the Proceedings of the USENIX 1996 Conference on Object-Oriented Technologies Toronto, Ontario, Canada, June 1996. For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: 4. WWW URL: A Distributed Object Model for the Java System Ann Wollrath, Roger Riggs, and Jim Waldo Sun Microsystems, Inc. Abstract We show a distributed object model for the Java 1 System [1,6] (hereafter referred to simply as Java) that retains as much of the semantics of the Java ob- ject model as possible, and only includes differences where they make sense for distributed objects. The distributed object system is simple , in that a) distribut- ed 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 [3] and Springs subcontract [8] and includes some novel features. To achieve its goal of seamless integration in the lan- guage, 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 f nal system will include distributed reference-counting garbage collection for distributed objects as well as lazy activation [11,16]. 1 Introduction Distributed systems require entities which reside in different address spaces, potentially on different ma- chines, to communicate. The Java system (hereafter referred to simply as Java) provides a basic commu- nication mechanism, sockets [13]. While F exible and suf f cient for general communication, the use of sock- ets 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 trade- marks of Sun Microsystems, Inc., and refer to Suns fam- ily of Java-branded products and services. 2. Patent pending An alternative to sockets is Remote Procedure Call (RPC) [13]. 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 call- ing 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 argu- ments and return values using some type of an exter- nal data representation (e.g., XDR)....
View Full Document

This note was uploaded on 07/30/2011 for the course COP 4600 taught by Professor Montagne during the Spring '08 term at University of Central Florida.

Page1 / 14

JavaDistributedObject-Waldo - The following paper was...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online