Distributed systems

1
INE4481 DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES

• Chapter 5
• Distributed systems
• with JAVA
• sockets, RMI , Threads
• Rufin Soh

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
2
Content

• JAVA RMI
• RMI server skeleton
• Writing a RMI client
• Running the client and server
• RMI and java security
• Java RMI Internals
• What is a codebase?
• How codebase is used
• RMI and Applets
• RMI multiple clients vs the same server object
• Downloading RMI stubs
• RMI Command-line examples
• RMI Troubleshooting
• RMI deployment examples

• Recalls on Networking
• Java Sockets
• What Is a Socket?
• Why Java Sockets?
• Socket Implementing a Client
• Socket Implementing a Server
• Running the Programs
• JAVA Threads
• JAVA RMI
• JAVA RMI vs other Middlewares
• Java-RMI Working mode
• Programming RMI
• Writing a RMI server

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
3
Content

• Recalls on Networking
• Java Sockets
• What Is a Socket?
• Why Java Sockets?
• Socket Implementing a Client
• Socket Implementing a Server
• Running the Programs

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
4
Recalls on Networking

• TCP( Transport Control Protocol )
• Is a connection-based protocol that provides a
  reliable flow of data between two computers.
• Example applications HTTP, FTP, Telnet, SMTP.
• UDP(User Datagram Protocol )
• Is a protocol that sends independent packets of
  data, called datagrams, from one computer to
  another with no guarantees about arrival.
• Example applications clock server, Ping.
• Understanding Ports
• The TCP and UDP protocols use ports to map
  incoming data to a particular process running on
  a computer.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
5
What Is a Socket?

• A socket is one endpoint of a two-way
  communication link between two programs running
  on the network.  A socket is bound to a port
  number so that the TCP layer can identify the
  application that data is destined to be sent.
• Normally, a server runs on a specific computer
  and has a socket that is bound to a specific port
  number.
• The server just waits, listening to the socket
  for a client to make a connection request.
• On the client-side The client knows the hostname
  of the machine on which the server is running and
  the port number to which the server is connected.
  
• To make a connection request, the client tries to
  rendezvous with the server on the server's
  machine and port.
•  

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
6
What Is a Socket?

• If everything goes well, the server accepts the
  connection. Upon acceptance, the server gets a
  new socket bound to a different port. It needs a
  new socket (and consequently a different port
  number) so that it can continue to listen to the
  original socket for connection requests while
  tending to the needs of the connected client.
• On the client side, if the connection is
  accepted, a socket is successfully created and
  the client can use the socket to communicate with
  the server. Note that the socket on the client
  side is not bound to the port number used to
  rendezvous with the server. Rather, the client is
  assigned a port number local to the machine on
  which the client is running.
• The client and server can now communicate by
  writing to or reading from their sockets.  
•  
•  

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
7
Why Java Sockets?

• You might wonder why you might choose to use
  sockets to communicate with remote objects when
  RMI is availble? Here are two possible reasons
• To communicate with non-java objects and
  programs Not all software on networks is
  written in Java-- at least, not yet.  Until it
  is, from time to time you'll need to interface a
  Java program with a non-Java program.
• Sockets are a good way to do this, because data
  transmitted over a socket is reduced to its any
  languages, running on almost any platform, can
  deal with a stream of bytes.
• To communicate as efficiently as possible.
• The convenience of RPC, RMI, and other facilities
  extract a price in the form of processing
  overhead. 
• A well-designed socket interface between programs
  can outperform one based on such higher-level
  facilities.  If you server must handle large
  volumes of requests, this may be important to
  you.
• Java Socket Classes
• The Java.net package provides following two
  classes
• Socket
• ServerSocket

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
8
Socket Implementing a Client

• Create a Socket object.
• Create an output stream that can be used to send
  info to the Socket.
• Create an input stream to read the response from
  the server.
• Do I/O with input and output streams.
• Close the socket when done.

Socket Client new Socket(?hostname,?portNumber)
PrintStream out new PrintStream(client.getOutput
Stream())
DataInputStream in new DataInputStream(client.ge
tInputStream())

• client.close()

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
9
Socket Implementing a Server

• Create a SocketServer object.
• Create a Socket object from the ServerSocket.
• Create an input stream to read input from the
  client.
