Distributed Objects and Advanced Remote Method Invocations Ren

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

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

Message Passing vs. Distributed Objects 6 Maart 2006 ISS 2006 3

The Message Passing Paradigm n Natural model for distributed computing. n mimics interhuman communications. Processes are tightly-coupled. n n n 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. n n n 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. 6 Maart 2006 ISS 2006 4

The Distributed Objects Paradigm n n 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 objectoriented programming language such as Java, objects are used to represent an entity significant to an application. Each object encapsulates: n n 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. 6 Maart 2006 ISS 2006 5

Local Objects vs. Distributed Objects n n 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. 6 Maart 2006 ISS 2006 6

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. 6 Maart 2006 ISS 2006 7

The Distributed Objects Paradigm - 3 n n n 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 6 Maart 2006 8

Message Passing versus Distributed Objects Compared to the message-passing paradigm, which is data-oriented, the distributed objects paradigm is actionoriented: 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. 6 Maart 2006 ISS 2006 9

The Distributed Objects Paradigm 6 Maart 2006 ISS 2006 10

An Archetypal Distributed Objects System 6 Maart 2006 ISS 2006 11

Distributed Object System n n 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. 6 Maart 2006 ISS 2006 12

Distributed Object System - 2 n n n 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. 6 Maart 2006 ISS 2006 13

Distributed Object System - 3 n n n 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. 6 Maart 2006 ISS 2006 14

An Archetypal Distributed Objects System 6 Maart 2006 ISS 2006 15

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 6 Maart 2006 ISS 2006 16

From Remote Procedure Call to Remote Method Invocation 6 Maart 2006 ISS 2006 17

Remote Procedure Calls (RPC) n n 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. 6 Maart 2006 ISS 2006 18

Local Procedure Call and Remote Procedure Call 6 Maart 2006 ISS 2006 19

Remote Procedure Calls (RPC) - 2 n n Since its introduction in the early 1980 s, the Remote Procedure Call model has been widely in use in network applications. There are two prevalent APIs for this paradigm. n n n the Open Network Computing Remote Procedure Call, evolved from the RPC API originated from Sun Microsystems in the early 1980 s. 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. 6 Maart 2006 ISS 2006 20

Java Remote Method Invocation 6 Maart 2006 ISS 2006 21

Remote Method Invocation n 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: n n n A remote object is declared with a remote interface, an extension of the Java 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. 6 Maart 2006 ISS 2006 22

The Java RMI Architecture 6 Maart 2006 ISS 2006 23

An Archetypal Distributed Objects System 6 Maart 2006 ISS 2006 24

Object Registry n n 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. 6 Maart 2006 ISS 2006 25

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

Steps for building an RMI application 6 Maart 2006 ISS 2006 27

Algorithm for developing the server-side software 1. 2. 3. 4. 5. 6. 7. 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 Some. Interface. java. Compile it until there is no more syntax error. Implement the interface in Some. Impl. 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 Some. Impl The files generated can be found in the directory as Some. Impl_Skel. class and Some. Impl_Stub. class. Steps 3 and 4 must be repeated each time that a change is made to the interface implementation. Create the object server program Some. Server. java. Compile it until there is no more syntax error. Activate the object server java Some. Server 6 Maart 2006 ISS 2006 28

Algorithm for developing the client-side software 1. 2. 3. 4. 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: Some. Impl_Stub. class. 5. 6. Develop the client program Some. Client. java, and compile it to generate the client class. Activate the client. java Some. Client 6 Maart 2006 ISS 2006 29

Placement of files for a RMI application Error in Figure 7. 17 of the book ! 6 Maart 2006 ISS 2006 30

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. 6 Maart 2006 ISS 2006 31

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: n n 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. 6 Maart 2006 ISS 2006 32

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. 6 Maart 2006 ISS 2006 33

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 2 nd half of this lecture. 6 Maart 2006 ISS 2006 34

Summary - 1 n n n 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. 6 Maart 2006 ISS 2006 35

Summary - 2 n n n 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). 6 Maart 2006 ISS 2006 36

Summary - 3 n Java RMI is a representative of distributed object systems. n n n 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 clientside software. There are tradeoffs between the socket API and the Java RMI API. 6 Maart 2006 ISS 2006 37

n BREAK 6 Maart 2006 ISS 2006 38

Advanced Remote Method Invocations 6 Maart 2006 ISS 2006 39

RMI – Advanced topics n n The Java RMI API has a rich collection of features. We will look at some of RMI’s more interesting advanced features, namely: n n 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. 6 Maart 2006 ISS 2006 40

The Java RMI Architecture 6 Maart 2006 ISS 2006 41

Java RMI Client Server Interaction 6 Maart 2006 ISS 2006 42

RMI Stub Downloading n n n 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. 6 Maart 2006 ISS 2006 43

