Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
82 views

Chapter Five Remote Method Invocation 1

Definitions Software Process Software Process Model (Humphrey 1990) the set of activities, methods, and practices that are used in the production and evolution of software Software Process Model one specific embodiment of a software process architecture (Humphrey 1990) Software project management
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
82 views

Chapter Five Remote Method Invocation 1

Definitions Software Process Software Process Model (Humphrey 1990) the set of activities, methods, and practices that are used in the production and evolution of software Software Process Model one specific embodiment of a software process architecture (Humphrey 1990) Software project management
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 79

CHAPTER FIVE: REMOTE INVOCATION

RECAP ON COMMUNICATION PARADIGMS

(Reference: Chapter 5 Coulouris, G., Dollimore,


J., Kindberg, T., Blair, G., Distributed Systems:
Concepts and Design, 5th Edition, Addison
Wesley, 2011.)
introduction cont……
Introduction
Recall;.
•How do entities communicate in Distributed Systems?
•three types of communication paradigm:-
– Interprocess Communication.
– Remote Invocation.
– Indirect Communication.

Distributed systems by Patrick ndungu 2


COMMINICATION PARADIGM CONT.. 2. REMOTE INVOCATION
2. REMOTE INVOCATION
– Introduction to Remote Invocation
 the most common communication paradigm in distributed systems,
 Covers a range of techniques based on a two way exchange between
communicating entities in a distributed system and resulting in the calling of a
remote operation, procedure or method.
•  Remote invocation techniques include:-
a. Request-reply protocols
b. Remote procedure calls (RPC)
c. Remote method invocation (RMI)
• All Remote Invocation techniques have one thing in common:
– Communication represents a two-way relationship between a sender and a
receiver with senders explicitly directing messages/invocations to the
associated receivers.
– Receivers are also generally aware of the identity of senders, and in most
cases both parties must exist at the same time(time coupling).
• 
Distributed systems by Patrick ndungu 3
REMOTE INVOCATION CONT..
• In contrast,
– a number of techniques have emerged
whereby communication is indirect, through a
third entity, allowing a strong degree of
decoupling between senders and receivers.
– In particular:
• space uncoupling:-Senders do not need to know
who they are sending to.
• time uncoupling:- Senders and receivers do not
need to exist at the same time.

Distributed systems by Patrick


4
ndungu
REMOTE INVOCATION CONT..
• Functions of Remote IPC
• Process registration for the purpose of identifying communicating
processes.
• Hide differences between local and remote communication.
• Overcome failures.
• Establishing communication channels between processes.
• Routing messages to the destination process.
• Synchronizing concurrent processes.
• Shutting down communication channels.
• Enforces a clean and simple interface providing a natural environment
for modular structuring of distributed applications.
– Types of Remote Invocation:
a) Request-Reply Protocols
Distributed systems by Patrick
5
ndungu
a) Request-Reply Protocols
a) Request-Reply Protocols
•RRP are effectively a pattern imposed on an underlying message passing service to support client-
server computing.
– The protocols typically involve a pairwise exchange of messages from client to server and
then from server back to client with;
• The first message;
– containing an encoding of the operation to be executed at the server and also
an array of bytes holding associated arguments and
• The second message
– containing any results of the operation, again encoded as an array of bytes.

– This paradigm is rather primitive and only really used in


• embedded systems where performance is paramount.
• The HTTP protocol.

– Most distributed systems will elect to use


• remote procedure calls or
• remote method invocation,
– both approaches are supported by underlying request-reply exchanges.

 
6
Distributed systems by Patrick ndungu
Request-Reply Protocols Cont…

• The request-reply communication is synchronous because the


client process blocks until the reply arrives from the server.
– It can also be reliable because the reply from the server is effectively an
acknowledgement to the client.
•  Asynchronous request-reply communication is an alternative that may be
useful in situations where clients can afford to retrieve replies.
•  In particular:
– Acknowledgements are redundant, since requests are followed by
replies.
– Establishing a connection involves two extra pairs of messages in
addition to the pair required for a request and a reply.
– Flow control is redundant for the majority of invocations, which
pass only small arguments and results.

Distributed systems by Patrick ndungu 7


Request-Reply Protocols Cont…

The protocol is based on a trio of communication primitives, doOperation,


getRequest and sendReply, as shown below.
Request-Reply message structure

This request-reply protocol matches requests to replies.


 It may be designed to provide certain delivery guarantees.
 If UDP datagrams are used, the delivery guarantees must be provided
by the request-reply protocol, which may use the server reply message as an
acknowledgement of the client request message.
8
Distributed systems by Patrick ndungu
Request-Reply Protocols Cont…

- Request-Reply message structure

Distributed systems by Patrick


