Five Steps to a Sketch

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

The first thing to do when building a distributed application is sketch a rough architecture. The key words here are sketch and rough. Were talking about a preliminary design at the level of the architectural diagrams used in the previous chapters. And even though doing this can be difficult, there are several facts that help you out: • There are really only four or five different distributed application architectures. Most distributed applications look fairly similar to each other. • Youre using Java and RMI. This narrows down some design choices for you and helps you make design decisions. • You dont actually have to get it right. Rough architectures are not cast in stone; they help you focus and narrow the rest of the design, turning vast and open-ended questions into things that are easier to think about. In particular, they let you place pieces of functionality at various points on the network, and help you design the remote interfaces. This effectively turns the task of designing a distributed application into the task of designing single-process components.

5.2.1 Five Steps to a Sketch

Once youve sketched a rough architecture a few times, the process becomes ingrained. However, the following sequence of steps can be helpful the first few times: 1. Figure out what youre going to build. This might sound obvious, but its important. You need some set of requirements for the application, not just what it does for any given single user, but also information about how many users it supports, how many users it needs to support concurrently, and requires what sort of networking environment. Most of the time, this information will be imprecise. Thats perfectly fine. Estimates are fine; flying blind is dangerous. 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