Distributed Computing

1. Distributed Computing • How many people have heard of this? • Can anyone explain it?

2. Distributed Computing • There is a lot of hype around Distributed Computing – some deserved, and some of it is marketing. • The programming community starts thinking of “Objects Everywhere” as a solution to a lot of problems. • The idea is to have a happy family of collaborating objects that can be located anywhere.

3. Distributed Computing • These objects are supposed to communicate through standard protocols across a network. • The client object sends a message to an object on the server that contains the details of the request, then the server objects gathers the required data, and sends it back. This is similar to how a web server works.

4. Distributed Computing • So, in the traditional client/server model, a request is translated into some intermediary format (with Web Servers, it’s HTML data. Others use XML streams or name/value pairs). • The server parses the request format, computes the response, and formats the response for transmission to the client. The client then again parses the response and displays it to the user. • But, this can involve a non-insignificant amount of work because then you have to come up with some transmission format.

5. CORBA • The fundamental idea between Distributed Object computing is that we can avoid writing this intermediate layer ourselves by using a Middleware. • A Middleware is a piece of software the lies between the operating system and the application. • This Middleware is what provides the services for this Distributed Object-based computing.

6. CORBA • There were lots of motivating factors to use a Middleware rather than writing a custom communication language • As projects scale (become larger), developing distributing applications whose components collaborate efficiently, reliably, transparently and scalably. • The growing trend of hardware getting faster, cheaper and smaller and software getting larger, slower, and more expensive.

7. Examples

8. Examples

9. Examples

10. Motivation for CORBA • In Theory.. • CORBA simplifies application internetworking, by providing a higher level of integration that just an untyped TCP bytestream • It keeps things objected oriented • Provides a foundation for even higher level object collaboration

11. CORBA • CORBA, or the Common Object Request Brokerage Architecture, is a way of specifying this behavior. • CORBA is just a standard, not a piece of software itself. • This standard is maintained by the OMG, the Object Management Group, which is a consortium of ~1000 different computer companies (Sun, HP, IBM, Cisco, Motorola, Boeing, etc.)

12. CORBA • The fundamental idea is that we delegate the job of finding out information and activating any requested services to a so called Object Request Broker, or ORB. • The ORB is kind of a universal translator for the inter-object communication. • Objects don’t directly talk between each other, the communicate through this ORB.

13. ORBS • ORBS are located across networks, and can communicated with each other. • Different ORBS can talk to each other across various networks, through a protocol called IIOP (Internet Inter-ORB Protocol) • There are many different ORBS written by different vendors available for use.

14. CORBA • CORBA is completely language-neutral. • You write Distributed Objects definitions in a language called IDL (Interface Definition Language) – which looks very similar to Java interfaces. • You specify the signatures of the objects and the types of data your objects can send and understand.

15. IDL • IDL is a language that defines the objects, independent of the implementation (like an interface, except this is language neutral, too) • Then, these IDL objects map to a specific programming language. • Language Mappings Exist for C, C++, Smalltalk, COBOL, Ada and Java.

16. IDL • A example of the mapping would like something like this

17. CORBA • Sounds simple, right? It isn’t.  • First, we create a Server Object, described in IDL, and register it with the ORB. • Then, we bind the Server object at the client side, and create stub files for the client. • An IDL pre-compiler generates a number of skeleton files, which contain a frame for filling in the actual functionality – this is where you fill in the actual functionality – and then compile them with the normal language compiler.

18. CORBA • This gets even more complicated when we get into the details of it.

19. CORBA • This sounds great (on paper) and is a very elegant solution to a complex problem. • Unfortunately, this has drawbacks. • It adds an addition layer of complexity onto the application itself. • CORBA has a somewhat deserved reputation for slow performance, complex implemenation and interoperability problems that preclude some people from using it, even when it may be appropriate to do so.

20. CORBA • There is a good quote I’ll steal from the book, which represents the author’s sentiments towards CORBA (a sentiment that I share) – it is very similar to the those expressed by French president Charles De Gaulle’s about Brazil: It has a great future.. and always will.

21. RMI • If both communicating objects are written in Java, the full complexity of CORBA is not required. • Sun developed a much simpler mechanism called RMI, or Remote Method Invocation, specifically for communication between Java applications. • RMI allows you to access an object on a different machine, and call methods on the remote object as if it were local.

