2 Motivating Example

Consider the simple client-server system shown in Figure 1. It consists of one client and one server interacting via a ``link" connector. Such a system is easy to describe in a steady-state ADL such as Wright. A description would capture the structure of the architecture, describing the topology of the system and its composition, as well as the behavior of the system as a whole. Each component description provides a high-level specification of its functionality and interfaces, while the connector specification indicates how the ``link" pattern of interaction combines the behaviors of a client and a server. In this case, the client makes a request, which is received by the server, and the server provides a response, which is communicated by the client. This sequence of actions can be repeated many times.

  

Figure 1: Static Topology: Simple Client-Server

  

Figure 2: Static Wright Specification: Simple Client-Server

The Wright specification shown in Figure 2 shows this interaction pattern, and further provides important details about the rules of the interaction. As detailed elsewhere [All97] [AG97], Wright uses a variant of CSP [Hoa85] to characterize architectural behavior. The essential idea is to treat both components and connectors as processes, which synchronize over suitably renamed alphabets. For example, the use of internal choice ($\sqcap$) in the client specification indicates that it is the client that decides whether it will make a request. The use of external choice ($\Box$) in the server specification indicates that the server is expected to respond to any number of requests, and may not terminate prematurely. Successful termination is indicated by $\S$. We have described in [All97] [AG97] how these formal descriptions can be used to check the consistency and completeness of architectural descriptions.

Note, however, that the server role will never terminate until the client is ready. But, what of a more realistic situation, where the server is running on an unreliable processor over a network, and may crash unexpectedly? In this case, the architect must consider two aspects of a robust architectural design. First is the simple view of the functionality, in which the client makes a request of the server, and receives a response. Second is the architect's solution to the problem of server crashes (i.e., the way in which a server is restarted or replaced so that there is always a service available for the client).