• Create an output stream that can be used to send
  info back to the client.
• Do I/O with input and output streams.
• Close the socket when done.  

• ServerSocket listenSocket new
  ServerSocket(portNumber).

While (someCondition)         Socket server
listenSocket.accept()        
doSomethingWith(server)    
DataInputStream in new DataInputStream(server.ge
tInputStream())
PrintStream out new PrintStream(server.getOutput
Stream())
server.close()
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
10
Running the Programs

• You must start the server program first. To do
  this,
• Run the server program using the Java
  interpreter, just as you would run any other Java
  application. Remember to run the server on the
  machine that the client program specifies when it
  creates the socket.
• Next, run the client program. Note that you can
  run the client on any machine on your network it
  does not have to run on the same machine as the
  server.
• If you are too quick, you might start the client
  before the server has a chance to initialize
  itself and begin listening on the port. If this
  happens, you will see a stack trace from the
  client. just restart the client.
• If you forget to change the server host name in
  the source code for the MySocketClient program,
  you will see an error message
• To keep our SocketServer example simple, we
  designed it to listen for and handle a single
  connection request. However, multiple client
  requests can come into the same port and,
  consequently, into the same ServerSocket object.
• Client connection requests are queued at the
  port, so the server must accept the connections
  sequentially.
• However, the server can service them
  simultaneously through the use of threads - one
  thread per each client connection.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
11
JAVA Threads

• The basic flow of logic in a threaded server is
  this
• From a logical point of view, multithreading
  means multiple lines of a single program can be
  executed at the same time, however, it is not the
  same as starting a program twice and saying that
  there are multiple lines of a program being
  executed at the same time.
• Creating threads
• Two ways of creating threads
• implementing the runnable interface.
• Extending the Thread class is the way Java
  inherits methods and variables from this parent
  class

while (true) accept a connection
create a thread to deal with the client end
while
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
12
Content

• JAVA RMI
• Java RMI Internals
• What is a codebase?
• How codebase is used
• RMI and Applets
• RMI multiple clients vs the same server object
• Downloading RMI stubs
• RMI Command-line examples
• RMI Troubleshooting
• RMI deployment examples

• Recalls on Networking
• Java Sockets
• JAVA Threads
• JAVA RMI
• JAVA RMI vs other Middlewares
• Java-RMI Working mode
• Programming RMI
• Writing a RMI server
• RMI server skeleton
• Writing a RMI client
• Running the client and server
• RMI and java security

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
13
JAVA RMI

• Remote Method Invocation (RMI) is the object
  equivalent of Remote Procedure Calls (RPC).
• While RPC allows you to call procedures over a
  network, RMI invokes an object's methods over a
  network.
• In the RMI model,
• the server defines objects that the client can
  use remotely.
• The clients can now invoke methods of this remote
  object as if it were a local object running in
  the same virtual machine as the client.
• RMI hides the underlying mechanism of
  transporting method arguments and return values
  across the network.
• In Java-RMI, an argument or return value can be
  of any primitive Java type or any other
  Serializable Java object.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
14
Java-RMI Working mode

• Since both the client and the server may reside
  on different machines/processes, there needs to
  be a mechanism that can establish a relationship
  between the two.
• Java-RMI uses a network-based registry program
  called RMIRegistry to keep track of the
  distributed objects. (Note The RMI Registry is
  an RMI server itself!!!)
• The RMI Registry
• The server object makes methods available for
  remote invocation by binding it to a name in the
  RMI Registry.
• The client object, can thus check for the
  availability of a certain server object by
  looking up its name in the registry.
• The RMI Registry thus acts as a central
  management point for Java-RMI.
• The RMI Registry is thus a simple name
  repository. It does not address the problem of
  actually invoking remote methods.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
15
Java-RMI Working mode

• Stubs and Skeletons
• Since the two objects may physically reside on
  different machines, a mechanism is needed to
  transmit the client's request to invoke a method
  on the server object to the server object and
  provide a response.
• Java-RMI uses an approach similar to RPC in this
  regard. The code for the server object must be
  processed by an RMI compiler called rmic, which
  is part of the JDK.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
16
Java-RMI Working mode