9
ndungu
Request-Reply Protocols Cont…
Failure model of the request-reply protocol
•If the three primitives doOperation, getRequest and sendReply are implemented
over UDP datagrams, then they suffer from the same communication failures i.e.:-
– They suffer from omission failures.
• Messages are not guaranteed to be delivered in sender order.
•  In addition, the protocol can suffer from the failure of processes.
•We assume that processes have crash failures.
– That is, when they halt, they remain halted –
•To allow for occasions when a server has failed or a request or reply message is
dropped, doOperation uses a timeout when it is waiting to get the server’s reply
message. The action taken when a timeout occurs depends upon the delivery
guarantees being offered.

Distributed systems by Patrick


10
ndungu
Request-Reply Protocols Cont…?
Styles of exchange protocols
– Three protocols, that produce differing behaviours in the presence of
communication failures are used for implementing various types of request
behaviour.  They were:-
i. Request (R) protocol;
ii. Request-reply (RR) protocol;
iii. Request-reply-acknowledge reply (RRA) protocol.
The messages passed in these protocols are summarized below:

Distributed systems by Patrick ndungu 11


Request-Reply Protocols Cont…?

Styles of exchange protocols cont..


i) The Request (R) Protocol
– A single Request message is sent by the client to the server:
• The R protocol
– may be used when there is no value to be returned from the remote
operation and the client requires no confirmation that the operation
has been executed.
• The client may proceed immediately after the request
message is sent-
– there is no need to wait for a reply message.
•  This protocol is implemented over UDP datagrams and
therefore suffers from the same communication failures.

Distributed systems by Patrick ndungu


12
Request-Reply Protocols Cont…?
Styles of exchange protocols cont..
ii) The Request-Reply (RR) Protocol
– The protocol is useful for most client-server exchanges because it
is based on the request-reply protocol:
– No special acknowledgement messages are required:-
» because a server’s reply message is regarded as an
acknowledgement of the client’s request message.
–  Similarly,
» a subsequent call from a client may be regarded as an
acknowledgement of a server’s reply message.
–  Communication failures due to UDP datagrams being lost may be
masked by the retransmission of requests with duplicate filtering and
the saving of replies in a history for retransmission.

Distributed systems by Patrick


13
ndungu
Request-Reply Protocols Cont…?
Styles of exchange protocols cont…
iii) The Request-Reply-Acknowledge Reply (RRA) Protocol
– The protocol is based on the exchange of three messages: Request-Reply-
Acknowledge reply:
• The Acknowledge reply message contains the requestId from the reply
message being acknowledged. This will enable the server to discard
entries from its history.
– The arrival of a requestId in an acknowledgement message will be
interpreted as acknowledging the receipt of all reply messages
with lower requestIds, so the loss of an acknowledgement
message is harmless.
•  Although the exchange involves an additional message, it need not
block the client, as the acknowledgement may be transmitted after
the reply has been given to the client. However it does use processing
and network resources.
Distributed systems by Patrick ndungu 14
b) Remote Procedure(Function) Call (RP/FC)
- In a remote procedure call (RPC- Communication),
- a process on the local system invokes a procedure on a remote
system.
- RPC is atomic i.e. carried out once (completely) or not at all (the operation will be
aborted)
- can be used to allow a process in one computer in a network, to invoke a
procedure (function), in another process executing in another computer
network.
HOW?
- A client stub marshal,
- server stub unmarshal,
- server marshal, and
- client stub unmarshal,
a) marshalling"
- refers to the process of converting the data or the objects into a byte-stream,
and
b) "unmarshalling"
- is the reverse process of converting the byte-stream back to their
original data or object.
- The conversion is achieved through "serialization". Distributed systems by Patrick
ndungu 15
b) Remote Procedure Call (RPC)
• In RPC,
– Procedures/function in processes on remote computers can be called as if
they are procedures in the local address space.
• The underlying RPC system :- then hides important aspects
of distribution;-
– including the encoding and decoding of parameters and results,
– the passing of messages and the preserving of the required
semantics for the procedure call.
– This approach directly and elegantly supports client-server computing with
servers offering a set of operations through a service interface and clients
calling these operations directly as if they were available locally.

– A procedure/subroutine/function is defined as a closed sequence of instructions that


is entered from, and returns control to, an external source.
–  A procedure call, also known as a function call or a subroutine call is the invocation
of a procedure. A local procedure call and an RPC behave similarly same for
differences in semantics. Distributed systems by Patrick ndungu 16
Remote Procedure Call (RPC) Cont…
• RPC is characterized by:-
a) RPC interface:
– a description of a set of remotely callable operations that are provided
by a server as sets of server routines that implement the interface
operations.
– RPC operations are realized through methods.
b) RPC objects:
– are either server instances or other resources that are operated on and
managed by RPC servers, e.g. databases, file servers etc.
– provide a means of object-oriented programming in the RPC
environment
•  An executable program includes
– a stub in compiled code that represents remote procedure code.
•  When program is run and procedure invoked, the stub forwards it to
client runtime for transmission across the network.
Distributed systems by Patrick ndungu 17
Remote Procedure Call (RPC) Cont…
The RPC Model

