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, its 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 dont 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 isnt. ?
• 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 Ill steal from the book,
  which represents the authors sentiments towards
  CORBA (a sentiment that I share) it is very
  similar to the those expressed by French
  president Charles De Gaulles 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 doesnt 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 ltsome boolean valuegt
• ..

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, youll 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, youve made your interface, and youve
  written its implementation in ATMImpl.
• Now we need to generate stub classes.
• These dont 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
  doesnt 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 serverstrauss.udel.edu
• final String portNumber9432
• ATMImpl atm new ATMImpl()
• Naming.bind(//serverportNumber,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 isnt 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.pol
  icy)
• System.setSecurityManager( new RMISecurityManager(
  ))
• Then, in your client code, you can grab a
  reference to the Remote Object by
• Object objNaming.lookup(//strauss.udel.edu9432
  )
• ATM remoteATM(ATM)obj //we now have our
  reference
• boolean loginOK remoteATM.authenticate(234903,23
  41)

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 ltportnumbergt
• Start the server
• java ATMServer
• Run the client, making sure the all.policy file
  is in the directory
• java ATMClient

44
Example

• Now Im 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. Lets 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.edu6000/
  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 objNaming.lookup(//strauss.udel.edu600
  0/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.
• Thats all folks!