This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full 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: firstname.lastname@example.org 4. WWW URL: http://www.usenix.org 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  and Springs subcontract  and includes some novel features. To achieve its goal of seamless integration in the lan- guage, the system exploits the use of pickling  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 . 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) . 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.
- Spring '08
- Operating Systems