• Stubs and Skeletons
• The rmic compiler generates two files a stub and
  a skeleton.
• The stub resides on the client machine and the
  skeleton resides on the server machine.
• When a client invokes a server method,
• The JVM looks at the stub to do type checking.
• The request is then routed to the skeleton on the
  server,
• Which in turn calls the appropriate method on the
  server object. In other words, the stub acts as a
  proxy to the skeleton and the skeleton is a proxy
  to the actual remote method.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
17
Programming RMI

• Remote Method Invocation (RMI) facilitates object
  function calls between Java Virtual Machines
  (JVMs).
• JVMs can be located on separate computers - yet
  one JVM can invoke methods belonging to an object
  stored in another JVM.
• Methods can even pass objects that a foreign
  virtual machine has never encountered before,
  allowing dynamic loading of new classes as
  required. This is a powerful feature!
• Consider the follow scenario
• Developer A writes a service that performs some
  useful function. He regularly updates this
  service, adding new features and improving
  existing ones.
• Developer B wishes to use the service provided by
  Developer A. However, it's inconvenient for A to
  supply B with an update every time.
• Java RMI provides a very easy solution! Since RMI
  can dynamically load new classes, Developer B can
  let RMI handle updates automatically for him.
  Developer A places the new classes in a web
  directory, where RMI can fetch the new updates as
  they are required.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
18
Programming RMI

• Connections made when client uses RMI
• Firstly, the client must contact an RMI registry,
  and request the name of the service. Developer B
  won't know the exact location of the RMI service,
  but he knows enough to contact Developer A's
  registry. This will point him in the direction of
  the service he wants to call..
• Developer A's service changes regularly, so
  Developer B doesn't have a copy of the class. Not
  to worry, because the client automatically
  fetches the new subclass from a webserver where
  the two developers share classes. The new class
  is loaded into memory, and the client is ready to
  use the new class. This happens transparently for
  Developer B - no extra code need to be written to
  fetch the class.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
19
Writing a RMI server

• We'll create a service that can calculate the
  square of a number, and the power of two numbers
  (238 for example).
• Due to the large size of the numbers, we'll use
  the java.math.BigInteger class for returning
  values rather than an integer or a long.
• Writing an interface
• The first thing we need to do is to agree upon an
  interface, An interface description is a
  description of the methods we will allow remote
  clients to invoke. Let's consider exactly what
  we'll need.
• A method that accepts as a parameter an integer,
  squares it, and returns a BigIntegerpublic
  BigInteger square ( int number_to_square )
• A method that accepts as a parameter two
  integers, calculates their power, and returns a
  BigIntegerpublic BigInteger power ( int num1,
  int num2 )
• Once we've decided on the methods that will
  compose our service, we have to create a Java
  interface.
• An interface is a method which contains abstract
  methods these methods must be implemented by
  another class.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
20
Writing a RMI server

• Here's the source code for our service
  (Interface) that calculates powers.
• Our interface extends java.rmi.Remote, which
  indicates that this is a remote service.
• We provide method definitions for our two methods
  (square and power), and the interface is
  complete.

This is where to define your interface
import java.math.BigInteger import
java.rmi. // // PowerService Interface // //
Interface for a RMI service that calculates
powers // public interface PowerService extends
java.rmi.Remote // Calculate the square of a
number public BigInteger square ( int number
) throws RemoteException // Calculate the power
of a number public BigInteger power ( int num1,
int num2) throws RemoteException
This is where to define it as RMI
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
21
Writing a RMI server

• Implementing the interface
• The next step is to implement the interface, and
  provide methods for the square and power
  functions.
• Implementing the interface is a little more
  tricky - we actually have to write the square and
  power methods! Don't worry if you're not sure how
  to calculate squares and powers, this isn't a
  math lesson. The real code we need to be
  concerned about is the constructor and main
  method.
• We have to declare a default constructor, even
  when we don't have any initialization code for
  our service. This is because our default
  constructor can throw a java.rmi.RemoteException,
  from its parent constructor in UnicastRemoteObject
  . Sound confusing? Don't worry, because our
  constructor is extremely simple.

public PowerServiceServer () throws
RemoteException            super()   
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
22
Writing a RMI server