Distributed systems by Patrick


18
ndungu
Remote Procedure Call (RPC) Cont…
The RPC Model
•  Call a procedure on a remote machine
– Client calls: remoteFileSys->Read (“…..”)
– Translated into call on server:
•Implementation:
– (1) request-response message passing
– (2) “stub” provides glue on client/server

Distributed systems by Patrick


19
ndungu
Remote Procedure Call (RPC) Cont…
The RPC Model

Distributed systems by Patrick


20
ndungu
Remote Procedure Call (RPC) Cont…
• RPC Operation
– Implementation (cont’d)
o Client stub
• build message
• send message
• wait for response
• unpack reply
• return result
o Server stub
o create N threads to wait for work to do
o loop: wait for command
o decode and unpack request parameters
o call procedure
o build reply message with results
o send reply

Distributed systems by Patrick


21
ndungu
Remote Procedure Call (RPC) Cont…
• RPC Operation
i. The client calls a local procedure, called the client stub.
i. It appears to the client that the client stub is the actual server procedure that
it wants to call. The purpose of the stub is to package the arguments for the
remote procedure, possibly put them into some standard format and then
build one or more network messages. The packaging of the client's
arguments into a network message is termed marshaling. (marshalling)
ii. These network messages are sent to the remote system by the client stub. This
requires the client stub execute a system call (usually write or sendto) into the
local kernel to send the message.
iii. The network messages are transferred to the remote system i.e. kernel uses the
network routines (TCP or UDP) to send the network message to the remote host.
Note Either a connection-oriented or a connection-less protocol is used.
iv. A server stub procedure is waiting on the remote system for the client's request/ A

server stub receives the messages from the kernel. It unmarshals the arguments
from the network message and possibly converts them.
v. The server stub executes a local procedure call to start the function / invoke the
actual server function andDistributed
passing systems
it the arguments(
by Patrick pass the parameters) that it
22
received in the network messagesndungufrom the client stub.
Remote Procedure Call (RPC) Cont…
• RPC Operation
vi The server process executes the procedure and returns the result to the server
stub i.e when the server procedure is finished, it returns to the server stub with
return values.
vii The server stub converts the return values, if necessary, and marshals them into
one or more network messages to send back to the client stub.
viii The messages get transferred back across the network to the client stub.
ix The client stub reads the network messages from the local kernel using read or
recv.
x After possibly converting the return values, the client stub finally returns to the
client function.
This appears to be a normal procedure return to the client.
 The client and server routines use stub programs for the network
communication. The RPC routine hides all the details.
 This simplifies the creation of the program and isolates the network
code.
 Before these steps can be performed, the server must be started on the
appropriate host.
Distributed systems by Patrick ndungu 23
Remote Procedure Call (RPC) Cont…
• Summary of RPC Operation
The specific steps are:
1) The client calls the procedure. It calls the client stub, which packages the arguments into
network messages. Packaging is called marshaling.
2) The client stub executes a system call (usually write or sendto) into the local kernel to
send the message.
3) The kernel uses the network routines (TCP or UDP) to send the network message to the
remote host. Note that connection-oriented or connectionless protocols can be used.
4) A server stub receives the messages from the kernel and unmarshals the arguments.
5) The server stub executes a local procedure call to start the function and pass the
parameters.
6) The server process executes the procedure and returns the result to the server stub.
7) The server stub marshals the results into network messages and passes them to the
kernel.
8) The messages are sent across the network.
9) The client stub receives the network messages containing the results from the kernel
using read or recv.
10) The client stub unmarshals the results and passes them to the client routine
Distributed systems by Patrick ndungu 24
Remote Procedure Call (RPC) Cont…
 Implementation issues
 Stub generator
 generates stub automatically.
 For this, only need procedure signature:-
 types of arguments,
 return value.
 Generates code on client to pack message, send it off
 On server to unpack message, call procedure
 Input: interface definitions in an interface definition language
(IDL)
 Output: stub code in the appropriate source language (e.g.Java,…)
 Implementation Detail(failure handling)
  Client can’t locate the server
 Procedure returns error upon binding time
 Request and reply messages are acknowledged; do timeout and retransmit
 All requests are accompanied by a sequence number for the client
 Server maintains per client:
 Sequence number of last request
Distributed systems by Patrick ndungu 25
 Result generated by last request
