2. Find a basic use case that will motivate the rough architecture. This amounts to narrowing down the information in step 1. A set of requirements usually lists all the things
that the application must do. Your task in this step is to imagine a typical user and figure out what she does with the application™a use case. This approach helps prioritize the
requirements and provides an incremental path for design and development. Your goal will be to design an application that supports the basic use case and adapt that
application to support other use cases and requirements.
3. Figure out what you can safely ignore for now. A typical rough sketch ignores scalability and security. Both of these are important, and both have the potential to be enormous
headaches, but both are also issues that can usually be dealt with later in the development process. At the start, its usually safe to assume that there are only a few
clients and that they operate inside a trusted environment.
4. Figure out what design decisions are imposed on the application by the deployment environment. Distributed applications are rarely off-the-shelf, shrinkwrapped applications
purchased as a commodity item; theyre designed for a specific environment. As such, theres little point in designing them without taking the clients environment into account.
There are usually four main issues involved: using a pre-existing persistent store e.g., a relational database, interoperating with a legacy application or applications, network
speed, and security.
5. Narrow down the servers to a few canonical choices. Once youve gone through steps 1 through 4 and isolated the basic use case, youll notice that youre already talking in
terms of specific servers. This step involves taking those servers and thinking about what their exact role in the system is.
And thats it. If you follow these five steps, youll be able to produce a rough sketch of the architecture. To help make this concrete, the next section will do this for the bank example.
5.3 The Basic Use Case
Weve already discussed the bank example a little bit and understand what it is that the application is supposed to do step 1. The next step is to create a basic use case. In subsequent
sections, we will assume that the following sequence of actions is typical for an ATM user:
1. The user walks up to the ATM and inserts an identification card. 2. The user enters a password.
3. If the password is correct, the user is given permission to perform transactions. This permission lasts until the identitication card is removed.
4. The user is given a menu of choices. The typical choices are: display an account balance, withdraw money, or deposit money. That is, the first menu consists of a generic
list of actions that are valid with any account. 5. After choosing an action, the user is given a list of valid accounts from which to choose
e.g., Checking or Savings. The user chooses an account and then the transaction proceeds.
6. After performing between one and five transactions, the user leaves, taking his or her identitification card.
5.4 Additional Design Decisions
The third and fourth steps in sketching out an architecture involve figuring out which design decisions can be safely postponed and which restrictions the deployment environment will place
upon our application. Since this is an RMI book, however, well make the following assumption:
There will be a server, or servers, written in Java and registered with a naming service. The client, also written in Java, will connect to the naming service,
retrieve a stub for the server, and use the stub to communicate with the server.
5.4.1 Design Postponements
As mentioned previously, we will postpone consideration of two key issues: security and scalability.
5.4.1.1 Security
Writing a security layer is difficult for two reasons. The first is that doing so often requires a good understanding of some rather complicated mathematics. The second is that its pretty hard to test.
Consider, for example, the functionality involved in depositing money to a bank account. Its easy to imagine a sequence of automated tests that will give you confidence that the code is correct.
Its much harder to imagine a series of tests that will ensure that no one can intercept and decode privileged information or that the passwords used for authentication are secure. For these
reasons, most applications that need security wind up using a thoroughly tested library or package that provides it.
For the bank example, we need to do two things: authenticate the user via password mechanism i.e., make sure the user has the authority to perform operations on a given account and
guarantee that the information sent between the client and the server is secure from eavesdropping. Since this second task is easily accomplished via SSL™and doesnt impact our
design at all™postponing security issues amounts to assuming that the user authentication task is easily solved and doesnt significantly impact the rest of the design.
RMI allows you, via the definition custom socket factories, to use any type of socket as the basic network communication
layer. By default, RMI uses the socket classes found in the
java.net package. The relationship between SSL and RMI
is discussed in Chapt er 18
.
5.4.1.2 Scalability
Our basic use case implies two very nice properties of our application. The first is that there isnt a great deal of state associated with a client. The second is that there isnt a lot of interaction
between distinct clients.
The first property implies that state management is fairly simple. When a client executes the basic use case, the server needs to authenticate the client and get the clients bank account data from
a persistent storage mechanism. Its plausible for us to assume that authentication is a once-per- client-session cost, and that the associated bank account information is not a large amount of
information nor hard to retrieve from the server.
The second property amounts to the following two assumptions: •
Two clients dont usually access the same bank account at the same time. •
Requests that one client makes e.g., a deposit or withdrawal wont affect other clients.
Note the presence of the word usually™we will, in later chapters, insert safeguards to guarantee data integrity in the
case that multiple clients attempt to access the same account at the same time. Those safeguards wont affect our
scalability assumptions, however.
We can restate these assumptions in a more general form: •
Two clients dont usually access the same changeable information at the same time. •
The changeable information is relatively isolated. Changes one client makes rarely affect other clients and do so in a known way.
These generalized assumptions, and the assumption that the state associated to a client is small, imply that once the single-client application is written, it will be fairly easy to make the application
scale. Hence, we can safely postpone worrying about scalability until we understand the single- client scenario. This is because of the following three implications:
• The changeable information, which is small and well-defined, can be cached in server
memory. •
Processing can be isolated. Therefore, you can use multiple servers on multiple machines without worrying about server communication.
• Because clients rarely access the same information simultaneously, caching the
changeable information is still a valid strategy even with multiple servers. These generalized assumptions hold for a surprisingly large number of applications the what-I-
put-in-my-shopping-cart-doesnt-affect-your-shopping-cart-at-all principle. And often, the key to making an application scale is figuring out how the generalized assumptions fail and limiting the
resulting problems. For example, both of the generalized assumptions fail in a scheduling application. That is:
• People trying to schedule meetings often access the same information simultaneously,
such as the schedules of other people and the list of available rooms and locations. •
A scheduling decision made by one user can definitely affect the other users. The trick is to realize that you still have some sort of isolation going on. There are actually two
types of isolation in the scheduling scenario: the people who need to be at a meeting and the geographic location of the meeting. If I need to meet with Bob and Sandy in Colorado, and you
need to meet with Alex and Pat in Oregon, then our requests are completely independent, and that fact should be reflected in the code.
A little confused? Its okay. Read this section again later. The key thing to remember is that if you can isolate the clients
from each other, or control how the clients affect eac h other, then the application can be made to scale without too many
problems.
5.4.2 Implications of the Environment
In a banking environment, one further design decision has already been made. Most banking applications, and indeed most applications that have a real need for reliable, long-term,
centralized storage of information, use some sort of database to store and retrieve data.
Thus, we will also assume that our server or servers will rely on some sort of third-party persistence mechanism to provide long-term storage and retrieval of information. We wont need
to implement this functionality, or make any decisions about how it is implemented. Our sole responsibility will be to build a communications layer between our application and the already
existing database.
5.5 A Distributed Architecturefor the Bank Example
The assumptions we just made are very plausible and apply to a wide variety of situations. But when we combine these assumptions with what we learned from the printer example, we have
enough information to sketch out our architecture.
Even without having more information about the banks computing environment and systems, and without having much of a requirements document beyond our single use case, we can still get a
good feel for the architecture of our banking application. A simple architectural diagram might look something like whats shown in
Figur e 5- 1 .
Figure 5-1. Simple architecture diagram for the bank example
Here, each components task is described: Client
Responsible for managing interaction with a user, usually via a GUI. It obtains a stub to a server from the registry and then invokes methods on the server.
Stub not pictured Implicitly, and without client knowledge, handles details of SSL connection.
Registry Maintains a mapping of human-readable names to server stubs and responds to queries
by returning serialized copies of stubs. Skeleton and launch code also not pictured
Well discuss these in detail later. Servers
Handle what is usually called business logic. That is, they respond to client requests, manipulate data, and occasionally store that data out to a database. In particular, servers
respond to requests from a client and make requests of the database. Database system
Responsible for long-term persistence and integrity of important data. This already exists; our main task with respect to it will be figuring out how to manage the communication
between our servers and it.
Given this, the main architectural questions that need to be resolved are: how many servers are there and what are they? There are two obvious choices: a single instance of
Bank or many
instances of Account
. In the first case, there is a single server whose interface contains methods such as the following:
public Money getBalanceAccount account throws RemoteException; public void makeDepositAccount account, Money amount throws
RemoteException, NegativeAmountException;
public void makeWithdrawalAccount account, Money amount throws RemoteException,
OverdraftException, NegativeAmountException;
Note that each method is passed an account description parameter presumably, though not necessarily, as a value object. This immediately suggests the second alternative: make each
account a separate server. The corresponding methods look similar; they simply have one fewer argument:
public Money getBalance throws RemoteException; public void makeDeposit Money amount throws RemoteException,
NegativeAmountException; public void makeWithdrawal Money amount throws RemoteException,
OverdraftException, NegativeAmountException;
In this scenario, there are many instances of a class that implements Account
. These instances, however, are not running in distinct JVMs. Instead, many small server objects are all residing
inside a few JVMs. Hence, they are implicitly either sharing, or contending, for resources. In later chapters, I refer to these two options as the bank option and the accounts option,
respectively.
5.6 Problems That Arise in Distributed Applications
