Download Block 3 - Unit 2

Block 3 - Unit 2
IPC in Non Shared Memory (II)
There are TWO sections in this Unit.
i.
RPC and Java’s RMI Mechanism
ii.
Using Java’s RMI Mechanism
Bacon Chapter 16 required
Section 1: RPC and Java’s RMI Mechanism
RPC – Remote Procedure Calls
Objectives: On completion of this section you should be able to:
1. Describe how issues related to concurrency can be separated from issues related to
distribution;
2. Distinguish between message passing and RPCs;
3. Describe the RRA protocol for an RPC implemented on an unreliable transport service;
4. Describe the problems that arise when a client, server or network crashes and when the
network becomes congested, and explain how the RPC protocol deals with the problems;
5. Explain the difference between a transparent and non-transparent approach to
integrating RPCs into a programming language;
6. Explain why an RPC is not a sensible mechanism for all types of communication;
7. Explain the issues related to the naming of objects in a distributed IPC system.
8. Explain Java’s RMI mechanism for implementing an RPC system of distributed IPC;
9. Describe the important classes in Java’s RMI packages;
10. Compare the RMI model of distributed IPC with the client–server model.
Procedures and Procedures Calls
Points to be noted
1. An application can consist of several procedures (or methods , in OO
terminology).
2. There is a single thread of control as one procedure calls another.
The calling process stops when the invoked process starts execution. Only after the
completion of the later which includes returning data results, the former resumes.
In OOP, Typically, variables hold references to objects rather than the objects
themselves, but hold the values of primitive data types directly.
Passing of arguments in procedure are passed by reference , while the values of
primitive data types are passed by value .
RPC–language integration (replaces Bacon, Section 15.8)
The advantage of an RPC system is that, when integrated into a conventional
programming language that uses procedure calls, the system developer can use the
familiar procedural calling mechanisms to program in a distributed setting. In other
words, the system developer does not need to know the details of how the (remote)
call being made in the local application is sent to a process on another machine,
carried out on that machine, and the result returned to the local application. All this is
automatically carried out by the underlying implementation.
Distribution transparency means should it be indistinguishable from a local call as far
as the application program is concerned. If it is to be indistinguishable, the compiler
needs to detect that the call is remote and produce the code that will find the target of the
call, and then use the underlying mechanisms that carry out the communication with the
remote machine. These underlying mechanisms usually involve the use of a stub on
both the local (client) and remote (server) machines. This involves the marshalling and
unmarshalling of arguments and return values.
Marshalling arguments is the activity of transforming the arguments of a procedure
call into a form suitable for transmission via a network. The arguments of a procedure
call are structured within the main memory and can consist of data values of various
types and references to them. Since network communication is usually the transmission
of a stream (sequence) of bytes, the procedure’s arguments have to be ‘flattened’ or
marshalled into a stream of bytes. On arrival, the stream of bytes must be reformed (i.e.
unmarshalled ) into their original structure, and, to do this, information about the
original structure must be transmitted in addition to the data.
The alternative to distribution transparency recognizes that remote calls are likely to
take longer than local calls and also involve additional types of failure (e.g. network
failure). Some languages, therefore, provide special syntax for a remote call so that the
application programmer can take such eventualities into account.
2 Security managers - Similar to the security systems that control applets, RMI security
managers control what remote objects and their clients can do. The developer of RMI
applications needs to know about them since both client and server applications must
start by creating and installing a security manager:
System.setSecurityManager(new RMISecurityManager());
Q. In what sense are concurrency and distribution issues separated when processes
can be created dynamically?
Concurrency is achieved by having two processes: the parent and the child it creates
using the '02, primitive. Distributed programming is achieved through the child process
that invokes the remote operation. Such a child process is called a distributed sequential
process .
Q. What is a remote procedure call RPC ?
A remote procedure call (RPC) is a call to a procedure located on a machine that
is different (remote) from the machine from which the call was made.
Q. How does a remote procedure call differ from a message passing scheme?
A message passing scheme may be asynchronous. An RPC is always synchronous, in the
sense that the calling procedure, having invoked a procedure on a remote machine, waits
for the result before continuing with its processing.
RPA Request–reply–acknowledge protocol and RARA protocol
RRA is where one process (the caller process) sends a message ( request) to another
process (the receiver process), the called system (server) sends a reply (which also acts as
an acknowledgement that the original message was received), and the calling system
(client), on receipt of the reply, sends an acknowledgement to confirm receipt of the
reply.
RARA is similar to RRA but an additional explicit acknowledgement of the receipt of the
original message is sent by the called system.
An orphan
An orphan is a remote procedure call whose client (i.e. the node making the call) crashes
after the request has been sent. That is, there has been client failure with the result that
the client is not able to deal with any reply generated by the orphan.
The major problem is that there may have been state changes in the server (i.e. the node
containing the called procedure) or other nodes as the result of acting on the original
request. On restart, the client is likely to retry the RPC with the state of the server
different from its state when the original request was made. When the client restarts, it
will be the application that decides whether or not to retry the RPC. The RPC service sees
only a request for a remote procedure call to be made and does not know that this is a
repeat request. Therefore, it will view this request as a new one and generate a new RPC
identifier.
Difference between the client–server model and an object model like RMI
The object model works within the OO paradigm, in which services are obtained by
sending messages (method invocations) to objects. In the client–server model also works
on the basis of a client sending messages to a server. However, in this case the messages
are not in the form of method invocations, but conform to another protocol agreed
between client and server, such that the server can invoke methods on its encapsulated
objects on behalf of the client. This does mean, however, that the client and the server
have to include code to transform method invocations into data streams and vice versa in
order to communicate.
Q. Why is RPC communication not particularly well suited to real-time systems requiring
massive amounts of data to be transferred (e.g. video streams)? (Study Question 8)
RPC communication requires all the data to be received before the operation commences
and is likely to have some maximum data size well below that required by the
application. Also, for some systems in which the data to be transferred is simply a (large)
stream of bytes, there is no requirement for sophisticated argument marshalling and,
indeed, to have such a mechanism would slow up the transmission.
Section 2: Using Java’s RMI Mechanism
Objectives
On completion of this section you should be able to:
1 explain Java’s RMI mechanism for implementing an RPC system of distributed IPC;
2 describe the important classes in Java’s RMI packages;
3 describe the main components of a small application which uses RMI;
4 compare the RMI model of distributed IPC with the client–server model;
5 use the IDE to run RMI applications;
6 explain the role of the security manager.
The Remote Object
One of the fundamental ideas about Java objects is that, when defining a class, it is often
a good idea to do so in two parts: an interface and an implementation. A Java interface
contains the signatures of the public methods that can be invoked on an object of the
class. The implementation contains the bodies of the public methods together with any
fields and private methods that may be required. This separation into interface and
implementation has many advantages. One of these is that a client (a user of a remote
object) needs only to know about the interface of the remote object’s class whereas the
server (the implementor of the remote object) needs to know about both the interface and
the implementation of the class.
The second idea is that an object is created only when a Java program (strictly, a Java
thread) is executed. An object exists in main memory until either it is no longer
referenced (in which case the garbage collector reclaims the storage it occupied) or the
thread that created it ceases execution. Thus, there must be a thread in existence if an
object is to exist. Thus, when there is a remote object, the client must be aware of the
object’s interface (to ensure that the remote method invocations made by the client can be
checked by the compiler). Of course, the implementations of these methods must be
known to the server because it is the server host that executes the methods.
This means that we shall develop classes for remote objects in the form of an interface
plus an implementation. Both are required by the server (you can’t have an
implementation without the associated interface) but only a copy of the interface is
required by the client.
The RMI Registry
The RMI registry is a Java program named rmiregistry, which when it is executing,
maintains a list of references to objects that have been registered with it. An object is
registered by a server using the rebind method from the class Naming (part of the
java.rmi package). The first argument of the rebind method is a String that specifies: 1
where the registry is located — by quoting the IP address of its host ( localhost can be
used when the registry is on the same host as the server) and the port on which the
registry listens for communications (by default this is 1099, and can be omitted);
2 a programmer defined name by which clients can gain access to the object. The second
argument is a reference to the object itself. There is an alternative method to rebind
known as bind. The difference between them depends upon whether or not an object with
the same string name already exists within the registry when these methods are invoked.
If an object already exists, rebind will replace its reference with a reference to the new
object whereas bind will throw an exception.
It is important to recognize that the RMI registry is a non-persistent scheme. The
registry forgets all its contents when the rmiregistry program stops.
The stub object
An important point to note is that the client process does not communicate directly with
the remote object. Instead, there is a stub object on the client's host that acts as a proxy
for the remote object. Therefore, whenever the client invokes a method on the remote
object, the message is sent to the stub, which is responsible for marshalling the arguments
and converting the message
into a stream object capable of being transmitted to the remote host using Java’s socket
and stream client–server mechanism. Once the message reaches the remote host, it is
transformed into a normal method invocation applied to the remote object.
Any response (return value) from the remote object follows the reverse procedure. The
stub on the client converts the return message into a value that is returned to the object
that made the original remote call.
Summary of Unit 2
You have now seen two models of IPC: the client–server model (in the previous unit)
and the object model (in this unit).
In Section 1 you learned about synchronous remote procedural calls (RPC). In
Section 2 you learned how to use Java’s version of RPC, called RMI (remote method
invocation), and that RMI is of a higher level of abstraction than the client–server
mechanism using sockets and data streams. You also saw that RMI falls a little short
of the complete object model.
Please Read all study material, exercises, SAQs, Bacon and block material.