Remote Procedure Call (RPC) Cont…
• RPC is normally considered to be at the presentation layer (layer 6). One of the
things it does is to provide the data conversion between hosts, so different
machine types can be used. Sun RPC uses the extended Data Representation
(XDR) standard to format data. Both TCP and UDP are supported

• Reasons for RPC popularity:


– Simple call syntax
– Familiar semantics
– Its specification of a well-defined interface - supports compile time type
checking among others.
– Ease of use
– Generality
– Efficiency due to rapid communication
– Can be used as an IPC mechanism for both across machines and within a
given machine.
Distributed systems by Patrick ndungu 26
Remote Procedure Call (RPC) Cont…
RPC Model Cont…
•Similar to ordinary procedure call model in the following ways:
a. Caller places arguments to the procedure
b. Control transferred to sequence of instructions
c. Procedure executed in a new execution environment
d. Control returns to the caller.
•In RPC however, the procedure may be local or remote
• RPC uses message passing scheme for information exchange
 
•RPC Procedure Parameters
–  Procedure parameters include:
• Process (threads)
• Arguments
• Message semantics
• Callable operations(methods)
• Parameters can be passed by copying into a message or by passing pointers in case
of shared memory.
27
Remote Procedure Call (RPC) Cont
Transparency of RPC
– Reply message contains result of procedure execution.
Transparency of RPC
 Both local and remote procedure calls should be (effectively) indistinguishable
to programmers
 This requires:
i. Semantic transparency
 Control information for coordination and error handling
ii. Syntactic transparency
 Data format and signal levels
What differentiates remote from local PC?
 Procedure executed in a different environment
 More prone to failures
 Consumes more time
 These makes semantic transparency more difficult to implement
28
Remote Procedure Call (RPC) Cont

Implementing RPC Mechanisms


 Based on stubs concepts that provides a normal procedure call
abstraction by concealing from the programs interface underlying RPC
system.
 Has 5 elements:
– The client:- Initiates request for a service
– The client stub:- marshals (Packages by encoding /decoding and encapsulating
request for a service data)
– The RPC Runtime:- Provides communication mechanism of send and receive
– The server stub:- marshals (Packages by encoding /decoding and encapsulating
service data)
– The server:- Executes request and provides service.

Distributed systems by Patrick


29
ndungu
Remote Procedure Call (RPC) Cont

Implementing RPC Mechanisms Cont..


•Client and Server Stubs

Distributed systems by Patrick


30
ndungu
Remote Procedure Call (RPC) Cont
Steps of a Remote Procedure Call
a. The client procedure calls the client stub in the normal way.
b. The client stub builds a message and calls the local OS.
c. The client’s OS sends the message to the remote OS.
d. The remote OS gives the message to the server stub.
e. The server stub unpacks the parameters and calls the server.
f. The server does the work and returns the result to the stub.
g. The server stub packs it in a message and calls its local OS.
h. The server’s OS sends the message to the client’s OS.
i. The client’s OS gives the message to the client stub.
j. The stub unpacks the result and returns to the client.

The net effect of all these steps is to convert the local call by the client procedure
to the client stub, to a local call to the server procedure without either client or
server being aware of the intermediate steps.

Distributed systems by Patrick


31
ndungu
Remote Procedure Call (RPC) Cont
Implementing RPC Mechanisms

Distributed systems by Patrick ndungu 32


Remote Procedure Call (RPC) Cont
Implementing RPC Mechanisms Cont..
 simple example,
 Consider a remote procedure, add(i, j), that takes two integer parameters i and j and
returns their arithmetic sum as a result.

33
Implementing RPC Mechanisms Cont..
Marshalling Arguments and Results
– Marshalling – encoding and decoding data into/from stream form before and
after transmission
– Must reflect the structures of all types of program objects used in the
concerned language
– Are of two types:
i. Those provided by RPC software – supports pre-defined data types
ii. User-defined –for supporting user-defined data types
Server Management
• Call packets and result packets are passed from RPC to RPC until they reach
their destination
•Server implementation
– Stateful servers – stores clients information from one RPC to the next
– Stateless servers- does not maintain any client state information
Server Creation
• Instance-per-call server – call duration
• Instance-per-session servers
34
• Persistent servers
Implementing RPC Mechanisms Cont..
• Server Management - Examples
– Stateful Servers
• Read(fid, n, buffer) – get n bytes of data from file whose Id is fid into the
buffer named buffer.
• Write(fid, n buffer) - the server takes n bytes of data from the specified
buffer, writes into fid at the byte position currently addressed by read-
write pointer.
– Stateless Servers
• Read(filename, ,position,n, buffer) – get n bytes of data from file whose Id
is filename into the buffer named buffer.
• Write(filename,position, n buffer) - the server takes n bytes of data from
the specified buffer, writes into fid at the byte position position.

