It is critical that the deployment of a software system be carefully planned. Many important system properties, particularly in a distributed setting, will be affected by the system's deployment. For example, the system's latency in delivering a given service can be improved if the system is deployed such that the most frequent and voluminous interactions required for that service occur either locally or over reliable and capacious network links.

For any large, distributed system, many deployments—that is, mappings of software components and connectors onto hardware hosts—will be possible in principle. Some of those deployments will be more effective than others in ensuring the desired system properties, such as its dependability, availability, security, and fault-tolerance. A system that meets its requirements and possesses these properties is said to deliver a desired level of service quality, most often referred to as QoS for "quality of service," to its users. Of course, in order to be able to claim that the system delivers the required QoS, the different QoS dimensions must be measurable and quantifiable. We revisit this issue in the next section. In the remainder of this section, we assume that the QoS dimensions in question are, in fact, measurable and quantifiable.

It should be noted that there are cases in which the deployment decisions can be and are made with relative ease—regardless of whether they are actually a good fit for the given system or not. One example is a typical desktop environment, in which a human user decides the software that he wants installed on his personal computer. Another example would be a system deployed by a space agency, comprising an interplanetary probe and a ground station. In such systems, it is typically known a priori on which side (flight or ground) the system's different components will reside. Yet another example, to an extent, is the wireless sensor network system depicted in Figure 10-1: The GUI components implemented in Java will reside on the PDAs, while the computationally intensive components implemented in C++ will be deployed to either the hubs or gateways (Malek et al. 2007). While the potential presence of multiple hubs and gateways, and multiple types of PDAs, still will require that the system's architects and engineers consider the effects of their deployment decisions within each class of components (in this example, GUI components and computationally intensive components, respectively), the number of possible deployments is significantly reduced.

The deployment problem is substantially more challenging in a system such as the one depicted in Figure 10-2, in which the number of hardware hosts is significantly larger and all devices provide roughly similar execution environments (in this case, Java). The problem of determining an effective deployment becomes intractable for a human engineer if, in addition to this, multiple QoS dimensions such as latency, security, availability, and power usage must be considered simultaneously, while taking into account any additional constraints. For example, component X may not be deployed on hosts Y and Z because of the component's size, the hosts' inability to provide the resources necessary for its execution, security concerns, or something else. This is a particularly challenging problem because of the following issues.

Figure 10-3. A small subset of the ERS system's architecture, comprising two software components and two hardware hosts. The components are depicted in UML for convenience.

In general, for a system comprising c software components and connectors that need to be deployed onto h hardware hosts, there are h ^c possible deployments. Clearly, some of those deployments may not be valid due to location constraints such as those mentioned above, memory restrictions on different devices, network bandwidth considerations, or availability of hardware and system software. This will reduce the space of possible deployments. On the other hand, the human user still must determine which deployment he prefers, why, and, in the process, may have to consider multiple invalid deployments.

As a simple example, consider the following scenario. A very small subset of the ERS system's architecture sketched in Figure 10-2 is depicted in Figure 10-3. This particular system contains only two software components and two hardware hosts; the connector enabling the interaction between the two components has been elided for simplicity. The two components interact to provide a schedule resource service, and the only property (that is, QoS dimension) of interest is latency. This small system has four possible deployments:

For such a small system, it is, in fact, possible to consider all of the possible deployments and to measure their actual latency. Let us assume that the measured latencies of the four deployments are as shown in Figure 10-4(a). These values are hypothetical, used here for illustration only. From this data, it is easy to determine that the first deployment exhibited the shortest latency and is thus the optimal deployment.

Let us now extend the example slightly and introduce another QoS dimension—durability. We define durability as the inverse of the system's rate of energy consumption. In many embedded and mobile settings, systems with higher energy consumption rates will run out of battery power sooner, that is, they will have lower durability. Therefore, deployments that reduce the energy consumption rate will increase the system's durability.

Figure 10-4. Evaluating deployments of the ERS subsystem from Figure 10-3. (a) Latency is the only QoS dimension of interest. (b) Latency and durability are the two QoS dimensions of interest.