• Implementing the interface
• Our implementation of the service also needs to
  have a main method. The main method will be
  responsible for creating an instance of our
  PowerServiceServer, and registering (or binding)
  the service with the RMI Registry. Our main
  method will also assign a security manager to the
  JVM, to prevent any nasty surprises from remotely
  loaded classes. In this case, a security manager
  isn't really needed, but in more complex systems
  where untrusted clients will be using the
  service, it is critical. 

    public static void main ( String args )
throws Exception            // Assign a
security manager, in the event that
dynamic       // classes are loaded       if
(System.getSecurityManager() null)           
System.setSecurityManager ( new
RMISecurityManager() )       // Create an
instance of our power service server
...       PowerServiceServer svr new
PowerServiceServer()       // ... and bind it
with the RMI Registry       Naming.bind
("PowerService", svr)       System.out.println
("Service bound....")   
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
23
RMI server skeleton

• Once the square and power methods are added, our
  server is complete. Here's the full source code
  skeleton for the PowerServiceServer.

import java.math. import java.rmi. import
java.rmi.server. // // PowerServiceServer // //
Server for a RMI service that calculates
powers // public class PowerServiceServer extends
UnicastRemoteObject implements PowerService
public PowerServiceServer () throws
RemoteException // Calculate the
square of a number public BigInteger square (
int number ) throws RemoteException
// Calculate the power of a number public
BigInteger power ( int num1, int num2) throws
RemoteException public static void
main ( String args ) throws Exception
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
24
Writing a RMI client

• What good is a service, if you don't write a
  client that uses it?
• Writing clients is the easy part - all a client
  has to do is
• call the registry to obtain a reference to the
  remote object,
• and call its methods.
• All the underlying network communication is
  hidden from view, which makes RMI clients simple.
• Our client must first assign a security manager,
  and then obtain a reference to the service.
• Note that the client receives an instance of the
  interface we defined earlier, and not the actual
  implementation.
• Some behind-the-scenes work is going on, but this
  is completely transparent to the client.

    // Assign security manager    if
(System.getSecurityManager() null)   
        System.setSecurityManager   (new
RMISecurityManager())       
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
25
Writing a RMI client

• To identify a service, we specify an RMI URL.
• The URL contains the hostname on which the
  service is located, and the logical name of the
  service.
• This returns a PowerService instance, which can
  then be used just like a local object reference.
• We can call the methods just as if we'd created
  an instance of the remote PowerServiceServer
  ourselves.

// Call registry for PowerService   
PowerService service (PowerService)
Naming.lookup("rmi//" args0
"/PowerService") // Call remote
methodSystem.out.println    ("Answer "
service.square(value)) // Call remote
methodSystem.out.println    ("Answer "
service.power(value,power))
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
26
Running the client and server

• Start the rmiregistry
• Windows users should do the following (assuming
  that your java\bin directory is in the current
  path) - start rmiregistry
• Unix users should do the following - rmiregistry
  
• Compile the server
• Compile the server, and use the rmic tool to
  create stub files.
• Start the server
• From the directory in which the classes are
  located, type the following-
• java PowerServiceServer
• Start the client
• You can run the client locally, or from a
  different machine. In either case, you'll need to
  specify the hostname of the machine where you are
  running the server. If you're running it locally,
  use localhost as the hostname.
• java PowerServiceClient localhost

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
27
RMI and java security

• If you running the client or server with JDK1.2,
  then you'll need to change the security settings.
  
• You'll need to specify a security policy file (a
  sample is included with the source code and
  classes) when you run the client and server.
• The following changes should be made when running
  the server
• java -Djava.security.policyjava.policy
  PowerServiceServer
• The following changes should be made when running
  the client
• java -Djava.security.policyjava.policy
  PowerServiceClient localhost

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
28
What is a codebase?

• A codebase can be defined as a source, or a
  place, from which to load classes into a Java
  virtual machine.
• For example, if you invited a new friend over for
  dinner, you would need to give that friend
  directions to the place where you lived, so that
  he or she could locate your house.
• Similarly, you can think of a codebase as the
  directions that you give to a JVM, so it can find
  your potentially remote classes.
• You can think of your CLASSPATH as a "local
  codebase", because it is the list of places on
  disk from which you load local classes.