35
Implementing RPC Mechanisms Cont..
• Parameter-Passing-Semantics
– Call-by-value – parameters copied onto a message
– Call-by-reference – passing pointers is meaningless because of the differences
in address spaces. Only possible incase of shared memory
• Call Semantics
– Failures during message passing may affect the RPC, hence the need for call
semantics:
• Possibly Or May-Be Call Semantics – caller continues after a time-out
• At-Least-Once Call Semantics
• Exactly-Once Call Semantics

36
Implementing RPC Mechanisms Cont..
Failure Handling
•RPC failures can be difficult to handle. There are four generalized types of failures that can
occur when an RPC call is made:
i. The Client’s request message is lost.
• If the client’s message gets lost then the client will wait forever unless a time out
error detection mechanism is employed.
ii. The client process fails while the server is processing the request.
• If the client process fails then, the server will carry out the remote operation
unnecessarily.
iii. The sever process fails while servicing the request.
iv. The reply message is lost.
• If the operation involves updating a data value then this can lead to a loss of data
integrity.
• Furthermore, the server would generate a reply to client process that does not exist.
This must be discarded by the client’s machine. When the client re-starts, it may be send
the request again causing the server to execute more than once.
• A similar situation arises when the server crashes. The server could crash just prior to
the execution of the remote operation or just after execution completes but before a
reply to the client is generated. In this case, clients will time-out and continually
generate retries until either the server restarts or the retry limit is met.
 
37
Remote Procedure Call (RPC) Cont
Communication Protocols for RPCs:-
i)  The Request Protocol – (the R Protocol)
 Nothing to return
 Acknowledgement not required
 Caller continues with execution after the call
 Provides May-Be-Call Semantics
 This RPC is asynchronous
 E.g. A time server node in a DS may send synchronization messages every T
seconds so losing a message or two is acceptable
2.
ii) The Request/Reply Protocol – (the RR Protocol)
– Suitable for simple RPCs – all arguments/results fit in a single packet buffer and has
less transmission time
– Based on implicit acknowledgement
– Has no failure-handling capabilities
– Uses timeouts-retries technique to handle failures, hence provides at-least-once
call semantics
– Can support exactly-once semantics if the server keeps records of replies. 38
Remote Procedure Call (RPC) Cont
Communication Protocols for RPCs cont…:-
iii) The Request/Reply/Acknowledgement Reply Protocol –(the RRA
Protocol)
 
Client acknowledge the receipt of reply messages and the server uses this to
delete reply information from its cache
Since acknowledgement messages may get lost, both messages (the reply and the
acknowledgement) have identifiers for matching purposes
• Exercise:
– Is there RARA Protocol? (Request, acknowledge, reply, acknowledge)
•Complicated RPCs
– Involving long duration
• Periodic probing of the server by the client
• Periodic generation of acknowledgement by the server
–Involving arguments/results that are too large
• Use several physical RPCs to handle one large logical RPC
• Use multidatagram messages
39
Remote Procedure Call (RPC) Cont

Server Binding
– Client stub needs to know the location of the server through binding
– Servers “export‟ their operations and clients “import‟ via the RPC Runtime.
– Interface names (type and instance) are used for servers
– Servers can be located by use of “broadcasting‟ or “Binding Agent‟.

RPC in Heterogeneous Environments

•Three types of heterogeneity to be addressed:


a) Data representation – how the particular machine represents data. E.g. 1‟s
or 2‟s compliments (syntax)
b) Transport protocol – making the RPC system independent of the protocol
c) Control protocol – must be independent of the control information in each
transport packet
•Delay decisions until bind time 40
Remote Procedure Call (RPC) Cont
• Light Weight RPC
–  Recall the differences between Monolithic-kernel operating systems (PCs) and
microkernel operating systems (DS). The two types of communication traffic
(cross-domain and cross-machine)
– The LRPC is a communication facility designed and optimized for cross-domain
communications
– Uses simple control/data transfer and simple stubs.
– Designed for concurrency
• Performance optimization
 Concurrent access to multiple servers – using threads, early reply approach or
call buffering approach
 Serving multiple request simultaneously
 Reducing per call workload of servers
 Reply caching of Idempotent remote procedures
 Proper selection of timeout values
 Proper design of RPC protocol specification
41
Remote Procedure Call (RPC) Cont
• Assignment
• Case Study: Sun RPC
– Search the Internet for typical RPCs and document their stub structures and
communication features. Main task is to write programs for the client/server
stubs and client/server RPC runtime

 Sun RPC
– Uses automatic stub generation but there is an option for manually writing
them
– RPC Language (RPCL) – an application's interface definition (IDL) which is an
extension of the Sun XDR (external data representation)
– Question?
• Do we use java or C++ for the case studies?

42
c) Remote Method Invocation (RMI)