Stub downloading n n 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: 6 Maart 2006 ISS 2006 44

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. Socket. Permission "*: 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. Socket. Permission "*: 80", "connect"; }; n This file can be filed in the same directory as the server class file. n When activating the client, a java. policy file also should be specified: java -Djava. security. policy=java. policy Some. Client n See http: //java. sun. com/products/jdk/1. 2/docs/guide/security/Policy. Files. html and http: //java. sun. com/products/jdk/1. 2/docs/guide/security/permissions. html n 6 Maart 2006 ISS 2006 45

File Placements Client host Server host client directory server directory Some. Client. class Some. Server. class Some. Interface _stub. class Some. Interface. Skeleton. class java. policy HTTP Server Some. Interface_ stub. class 6 Maart 2006 ISS 2006 46

RMI Security Manager n n n 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 RMISecurity. Manager 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. set. Security. Manager(new RMISecurity. Manager( )); } catch { …} 6 Maart 2006 ISS 2006 47

Algorithm for building an RMI Application Server side: 1. 2. 3. 4. 5. 6. 7. 8. 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 Some. Server 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. 6 Maart 2006 ISS 2006 48

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

RMI Callbacks 6 Maart 2006 ISS 2006 50

Introduction n n In the client server model, the server is passive: the IPC is initiated by the client; the server waits for the arrival of requests and provides responses. Some applications require the server to initiate communication upon certain events. Examples applications are: n n n n monitoring games auctioning voting/polling chat-room message/bulletin board groupware 6 Maart 2006 ISS 2006 51

Polling vs. Callback In the absence of callback, a client will have to poll a passive server repeatedly if it needs to be notified that an event has occurred at the server end. 6 Maart 2006 ISS 2006 52

Two-way communications n n n Some applications require that both sides may initiate IPC. Using sockets, duplex communication can be achieved by using two sockets on either side. With connection-oriented sockets, each side acts as both a client and a server. 6 Maart 2006 ISS 2006 53

RMI Callbacks n n A callback client registers itself with an RMI server. The server makes a callback to each registered client upon the occurrence of a certain event. 6 Maart 2006 ISS 2006 54

Callback Client-Server Interactions 6 Maart 2006 ISS 2006 55

Callback application files 6 Maart 2006 ISS 2006 56

RMI Callback file placements Server host Client host client directory server directory Some. Client. class Some. Server. class Callback. Interface _skel. class Some. Interface _stub. class java. policy Some. Interface. Skeleton. class Callback. Interface _stub. class java. policy HTTP Server Some. Interface _stub. class 6 Maart 2006 ISS 2006 57

RMI Callback Interface n n n The server provides a remote method which allows a client to register itself for callbacks. A Remote interface for the callback is needed, in addition to the server-side interface. The interface specifies a method for accepting a callback from the server. The client program is a subclass of Remote. Object and implements the callback interface, including the callback method. The client registers itself for callback in its main method. The server invokes the client’s remote method upon the occurrence of the anticipated event. 6 Maart 2006 ISS 2006 58

Algorithm for building an RMI Callback Application Server side: 1. 2. 3. 4. 5. 6. 7. 8. 9. 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 skeleton. class file: rmic Some. Server 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. Obtain the Callback. Interface. Compile it with javac, then use rmic to generate the stub file for the callback. 6 Maart 2006 ISS 2006 59

Algorithm for building an RMI Callback Application Client side: 1. Open a directory for all the files to be generated for this application. 2. Implement the client program or applet, and compile it to generate the client class. 3. If stub downloading is not in effect, copy the server interface stub class file by hand. 4. Implement the callback interface. Compile it using javac, then using rmic to generate a stub class and a skeleton class for it. 5. Set up a java. policy file. 6. Activate the client, specifying (i) the server host name, and (ii) the security policy file. 6 Maart 2006 ISS 2006 60

Summary-1 n n n Stub downloading allows a stub class to be loaded to an object client at runtime, thereby allowing a remote object’s implementation to be modified and its stub class regenerated without affecting the software on the client host. A security manager oversees access restrictions specified in a Java security policy file, which can be a system-wide policy file, or a policy file applied to an individual application only. For security protection, the use of security managers is recommended in all RMI applications, regardless of whether stub downloading is involved. 6 Maart 2006 ISS 2006 61

Summary-2 n Client callback: n n Client callback is useful for an application where the clients desire to be notified by the server of the occurrence of some event. Client callback allows an object server to make remote method call to a client via a reference to a client remote interface. 6 Maart 2006 ISS 2006 62

Summary-3 n Client callback: n To provide client callback, the client-side software n n The object server: n n n supplies a remote interface, instantiate an object which implements the interface, passes a reference to the object to the server via a remote method call to the server. collects these client references in a data structure. when the awaited event occurs, the object server invokes the callback method (defined in the client remote interface) to pass data to the client. Two sets of stub-skeletons are needed: one for the server remote interface, the other one for the client remote interface. 6 Maart 2006 ISS 2006 63

Self study exercises n Chapter 7 n n Exercises 1, 2, 3 and 4 Chapter 8 n Exercises 1 and 4 6 Maart 2006 ISS 2006 64