• When loading classes from a local disk-based
  source, your CLASSPATH variable is consulted.
• Your CLASSPATH can be set to take either relative
  or absolute path names to directories and/or
  archives of class files.
• So just as CLASSPATH is a kind of "local
  codebase", the codebase used by applets and
  remote objects can be thought of as a "remote
  codebase".

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
29
How codebase is used in general

• To interact with an applet, that applet and any
  classes that it needs to run must be accessible
  by remote clients.
• While applets can be accessed from "ftp//" or
  local "file///" URLs, they are usually accessed
  from a remote HTTP server.
• The client browser requests an applet class that
  is not found in the client's CLASSPATH
• The class definition of the applet (and any other
  class(es) that it needs) is downloaded from the
  server to the client using HTTP
• The applet executes on the client
• An HTML source to invoke an applet will contain
  something like
• The applet's codebase is always relative to the
  URL of the HTML page in which the ltappletgt tag is
  contained.

ltapplet height100 width100 codebase"myclasses/"
code"My.class"gt ltparam name"ticker"gt
lt/appletgt
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
30
How codebase is used in RMI

• Using RMI, applications can create remote objects
  that accept method calls from clients in other
  JVMs.
• In order for a client to call methods on a remote
  object, the client must have a way to communicate
  with the remote object.
• Rather than having to program the client to speak
  the remote object's protocol, RMI uses special
  classes called stubs that can be downloaded to
  the client that are used to communicate with
  (make method calls on) the remote object.
• The java.rmi.server.codebase property value
  represents one or more URL locations from which
  these stubs (and any classes needed by the stubs)
  can be downloaded.
• Like applets, the classes needed to execute
  remote method calls can be downloaded from
  "file///" URLs, but like applets, a "file///"
  URL generally requires that the client and the
  server reside on the same physical host, unless
  the file system referred to by the URL is made
  available using some other protocol, such as NFS.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
31
Java RMI Internals

• The RMI Server creates an instance of the 'Server
  Object' which extends UnicastRemoteObject
• The constructor for UnicastRemoteObject "exports"
  the Server Object - basically making it available
  to service incoming RMI calls. A TCP socket which
  is bound to an arbitrary port number is created
  and a thread is also created that listens for
  connections on that socket.
• The server registers the server object with the
  registry. This operation actually hands the
  client-side "stub" for that server object. This
  stub contains the information needed to "call
  back" the server when it is invoked (such as the
  hostname/port of the server listening socket).

Registry
3 RMI
Client
1
RMI
RMI Server
HTTP URL
HTTP URL
Web server
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
32
Java RMI Internals

• A client obtains this stub by calling the
  registry, which hands it the stub directly.
• This is also where the "codebase" comes in If
  the server specified a "codebase" to use for
  clients to obtain the classfile for the stub,
  this will be passed along to the client via the
  registry.
• The client can then use the codebase to resolve
  the stub class - that is, to load the stub
  classfile itself).
• That is all that the RMIRegistry really does It
  holds onto remote object stubs which it can hand
  off to clients when requested.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
33
Java RMI Internals

1. When the client issues a remote method invocation
   to the server, the stub class creates a
   "RemoteCall" which basically (a) opens a socket
   to the server on the port specified in the stub
   itself, and (b) Sends the RMI header information
   as described in the RMI spec.
2. The stub class marshalls the arguments over the
   connection by using methods on RemoteCall to
   obtain the output stream which basically returns
   a subclass of ObjectOutputStream which knows how
   to deal with passing objects which extend
   java.rmi.Remote, which serializes Java objects
   over the socket

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
34
Java RMI Internals

1. The stub class calls RemoteCall.executeCall which
   causes the RMI to happen.
2. On the server side, when a client connects to the
   server socket, a new thread is forked to deal
   with the incoming call. The original thread can
   continue listening to the original socket so that
   additional calls from other clients can be made.
3. The server reads the header information and
   creates a RemoteCall of its own to deal with
   unmarshalling the RMI arguments from the socket.
4. The server calls the "dispatch" method of the
   skeleton class (the server-side "stub" generated
   by rmic), which calls the appropriate method on
   the object and pushes the result back down the
   wire (using the same 'RemoteCall' interface which
   the client used to marshall the arguments). If
   the server object threw an exception then the
   server catches this and marshalls that down the
   wire instead of the return value.