Introduction
– Remote method invocation (RMI) strongly resembles remote
procedure calls but in a world of distributed objects.
• With this approach, a calling object can invoke a method in a
remote object.
•  Similar to RPC, the underlying details are generally hidden
from the user.
• RMI implementations may, though, go further by supporting
object identity and the associated ability to pass object
identifiers as parameters in remote calls.

•  They also benefit more generally from tighter integration into


object-oriented languages.
43
Remote Method Invocation (RMI) Cont..

Introduction
•The commonalities between RMI and RPC
– They both support programming with interfaces(RPI),
with the resultant benefits that stem from this approach.
– They are both typically constructed on top of request-
reply protocols and can offer a range of call semantics
such as at-least-once and atmost-once.
– They both offer a similar level of transparency – that is,
local and remote calls employ the same syntax but
remote interfaces typically expose the distributed nature
of the underlying call, for example by supporting remote
exceptions.
44
Remote Method Invocation (RMI) Cont..

Remote and Local Method Invocation

•Overview of the Session


•Introduce the architecture of Java RMI
–Explain how Java RMI works
–Build a Java RMI Distributed application 45
Remote Method Invocation (RMI) Cont..

 The Goal of RMI


 Object oriented RPC Mechanism
 To extend the Java Object model to support programming with distributed
Objects
 The intention is to make distributed programming as easy as standard Java
programming
o Focus on application logic not distribution

  A Simple Overview
 Java RMI allows one Java object to call methods on another Java object in a
different JVM (Java virtual machine)
 A Java Virtual Machine (JVM) enables a set of computer software programs
and data structures to use a virtual machine model for the execution of other
computer programs and scripts

46
Remote Method Invocation (RMI) Cont..
A Java Virtual Machine (JVM) enables a set of computer software programs and
data structures to use a virtual machine model for the execution of other computer
programs and scripts

47
Remote Method Invocation (RMI) Cont..

• RMI distributed application


 The Java Remote Method Invocation (RMI) system
 allows an object running in one Java virtual machine to invoke
methods on an object running in another Java virtual machine.
 Thus, RMI provides the mechanism by which the server and the client
communicate and pass information back and forth.
 - Such an application is sometimes referred to as a distributed object
application.
 RMI applications often comprise two separate programs,
• A server and a client.
– A typical server program creates some remote objects, makes
references to these objects accessible, and waits for clients to invoke
methods on these objects.
 A typical client program obtains a remote reference to one or more
remote objects on a server and then invokes methods on them.48
Remote Method Invocation (RMI) Cont..

 Java RMI functions


 Locate remote objects
 Applications can use various mechanisms to obtain references to remote
objects.
 register its remote objects with RMI's simple naming facility, the RMI
registry Or
 pass and return remote object references as part of other remote invocations.

 
 Communicate with remote objects.
Communication between remote objects are handled by RMI.
 Load class definitions for objects that are passed around.
provides mechanisms for loading an object's class definitions
as well as for transmitting an object's data
49
Remote Method Invocation (RMI) Cont..
• RMI distributed application

– RMI distributed application uses the RMI registry to obtain a reference to a remote object

– The server calls the registry to associate (or bind) a name with a remote object

– The client looks up the remote object by its name in the server's registry and then invokes a method on it

– RMI system uses an existing web server to load class definitions, from server to client and from client to
server, for objects when needed 50
 
Remote Method Invocation (RMI) Cont..

 Java RMI functions Remote Interfaces, Objects and Methods


– Java RMI distributed application comprises of
Interfaces
 The interfaces declare methods
Objects
 The objects are operated on by invoked methods to provide
services to the client
Classes
 The classes implement the methods declared in the interfaces

51
Java Remote Method Invocation
Implementation
 Key components/class definitions in RMI:
 Name server (provides location information of
services)
 Interface definition of server code
 Implementation of server
 Implementation of client

Distributed systems by Patrick


52
ndungu
Java Remote Method Invocation
Implementation(Example: )
date server interface definition
import java.rmi.*;
import java.rmi.server.*;
import java.util.Date;
public interface DateServer extends Remote {
public Date getDate() throws RemoteException;
}

Distributed systems by Patrick


53
ndungu
Java Remote Method Invocation
Implementation(Example: )
RMI Server Code
import java.rmi.*;
import java.rmi.server.*;
import java.util.Date;
public class DateServerImpl
extends UnicastRemoteObject implements DateServer {
public DateServerImpl() throws RemoteException { }
public Date getDate() {
return new Date();
}
public static void main(String() args) {
DateServerImpl dateServer = new DateServerImpl();
Naming.bind(“Date Server”, dateServer);
}
}
Distributed systems by Patrick
54
ndungu
Java Remote Method Invocation
Implementation(Example: )
RMI Client Code
import java.rmi.Naming;
import java.util.Date;
public class DateClient {
public static void main(String[] args) {
DateServer dateServer =
(DateServer)Naming.lookup(“rmi://” + args[0] +
“/Date Server”);
Date when = dateServer.getDate();
System.out.println(when);
}
}

