The Bank Example Introducing the Bank Example

networked applications. By the end of this chapter, youll have a better idea of the design decisions and choices that must be made to build a distributed system, as well as how to begin.

5.1 The Bank Example

When traveling, take advantage of more than 13,000 Bank of America ATMs coast to coast. Were in 30 states and the District of Columbia. As a Bank of America Check Card or ATM cardholder, theres no ATM fee when you use an ATM displaying a Bank of America sign... ™Bank of America Advertisement A simple banking application implementing an automatic teller machine is, in many ways, the ideal first application for someone learning to design and build distributed programs. Why? The most obvious benefit is that the application is easy to understand; most readers of this book know exactly what an ATM is supposed to do. Moreover, there isnt a great deal of business logic involved, and the business logic that does exist is straightforward. Finally, theres very little GUI interface code to deal with. This means that most of our discussion deals with the distributed parts of the application, rather than the details of exactly how to process a transaction or which buttons need to be disabled when. Another important fact is that a banking application is inherently a distributed application with a centralized server or cluster of servers. In other words, it adheres to a traditional model of a client-server application, in which the two roles are strongly differentiated: Server The server is centralized on a small set of carefully maintained machines that few people can access. It is long-running and has important data, which it is responsible for maintaining over the course of the applications lifetime. All the business logic runs inside the server. Client The client is a relatively short-lived program. Any persistent state the client stores, other than user-interface configuration information, should be stored in the server. The clients role in the application is to provide the user with a way to interact with the server. The client application makes very few demands on the client machine and can be run on a wide range of computers. Moreover, a banking application involves two very important aspects of distributed programming: security and scalability. Security involves two different things: authenticating users such as when an ATM user enters his or her PIN and guarding sensitive data. When information is sent across a computer network, there is the possibility of a third party eavesdropping to discover sensitive information. This is especially true over the Internet and is an important reason for the widespread adoption of encryption standards such as the Secure Sockets Layer SSL. Scalability allows the server to handle many clients at the same time. The bank application has a centralized server that not only stores the bank account information in a very small number of places, but is responsible for authenticating clients. This means that all 13,000 of the Bank of America ATMs mentioned at the beginning of this section are probably being served by a very small number of machines, which have to handle a lot of simultaneous clients. Other Types of Distributed Applications For the most part, we will focus on the bank example and occasionally revisit the remote printer server in this book. Having a small set of examples that well repeatedly discuss from various points of view helps to keep the discussion more concrete. And, as I mentioned, the banking example allows us to talk about both scalability and security. There are many examples of distributed applications that dont require much in the way of security or scalability. For example, consider the typical internet chat room application. It consists of a distributed whiteboard, which contains the transcript of an ongoing conversation among several people. Most of the people are deliberately anonymous; they choose a handle and participate without the server authenticating them or having any long-term persistent state. Moreover, chat rooms dont need to scale because conversations dont scale well™its almost impossible to have a conversation among 100 people. And, while chat rooms usually have a server on which the clients log, there is no reason to have just one server or a small nexus of coordinated servers. The bank example, on the other hand, is conceptually simple but also involves scalability and security issues. Consequently, its a more useful example than a chat application.

5.2 Sketching a Rough Architecture