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 bank’s 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 what’s shown in Figure 5-1.
Figure 5-1. Simple architecture diagram for the bank example
Here, each component’s task is described:
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.
Implicitly, and without client knowledge, handles details of SSL connection.
Maintains a mapping of human-readable names to server stubs and responds to queries by returning serialized copies of stubs.
We’ll discuss these in detail later.
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 ...