Distributed systems by Patrick


55
ndungu
Java Remote Method Invocation
Implementation(Example: )
NOTE
o RMI support code keeps track of who is actively
using the remote objects.
o How?
o Pings periodically to check whether client is alive
o While client is alive:
o Keeps a pointer to the object in a table (not really use the
object, but just hang on to a reference)

Distributed systems by Patrick


56
ndungu
Remote Method Invocation (RMI) Cont..

Distributed Programming
 Java RMI is interface based
A remote object (or distributed service) is specified by its interface
 “interfaces define behaviour and classes define implementations”
 Termed Remote Interfaces

57
Remote Method Invocation (RMI) Cont..

RMI implementation
 RMI passes a remote stub for a remote object
 The stub acts as the local representative, or proxy, for the remote
object and basically is, to the client, the remote reference.
 The client invokes a method on the local stub, which is responsible
for carrying out the method invocation on the remote object
 A stub for a remote object implements the same set of remote
interfaces that the remote object implements.
 This property enables a stub to be cast to any of the interfaces that
the remote object implements
 However, only those methods defined in a remote interface are
available to be called from the receiving Java virtual machine.

58
Remote Method Invocation (RMI) Cont..

RMI implementation cont…


 From RPC to RMI

59
The RMI Architecture
Remote Method Invocation (RMI) Cont..

RMI implementation cont…


The RMI Architecture

60
Remote Method Invocation (RMI) Cont..

Essential characteristics RMI


 Full integration with object-oriented programming language
 Ability to exploit objects, class and inheritance
 Added benefits from exploiting built in (object-oriented) approaches to, for
example, exception handling
 From procedure calling to method invocation
 Added expressiveness of supporting object references
 More sophisticated options for parameter passing
 Pass by (object) reference
 Pass by value (exploiting serialisation)
Often integrated with code (object) mobility
E.G. Use of class loading in RMI
Distributed Programming (cont.)
•Before you invoke a method on a remote object you need a reference to this object
– Look for an object with a specific interface type
•There are many ways to find this information;
– Discovery Protocols
– Naming Service e.g. RMI Registry 61
Remote Method Invocation (RMI) Cont..

The RMI Registry


The RMI Registry is a naming service
Separately Running service
Initiated using Java‟s “rmiregistry” tool
Server programs register remote objects
Give the object a name it can be found using
– Client programs lookup object references that match this
service name
Registry names have a URL format
– rmi://<hostname>:<port>/<ServiceName>
E.g. rmi://localhost:1099/CalculatorService
E.g. rmi://194.80.36.30:1099/ChatService
62
Remote Method Invocation (RMI) Cont..

The RMI Registry Interface

63
Remote Method Invocation (RMI) Cont..

Stubs and Skeleton Layer


 Stubs and skeletons are generated from the remote interface
Using the “rmic” Java tool
 Stub communicates with a skeleton rather than the remote object
– This a Proxy approach
– Marshalls the parameters and results to be sent across the wire
– After java 1.1 skeletons were made obsolete and RMI now uses reflection to direct a
request to an object

64
Remote Method Invocation (RMI) Cont..

Parameter Passing
 Parameter Passing in Java RMI is different from standard
Java
Reminder: In Java, primitives are passed by value, Objects are
passed by reference
 In Java RMI
Objects and primitives are passed by value
Remote objects are passed by reference
 You must be aware of the differences!
Otherwise you'll generate logical bugs that are difficult to
identify

65
Remote Method Invocation (RMI) Cont..

Parameter Passing 2
 RMI-Pass by Value Client
All ordinary objects and primitives are serialised and a copy is
passed
Any changes to the copy do not affect the original
It is your job to ensure your Objects can be serialised!

• RMI-Pass by Reference
Remote Object is the parameter, a stub (reference) is sent the
stub is used to modify the object, the original object is modified
 
66
Remote Method Invocation (RMI) Cont..

Designing and Implementing the Application Components


 In general terms:
Determine your application architecture
 Include which components are local objects and which components are
remotely accessible
Define the remote interfaces.
 A remote interface specifies the methods that can be invoked remotely by a
client.
– Implement the remote objects.
 Remote objects must implement one or more remote interfaces
– Implement the clients
 Clients that use remote objects can be implemented at any time after the
remote interfaces are defined

67
Remote Method Invocation (RMI) Cont..
Building a Java RMI system
– An RMI system must be composed of the following parts:

Step 1 - Define the Remote Interface


 Declare the methods you'd like to call remotely