Figure 10-4(b) shows the (hypothetical) durability values plotted alongside the previously obtained latency values. The first deployment still exhibits the shortest latency, but the third deployment is most durable. This phenomenon is known as Pareto optimal in multicriteria problems such as this one: No single deployment can be considered optimal unless additional criteria are introduced that will allow an architect to reconcile the two competing deployment options. In this example, if the system's stakeholders deemed durability more important than latency, the third deployment would likely be selected over the first one. However, even if there is no such additional criterion, the architect still has all relevant data available and can make the decision(s) he deems most appropriate.

To illustrate how quickly this problem becomes intractable, let us consider a slightly expanded scenario, depicted in Figure 10-5: This subsystem of the ERS has three components and three hosts. Even though it does not directly impact the discussion below, for the sake of completeness it should be noted that this three-component system provides an exchange plan service as well as the schedule resource service. Furthermore, there are now three QoS dimensions of interest: In addition to minimizing latency and maximizing durability, the system must also minimize the total volume of data exchanged across the network.

Figure 10-5. A slightly larger subset of the ERS system's architecture, comprising three software components and three hardware hosts.

This system has twenty-seven possible deployments (3³). For each of those deployments, let us assume that the three QoS properties have been measured or estimated. Visualizing the twenty-seven data points in a single three-dimensional diagram would be possible, though difficult. Note that visualizing software deployment scenarios with greater numbers of components and hosts, and especially with four or more QoS dimensions, in a single diagram would be essentially impossible. Instead, architects would most likely plot separate two-dimensional diagrams to study the relationships between pairs of QoS dimensions. The three such diagrams for the scenario from Figure 10-5 are shown for illustration in Figure 10-6.

It should be obvious from this example that, even for a system that is as small as the one depicted in Figure 10-5, manually calculating the QoS values of individual deployments and then determining the best deployment from those values is infeasible. Therefore, a solution that meets the challenges identified above and allows a software system's architects to plan the system's deployment appropriately will need to (1) provide an extensible model that supports inclusion of arbitrary system parameters; (2) support the definition of new QoS dimensions using the system parameters; (3) allow users to specify their QoS preferences; and (4) provide efficient and generic algorithms that can be used to find a solution (that is, deployment architecture) which maximizes the users' satisfaction in a reasonable amount of time.

Figure 10-6. The pair–wise trade-offs among the three QoS of interest (latency, durability, and interaction volume) for the ERS subsystem shown in Figure 10-5.

This solution is amenable to implementation, alleviating at least some of the architect's responsibility. In turn, this allows architects to focus on tasks such as specifying concrete targets for QoS dimensions of interest, rather than on menial but critical tasks such as determining whether a given deployment satisfies all of the system constraints and, if so, calculating the values of its various QoS dimensions.

For example, in the case of the scenario from Figure 10-5 and Figure 10-6, the architect may be interested in a deployment with specific latency, durability, and interaction volume thresholds. Manually determining and analyzing each individual deployment that is possible, that is, that satisfies all system constraints, and choosing one that in fact meets the set thresholds, would be overly time consuming (it could take hours for this small scenario and years for even only slightly larger systems) and error-prone. Furthermore, the architect will likely elect to stop once he has found the first deployment that meets the desired criteria. In contrast, a software-based solution working on the same problem would likely be able to determine a number of valid deployments that meet the QoS criteria, and choose the best one.

Automated support for deployment modeling and analysis would also allow architects to study, and quantify, any changes in a system's run time behavior. In turn, this would allow them to formulate plans regarding whether and when to redeploy the system or some of its parts.

In order to be able to make and effect a deployment plan for a large, long-lived, distributed software system, the system's architects first need to create a detailed model comprising all concerns pertaining to the system's deployment. This is an example of several concerns pertaining to the system's hardware and network infrastructure permeating the space of principal design decisions, that is, the system's software architecture.

