distributed computing
Download
Skip this Video
Download Presentation
Distributed Computing

Loading in 2 Seconds...

play fullscreen
1 / 49

Distributed Computing - PowerPoint PPT Presentation


  • 286 Views
  • Uploaded on

Distributed Computing. How many people have heard of this? Can anyone explain it?. Distributed Computing. There is a lot of hype around Distributed Computing – some deserved, and some of it is marketing.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Distributed Computing' - LionelDale


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
distributed computing
Distributed Computing
  • How many people have heard of this?
  • Can anyone explain it?
distributed computing2
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.
distributed computing3
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.
distributed computing4
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.
corba
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.
corba6
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.
motivation for corba
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
corba11
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.)
corba12
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.
slide13
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.
corba14
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.
slide15
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.
slide16
IDL
  • A example of the mapping would like something like this
corba17
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.
corba18
CORBA
  • This gets even more complicated when we get into the details of it.
corba19
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.
corba20
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.
slide21
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.
slide22
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.
slide23
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.
stubs
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.
stubs25
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.
stubs26
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.
stubs27
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.
setting up rmi
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.
interfaces and implementations
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;

}

interfaces and implementations30
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.
interfaces and implementations31
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>;

}

…..

}

remote server
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.
unicastremoteobject
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.
naming conventions
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
generating stubs
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.
accessing remote objects
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.
rmiregistry
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.
rmiregistry38
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”);

rmiregistry39
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.
rmiregistry40
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;

};

rmiregistry41
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);

running rmiregistry
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.
getting this all running
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

example
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
hello java
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;

}

helloimpl java
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;

}

}

helloserver java
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();

}

}

}

helloclient
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(); }

}

}

seperating these and running them
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!
ad