Transcript Introduction

TDTS04 Föreläsning 5:
Distribuerade objektbaserade system
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
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, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Architecture: Distributed Objects (1)
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Distributed objects: Corba examples
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
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, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Architecture: CORBA
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
More about objects
•
•
compile-time vs run-time
transient vs persistent
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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, 2e, (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, 2e, (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.
Remote Machine
bind
RMI Server
Registry
skeleton
return
call
lookup
stub
RMI Client
Local Machine
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
The Stub and Skeleton
Stub
RMI Client
skeleton
call
RMI Server
return
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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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)
Remote Machine (Server)
SampleServer remoteObject;
int s;
…
s = remoteObject.sum(1,2);
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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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, 2e, (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.
/* SampleServer.java */
import java.rmi.*;
public interface SampleServer extends Remote
{
public int sum(int a,int b) throws
RemoteException;
}
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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.UnicastRemoteObject.
The server uses the RMISecurityManager to protect its resources while engaging in
remote communication.
/* SampleServerImpl.java */
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
public class SampleServerImpl extends UnicastRemoteObject
implements SampleServer
{
SampleServerImpl() throws RemoteException
{
super();
}
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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
/* SampleServerImpl.java */
public int sum(int a,int b) throws
RemoteException
{
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, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Step 2: Develop the remote object and its interface
/* SampleServerImpl.java */
public static void main(String args[])
{
try
{
System.setSecurityManager(new RMISecurityManager());
//set the security manager
//create a local instance of the object
SampleServerImpl Server = new SampleServerImpl();
//put the local instance in the registry
Naming.rebind("SAMPLE-SERVER" , Server);
System.out.println("Server waiting.....");
}
}
catch (java.net.MalformedURLException me)
{
System.out.println("Malformed URL: " + me.toString());
catch (RemoteException re) {
System.out.println("Remote exception: " +
re.toString()); }
}
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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 (remoteObject) as prefix and the remote
method name (sum) as suffix.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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 SampleClient
{
public static void main(String[] args)
{
// set the security manager for the client
System.setSecurityManager(new RMISecurityManager());
//get the remote object from the registry
try
{
System.out.println("Security Manager loaded");
String url = "//localhost/SAMPLE-SERVER";
SampleServer remoteObject =
(SampleServer)Naming.lookup(url);
System.out.println("Got remote object");
System.out.println(" 1 + 2 = " + remoteObject.sum(1,2) );
}
catch (RemoteException exc) {
System.out.println("Error in lookup: " + exc.toString()); }
catch (java.net.MalformedURLException exc) {
System.out.println("Malformed URL: " + exc.toString());
}
catch (java.rmi.NotBoundException exc) {
System.out.println("NotBound: " + exc.toString());
}
}
}
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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>
elpis:~/rmi>
elpis:~/rmi>
elpis:~/rmi>
set CLASSPATH=”~/rmi”
javac SampleServer.java
javac SampleServerImpl.java
rmic SampleServerImpl
elpis:~/rmi> javac SampleClient.java
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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, 2e, (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
SampleServerImpl
elpis:~/rmi> java –
Djava.security.policy=policy.all SampleClient
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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.AllPermission;
};
Now, we given an example for assigning resource permissions:
grant {
permission java.io.filePermission “/tmp/*”, “read”,
“write”;
permission java.net.SocketPermission
“somehost.somedomain.com:999”,”connect”;
permission java.net.SocketPermission “*:102465535”,”connect,request”;
permission java.net.SocketPermission “*:80”,”connect”;
};
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (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.doc3.html
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5