Consider the two diagrams in Figure 10-7, corresponding to a subset of the ERS application depicted in Figure 10-2: The top diagram shows a high-level view of the ERS system's architectural configuration, while the bottom diagram shows the configuration of the hardware hosts on which the software is to be deployed. For simplicity, the top diagram does not show any software connectors. Instead, all interaction paths among the components are represented simply as lines. The reader can choose to interpret them as procedure calls for the purpose of the ensuing discussion. The dashed lines in the bottom diagram depict network connectivity.

A software architect would need a lot more information than is contained in the two diagrams in Figure 10-7 to determine what an effective deployment of ERS's software components to its hardware hosts would be. For example, the architect would need to know how computationally intensive the Deployment Advisor component is; how large the Repository is; how frequently the Clock component updates the remaining components in the system; what type of GUI facilities the five UI components in the system require; and so on. Furthermore, the architect would need to know many of the characteristics of the five hosts (such as their capacities, available peripheral devices, system-level software running on each, and so on) as well as the network links connecting them (such as the available bandwidth, protocol, link reliability, and so on). Only after all of this information is available can the architect make appropriate deployment decisions.

Therefore, an effective deployment model requires the following elements:

The architects may also need to represent system users or user types and their preferences in order to make appropriate decisions in situations in which multiple deployment options are acceptable.

For any moderately-sized software system, the above model can be very large, especially if architects decide to capture many parameters and constraints of the overall system and its individual hardware and software elements. Example parameters of a software component are the CPU and memory requirements for the component's execution, characteristics of the required execution substrate, such as the needed version of the Java Virtual Machine, and so on. Likewise, for a connector enabling the interaction of two or more components, the system model would encompass many of the same parameters as in the case of components, but would also capture parameters such as the sizes and frequencies of the interaction between the components, security mechanisms available, and whether the connector assumes a particular distribution profile (such as single address space, interprocess, or network-based).

Figure 10-7. The software architectural configuration of a subset of the ERS application (top) and the hardware configuration on which the software is to be deployed (bottom).

Even though the primary responsibility of a software architect is to focus on a system's software aspects, in the case of deployment modeling software architects must also consider the characteristics of the hardware platforms and the network. Extensible architecture descriptions languages such as xADL, AADL, and even UML, discussed in Chapter 6, are able to or already incorporate such modeling elements.

There may be many constraints specified on the software and hardware elements of a deployment model. For instance, location constraints may specify the relationship between software and hardware elements: requiring, allowing, or prohibiting that certain elements be deployed on certain hosts. In the example from Figure 10-7, it may be required that the Clock component reside on Host 2, while the Repository component may be prohibited from residing on that host.

Collocation constraints specify groups of components and connectors that need to be deployed, and redeployed, as a collection, as well as groups of components and connectors that may not be deployed on the same host. For example, another way of specifying the above two location constraints for Figure 10-7 would be to couple the Clock component's location constraint (that it must reside on Host 2) with a collocation constraint stating that the Clock and Repository components may not reside on the same host.

Beyond location and collocation, other constraints may restrict the versions of software connectors that may be used to enable the interactions of specific versions of components, the hardware configurations that are required or disallowed for deploying a given component, and so on. A final, critical facet of a deployment model is a quantification of the QoS dimensions of interest. If a given system property cannot be quantified, it cannot be estimated or measured precisely and the impact on that property of a system's particular deployment cannot be assessed objectively. Thus, for example, trying to determine a deployment of the ERS that will optimize its usability would be inherently difficult: Usability is a largely subjective notion that depends on many, sometimes implicit and possibly ill-understood, factors.

Fortunately, many important system properties can be quantified: reliability, availability, size, energy consumption rate, latency, and data volume are examples. Some of these properties may have multiple interpretations, which will differ across architects, projects, and organizations. Nonetheless, in principle it is possible to select a specific definition for a given property. Thus for example, one possible definition of availability for a system service (such as schedule resource discussed in the context of Figure 10-3) may be as the ratio of the successfully completed service requests to the total number of attempted service requests. It is not critical that this be the only, or the best, definition of availability. It is much more important that the definition fits the needs of the project in question, and that it is applied consistently.

