1 / 64

Distributed Objects and Advanced Remote Method Invocations

Distributed Objects and Advanced Remote Method Invocations. René de Vries Based on the slides by M.L. Liu and Marko van Eekelen. Overview (Distributed Objects). Message Passing vs. Distributed Objects The Distributed Objects Paradigm Remote Procedure Call vs Remote Method Invocation

hendersonj
Download Presentation

Distributed Objects and Advanced Remote Method Invocations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed ObjectsandAdvanced Remote Method Invocations René de Vries Based on the slides by M.L. Liu and Marko van Eekelen ISS 2006

  2. Overview (Distributed Objects) • Message Passing vs. Distributed Objects • The Distributed Objects Paradigm • Remote Procedure Call vs Remote Method Invocation • Java RMI • The Java RMI Architecture • The Object Registry • Stubs and Skeletons • Steps for building an RMI application ISS 2006

  3. Message Passingvs. Distributed Objects ISS 2006

  4. The Message Passing Paradigm • Natural model for distributed computing. • mimics interhuman communications. • Processes are tightly-coupled. • throughout their interaction, the processes must be in direct communication with each other. If communication is lost between the processes (due to failures in the communication link, in the systems, or in one of the processes), the collaboration fails. • The message-passing paradigm is data-oriented. • Each message contains marshalled data, and is interpreted as a request or response according to the protocol. • The receiving of each message triggers an action in the receiving process. • It is inadequate for complex applications involving a large mix of requests and responses. In such an application, the task of interpreting the messages can become overwhelming. ISS 2006

  5. The Distributed Objects Paradigm • The distributed object paradigm is a paradigm that provides abstractions beyond those of the message-passing model. It is based on objects that exist in a distributed system. • In object-oriented programming, supported by an object-oriented programming language such as Java, objects are used to represent an entity significant to an application. Each object encapsulates: • the state or data of the entity: in Java, such data is contained in the instance variables of each object; • the operations of the entity, through which the state of the entity can be accessed or updated. ISS 2006

  6. Local Objects vs. Distributed Objects • Local objects are those whose methods can only be invoked by a local process, a process that runs on the same computer on which the object exists. • A distributed object is one whose methods can be invoked by a remote process, a process running on a computer connected via a network to the computer on which the object exists. ISS 2006

  7. The Distributed Objects Paradigm-2 In a distributed object paradigm, network resources are represented by distributed objects. To request service from a network resource, a process invokes one of its operations or methods, passing data as parameters to the method. The method is executed on the remote host, and the response is sent back to the requesting process as a return value. ISS 2006

  8. The Distributed Objects Paradigm - 3 • A process running in host A makes a method call to a distributed object residing on host B, passing with the call data for the parameters, if any. • The method call invokes an action performed by the method on host B, and a return value, if any, is passed from host B to host A. • A process which makes use of a distributed object is said to be a client process of that object, and the methods of the object are called remote methods (as opposed to local methods, or methods belonging to a local object) to the client process. ISS 2006

  9. Message Passing versus Distributed Objects Compared to the message-passing paradigm, which is data-oriented, the distributed objects paradigm is action-oriented: the focus is on the invocation of the operations, while the data passed takes on a secondary role. Although less intuitive to human-beings, the distributed-object paradigm is more natural to object-oriented software development. ISS 2006

  10. The Distributed Objects Paradigm ISS 2006

  11. An Archetypal Distributed Objects System ISS 2006

  12. Distributed Object System • A distributed object is provided, or exported, by a process, here called the object server. A facility, here called an object registry, must be present in the system architecture for the distributed object to be registered. • To access a distributed object, a process –an object client – looks up the object registry for a reference[1] to the object. This reference is used by the object client to make calls to the methods. [1] A reference is a “handle” for an object; it is a representation through which an object can be located in the computer where the object resides. ISS 2006

  13. Distributed Object System - 2 • Logically, the object client makes a call directly to a remote method. • In reality, the call is handled by a software component, called a client proxy, which interacts which the software on the client host that provides the runtime support for the distributed object system. • The runtime support is responsible for the interprocess communication needed to transmit the call to the remote host, including the marshalling of the argument data that needs to be transmitted to the remote object. ISS 2006

  14. Distributed Object System - 3 • A similar architecture is required on the server side, where the runtime support for the distributed object system handles the receiving of messages and the unmarshalling of data, and forwards the call to a software component called the server proxy. • The server proxy interfaces with the distributed object to invoke the method call locally, passing in the unmarshalled data for the arguments. • The method call results in the performance of some tasks on the server host. The outcome of the execution of the method, including the marshalled data for the return value, is forwarded by the server proxy to the client proxy, via the runtime support and network support on both sides. ISS 2006

  15. An Archetypal Distributed Objects System ISS 2006

  16. Distributed Object Systems/Protocols The distributed object paradigm has been widely adopted in distributed applications, for which a large number of mechanisms based on the paradigm are available. Among the most well known of such mechanisms are: ~ Java Remote Method Invocation (RMI), ~ the Common Object Request Broker Architecture (CORBA) systems, ~ .NET and its predecessor, the Distributed Component Object Model (DCOM) ~ mechanisms that support the Simple Object Access Protocol (SOAP). Of these, the most straightforward is the Java RMI ISS 2006

  17. From Remote Procedure Call to Remote Method Invocation ISS 2006

  18. Remote Procedure Calls (RPC) • Remote Method Invocation has its origin in a paradigm called Remote Procedure Call • In the remote procedure call model, a procedure call is made by one process to another, with data passed as arguments. Upon receiving a call, the actions encoded in the procedure are executed, the caller is notified of the completion of the call, and a return value, if any, is transmitted from the callee to the caller. ISS 2006

  19. Local Procedure Call and Remote Procedure Call ISS 2006

  20. Remote Procedure Calls (RPC) - 2 • Since its introduction in the early 1980s, the Remote Procedure Call model has been widely in use in network applications. • There are two prevalent APIs for this paradigm. • the Open Network Computing Remote Procedure Call, evolved from the RPC API originated from Sun Microsystems in the early 1980s. • The other well-known API is the Open Group Distributed Computing Environment (DCE) RPC. • Both APIs provide a tool, rpcgen, for transforming remote procedure calls to local procedure calls to the stub. ISS 2006

  21. Java Remote Method Invocation ISS 2006

  22. Remote Method Invocation • Remote Method Invocation (RMI) is an object-oriented implementation of the Remote Procedure Call model. It is an API for Java programs only. • Using RMI, an object server exports a remote object and registers it with a directory service. The object provides remote methods, which can be invoked in client programs. • Syntactically: • A remote object is declared with a remote interface, an extension of theJava interface. • The remote interface is implemented by the object server. • An object client accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations. ISS 2006

  23. The Java RMI Architecture ISS 2006

  24. An Archetypal Distributed Objects System ISS 2006

  25. Object Registry • The RMI API allows a number of directory services to be used[1] for registering a distributed object. • We will use a simple directory service called the RMI registry, rmiregistry, which is provided with the Java Software Development Kit (SDK)[2]. The RMI Registry is a service whose server, when active, runs on the object server’s host machine, by convention and by default on the TCP port 1099. [1] One such service is the Java Naming and Directory Interface (JNDI), which is more general than the RMI registry, in the sense that it can be used by applications that do not use the RMI API. [2] The Java SDK is what you download to your machine to obtain the use of the Java class libraries and tools such as the java compiler javac . ISS 2006

  26. The interaction between the stub and the skeleton A time-event diagram describing the interaction between the stub and the skeleton: ISS 2006

  27. Steps for building an RMI application ISS 2006

  28. Algorithm for developing the server-side software • Study chapters 7.7 and 7.8 of the book carefully. • Open a directory for all the files to be generated for this application. • Specify the remote-server interface in SomeInterface.java. Compile it until there is no more syntax error. • Implement the interface in SomeImpl.java Compile it until there is no more syntax error. • Use the RMI compiler rmic to process the implementation class and generate the stub file and skelton file for the remote object: rmic SomeImpl The files generated can be found in the directory as SomeImpl_Skel.class and SomeImpl_Stub.class. Steps 3 and 4 must be repeated each time that a change is made to the interface implementation. 6. Create the object server program SomeServer.java. Compile it until there is no more syntax error. 7. Activate the object server java SomeServer ISS 2006

  29. Algorithm for developing the client-side software • Study chapters 7.7 and 7.8 of the book carefully. • Open a directory for all the files to be generated for this application. • Obtain a copy of the remote interface class file. Alternatively, obtain a copy of the source file for the remote interface, and compile it using javac to generate the interface class file. • Obtain a copy of the stub file for the implementation of the interface: SomeImpl_Stub.class. • Develop the client program SomeClient.java, and compile it to generate the client class. • Activate the client. java SomeClient ISS 2006

  30. Placement of files for a RMI application Error in Figure 7.17 of the book ! ISS 2006

  31. Testing and Debugging an RMI Application 1. Build a template for a minimal RMI program. Start with a remote interface with a single signature, its implementation using a stub, a server program which exports the object, and a client program which invokes the remote method. Test the template programs on one host until the remote method can be made successfully. 2. Add one signature at a time to the interface. With each addition, modify the client program to invoke the added method. 3. Fill in the definition of each remote method, one at a time. Test and thoroughly debug each newly added method before proceeding with the next one. 4. After all remote methods have been thoroughly tested, develop the client application using an incremental approach. With each increment, test and debug the programs. ISS 2006

  32. Comparison of the RMI and the socket APIs The remote method invocation API is an efficient tool for building network applications. It can be used in lieu of the socket API in a network application. Some of the tradeoffs between the RMI API and the socket API are as follows: • The socket API is closely related to the operating system, and hence has less execution overhead. For applications which require high performance, this may be a consideration. • The RMI API provides the abstraction which eases the task of software development. Programs developed with a higher level of abstraction are more comprehensible and hence easier to debug. ISS 2006

  33. A Sample Enterprise Application In the illustrated application, the object server provides remote methods which allows the object clients to look up or update the data in an Expense Records database. Programs which are clients of the object provide the application or business logic for processing the data and the presentation logic for the user interface which presents the data. ISS 2006

  34. To be continued The Java RMI facility is rich in features. This chapter has presented a very basic subset of those features, as an illustration of a distributed object system. Some of the more interesting advanced features of RMI will be presented in the 2nd half of this lecture. ISS 2006

  35. Summary - 1 • The distributed object paradigm is at a higher level of abstraction than the message-passing paradigm. • Using the paradigm, a process invokes methods of a remote object, passing in data as arguments and receiving a return value with each call, using syntax similar to local method calls. • In a distributed object system, an object server provides a distributed object whose methods can be invoked by an object client. ISS 2006

  36. Summary - 2 • Each side requires a proxy which interacts with the system’s runtime support to perform the necessary IPC. • An object registry must be available which allows distributed objects to be registered and looked up. • Among the best-known distributed object system protocols are the Java Remote Method Invocation (RMI), the Distributed Component Object Model (DCOM), .NET, the Common Object Request Broker Architecture (CORBA) , and the Simple Object Access Protocol (SOAP). ISS 2006

  37. Summary - 3 • Java RMI is a representative of distributed object systems. • The architecture of the Java Remote Method Invocation API includes three abstract layers on both the client side and the server side. • The software for a RMI application includes a remote interface, server-side software, and client-side software. • There are tradeoffs between the socket API and the Java RMI API. ISS 2006

  38. BREAK ISS 2006

  39. Advanced Remote Method Invocations ISS 2006

  40. RMI – Advanced topics • The Java RMI API has a rich collection of features. • We will look at some of RMI’s more interesting advanced features, namely: • stub downloading • security manager • client callback. • Although these features are not inherent to the distributed object paradigm, they are helpful mechanisms and can be useful to application developers. ISS 2006

  41. The Java RMI Architecture ISS 2006

  42. Java RMI Client Server Interaction ISS 2006

  43. RMI Stub Downloading • RMI is designed to allow stubs to be made available to the client dynamically. Doing so allows changes to be made in the remote methods without affecting the client program. • The stub can be filed with an web server and be downloaded using HTTP. • Security measures are needed to prevent both the client side and the server side: • A java security policy file needs to be set on the server host and also on the client host. • A Java Security Manager should be instantiated in both the client and server programs. ISS 2006

  44. Stub downloading • If the stub is to be downloaded from a remote server, transfer the stub class to the appropriate directory on that server, e.g., www.csc.calpoly.edu/~mliu/www, and make sure that the access permission to the file is set. • When activating the server, specify command options: ISS 2006

  45. The java.policy file • The RMI security manager does not permit network access. Exceptions can be made via the specification in a java.policy file. grant { // permits socket access to all common TCP ports, including the default // RMI registry port (1099) – need for both the client and the server. permission java.net.SocketPermission "*:1024-65535", "connect,accept,resolve"; // permits socket access to port 80, the default HTTP port – needed // by client to contact an HTTP server for stub downloading permission java.net.SocketPermission "*:80", "connect"; }; • This file can be filed in the same directory as the server class file. • When activating the client, a java.policy file also should be specified: java -Djava.security.policy=java.policy SomeClient • See http://java.sun.com/products/jdk/1.2/docs/guide/security/PolicyFiles.html and http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html ISS 2006

  46. Client host Server host client directory server directory SomeClient.class SomeServer.class SomeInterface _ stub.class SomeInterface.Skeleton.class java.policy java.policy HTTP Server SomeInterface stub.class _ File Placements ISS 2006

  47. RMI Security Manager • Since RMI involves access to/from a foreign host, and possibly object downloading, it is important for both the server and the client to protect its system from malicious access. • The RMISecurityManager is a class provided Java, and can be instantiated in both the client and the server for limiting access privileges. • You can write your own security manager, if so desired. try { System.setSecurityManager(new RMISecurityManager( )); } catch { …} ISS 2006

  48. Algorithm for building an RMI Application Server side: • Open a directory for all the files to be generated for this application. • Specify the remote-server interface, and compile it to generate the interface class file. • Build the remote server class by implementing the interface, and compile it using javac. • Use rmic to process the server class to generate a stub.class file and a skelton.class file: rmic SomeServer • If stub downloading is desired, copy the stub file to an appropriate directory on the HTTP host. • Activate the RMIRegistry, if it has not already been activated. • Set up a java.policy file. • Activate the server, specifying (i) the codebase if stub downloading is desired, (ii) the server host name, and (iii) the security policy file. ISS 2006

  49. Algorithm for building an RMI Application Client side: • Open a directory for all the files to be generated for this application. • Implement the client program or applet, and compile it to generate the client class. • If stub downloading is not in effect, copy the server interface stub class file by hand. • Set up a java.policy file. • Activate the client, specifying (i) the server host name, and (ii) the security policy file. ISS 2006

  50. RMI Callbacks ISS 2006

More Related