5. Back on the client side, the return value of the
   RMI is unmarshalled (using the RemoteCall created
   in step 5 above) and returned from the stub back
   to the client code itself. If an exception was
   thrown from the server that's unmarshalled and
   re-thrown from the stub.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
35
RMI multiple clients vs the same server object

• All the Clients get stubs which contain the same
  hostname/port number as the server-side socket
  which is listening for calls on the object.
• When a client connects, the server forks a new
  thread to deal with the incoming request, but
  keeps listening to that original socket (in
  another thread) so that other calls can be made.
• There doesn't appear to be any synchronization
  within the server side components - if multiple
  clients simultaneously call into the server
  object they can all manipulate the server object
  state at the same time.
• You can of course make methods in your server
  object "synchronized" to synchronize access to
  them.
• Now, the RMI specification defines both a "single
  op" and a "stream" protocol for RMI calls. The
  former allows a single RMI call to be made on a
  socket which is then closed the latter allows
  multiple RMI calls to be issued on the same
  socket one after the other.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
36
RMI multiple clients vs the same server object

• Sun's RMI implementation appears to be using this
  latter mechanism which means that a single
  client-side stub object will open a single socket
  to the server for all of its communication.
• Multiple stubs within the same JVM or different
  JVMs on the same host will each have their own
  socket to the server (which might all dispatch
  calls to the same server-side object). The net
  result is that each time you obtain a stub (from
  the registry) for a particular server-side
  object, you will eventually create a new socket
  to talk to the server.
• So basicallyON THE SERVER A single
  'UnicastRemoteObject' which ends up creating
  multiple threads to listen for calls on this
  single object - one thread per socket (basically
  meaning one thread per client)
• ON THE CLIENT One socket to the server per stub,
  meaning that if the client has multiple stubs
  pointing to the same server object it will have
  multiple sockets open to that server.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
37
RMI and Applets

• A remote system can run a program, for example an
  applet, which has never been installed on its
  disk
• For example, a JVM running from within a web
  browser can download the bytecodes for subclasses
  of java.applet.Applet and any other classes
  needed by that applet.
• The system on which the browser is running has
  most likely never run this applet before, nor
  installed it on its disk. Once all the necessary
  classes have been downloaded from the server, the
  browser can start the execution of the applet
  program using the local resources of the system
  on which the client browser is running.
• For the first few sections of this document,
  codebase with regard to applets will be discussed
  in order to help describe codebase with regard to
  Java Remote Method Invocation (RMI).
• Java RMI takes advantage of this capability to
  download and execute classes and on systems where
  those classes have never been installed on disk.
• Using the RMI API any JVM, not only those in
  browsers, can download any Java class file
  including specialized RMI stub classes, which
  enable the execution of method calls on a remote
  server using the server system's resources.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
38
RMI and Applets

• The notion of a codebase originates from the use
  of ClassLoaders in the Java programming language.
  
• When a Java program uses a ClassLoader, that
  class loader needs to know the location(s) from
  which it should be allowed to load classes.
• Usually, a class loader is used in conjunction
  with an HTTP server that is serving up compiled
  classes for the Java platform.
• The first ClassLoader/codebase pairing that you
  came into contact with was the AppletClassLoader,
  and the "codebase" part of the ltappletgt HTML tag
• An HTML source to invoke an applet will contain
  something like
• to invoke a servlet will contain something like

ltapplet height100 width100 codebase"myclasses/"
code"My.class"gt ltparam name"ticker"gt lt/appletgt

ltservlet codebase"myclasses/" code"My.class"gt lt
param name"ticker"gt lt/servletgt
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
39
RMI development steps

• The development process is shown bellow where Bob
  is the server developer and Alice the client one.
  

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
40
RMI development steps

• The different steps Bob must follow to get his
  server implemented and running are
• Define the server interface. The server object
  declares its service via a remote interface, that
  must therefore extends the java.rmi.Remote
  interface.
