Serialisation, Callbacks and Remote Object Activation

1
Serialisation, Callbacks and Remote Object
Activation
2
java.io.Serializable

• So far, weve just passed instances of
  java.lang.String from client to server.
• What if we want to pass more complex,
  programmer-defined data structures?
• To do this, mechanisms must be put in place to
  convert such data structures to and from byte
  streams.
• Java provides a simple means to do this the
  java.io.Serializable interface.

3
Serializable Objects

• The ability to send structured object instances
  across a network via object serialization is a
  powerful feature.
• The byte stream produced by serialization is in a
  form sufficient to reconstruct the object
  instance as it is read.
• Object serialization can also be employed to
  provide lightweight persistence the archival of
  an object for use in a later invocation of the
  same program.

4
Writing Objects

• Writing objects to a stream is a straightforward
  process.
• For example, this writes a String to a file
  called tmp and then gets the current time by
  constructing a Date object and then serializes it
  to the same file
• FileOutputStream f new FileOutputStream( "tmp"
  )
• ObjectOutputStream s new ObjectOutputStream( f
  )
• s.writeObject( "Today" )
• s.writeObject( new Date() )
• s.flush()
• Primitive data types may also be written through
  methods such as writeInt, writeFloat, etc.

5
Reading Objects

• This reads in the String and the Date objects
  that were written to the file named tmp
• FileInputStream f new FileInputStream( tmp
  )
• ObjectInputStream s new ObjectInputStream( f
  )
• String today (String)s.readObject()
• Date date (Date)s.readObject()
• The readObject method is used to read in objects
  from the file returning a java.lang.Object each
  time.
• It deserializes objects from the stream and
  traverses its references to other objects
  recursively to deserialize all objects that can
  be reached from it.
• You can also readInt, readFloat, etc.

6
Implementing Serializable

• An object is serializable if it implements the
  Serializable interface.
• public class MyClass
• implements java.io.Serializable
• ...
• There are no methods that must be defined, you
  can just use the defaultWriteObject method of the
  ObjectOutputStream and the defaultReadObject
  method of the ObjectInputStream.
• You can specify readObject and writeObject
  methods to customise the behaviour.

7
Task

• We start by defining a serializable superclass of
  messages, providing a method by which the message
  can be called upon to execute itself.
• import java.io.
• public abstract class Task
• implements Serializable
• public Object execute() return null
• We can then specify a number of different
  requests by extending this class and overriding
  the execute() method.

8
Shout Task

• For example, lets define a ShoutTask that, when
  executed, will change a message to upper case.
• public class ShoutTask extends Task
• String _msg
• public ShoutTask( String msg )
• _msg msg
• public Object execute()
• return new String( _msg.toUpperCase() )

9
Lines Task

• public class LinesTask extends Task
• String _msg int _n
• public LinesTask( String msg, int n )
• _msg msg
• _n n
• public Object execute()
• String lines _msg
• for (int i 1 i lt _n i)
• lines lines "\n" _msg
• return lines

10
Task Server Interface

• To develop a server that processes tasks, we can
  simply adapt the rmishout example
• public interface TaskServerInterface
• extends Remote
• public Object doit( Task t )
• throws RemoteException

11
Task Server Implementation

• public class TaskServerImpl
• extends java.rmi.server.UnicastRemoteObject
• implements TaskServerInterface
• public TaskServerImpl()
• throws RemoteException
• public Object doit( Task t )
• throws RemoteException
• return t.execute()

12
Mobile code

• Object serialization gives a lot of flexibility
  to the application developer.
• Method parameters are not restricted to data.
• A client can send an intelligent message to the
  server.
• The message executes a query on the server, then
  filters the result.
• It then returns to the client with the processed
  data as its payload.
• It may even visit multiple servers before
  returning to the client.

13
Parameter Passing

• As we have seen, any Serializable Java object can
  be passed by copy using RMI.
• This enables
• Easy passing of complex-structured information.
• Working with objects locally, after passing.
• Object replication and caching.
• Furthermore, remote object references may be
  passed as parameters.
• Obviously, this is parameter passing by
  reference, not by value.
• It does allow any remote object to serve as a
  "broker" for other remote objects.

14
Parameter Passing Example

• RemoteBank bank Naming.lookup("...")
• RemoteAccount acct bank.getAccount(87654321)
• Balance bal acct.getBalance()
• With this model, we use the RMI Registry only to
  bootstrap the system.
