In distributed systems, processes communicate by passing messages. The inter process communication is necessary for distribution of computational load and sharing of resources. At each process the received messages are initially stored in volatile storage, and are processed later. When a process fails, it losses contents of the volatile store, thereby losing the received messages. These are called lost messages. It also looses the effect of processes. To avoid inconsistencies within the system , a non failed process needs to resend the messages lost by a failed process(ozalp babaglu 1993 pp.67-72). Also, it must discard messages it has received from the failed process, because the sender has lost knowledge of such messages. These messages are termed as orphan messages and the receiving process is called an orphan process. The recovery mechanisms aims at discarding orphan messages. The process of restoration of state of a process to an earlier state, is termed as process rollback. Thus the effect of the failure is not limited to the failed process alone due to message dependencies.
Message passing systems have been called “shared nothing systems because the message passing abstraction hides underlying states changes that may be used in the implementation of sending messages(Andrew Nelson 1984 p 39-59).
Message passing model based programming languages typically define messaging as the ( usually asynchronous) sending (usually by copy) of a data item to a communication endpoint ( Actor, process, thread, socket , etc). Such messaging is used in web services by SOAP . This concept is the higher level version of a datagram except that messages can be larger than a packet and can optionally be made reliable, durable, secure , and/or transacted(Birrrell et al 1994 PP.33-49).
Messages are also commonly used in the same sense as a means of interprocess communication , the other common technique being streams or pipes, in which data are sent as a sequence of elementary data items instead ( the higher- level version of a virtual circuit). In some very well defined and controlled application environment, a message may not need message identifies at all. The interaction between agents may be strictly defined that threes no need to specify the type of message being sent because the receiver is already expecting it. Suppose for example that we have two chess playing agents talking to each other. Assuming that they both always make valid moves and that they both continue to play until checkmate result, the only kind of message they need to exchange is the one that contains the next move that they want to make, with an optional argument that indicates if the move result in a “check” or “checkmate|”. In this case there's no need for message identifiers the message can just contain the chess players moves.
Utilization of Message Passing
In a sense, every week network standard and protocol discussed so far can be boiled down to some form of message passing. HTTP,SSL, even low level network protocols like the TCP/IP are protocols built around some form of message passing. When we speak of message passing in this chapter, however we are talking about message passing that is done explicitly by the application programmer. While these other protocol are built around some kind of message passing protocol, that level of protocol is hidden from the developer by an API of some kind. For example, SSL is utilized by an application programmer through a class library , where method calls on SSL related objects are automatically broken down into SSL complaint messages. Likewise . incoming SSL “messages” are processed and mapped into new data objects and methods calls on SSL objects(ozalp Babaoglu 1993 pp.67-72). This is what makes these complicated but powerful protocols so useful: the applications programmer doesn't need to know the details of the protocol at the lower level .
While message passing is not as sophisticated and as robust as the distributed objects, it is very simple to implement using the java I/O package. The reason of the two approaches are very different. The distributing objects extends an application across the network by making its objects appear to be spread across the host in our virtual machine, massage passing serves a much simpler role , defining a simple communication protocol for sending data, this also avoids the communication overhead involved in using most distributed objects scheme and this does not require any special network protocols. So we can say the message passing is a very useful and necessary tool, particularly in the following situations: communication needs are relatively simple in nature(Dasgupta Leblanc Spafford 1985 pp.89)
The scope of your system is limited so that rapid implementation takes precedence over sophistication and flexibility of design
Special network protocols need to be avoided ( e.g. parts of the system needs to be operate behind a firewall)
Remote object protocols(e.g. an applet in a browser that doesn't support RMI or COBRA) simply aren't available.
Transaction throughout is crucial.
Remote Procedure Call
This system abstract the communication interface to the level of a procedure call. Thus instead of application programmers having to deal directly with sockets, the programmer has the illusion of calling a local procedure when , in fact the arguments of the call are packaged up and shipped off to the remote target of the call. Such RPC systems encode arguments and return values using some type of an external data representation (e.g. . XDR).
Remote procedure call , however does not translate well into distributed system objects systems where communication between program level objects residing in different address space is needed. In order to match the semantic of object invocation, distributed object system requires remote method invocation or RMI. In such systems , the programmer has the illusion of invoking a method on an object when in fact the invocation may act one remote object( one not resident in the callers address space).
Remote Procedure call system have been around since Andrew Birrell and Gred Nelson first proposed them in 1984. During the intervening 15years ,numerous evolutionary improvements have occurred in the basic RPC system, this has lead to improved system such as NCS2 that offers programmers more functionality or great simplicity. The common object request broker architecture from the object management group and Microsoft distributed common object model 4 are this evolutionary process latest outgrowths .(Birrell 2008: 39-59)
With the introduction of java developers kit release 1.1 a third alternative for creating distributed applications has emerged. The java remote methods invocation systems has many of the same features of the RPC systems, letting an object run in on java virtual machine make a method call on an object running in another , perhaps on a different physical machine. On the surface , the system is just another RPC mechanism much like CORBA and DCOM. But on a closer look RMI represent a very different evolutionary progression, one that results in a system that differs not just in detail but in the very set of assumptions made about the distributed systems in which it operates ,theses difference leads to differences in the programming model, capabilities and way the mechanisms interact.
Distributed computing Environment and RPC
DCE/RPC is a type of RPC that allows a software to accessible across multiple computers, working on multiple PCs making it looks like all the software is working on the same PC creating a smoke screen effect, this is what RPC does making itself look like a local procedure call. RPC makes it easier for users to complete a task i.e. programming without any knowledge of the network code. DCE/RPC is quite different from RPC itself, the services offered by DCE/RPC includes Cell Directory Service (CDS) and DCE's Distributed File System (DFS), while RPC refers to technologies such as ONC RPC (Open Network Computing Remote Procedure Call) which is a NFS that was originally created by Sun Microsystems. Another technology of RPC is XML-RPC.
Remote Object Invocation and Utilization
RMI is a way programmer using a java programming and development environment can write an object-oriented program, in which objects that are located on different computer in a distributed network. RMI is the java version of RPC, the difference is that RMI has the ability to pass more than one object along with a single request. The object can include data that will change the performance of a service in a remote PC. RMI has also been known to be called “moving behaviour” a name given by its creator Sun Microsystems, an example of RMI is when a customer logs their account details in an expense account, a java program communicates with customer using RMI, the computer connects to another computer using a java program in a remote computer that has details of the latest policy about the customer expense reporting.
In the response that will be sent back to the customer the program will send back an object associated method information that would enable that remote computer program to screen the user's account details, in a way that was consistent with the latest policy. This is an advantage to the business because it will help keep track of data, and the program updates itself with the new policies, so when accessed the latest details will be presented to the customer.
RMI has three layer it can be implemented in, they are Stub and Skeleton, transport layer and remote reference layer. A stub program in the client side of the client/server relationship, and a corresponding skeleton at the server end. The stub appears to the calling program to be the program being called for a service, sun uses the term “proxy” for stub. Remote reference layer has been known to behave differently depending on the parameters it passed by the calling program, e.g. this layer can determine the request is to call a single remote service or multiple remote programs as in a multicast. A transport layer on another hand sets up and manages the request, a single request travels down through the layers on one computer and up through another at the other end.
Automatic activation of remote objects is a new feature in RMI as of Java 1.2 was created. The activation subsystem in RMI provides you with two basic features, the ability to have remote objects instantiated(activated) on-demand by client requests, and the ability for remote object references to remain valid across server crashes, making references persistent. These features can be quite useful in certain types of distributed applications (Birrell et al 1994 pp.34-39).
I f a remote object is made activable, it can be registered with the RMI registry without actually being instantiated. Usually, RMI' remote objects (based on the Unicast Remote Object Interface) provide only non-persistent references to themselves. Such a reference can be created for a client only if the referenced object already exists in a remote Java VM. In addition, the remote reference is valid only during the lifetime of the remote object., the remote object activation service adds support for persistent remote references that can be created even if the remote object is not running at the time of the request and that can persist beyond the lifetime of an individual server object(Dasgupta Leblanc Spafford 1985 pp. 89).
The key features provided by RMI activation service groups, and each activation group runs within its own Java VM, if you don't group your activable object runs inside a separate Java VM. You typically define an activable remote object by (Birrell et al 1994 pp. 34-49) as sub-classing your remote object implementation from the activable class provided in the Java.rmi.activation package, providing activation constructors in the server implementation and registering the object, and its activation method with the activation service.
If a user wants remote clients to directly access their activable object, they will also need to register the object with the RMI registry, so that it can be found by the name in the network. You can register an activable class with the registry without actually creating an instance of the remote object, as we'll see shortly. The user can also create am activable object without using a sub-class, this might be necessary if they need to extend another class and the Java single-inheritance limit them from also extending activable.
Andrew D. Birrell, Bruce Jay Nelson 1984, Implementing remote procedure calls, ACM transaction on computer systems (TOCS), v.2 n.1, p.39-59
Birrell, Andrew, et al (1994). “Network Objects,” Digital Equipment Corporation Systems Research Centre Technical Report 115
Dasgupta, P. , R .J Leblanc and E. Spafford. (1985). The clouds project: Designing and Implementing a Fault Tolerant
Distributed Operating system. “ Georgia Institute of Technology Technical Report GIT-ICS-85/29
Birman K., T. Joseph 1987, exploring virtual synchrony in distributed systems, proceedings of the eleventh ACM symposium on operating system principles , Austin Texas United States P.123-138
Ozalp Babaoglu , Keith Manzullo, 1993, Consistent global states of distributed systems: fundamental concepts and mechanisms, Distributes systems (2nd Ed.). ACM press/Addison- Wesley publishing Co. New York , NY pp.67-72.