Using RMI in Distributed Applications

By design, RMI programs closely resemble local Java applications. Programmers invoke a service on a distant networked server merely by making a method call. RMI's transparency is extremely valuable for a programmer's productivity because it makes distributing an application a relatively easy task. However, designing a scalable, reliable, and high-performance distributed application is not easy. Distributed programming brings a whole new class of potential errors.

Distributed programming is a complicated task, and one chapter cannot discuss all the issues. However, we will discuss common mistakes that most programmers trip over at least once during their career.

Handling the Unreliable Network

While it seems obvious when stated in a book, many developers of distributed programs make the cardinal error of ignoring the unreliable and potentially insecure network between the client and server. Even today when nearly every Web user has learned to expect a Web site outage and refuses to enter credit card information except on a secure site, it's all too easy to overlook these issues. It's not that programmers are careless, but in many cases, it is difficult to spot all the potential failure scenarios.

Consider writing an Internet banking application, which, for simplicity, only allows customers to deposit money. Every programmer should see that the deposit needs to run in a transaction to ensure that the account update is atomic and durable. Customers will not accept balance mistakes or lost deposits. However, there are also new failure cases in a distributed application. Some of these failure cases are handled automatically by the transaction infrastructure. For instance, if the server machine or the database dies during the transaction, a rollback returns the customer's original balance. Of course, the client would see an error message. This is undesirable, but customers can try their deposit again later.

Now consider the case where the deposit completes, the transaction commits, but the network fails during the communication with the client. In this case, the client again sees an error message, but in fact, the transaction has completed and the deposit is in the account. In this case, an unsuspecting customer might try the deposit again, not realizing that the previous transaction had in fact completed.

Distributed programs must consider the potential for failure during any point in the communication path. Sometimes the only reasonable answer is to display a message asking the user or system administrator to access the transaction logs and determine the current state.

Performance Implications of Cross-Network Method Calls

Another common distributed programming error is to neglect the performance overhead of making method calls across the network. Local method calls are a relatively cheap operation, but remote calls are usually at least 100 times slower.

There are two main problems with the performance of remote method calls: network bandwidth and latency. RMI calls send method parameters across the network connection to the server. Thus, the amount of network traffic depends on the size of the method parameters. Local Java calls do not have this issue because objects are passed by reference: Only a pointer is actually passed from the caller into the method. RMI calls with large parameters might work fine on a fast local network, but on the Internet, network bandwidth becomes a real issue. Clients connecting from throughout the world across congested networks can see very poor performance if large amounts of data need to be transferred between the client and server.

In addition to minimizing the data sent across the network connection, distributed applications must also be concerned with the frequency of remote method calls. Local method calls are relatively inexpensive, and most Java programs make thousands—if not millions—of method calls per second. Remote method calls across a network wire cannot achieve this level of performance. Programmers need to make this distinction and, where possible, minimize the number of round trips between the RMI client and server. One common pattern is to avoid calling fine-grained methods on a remote object. For instance, a customer might be a remote object. Instead of making individual remote calls to read the customer's name, address, and phone number, the distributed application should make a single remote call that returns all the required information in one network round trip.

WebLogic RMI Optimizations

In many cases, an RMI client and server are located on the same WebLogic Server. This is very common because all communication with EJBs is via RMI. If a servlet needs to call an EJB, it is making an RMI call although both components might run in the same WebLogic Server. Because this is a common case, the WebLogic Server includes optimizations to make these calls run nearly as fast as direct method calls. Obviously, there is no point in having the client and server communicate over a network connection so the WebLogic RMI implementation recognizes that the client and server are co-located and no network communication is required.

The WebLogic Server also includes a co-location optimization where the client's call skips the RMI infrastructure and calls directly on the implementation object. This optimization makes the RMI call's performance comparable to a local method call. However, programmers should be aware that because the call is skipping marshaling and unmarshaling, the client and server are using call by reference. While this optimization is a departure from RMI's parameter passing, the semantics should be familiar to programmers. In fact, call by reference is the calling convention used by local Java method calls.