Distributed Web Systems Distributed Objects and Remote Method Invocation Lecturer Department University

Outline Programming models for distributed applications Distributed objects Java RMI case study Distributed event-based systems

Programming models for distributed applications Requirement: –processes need to be able to invoke operations in other processes Applications, services Middleware layers request-reply protocol marshalling and external data representation UDP and TCP This lecture RMI, RPC, and events

Programming models (contd.) Remote procedure call –provide clients with the ability to call procedures in server programs running in separate processes, likely on different computers Remote method invocation –allowing objects to invoke methods of objects that can be in different processes and on different computers Event-based programming –objects can receive notifications from other possibly remote objects about events they are interested in – essentially distributed event-driven programming

Object-oriented programming Objects: –encapsulation of data and code operating on that data Object reference: –a pointer to an object –String s = new String(); Interfaces: –methods, their arguments, return values and exceptions (aka method signatures) –int getValue(String attribute) throws Exception

Object-oriented programming Actions: –initiated by object invoking method of another object Exceptions: –a mechanism for handling error –control passes to a block of code that catches the exception Garbage collection: –Reusing memory occupied by objects that are no longer needed – object references are used to determine that! –In some languages, programmers have to do it manually

What about distributed objects? Can adopt the client-server architecture: invocation remote invocation remote local invocation A B C D E F ClientServer (managing remote objects) Request to call a method on a remote object is sent to server in a message (result is returned back to client in another message) © Pearson Education 2005

Distributed object model Remote object reference: –a mechanism to access (identify) a remote object –a unique identifier that can be used throughout a distributed system Remote interface: –a way to specify what the remote object signature is like (which methods we can call, what are inputs and outputs?) interface remote m1 m2 m3 m4 m5 m6 Data implement. remoteobject { of methods © Pearson Education 2005

Distributed object model (contd.) Actions: –like in non-distributed – initiated by method invocations (except these can be remote now) Garbage collection: –More tricky! –Local garbage collector need to have information about remote references to its objects –Need to count local as well as remote references to an object. Exceptions: –need to transfer back to the client –additional sources of exceptions (server crashes, network failures)

Design issues for RMI Invocation semantics (meaning): –Recall: messages can get lost, processes can crash Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Yes Not applicable No Yes Not applicable Re-execute procedure Retransmit replyAt-most-once At-least-once Maybe

RMI implementation Proxy: makes invocation transparent for client -- remote referencing, marshalling request, sending it to server, unmarshalling response Dispatcher: passes request message to the requested skeleton method Skeleton: the opposite of proxy – unmarshalling request, calling remote object, marshalling and sending back response object A object B skeleton Request proxy for B Reply Communication Remote Remote reference Communication module reference module module for B’s class & dispatcher remote client server © Pearson Education 2005

Java RMI Client object RMI stub RMI dispatcher and skeleton Remote object RMI registry Client Server Remote reference module Proxy

Making remote service Make remote interface –public interface MyRemote { … Make implementation of remote class –public class MyRemoteImpl implements MyRemote {.. Start RMI registry on the server –rmiregistry Start remote service –java MyRemoteImpl

Making remote interface import java.rmi.*;... public interface MyRemote extends Remote {... public String sayHello() throws RemoteException;... } Need to announce that this is a remote interface Errors occurring during remote invocation Input/return values must be Serializable, since they will be sent over network Contains definitions of necessary classes etc

Making remote implementation import java.rmi.*;... public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote {... public MyRemoteImpl() throws RemoteException { };... public String sayHello() throws RemoteException { return “Server says hello!”); }... } This is to include functionality needed to work as a remote object Implementation of the remote method UnicastRemoteObject throws RemoteException in its constructor – so we have to do the same in our class Contains definitions of necessary classes etc

In the main method of your service class… Need to instantiate the class Need to give it an RMI name – so that clients could access it by this name through the RMI registry... try { MyRemote service = new MyRemoteImpl(); Naming.rebind(“Remote hello”, service); } catch (Exception e) {... }... This registers your object with RMI registry

Generating stubs and skeletons In olderJava versions: –Use rmic –Produces a new class Stub: _Stub even older Java versions also produced a separate skeleton class _Skel In newer Java version (1.5 and later): –Generated automatically at run time MyRemoteImpl_Stub.class

What about the client code? Client need to do two steps to call a remote object: –Get remote reference (in this case reference to the corresponding RMI stub) –Call it!... try { MyRemote service = (MyRemote) Naming.lookup(“rmi://localhost/Remote hello”); String s = service.sayHello();... } catch (Exception e) {... }... RMI name of the remote object Host where the server is running

What actually happens… Client object RMI stub RMI dispatcher Remote object RMI registry: Client Server NameStub Remote hello RMI stub lookup() stub returned sayHello()

A note on which files you will need on client and server On client: –Your client class –Remote interface class (MyRemote.class) On server: –Remote interface class (MyRemote.class) –Remote class implementation (MyRemoteImpl.class) In older Java versions, also needed stub class (MyRemoteImpl_Stub.class) on both server and client –Why would we need stub class on the client?

Remote Procedure Call (RPC) The same idea as RMI –Client-server –Stubs and skeletons (clients and server stub procedures) –Communication modules and dispatcher on the server Have a look for examples, at the Sun RPC case study in the book

Event-based programming Program execution is driven by external events as opposed to a pre-programmed sequence: What is the most common application? Distributed even-based systems –Extend the local event model by allowing objects at different locations to be notified of events taking place at an object While (forever) { // Wait for next event // Send notification to all interested objects }

Distributed event-based systems How the communication happens –Receiving object needs to register its interest in a type of event (subscribe to a particular type of event) Characteristics: –Heterogeneous Objects can interoperate even when they were not designed to work together explicitly –Asynchronous Objects generating events do not have to synchronise with objects that subscribe to those events

Example: Stock dealing system © Pearson Education 2005

Participants in distributed event notification Object of interest – source of events Event – some change in an object of interest (usually a result of method execution) Notification – an object that contains information about an event (its type and other attributes) Subscriber – an object interested in some type of events Observer – intermediary decoupling event source and subscriber (forwarding, filtering, patterns of events, mailboxes) Publisher – object declaring that it will generate notifications (either the object of interest or an observer)

Architectures for event notification subscriberobserverobject of interest Event service object of interest observer subscriber notification © Pearson Education 2005

Example: Jini A distributed Java-based computing environment that can offer ``network plug and play'‘. Examples: –A new printer, digital camera, etc.. can be connected to the network and announce its presence and capabilities. A client can then use this printer without having to be specially configured to do so and the camera can send pictures to the printer.

Summary Centralised: procedure call, method invocation, event-based programming Distributed: RPC, RMI, distributed event-based programming Adopt the client-server architecture –stubs (proxies), dispatchers, skeletons –exceptions (errors), garbage collection –Example: Java RMI Questions