Developing a detailed deployment model will be a sizeable, human-intensive task for any large, distributed application: Many parameters of many system elements will have to be modeled; many constraints will have to be captured; QoS dimensions of interest will have to be formally defined; system users and their preferences will have to be modeled; and so on. Doing all that will be worthwhile only if the model is used effectively to make the necessary, complex deployment decisions. To that end, the system's deployment model will have to be analyzed for properties of interest.

Figure 10-8. Two possible deployments of the subset of ERS depicted in Figure 10-7.

Consider for illustration the two diagrams in Figure 10-8. Both represent deployments of the ERS application's software elements onto its hardware nodes. The connectivities of both the software and the hardware configurations in the two Figure 10-8 diagrams are identical to those depicted in Figure 10-7. In other words, the applications corresponding to the two deployments are functionally equivalent to each other. The only difference between the two diagrams is that some of the software elements have been repositioned across the hosts. Using the terminology introduced in Chapter 3, we can then say that the two diagrams represent different candidate deployment views of the ERS application's architecture. An architect considering these two candidate deployments will have to make certain determinations, as detailed below.

Answering the first question—Is a deployment valid?—is relatively easy. If the system constraints have been specified rigorously, then this becomes a straightforward constraint satisfaction problem.

The answer to the second question—Which deployment is better?—is more uncertain. To answer that question, the architect must have a clearly defined measure of goodness for a system's deployment. That means that the system's deployment model will need to provide definitions of all QoS dimensions of interest. In turn, these QoS dimensions will have to be measured, or at least estimated. If multiple QoS dimensions are under consideration, as will be the case with most all large systems, the architect will very likely have to deal with Pareto optimal situations (recall from Figure 10-4(b): One deployment may prove superior with respect to one subset of the QoS dimensions, while another deployment may be better with respect to a different subset of the QoS dimensions.

For this reason, additional criteria will have to be introduced into the model. One possibility is to rank the QoS dimensions. For example, it may be decided that durability is more critical than latency. In that case, the third deployment from Figure 10-4(b) would be selected.

Another possibility, as suggested previously, is to introduce system users into the deployment model and capture their preferences explicitly. For example, one user could state that high durability of the schedule resource service in the ERS system is more important, by a given quantified factor, than its low latency; another user may specify another, possibly clashing preference. This would allow the architects to introduce the notion of the system's utility and select the deployment that provides the greatest total utility to all the users, or alternatively, the deployment that provides the greatest utility to the most important user or users.

Answering the third question—Is there a better deployment than the current one?—can be very challenging. It may require considering a very large number of deployment options and for each of them establishing the deployment's validity and comparing the new deployment to the existing one. This question is closely related to a more general question—What is the best deployment possible for a given system?—which is infeasible to answer in the general case because of the deployment problem's exponential nature.

There is a class of algorithms that can be applied to questions such as these. As stated above, the deployment problem is an instance of multidimensional optimization problems. Techniques such as mixed-integer linear programming (MIP) and mixed-integer nonlinear programming (MINLP) are frequently used to solve such problems (Nemhauser and Wolsey 1988). The main shortcoming of MIP is that it searches exhaustively for the best solution to a problem, and is thus inapplicable to even moderately large deployment scenarios. MINLP algorithms in turn provide approximate, rather than optimal, solutions. Furthermore, MINLP algorithms may not always converge on a solution.

There are other heuristic-based strategies that can be applied to solving complex problems such as this, including greedy, genetic, and decentralized strategies (Malek et al. 2007). However, none of those strategies can guarantee that the suggested deployment is the optimal one. In the case of the simpler formulation of the third question—Is there a better deployment than the current one?—this may result in failing to identify a better deployment even though many such deployments may exist. In the case of the question's more general formulation—What is the best deployment possible for a given system?—this may result in selecting a deployment that is actually suboptimal but is the best deployment the chosen algorithm can find.

Once the deployment problem has been modeled and a specific software system's deployment suggested in the manner outlined above, that deployment needs to be effected. As noted by Richard Hall and colleagues (Hall et al. 1997; Hall, Heimbigner, and Wolf 1999) and Carzaniga and colleagues (Carzaniga et al. 1998), some of the activities in a software system's deployment process take place on the host that is the source of the deployed component, while other activities take place on the host that is the destination of the deployed component. Source hosts are also referred to as producers, while destination hosts are referred to as targets, or consumers. The overall relationship among these activities is shown in Figure 10-9. We will briefly discuss each of these activities below, with a particular focus on the role of software architecture in the deployment process.

Figure 10-9. Software deployment process: deployment activities and their relationships. The diagram has been adopted from (Carzaniga et al. 1998).

Release. A software system's release is the initial activity in that system's deployment process. It takes place on the producer site, or sites, after the system's development has been completed. The system is packaged so that it can be transferred to the consumer sites. In certain settings (such as desktop computing) the system may need to be advertised to potential consumers. The packaged system will typically contain the following:

Install. Once the system has been packaged at the producer sites and transferred to the consumer sites, it is ready to be configured and installed for operation. Installation is a complex activity that encompasses all of the steps necessary to enable the system to execute. In other words, installation deals with:

Activate. Once the system is installed, it needs to be activated for use on the target hosts. Activation consists of providing a command, or sequence of commands, that will be required to start up the system.

Deactivate. Deactivation involves disabling and/or shutting down a system, or any of the system's facilities that are still active on the target hosts.

Update. Once a system has been installed and activated on the target hosts, over time it may need to be updated for different reasons. Updates are initiated by the system's producers, and involve the same activities as the system's original installation, with the caveat that only the necessary subset of the system is packaged and received from the producer hosts. The system may need to be deactivated before it is updated, and then reactivated thereafter. Alternatively, the system may support dynamic redeployment (recall the above discussion and also see Chapter 14). It is critical that the software system's update be properly reflected in its architectural models. If this is not ensured, the architecture will degrade, and any subsequent updates may result in system defects.

Adapt. Adaptation encompasses a wide range of activities that result in changing the system, possibly dynamically, in response to events in the system's execution environment. Adaptation is an important aspect of architecture-based software development, thus Chapter 14 is dedicated to it. With respect to software deployment, adaptation can result in the system's redeployment (that is, repositioning of its software components across execution processes and/or hardware hosts). Adaptation will be further discussed below in the context of mobility.

De-Install. If the system is no longer needed on the consumer sites, it will need to be removed. A simple view of de-installing a system is that it simply reverses the steps taken during the installation. However, any subsequent updates and adaptations must also be taken into account, as must any dependencies that other systems on the given consumer host have to the system being removed. This is why it is critical to maintain current architectural models for all deployed software systems. It should also be noted that, before the system is de-installed, it may need to be deactivated first.

De-Release. After some time, the producer of a given system may decide not to support the system any longer. In other words, the producer may decide to retire the system. This may be because one or more of the system's subsequent versions are superior, the market size for the product is too small, the producer has discontinued the product, or the producer has gone out of business. The withdrawal of the producer's support for the system is usually advertised. The system's consumers can then decide whether they still want to use the system, with the accompanying risks, or to de-install it.

In remote evaluation, a component on the source host has the know-how but not the resources needed for performing a service. The component is transferred to the destination host, where it is executed using the available resources. The result of the execution is returned to the source host.

In the terminology used previously in this chapter (that is, from a software architectural perspective), this means that in remote evaluation a software component is:

In code-on-demand, the needed resources are available locally, but the know-how is not. The local subsystem thus requests the component(s) providing the know-how from the appropriate remote host(s).

From a software architectural perspective, code-on-demand requires the same steps as remote evaluation; the only difference is that the roles of the target and destination hosts are reversed.

If a component on a given host (1) has the know-how for providing some service, (2) has some execution state, and (3) has access to some, though not all, of the resources needed to provide that service, the component, along with its state and local resources, may migrate to the destination host, which may have the remaining resources needed for providing the service. The component, along with its state, will be installed on the destination host and will access all of the needed resources to provide the service.

As mentioned above, from a software architectural perspective, mobile agents are stateful software components. Therefore before the steps outlined above are taken, a mobile agent must first be safely de-activated and possibly de-installed from the source host. This may pose certain challenges.