• This interface must extend java.rmi.Remote
• Each method must declare java.rmi.RemoteException in its throws clause
• You can have multiple remote interfaces

 Remember about parameter passing


• Remote objects must be passed as remote interface types 68
• Local objects must be serializable
Remote Method Invocation (RMI) Cont..

•Example ChatServer Interface


public interface ChatServer extends java.rmi.Remote {
}
public void login(String name, String password)
throws java.rmi.RemoteException;
public void logout(String name)
throws java.rmi.RemoteException;
public void chat(String name, String message)
throws java.rmi.RemoteException;
}

Step 2 - Implement the remote service


Your class must implement the Remote interface
Extend this class with UnicastRemoteObject
–Must provide a constructor that throws a RemoteException.
–Call super() in the constructor
•This activates code in UnicastRemoteObject that performs the RMI linking and
remote object initialization. 69
Remote Method Invocation (RMI) Cont..

Example Remote Object (ChatServiceImpl)


 public class ChatServerImpl
extends java.rmi.server.UnicastRemoteObject implements
ChatServer {
public ChatServerImpl() throws java.rmi.RemoteException{
Super();
}
public void login(String name, String pass) throws java.rmi.RemoteException { //
Method Implementation
}
public void logout(String name) throws java.rmi.RemoteException{
// Method Implementation}
public void chat(String name, String msg) throws java.rmi.RemoteException{
// Method Implementation
}
Distributed systems by Patrick
70
ndungu
Remote Method Invocation (RMI) Cont..

Step 3 – Generate Stubs & Skeletons


 Generate the Remote Interface stub
This stub contains information that allows it to connect to a remote object,
which contains the implementation of the methods
 RMI provides a tool called rmic to generate stubs
Use rmic on the remote object
 e.g. rmic ChatServerImpl
The files: *impl_Stub.class and *impl_Skel.class will be created

Distributed systems by Patrick


71
ndungu
Remote Method Invocation (RMI) Cont..
 Step 4 – Create the Server
  The server is a Java application
Creates one or more instances of remote objects
Binds at least one of the remote objects to a name in the RMI registry
 Uses the Naming.rebind() operation
Example Chat Server
public class ChattingServer {
public ChattingServer() {
try {
ChatServer c = new ChatServerImpl();
Naming.rebind("rmi://localhost/ChatService", c);
}
catch (Exception e) {
System.out.println("Server Error: " + e);
}
}
public static void main(String args[]) {
//Create the new Calculator server
new ChattingServer();
}
} 72
Remote Method Invocation (RMI) Cont..
 Step 4 – Create the Server Cont..

73
Remote Method Invocation (RMI) Cont..
Step 5 – Create the Client
 Get a remote reference by calling Naming.lookup()
Remember - Lookup by service name
 Receives a stub object for the requested remote object
Loads code for the stub either locally or remotely
 Invoke methods directly on the reference
Much like on standard Java objects

74
Remote Method Invocation (RMI) Cont..
Example Chat Client
public class calculatorclient {
public static void main(String[] args) {
try {
// Get a reference to the remote object through the rmiregistry
ChatServer c = (ChatServer)
Naming.lookup("rmi://localhost/ChatService");
// Now use the reference c to call remote methods
c.login(“Chas”,”*****”);
c.chat(“Chas”, “Hello”);
// Catch the exceptions that may occur - rubbish URL, Remote
exception
} catch (RemoteException re) {
System.out.println("RemoteException“+re);
}
}
}
75
)
Remote Method Invocation (RMI) Cont..

Java RMI Advanced Features


a. Serialisation
b. Callbacks
c. Remote Activation
a)Serialisation
 To pass user created objects as parameters in RMI they must be serialisable
o This is easy in Java – simply make the class implement the Serializable
interface
o If you want to optimise the serialisation you can override the methods of
serializable with your own implementation e.g.
ObjectInput(Output)Stream
 Transforming an Object in a stream of bytes
o Can be sent across the network

76
Remote Method Invocation (RMI) Cont..
b) Callbacks
 In many applications the server may want to callback the
client
All messages in the chat system are displayed on a central
server
You could change the server to callback every client with
each new chat message allowing the message to be displayed
on each client
 Callbacks are just a reverse RMI
You create a remote object on the client and pass this
reference to the server, who can invoke it directly
–  Using Callbacks in Chat
• See the diagram below

77
Remote Method Invocation (RMI) Cont..

 c) Remote Activation


 Server hosting remote objects continuously execute
This wastes system resources
 Ideally, a Remote Object would be dormant until it was
invoked
Java RMI Remote Activation provides this process
Rather than a server program, you register each object with the
rmid daemon
 Unfortunately this is complex to program!
• See on-line tutorials on web site to find out how to do it
Ask the demonstrators

78
The END

Q&A

THANKS

Distributed systems by Patrick


79
ndungu

You might also like