TDTS 04 Frelsning 5 Distribuerade objektbaserade system Tanenbaum

TDTS 04 Föreläsning 5: Distribuerade objektbaserade system Tanenbaum & Van Steen, Distributed Systems: Principles

Outline • Architecture – • Processes – • object servers Communication – • binding, RMI, parameter passing Naming – • • • distributed objects Corba object references Synchronization Consistency and replication Fault tolerance Example domain: Corba and Java Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Architecture: Distributed Objects (1) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2

Distributed objects: Corba examples Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2

Architecture: Distributed Objects (2) Figure 10 -1. Common organization of a remote object with client-side proxy. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Architecture: CORBA Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c)

More about objects • • compile-time vs run-time transient vs persistent Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Example: Enterprise Java Beans Figure 10 -2. General architecture of an EJB server. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Four Types of EJBs • • Stateless session beans Stateful session beans Entity beans Message-driven beans Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

The General RMI Architecture 1. 2. 3. The server must first bind its name to the registry The client looks up the server name in the registry to establish remote references. The stub serializes the parameters to skeleton, the skeleton invokes the remote method and serializes the result back to the stub. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

The Stub and Skeleton A client invokes a remote method, the call is first forwarded to the stub. The stub is responsible for sending the remote call over to the server-side skeleton The stub opens a socket to the remote server, marshals (Java: serializes) the object parameters and forwards the data stream to the skeleton. A skeleton contains a method that receives the remote calls, unmarshals the parameters, and invokes the actual remote object implementation. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Processes Object servers Policies för object invocation, memory usage and threading Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Processes: Object Adapter Figure 10 -5. Organization of an object server supporting different activation policies. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Communication: Binding a Client to an Object Figure 10 -7. (a) An example with implicit binding using only global references. (b) An example with explicit binding using global and local references. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Implementing Object References • • Socket-like solution: Network address and end point DCE-like solution: Local daemon URL-like solution: Location server General solution: Implementation handle Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Static vs Dynamic Remote Method Invocations (RMIs) Dynamic invocation, format: invoke(object, method, input_params, output_params) Static invocation, example: fobject. append(int) // append an int to file object fobject Dynamic invocation, example: invoke(fobject, id(append), int) // id(append) returns an id for method append Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Parameter Passing Figure 10 -8. The situation when passing an object by reference or by value. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Example: Java RMI • • • cloning local objects vs remote objects how to invoke remote objects serializing the proxy Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Java Remote Object Invocation (RMI) Overview of RMI Java RMI allowed programmer to execute remote function class using the same semantics as local functions calls. Local Machine (Client) Sample. Server remote. Object; int s; … s = remote. Object. sum(1, 2); Remote Machine (Server) 1, 2 3 public int sum(int a, int b) { return a + b; } System. out. println(s); Java RMI example slides courtesy of Joseph Kee-Yin, University of Illinois Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Object-Based Messaging (1) Figure 10 -9. CORBA’s callback model for asynchronous method invocation. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Object-Based Messaging (2) Figure 10 -10. CORBA’s polling model for asynchronous method invocation. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Naming: CORBA Object References Figure 10 -11. The organization of an IOR with specific information for IIOP. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Synchronization: Locking Objects Figure 10 -14. Differences in control flow for locking objects Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Consistency and Replication: Granularity of invocations and Entry Consistency Figure 10 -15. Deterministic thread scheduling for replicated object servers. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replication Frameworks (1) Invocations to objects are intercepted at three different points: • At the client side just before the invocation is passed to the stub. • Inside the client’s stub, where the interception forms part of the replication algorithm. • At the server side, just before the object is about to be invoked. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Interceptors, generally Figure 2 -15. Using interceptors to handle remote-object invocations. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replication Frameworks (2): Interceptors in EJB Figure 10 -16. A general framework for separating replication algorithms from objects in an EJB environment. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replicated Invocations (1) Figure 10 -17. The problem of replicated method invocations. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replicated Invocations (2) Figure 10 -18. (a) Forwarding an invocation request from a replicated object to another replicated object. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Replicated Invocations (3) Figure 10 -18. (b) Returning a reply from one replicated object to another. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Fault Tolerance: Example in CORBA Figure 10 -19. A possible organization of an IOGR for an object group having a primary and backups. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Fault Tolerance: An Example Architecture Figure 10 -20. An example architecture of a fault-tolerant CORBA system. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Fault Tolerance: Example in Java Causes for nondeterministic behavior: 1. JVM can execute native code, that is, code that is external to the JVM and provided to the latter through an interface. 2. Input data may be subject to nondeterminism. 3. In the presence of failures, different JVMs will produce different output revealing that the machines have been replicated. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Steps for Developing an RMI System 1. Define the remote interface 2. Develop the remote object by implementing the remote interface. 3. Develop the client program. 4. Compile the Java source files. 5. Generate the client stubs and server skeletons. 6. Start the RMI registry. 7. Start the remote server objects. 8. Run the client Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 1: Defining the Remote Interface To create an RMI application, the first step is the defining of a remote interface between the client and server objects. /* Sample. Server. java */ import java. rmi. *; public interface Sample. Server extends Remote { public int sum(int a, int b) throws Remote. Exception; } Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 2: Develop the remote object and its interface The server is a simple unicast remote server. Create server by extending java. rmi. server. Unicast. Remote. Object. The server uses the RMISecurity. Manager to protect its resources while engaging in remote communication. /* Sample. Server. Impl. java */ import java. rmi. *; import java. rmi. server. *; import java. rmi. registry. *; public class Sample. Server. Impl extends Unicast. Remote. Object implements Sample. Server { Sample. Server. Impl() throws Remote. Exception { super(); } Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 2: Develop the remote object and its interface Implement the remote methods /* Sample. Server. Impl. java */ public int sum(int a, int b) throws Remote. Exception { return a + b; } } The server must bind its name to the registry, the client will look up the server name. Use java. rmi. Naming class to bind the server name to registry. In this example the name call “SAMPLE-SERVER”. In the main method of your server object, the RMI security manager is created and installed. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 2: Develop the remote object and its interface /* Sample. Server. Impl. java */ public static void main(String args[]) { try { System. set. Security. Manager(new RMISecurity. Manager()); //set the security manager //create a local instance of the object Sample. Server. Impl Server = new Sample. Server. Impl(); //put the local instance in the registry Naming. rebind("SAMPLE-SERVER" , Server); System. out. println("Server waiting. . . "); } } catch (java. net. Malformed. URLException me) { System. out. println("Malformed URL: " + me. to. String()); catch (Remote. Exception re) { System. out. println("Remote exception: " + re. to. String()); } } Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 3: Develop the client program In order for the client object to invoke methods on the server, it must first look up the name of server in the registry. You use the java. rmi. Naming class to lookup the server name. The server name is specified as URL in the from ( rmi: //host: port/name ) Default RMI port is 1099. The name specified in the URL must exactly match the name that the server has bound to the registry. In this example, the name is “SAMPLE-SERVER” The remote method invocation is programmed using the remote interface name (remote. Object) as prefix and the remote method name (sum) as suffix. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 3: Develop the client program import java. rmi. *; import java. rmi. server. *; public class Sample. Client { public static void main(String[] args) { // set the security manager for the client System. set. Security. Manager(new RMISecurity. Manager()); //get the remote object from the registry { System. out. println("Security Manager loaded"); String url = "//localhost/SAMPLE-SERVER"; Sample. Server remote. Object = (Sample. Server)Naming. lookup(url); System. out. println("Got remote object"); System. out. println(" 1 + 2 = " + remote. Object. sum(1, 2) ); } catch (Remote. Exception exc) { System. out. println("Error in lookup: " + exc. to. String()); } catch (java. net. Malformed. URLException exc) { System. out. println("Malformed URL: " + exc. to. String()); } catch (java. rmi. Not. Bound. Exception exc) { System. out. println("Not. Bound: " + exc. to. String()); } } } Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 4 & 5: Compile the Java source files & Generate the client stubs and server skeletons Assume the program compile and executing at elpis on ~/rmi Once the interface is completed, you need to generate stubs and skeleton code. The RMI system provides an RMI compiler (rmic) that takes your generated interface class and procedures stub code on its self. elpis: ~/rmi> set CLASSPATH=”~/rmi” javac Sample. Server. Impl. java rmic Sample. Server. Impl elpis: ~/rmi> javac Sample. Client. java Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Step 6: Start the RMI registry The RMI applications need install to Registry. And the Registry must start manual by call rmiregisty. The rmiregistry us uses port 1099 by default. You can also bind rmiregistry to a different port by indicating the new port number as : rmiregistry <new port> elpis: ~/rmi> rmiregistry Remark: On Windows, you have to type in from the command line: > start rmiregistry Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Steps 7 & 8: Start the remote server objects & Run the client Once the Registry is started, the server can be started and will be able to store itself in the Registry. Because of the grained security model in Java 2. 0, you must setup a security policy for RMI by set java. security. policy to the file policy. all elpis: ~/rmi> java – Djava. security. policy=policy. all Sample. Server. Impl elpis: ~/rmi> java – Djava. security. policy=policy. all Sample. Client Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Java Policy File In Java 2, the java application must first obtain information regarding its privileges. It can obtain the security policy through a policy file. In above example, we allow Java code to have all permissions, the contains of the policy file policy. all is: grant { permission java. security. All. Permission; }; Now, we given an example for assigning resource permissions: grant { permission java. io. file. Permission “/tmp/*”, “read”, “write”; permission java. net. Socket. Permission “somehost. somedomain. com: 999”, ”connect”; permission java. net. Socket. Permission “*: 102465535”, ”connect, request”; permission java. net. Socket. Permission “*: 80”, ”connect”; }; Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5

Comment for the Java Policy File 1. allow the Java code to read/write any files only under the /tmp directory, includes any subdirectories 2. allow all java classes to establish a network connection with the host “somehost. somedomain. com” on port 999 3. allows classes to connection to or accept connections on unprivileged ports greater than 1024 , on any host 4. allows all classes to connect to the HTTP port 80 on any host. You can obtain complete details by following links: http: //java. sun. com/products//jdk/1. 2/docs/guide/ security/spec/security-spec. doc 3. html Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2 e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0 -13 -239227 -5