• A reference to the bank is obtained from the
  Registry.
• Any further object references can then be
  obtained directly from the bank server e.g. an
  object reference to a RemoteAccount object.
• This may subsequently be used to obtain a copy of
  a Serializable Balance object.

15
Client Callbacks

• When a client object invokes a remote method, the
  calling thread is blocked until the remote method
  returns.
• When a server-side computation is likely to be
  lengthy, it can be more convenient to have the
  client pass a call-back remote object reference.
• The server will invoke a method on the clients
  call-back object to pass the result of the
  computation.
• Call-backs can also be used to implement extended
  messaging conversations between client and server.

16
The Auction Example

• Consider a first price, sealed bid auction.
• The system will consist of a single auctioneer
  and a number of bidders.
• The auctioneer receives bids from bidders until
  some end condition holds e.g. a deadline is
  reached or sufficient number of bids have been
  received.
• When this condition holds, the auction closes and
  the outcome is reported.

17
Bidder-Auctioneer Communication

• How should the bidders talk to the auctioneer?
• They could submit their bid through a
  bid-and-wait method, which returns the outcome
  when the auction closes.
• They could submit their bid and then periodically
  poll the server to discover whether or not the
  auction has closed.
• They could submit their bid and give the
  auctioneer a callback reference to use once the
  auction closes.

18
The Auctioneer Interface

• package cs3515.examples.auction
• import java.rmi.Remote
• import java.rmi.RemoteException
• public interface AuctioneerInterface
• extends Remote
• public void bid( BidderInterface buyer,
• float price )
• throws RemoteException

19
The Bidder Interface

• package cs3515.examples.auction
• import java.rmi.Remote
• import java.rmi.RemoteException
• public interface BidderInterface extends Remote
• public void won( String item,
• float price )
• throws RemoteException
• public void lost( String item,
• String msg )
• throws RemoteException

20
The Auctioneer Implementation

• The implementation of the bid method
• Records the new bidder for callbacks.
• Checks in the new bid as a winner or a loser.
• Check whether the condition for the end of the
  auction holds (number of bids equals number
  required).
• If the condition for the end of the auction
  holds, the auctioneer invokes either the won()
  method or the lost() method on each bidder
  callback remote object.

21
Robust and Scalable Distributed Systems

• In designing distributed systems, both
  scalability and robustness are key issues.
• Lets consider one aspect of scalability.
• Suppose we have a server providing access to an
  important data resource.
• We could have a data access object running on a
  server 24/7.
• What if access to the database is only required
  infrequently.
• Is it sensible to have it running, consuming
  resources unless it is being used?

22
Robust and Scalable Distributed Systems

• Lets consider one aspect of robustness.
• What if a remote server crashes due to a system
  failure?
• Ideally, we would like the remote object to be
  regenerated when it is next required.
• And, its remote reference should be persistent.

23
RMI Activation Service Features

• The key features of the RMI activation service
  include
• The ability to automatically generate remote
  objects triggered by requests for references to
  these objects.
• Support for activation groups so that grouped
  objects can be started in the same JVM.
• The ability to restart remote objects if they
  exit or are destroyed due to a system failure.

24
Creating Activatable Remote Objects

• To create an activatable remote object
• The remote object implementation should subclass
  (extend) java.rmi.activation.Activatable (not
  java.rmi.server.UnicastRemoteObject).
• Activation constructors should be specified in
  the server implementation.
• The remote object and its activation method must
  be registered with the activation service.
• If you want clients to directly access the
  activatable objects, you need to register the
  object with the naming service.

25
Persistent Remote References

• A reference to an activatable remote object does
  not have to have a live object behind it.
• The object may not have been created yet.
• It may have been garbage collected by its JVM.
• Its JVM may have exited.
• The reference remains valid no matter how many
  times the remote object goes down and is
  reactivated.

26
Client invocation

• Clients obtain a remote reference in the normal
  way either through a naming service or from some
  other object.
• Clients obtain a stub in the normal way either
  from the local CLASSPATH or via HTTP.
• When the client invokes the remote object
• The activation service notices that the remote
  object is not running and starts it.
• If there is no VM for the remote object, a VM is
  created.
• As long as the remote object is running,
  subsequent requests are handled as usual.