Should We Implement Bank or Account?

Given this, there are two distinct questions that need to be considered. The first is: how many clients does a particular failure affect? And the second is: how hard is it to recover from a failure? One rule of thumb: when thinking about how fatal a server failure might be, simply ask yourself, How much client- specific state does the server have and from how many clients?

6.2.6.1 Applying this to Bank versus Accounts

At the level of single server failed, if an instance of Account fails, one particular bank account is inaccessible and the data associated with it may be corrupted, which could cause problems in recovery. However, the recovery process is three straightforward steps: check the data, relaunch the server, and use rebind to reclaim the name in the registry. If an instance of Bank , or even of Branch , fails, a much larger amount of data could be corrupted. In addition, when an instance of Bank fails, everyone is affected i.e., all the clients are hit, not just one or two. Its hard to imagine Account failing; its a fairly simple object. Failures are more likely to be of an entire JVM or an entire machine, rather than of a single instance of Account . Advantage: Accounts 6.2.7 How Easy Is It to Gracefully Extend the Software and Add New Functionality? There are two basic facts of life that must be accounted for: Requirements are constantly changing. If your application is to be successful, it will need to evolve. This is especially true immediately after the first version is deployed™users will use the application and immediately spot all of the things they should have mentioned but didnt think of during requirements analysis. Smaller servers are easier to modify and extend. Simple objects are much easier to modify or replace. This is especially true when the distributed architecture involves a layer of indirection. This is the case, for example, when a factory is used. Well discuss factories in Chapt er 17 .

6.2.7.1 Applying this to Bank versus Accounts

In this case, because theyre both simple servers, its pretty much a wash. Advantage: neither 6.3 Should We Implement Bank or Account? As is often the case, either will work. The actual code used to implement the server is similar in either case. And, ultimately, the decision is often simply a matter of taste. In this case, well go with many small servers and many instances of Account . This will give us many small advantages and buy us one big headache: the problems associated with resource allocation. Well deal with these problems in the next chapter and again in Chapt er 17 . But for now, its Account .

Chapter 7. Designing the Remote Interface

In the previous chapter, we discussed the architecture of the bank example in detail and concluded that implementing many small Account servers seems like a good design decision. In this chapter, well tackle the design of Account s remote interface. As part of this, we will also discuss the issues involved in building data objects, objects designed to be passed by value over the wire. By the end of this chapter, you will have a list of basic design criteria that will help you design your own remote interfaces.

7.1 Important Questions When Designing Remote Interfaces

Every program has at least two purposes: the one for which it was written, and another for which it wasnt. ™Alan Perlis Now that weve decided to have many little Account servers, the next step is to design the Account server interface. Just as the choice of server architectures was substantially influenced by the problems that arise in the design of distributed applications, the design of the server interface is also affected by both network latency and the possibility of partial failure. But interfaces also need to be designed with the applications or at least the servers lifecycle in mind. As the quote at the beginning of this section suggests, the simple truth is that nobody ever really knows how an application, or even a server, will be used once it is deployed. Over time, how an application is used and what functionality it needs to support will change. A needlessly brittle interface, one that embodies too many assumptions about the exact use of the application, will make it harder to evolve the codebase. As in the previous chapter, Ive attempted to capture a series of design points in the form of questions. Again, the list isnt intended to be complete; as you get more experienced at designing distributed systems, you will come up with more questions and your own ways of thinking about these problems. Unlike the decision between various server architectures, we have only one candidate interface here. Hence, we will take a slightly different approach by starting with a potential interface and then discuss it in light of the design questions. Heres the interface well implement: public interface Account extends Remote { public Money getBalance throws RemoteException; public void makeDepositMoney amount throws RemoteException, NegativeAmountException; public void makeWithdrawalMoney amount throws RemoteException, OverdraftException, NegativeAmountException; } Remember that every method in a remote in terface e.g., an interface that extends Remote and is intended to be used as the public interface to a server must be declared as throwing RemoteException . The following questions ought to be asked about any proposed remote interface. 7.1.1 Should We Pass Method Objects?