Java Enterprise Best Practices

Wrap RMI Calls in Command Objects

Suppose you’re wrapping each remote method call in a retry loop, distinguishing the different types of remote exceptions, and stamping remote requests with identifiers. Then simple remote method invocations such as server.performAction( ), in which server is a stub associated with some remote object, balloon to 20 or 30 lines of code, most of which simply deal with the complexities of failure handling. This is bad for two reasons. The first is that a simple and easy-to-read line of business logic has become cluttered with extraneous things. And the second is that a lot of code is being written over and over again (the failure-handling code is boilerplate code).

The solution to both of these problems is to encapsulate all the code you’ve been adding inside a single class. For example, you could define a new class called SpecificCallToServer which encapsulates all this code. And then server.performAction( ) becomes:

(new SpecificCallToServer( . . . ))..makeRemoteCall(  )

This is a little less readable than the original code, but it’s still very readable. And all the logic dealing with the network infrastructure has been neatly encapsulated into a single class, SpecificCallToServer. If SpecificCallToServer simply extends an abstract base class (named something like RemoteMethodCall), you’ve made the client application more readable, and only written the code that deals with the complexities of making the remote method call once.

Tip

For more information ...