22. RMI • This involves shipping the method parameters to the other machine, having that machine execute them, and returning to result back. RMI handles these details. • In RMI terminology, the object whose method makes the remote call is called the client object. • The remote object being called is the server object.

23. RMI • It is worthwhile to mention that this client/server terminology refers to only that method call. It is entirely possible that what was the server in the previous call can make a call back, in which case, it would then be the client.

24. Stubs • As we saw with CORBA, when client code wants to invoke a remote method on a remote object, it actually calls an ordinary method of the Java programming language that is encapsulated in an object called a STUB. • This stub resides on the client machine, not the server. • This stub file packages the parameters used in the remote method call into a block of bytes. This process of encoding the parameters is called parameter marshalling.

25. Stubs • The purpose of this marshalling is to convert the parameters into a format suitable for transport from one JVM to another. • So, the stub on the client side consists of • An identifier of the remote object to be used. • A description of the method to be called. • The marshalled parameters.

26. Stubs • The stub then sends this information to the server. On the server side, a receiver object • Unmarshalls the parameters • Locates the object to be called. • Calls the desired method. • Captures and marshals the return value (or exception) of the call. • Sends a package consisting of the marshalled return data back to the stub on the client.

27. Stubs • Then, the client unmarshals the return value (or exception). • This return value becomes the return value of the stub call, or, if an exception was generated, the stub call will generate an exception. • This whole complex is rather complex, but the good news is that mostly transparent to the Java programmer.

28. Setting up RMI • There are 3 major steps to get this all working • Define a remote interface that defines the remote methods that client will use to interact with the server object. • Define the server application that implements these objects. • Define the client application that uses the remote interface reference to call these methods.

29. Interfaces and Implementations • Your client program needs to manipulate server objects, but it doesn’t actually have copies of them – they reside on the server. • Still, you code needs to know what it can do with these objects – what interface they publish. • This interface is shared and resides on both machines interface ATM //shared by client and server extends Remote { boolean authenticate(int account, int pin) throws RemoteException; boolean withdraw(double amount) throws RemoteException; boolean deposit(double amount) throws RemoteException; }

30. Interfaces and Implementations • Just like the previous example, all interfaces for remote objects must extend the Remote interface in the java.rmi package • They also all must advertise that they throw a RemoteException • This is because of what we talking about in the networking lecture – remote computing is inherently unreliable, so Java forces you to deal with the situation that remote objects are unavailable.