• Write the server code. Bob must provide the Java
  file containing the server class that implements
  its server interface, and that inherits from the
  java.rmi.UnicastRemoteObject class. He must also
  include the code that will install a
  SecurityManager and that will register the server
  interface within the RMI naming context using the
  Naming.bind (or rebind) method. The daemon
  program that is in charge of the naming service
  is rmiregistry, and it must of course be running
  for the interface registration to succeed(Recall
  the RMIregistry is a server itself).
• Compile the server class. Bob first uses the
  javac compiler to produce the server .class file,
  and secondly, runs the rmic compiler to obtain
  the stub and skeleton .class files.
• Execute the server program. If the rmiregistry
  daemon is not already running, Bob must launch
  it. He can then run the java interpreter with his
  server .class file.
• Distribute the stub class. In order to get
  clients calling the methods of his server, Bob
  needs to give them the stub class he has just
  generated, to Alice for example. This will enable
  her code to make successful requests on his
  server object.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
41
RMI Command-line examples

• In the case of an applet, the applet codebase
  value is embedded in an HTML page, as we saw in
  the HTML example ..
• In the case of Java RMI codebase, rather than
  having a reference to the class embedded in an
  HTML page, the client first contacts the RMI
  registry for a reference to the remote object.
  Because the remote object's codebase can refer to
  any URL, not just one that is relative to a known
  URL,
• The value of the RMI codebase must be an absolute
  URL to the location of the stub class and any
  other classes needed by the stub class. This
  value of the codebase property can refer to
• The URL of a directory in which the classes are
  organized in package-named sub-directories
• The URL of a JAR file in which the classes are
  organized in package-named directories
• A space-delimited string containing multiple
  instances of JAR files and/or directories that
  meet the criteria above
• Note When the codebase property value is set to
  the URL of a directory, the value must be
  terminated by a "/".

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
42
RMI Command-line examples

• Examples
• If the location of your downloadable classes is
  on an HTTP server named "webvector", in the
  directory "export" (under the web root), your
  codebase property setting might look like this
• If the location of your downloadable classes is
  on an HTTP server named "webline", in a JAR file
  named "mystuff.jar", in the directory "public"
  (under the web root), your codebase property
  setting might look like this
• Now let's suppose that the location of your
  downloadable classes has been split between two
  JAR files, "myStuff.jar" and "myOtherStuff.jar".
  If these JAR files are located on different
  servers (named "webfront" and "webwave"), your
  codebase property setting might look like this

-Djava.rmi.server.codebasehttp//webvector/export
/
-Djava.rmi.server.codebasehttp//webline/public/m
ystuff.jar
-Djava.rmi.server.codebase"http//webfront/myStuf
f.jar http//webwave/myOtherStuff.jar"
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
43
RMI Troubleshooting

• Any serializable class, including RMI stubs, can
  be downloaded if your RMI programs are configured
  properly. Here are the conditions under which
  dynamic stub downloading will work
• The stub class and any of the classes that the
  stub relies on are served up from a URL reachable
  from the client.
• The java.rmi.server.codebase property has been
  set on the server program (or in the case of
  activation, the "setup" program) that makes the
  call to bind or rebind, such that
• The value of the codebase property is the URL in
  step A and
• If the URL specified as the value of the codebase
  property is a directory, it must end in a
  trailing "/"
• The rmiregistry cannot find the stub class or any
  of the classes that the stub relies on in its
  CLASSPATH. This is so the codebase gets annotated
  to the stub when the registry does its class load
  of the stub, as a result of calls to bind or
  rebind in the server or setup code.
• The client has installed a SecurityManager that
  allows the stub to be downloaded. In the Java 2
  SDK, Standard Edition, v 1.2 this means that the
  client must also have a properly configured
  security policy file.
• There are two common problems associated with the
  java.rmi.server.codebase property, which are
  discussed next.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
44
RMI Troubleshooting

• If you encounter a problem running your RMI
  server
• Receipt of a ClassNotFoundException when
  attempting to bind or rebind a remote object to a
  name in the registry. This exception is usually
  due to a malformed codebase property, resulting
  in the registry not being able to locate the
  remote object's stubs or other classes needed by
  the stub.
• It is important to note that the remote object's
  stub implements all the same interfaces as the
  remote object itself, so those interfaces, as
  well as any other custom classes declared as
  method parameters or return values, must also be
  available for download from the specified
  codebase.
