Overview

Component-and-connector (C&C) views define models consisting of elements that have some runtime presence, such as processes, objects, clients, servers, and data stores. Additionally, component-and-connector models include as elements the pathways of interaction, such as communication links and protocols, information flows, and access to shared storage. Often, these interactions are carried out using complex infrastructure, such as middleware frameworks, distributed communication channels, and process schedulers.

A C&C view provides a picture of runtime entities and potential interactions. Such a view may contain many instances of the same component type. For example, you might have a Web client component type that is instantiated many times within the same view. Drawing on an analogy from object-oriented systems, C&C views are similar to object, or collaboration, diagrams, as opposed to class diagrams, which define the types of the elements.

Choosing the appropriate forms of interaction between computational elements is a critical aspect of an architect's task. These interactions may represent complex forms of communication. For example, a connection between a client component and a server component might represent a complex protocol of communication, supported by sophisticated runtime infrastructure. Other interactions might represent multiparty forms of communication, such as event broadcast, or n-way data synchronization. These interactions are captured as connectors in the C&C viewtype.

C&C views are commonly used in practice; indeed, box-and-line diagrams depicting these views are often the graphical medium of choice as a principal first-look explanation of the architecture of a system. But these informal C&C views can be misleading, ambiguous, and inconsistent. Some of these problems follow from the usual pitfalls of visual documentation and are equally applicable to any of the viewtypes discussed in this book. But other problems are more specifically related to the use of components and connectors to portray a system's execution structure. In this chapter, we bring some clarity to the picture by describing guidelines for documenting C&C views and by highlighting common pitfalls.

Let us begin with an informal examination of the C&C viewtype by means of a simple example. Figure 3.1 illustrates a primary presentation of a C&C view as one might encounter it in a typical description of a system's runtime architecture.

Figure 3.1. A bird's-eyeview of a system as it might appear during runtime. This system contains a shared repository that is accessed by servers and an administrative component. A set of client tellers can interact with the account repository servers and communicate among themselves through a publish-subscribe connector.

What is this diagram, backed up by its supporting documentation, attempting to convey? We are being shown a bird's-eyeview of the system as it might appear during runtime. The system contains a shared repository of customer accounts (Account Database) accessed by two servers and an administrative component. A set of client tellers can interact with the account repository servers, embodying a client-server style. These client components communicate among themselves by publishing and subscribing to events. We learn from the supporting documentation that the purpose of the two servers is to enhance reliability: If the main server goes down, the backup can take over. Finally, a component allows an administrator to access, and presumably maintain, the shared-data store.

Each of the three types of connectors shown in Figure 3.1 represents a different form of interaction among the connected parts. The client-server connector allows a set of concurrent clients to retrieve data synchronously via service requests. This variant of the client-server style supports transparent failover to a backup server. The database access connector supports authenticated administrative access for monitoring and maintaining the database. The publish-subscribe connector supports asynchronous event announcement and notification.

Each of these connectors represents a complex form of interaction and will likely require nontrivial implementation mechanisms. For example, the client-server connector type represents a protocol of interaction that prescribes how clients initiate a client-server session, constraints on ordering of requests, how/when failover is achieved, and how sessions are terminated. Implementation of this connecter will probably involve runtime mechanisms that detect when a server has gone down, queue client requests, handle attachment and detachment of clients, and so on. Note also that connectors need not be binary: Two of the three connector types in Figure 3.1 can involve more than two participants.

It may also be possible to carry out both qualitative and quantitative analyses of such system properties as performance, reliability, and security. For instance, the design decision that causes the administrative interface to be the only way to change the database schema would have a positive impact on the security of the system. But it also might have implications on administratability or concurrency. For example, does the use of the administrative interface lock out the servers? Similarly, by knowing properties about the reliability of the individual servers, you might be able to produce numeric estimates of the overall reliability of the system, using some form of reliability analysis.

Some things to note about Figure 3.1 are that it

• Acts as a key to the associated supporting documentation, which is not shown
• Is simple enough to be comprehended in a single bite
• Is explicit about its vocabulary of component and connector types
• Provides a key to discussions about the number and kind of interfaces on its components and connectors
• Uses for its components and its connectors abstractions that concentrate on application functionality rather than on an implementation mechanism

The documentation accompanying the figure elaborates on the elements shown. Such supporting documentation should explain how Account ServerBackup provides reliability for the total system. An expanded C&C figure, not shown here, might focus on the main account server, its backup, and the client-server connection.