31. Interfaces and Implementations • Now, on the server side, you actually have to implement the code. public class ATMImpl extends UnicastRemoteObject implements ATM { { public authenticate(int account, int pin) throws RemoteException { // ACTUAL CODE GOES HERE return <some boolean value>; } ….. }

32. Remote Server • Normally, server classes extend the class RemoteServer from java.rmi.server • RemoteServer is an abstract class that defines only the basic methods for communication • UnicastRemoteObject is an concrete class that inherits from RemoteServer, so you can use it for your program without having to write any addition lines of code.

33. UnicastRemoteObject • This UnicastRemoteObject, as we just saw, resides on the server. It then must be alive (read: running) when it is requested and must be reachable through the TCP/IP protocol.

34. Naming Conventions • To get this whole RMI thing up and running, there are a lot of different class files you need. Name them like this, you’ll be happy you did later on. • No suffix (e.g. ATM) The Remote Interface • Impl suffix (ATMImpl) The Server class implementing this interface • Server suffix (ATMServer) The Server program that creates server objects. • Client suffix The Client program that calls these remote methods. • _Stub and _Skel suffix Stubs that are automatically generated by rmic

35. Generating Stubs • So, you’ve made your interface, and you’ve written it’s implementation in ATMImpl. • Now we need to generate stub classes. • These don’t need to be written by hand. • Simple run a program called rmic on your Impl class rmic –v1.2 ATMImpl • This will generate two files – an ATMImpl_Stub.class and a ATMImpl_Skel.class. • The Skel (Skeleton) file is no longer needed with Java 2 – delete it or just forget about it.

36. Accessing Remote Objects • To access a remote object that exists on a server, the client needs a local stub object. • But, how does a client request this stub if it doesn’t have it already? • The common solution is to call a remote object of another server and get a stub object. • However, this is a bit of a chicken-and-egg problem here. The first server object is going to be have to found some other way.

37. RMIRegistry • Java provides a bootstrap registry service to located this first server object, called RMIRegistry. • The server program registers objects with this bootstrap registry service, and then the client retrieves stubs to those objects. • You register this server by giving the bootstrap registry service a reference to an object and a name. The name is a (hopefully) unique String.

38. RMIRegistry • Your server object should bind (or rebind) to a service by specifying the server name and the object name in the following way. import java.rmi.*; import java.rmi.registry.*; import java.rmi.server.*; final String server=“strauss.udel.edu”; final String portNumber=“9432”; ATMImpl atm = new ATMImpl(); Naming.bind(“//”+server+”:”+portNumber,atm); System.out.println(“Server Started”);

39. RMIRegistry • Before your client can access this remote object, we have to think about security for a moment. • Java is very quirky with security and remote objects, therefore, we have to tell the security manager that everything is kosher and to allow us to access this remote object. This isn’t hard to do.

40. RMIRegistry • Create a policy file, call it all.policy (for allowing everything) that allows everything, by putting these following lines in it. grant { //Allow Everything permission java.security.AllPermission; };

41. RMIRegistry • Now, from your Client code, first you set the security manager System.setProperty(“java.security.policy”,”all.policy”); System.setSecurityManager( new RMISecurityManager()); • Then, in your client code, you can grab a reference to the Remote Object by Object obj=Naming.lookup(“//strauss.udel.edu:9432”); ATM remoteATM=(ATM)obj; //we now have our reference boolean loginOK = remoteATM.authenticate(234903,2341);

42. Running RMIRegistry • To start this RMIRegistry service on strauss, you can type rmiregistry 9432 & or, on windows start rmiregistry 9432 • Either of these commands will start RMIRegistry running in the background.

43. Getting this all running • First, compile the source files for the interface, implementation, client and server classes. javac *.java • Then, run rmic on the implementation class rmic –v1.2 ATMImpl.java • Start the rmiregistry on the machine the SERVER will run on rmiregistry <portnumber> & • Start the server java ATMServer & • Run the client, making sure the all.policy file is in the directory java ATMClient

44. Example • Now I’m going to run through an example of a very simple RMI server program that simply accepts a request, and returns the current date and time through a message. Let’s look at the interface first

45. Hello.java • Simple interface that defines 1 method, getMessage() import java.rmi.*; import java.rmi.server.*; public interface Hello extends Remote { String getMessage() throws RemoteException; }

46. HelloImpl.java • Next, we actually right the server implementation for this Interface import java.rmi.*; import java.rmi.registry.*; public class HelloImpl extends UnicastRemoteObject implements Hello { public HelloImpl() throws RemoteException { } public String getMessage() throws RemoteException { } { Date now = new Date(); System.out.println(“Processing request!”); //we print on server side return “Hello, the time is “+now; } }

47. HelloServer.java • Then, we write this server code that we will actually run import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*; public class HelloServer { public static void main(String[] args) { try { HelloImpl h = new HelloImpl(); Naming.rebind(“//strauss.udel.edu:6000/hello”,h); //”hello” is the name System.out.println(“Server Running”); } catch (Exception e) { e.printStackTrace(); } } }

48. HelloClient • Then, for the client import java.rmi.*; import java.rmi.registry.*; public class HelloClient { public static void main(String[] args) { System.setProperty(“java.security.policy”,”all.policy”); System.setSecurityManager(new RMISecurityManager()); try { System.out.println(“Client running…”); Object obj=Naming.lookup(“//strauss.udel.edu:6000/hello”); Hello hobj = (Hello obj); System.out.println(“Server returned “+hobj.getMessage() ); } catch (Exception e) { e.printStackTrace(); } } }

49. Seperating these and running them • Compile all the files • Run rmic –v1.2 on HelloImpl.java • Upload the class files for the Hello.class, HelloImpl.class and HelloServer.class and HelloImpl_Stub.class to the server. • Run RMIRegistry on the same port specified in your program, and then run the server. • On the client, compile all the files and run HelloClient. Rinse and Repeat. • That’s all folks!