RPC Vs RMI
Remote Procedure Call (RPC) is a powerful technique for constructing distributed client-server based applications.
RPC is a client /server infrastructure that increases the interoperability, portability and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. An RPC is analogous to function call.
How RPC Works
An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. Figure 32.1 shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. The thread is blocked from processing until either a reply is received, or it times out. When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply to the client. After the RPC call is completed, the client program continues. RPC specifically supports network applications.Fig. 32.1 Remote Procedure Calling Mechanism A remote procedure is uniquely identified by the triple: (program number, version number, procedure number) The program number identifies a group of related remote procedures, each of which has a unique procedure number. A program may consist of one or more versions. Each version consists of a collection of procedures which are available to be called remotely. Version numbers enable multiple versions of an RPC protocol to be available simultaneously. Each version contains a a number of procedures that can be called remotely. Each procedure has a procedure number.
RPC Application Development
Consider an example:A client/server lookup in a personal database on a remote machine. Assuming that we cannot access the database from the local machine (via NFS).
We use UNIX to run a remote shell and execute the command this way. There are some problems with this method:
- the command may be slow to execute.
- You require an login account on the remote machine.
- establish an server on the remote machine that can repond to queries.
- Retrieve information by calling a query which will be quicker than previous approach.
- Specify the protocol for client server communication
- Develop the client program
- Develop the server program
Reomote Procedure Calling Mechanism
A remote procedure is uniquely identified by the triple: ( program number, version number, procedure number).
ADVANTAGES:
Many distributed systems use Remote Procedure Calls(RPCs) as their main communication mechanism.
RMI is a Remote method invocation
- RMI (Remote Method Invocation) is a way that a programmer, using the Java programming language and development environment, can write object-oriented programming in which objects on different computers can interact in a distributed network. RMI is the Java version of what is generally known as a remote procedure call (RPC), but with the ability to pass one or more objects along with the request. The object can include information that will change the service that is performed in the remote computer. Sun Microsystems, the inventors of Java, calls this "moving behavior." For example, when a user at a remote computer fills out an expense account, the Java program interacting with the user could communicate, using RMI, with a Java program in another computer that always had the latest policy about expense reporting. In reply, that program would send back an object and associated method information that would enable the remote computer program to screen the user's expense account data in a way that was consistent with the latest policy. The user and the company both would save time by catching mistakes early. Whenever the company policy changed, it would require a change to a program in only one computer.
Sun calls its object parameter-passing mechanism object serialization. An RMI request is a request to invoke the method of a remote object. The request has the same syntax as a request to invoke an object method in the same (local) computer. In general, RMI is designed to preserve the object model and its advantages across a network.
RMI is implemented as three layers:
- 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 as a synonym for stub.)
- A Remote Reference Layer that can behave differently depending on the parameters passed by the calling program. For example, this layer can determine whether the request is to call a single remote service or multiple remote programs as in a multicast.
- A Transport Connection Layer, which sets up and manages the request.
What are the pros and cons of JMS over RMI and vice versa? Which technology is best suited for what kind of projects?
Remote Procedure Call (RPC) technologies like RMI attempt to mimic the behavior of system that runs in one process. When a remote procedure is invoked the caller is blocked until the procedure completes and returns control to the caller. This synchronized model allows the developer to view the system as if its all running on one process. Work is performed sequentially ensuring that tasks are completed in a predefined order. The synchronized nature of RPC tightly couples the client (the software making the call) to the server (the software servicing the call). The client can not proceed (its blocked) until the server responds. The tightly-coupled nature of RPC creates highly interdependent systems where a failure on one system has an immediate and debilitating impact on other systems. In J2EE, for example, the EJB server must be functioning properly for the Servlets to function. RPC works well in many scenarios, but its synchronous, tightly coupled nature is a severe handicap in system-to-system processing where vertical applications are integrated together. In system-to-system scenarios the lines of communication between vertical systems are many, and also multi-directional.
Consider the challenges of implementing a multi-application infrastructure using a tightly-coupled RPC mechanism. There is the many to many problem of managing the connections between these systems. When you add another application to the mix, you have to go back and let all the other systems know about it. Also, Systems can crash. Scheduled downtimes need to happen. Object interfaces need to be upgraded. When one part of the system goes down, everything halts. When you post an order an order entry system, it needs to make a synchronous call right then and there to the helpdesk system to let it know there is a new customer. This causes the order entry system to stop and wait for this to happen. Its the synchronized, tightly coupled, interdependent nature of RPC systems that cause entire systems to fail as a result of failures in subsystems. When the tightly coupled nature of RPC is not appropriate, as in system-to-system, messaging provides an alternative.
With the use of Message Oriented Middleware (MOM), problems with the availability of subsystems are not an issue. A fundamental concept of MOM is that communications between components is intended to be asynchronous in nature. Code that is written to connect the pieces together assume that there is a one-way message that requires no immediate response. In other words, there is no blocking. Once a message is sent the client can move on to other tasks; it doesn't have to wait for a response. This is the major difference between RPC and asynchronous messaging and is critical to understanding the advantages offered by MOM systems.
In an asynchronous messaging system each subsystem (Accounts Receivable, Inventory, etc) is decoupled form the other systems. They communicate through the messaging server, so that a failure in one does not impede the operation of the others.
Partial failure in a networked system is a fact of life. One of the systems will have an unpredictable failure or need to be shut down at sometime during the life of the system. This can be further magnified by geographic dispersion of your in-house and partner systems. In recognition of this JMS provides guaranteed delivery, which ensures that its intended consumers will eventually receive a message sent even if partial failure occurs.
Guaranteed delivery uses a store and forward mechanism, which means that the underlying message server will write the incoming messages out to a persistent store if the intended consumers are not currently available. When the receiving application becomes available at a later time, the store and forward mechanism will deliver all of the messages that the consumers missed while unavailable.
Remote Procedure Call (RPC) technologies like RMI attempt to mimic the behavior of system that runs in one process. When a remote procedure is invoked the caller is blocked until the procedure completes and returns control to the caller. This synchronized model allows the developer to view the system as if its all running on one process. Work is performed sequentially ensuring that tasks are completed in a predefined order. The synchronized nature of RPC tightly couples the client (the software making the call) to the server (the software servicing the call). The client can not proceed (its blocked) until the server responds. The tightly-coupled nature of RPC creates highly interdependent systems where a failure on one system has an immediate and debilitating impact on other systems. In J2EE, for example, the EJB server must be functioning properly for the Servlets to function. RPC works well in many scenarios, but its synchronous, tightly coupled nature is a severe handicap in system-to-system processing where vertical applications are integrated together. In system-to-system scenarios the lines of communication between vertical systems are many, and also multi-directional.
Consider the challenges of implementing a multi-application infrastructure using a tightly-coupled RPC mechanism. There is the many to many problem of managing the connections between these systems. When you add another application to the mix, you have to go back and let all the other systems know about it. Also, Systems can crash. Scheduled downtimes need to happen. Object interfaces need to be upgraded. When one part of the system goes down, everything halts. When you post an order an order entry system, it needs to make a synchronous call right then and there to the helpdesk system to let it know there is a new customer. This causes the order entry system to stop and wait for this to happen. Its the synchronized, tightly coupled, interdependent nature of RPC systems that cause entire systems to fail as a result of failures in subsystems. When the tightly coupled nature of RPC is not appropriate, as in system-to-system, messaging provides an alternative.
With the use of Message Oriented Middleware (MOM), problems with the availability of subsystems are not an issue. A fundamental concept of MOM is that communications between components is intended to be asynchronous in nature. Code that is written to connect the pieces together assume that there is a one-way message that requires no immediate response. In other words, there is no blocking. Once a message is sent the client can move on to other tasks; it doesn't have to wait for a response. This is the major difference between RPC and asynchronous messaging and is critical to understanding the advantages offered by MOM systems.
In an asynchronous messaging system each subsystem (Accounts Receivable, Inventory, etc) is decoupled form the other systems. They communicate through the messaging server, so that a failure in one does not impede the operation of the others.
Partial failure in a networked system is a fact of life. One of the systems will have an unpredictable failure or need to be shut down at sometime during the life of the system. This can be further magnified by geographic dispersion of your in-house and partner systems. In recognition of this JMS provides guaranteed delivery, which ensures that its intended consumers will eventually receive a message sent even if partial failure occurs.
Guaranteed delivery uses a store and forward mechanism, which means that the underlying message server will write the incoming messages out to a persistent store if the intended consumers are not currently available. When the receiving application becomes available at a later time, the store and forward mechanism will deliver all of the messages that the consumers missed while unavailable.
As Daff says, Java RMI itself is really only relevent to Java-to_Java communications. In terms of ease of development these days the degree of coding from the service provider's perspective is pretty similar. However in addition to performance issues, where the gap between WebServices and RMI is quite variable (for some message sizes there can be negligable difference,) there's another aspect to consider: resilience. Typically, RMI is easy to set up when one client talks to one server and you don't mind the availability of the client being coupled to that of the single server. Server down, client down, such is life. In the Web Service case you can quite easily deploy your service to a cluster of servers and, given that you are invoking the Web Service over HTTP, you can easily exploit all the normal network routing and spraying techniques used in larger scale web sites. No special coding needed in the server or the client. Now, you can get this same level of resilience with RMI, but that requires a slightly better service-provision infrastructure and thats's where the JEE EJB programming model (or frameworks such as Spring) come in to play. EJB uses RMI over IIOP, a protocol that allows for resilient calling to server instances, transparently dealing with server outages. [It does quite a lot more too, such as secutiry and transactions, but then so can Web Services. Interesting but not part of this discussion.] Bottom line: For production quality service provision I normally start by creating an service object. I happen to use JEE EJB 3, other folks use Spring. You can expose that service object as a Web Service or as RMI/IIOP with some very simple configuration/annotation. It's very little effort to pick either or both. My world happens to major on interop, so I tend to expose Web Services. If you have only Java to consider it may give some performance improvement to use RMI/IIOP but this is not guaranteed, you would need to measure perfromance to be sure. |