• Most frequently, this exception is thrown as a
  result of omitting the trailing slash from the
  URL value of the property. Other reasons would
  include the value of the property is not a URL
  the path to the classes specified in the URL is
  incorrect or misspelled the stub class or any
  other necessary classes are not all available
  from the specified URL.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
45
RMI Troubleshooting

• The exception that you may encounter in such a
  case would look like this
• If you encounter a problem running your RMI
  client
• The second problem you could encounter is the
  receipt of a ClassNotFoundException when
  attempting to lookup a remote object in the
  registry. If you receive this exception in a
  stacktrace resulting from an attempt to run your
  RMI client code, then your problem is the
  CLASSPATH with which your RMI registry was
  started. Here is what the exception will look
  like

java.rmi.ServerException RemoteException
occurred in server thread nested exception is
java.rmi.UnmarshalException error unmarshalling
arguments nested exception is java.lang.ClassNot
FoundException examples.callback.MessageReceiverI
mpl_Stub java.rmi.UnmarshalException error
unmarshalling arguments nested exception
is java.lang.ClassNotFoundException
examples.callback.MessageReceiverImpl_Stub java.la
ng.ClassNotFoundException examples.callback.Messa
geReceiverImpl_Stub at sun.rmi.transport.StreamRem
oteCall.exceptionReceivedFromServer(Compiled
Code) at sun.rmi.transport.StreamRemoteCall.execut
eCall(Compiled Code) at sun.rmi.server.UnicastRef.
invoke(Compiled Code) at sun.rmi.registry.Registry
Impl_Stub.rebind(Compiled Code) at
java.rmi.Naming.rebind(Compiled Code) at
examples.callback.MessageReceiverImpl.main(Compile
d Code) RemoteException occurred in server
thread nested exception is java.rmi.UnmarshalExc
eption error unmarshalling arguments nested
exception is java.lang.ClassNotFoundException
examples.callback.MessageReceiverImpl_Stub
java.rmi.UnmarshalException Return value class
not found nested exception is java.lang.ClassNot
FoundException MyImpl_Stub at sun.rmi.registry.Re
gistryImpl_Stub.lookup(RegistryImpl_Stub.java109
at java.rmi.Naming.lookup(Naming.java60) at
RmiClient.main(MyClient.java28)
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
46
RMI Troubleshooting

• This is a list of some Exceptions that may occur
  During Remote Object Export
• When a remote object class is created that
  extends UnicastRemoteObject, the object is
  exported, meaning it can receive calls from
  external Java virtual machines and can be passed
  in an RMI call as either a parameter or return
  value. An object can either be exported on an
  anonymous port or on a specified port. For
  objects not extended from UnicastRemoteObject,
  the java.rmi.server.UnicastRemoteObject.exportObje
  ct method is used to explicitly export the
  object.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
47
RMI Troubleshooting
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
48
JAVA RMI vs other Middlewares

• Java-RMI is a Java-specific middleware that
  allows client Java programs to invoke server Java
  objects as if they were local.
• Java-RMI is tightly coupled with the Java
  language. Hence there are no separate IDL
  mappings that are required to invoke remote
  object methods.
• This is different from DCOM or CORBA where IDL
  mappings have to be created to invoke remote
  methods.
• Since Java-RMI is tightly coupled with The Java
  Language, Java-RMI can work with true
  sub-classes. Neither DCOM nor CORBA can work with
  true subclasses since they are static object
  models
• Because of this, parameters passed during method
  calls between machines can be true Java Objects.
  This is impossible in DCOM or CORBA at present.
• If a process in an RMI system receives an object
  of a class that it has never seen before, it can
  request that its class information be sent over
  the network.
• Over and above all this, Java-RMI supports
  Distributed Garbage Collection that ties into the
  local Garbage Collectors in each JVM.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
49
RMI deployment examples

• Each main functionality are designed as a
  totally independent system based on this
  architecture
• PRESENTATION,
• ACQUISITION,
• ACCESS
• each functionality is a standalone system which
  can be used for another goal.

Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
50
RMI deployment examples
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES
51
RMI deployment examples
Wilfried Probst Rufin Soh INE4481
DISTRIBUTED DATABASES CLIENT-SERVER
ARCHITECTURES