Deploying Loosely Coupled, Component-based Applications intoDistributed Environments

Abbas Heydarnoori and Farhad MavaddatSchool of Computer Science,

University of Waterloo,Waterloo, ON,

Canada, N2L 3G1{aheydarnoori, fmavaddat}@cs.uwaterloo.ca

Farhad ArbabDepartment of Software Engineering,

Centrum voor Wiskunde en Informatica,P.O. Box 94079, NL-1090 GB,Amsterdam, The Netherlands

Farhad.Arbab@cwi.nl

Abstract

With significant advances in software developmenttechnologies in recent years, it is now possible tohave complex software applications, which include alarge number of heterogeneous software componentsdistributed over a large network of computers with dif-ferent computational capabilities. To run such applica-tions, their components must be instantiated on properhardware resources in their target environments so thatsome requirements and constraints are met. This pro-cess is called software deployment. For large, dis-tributed, component-based applications with many con-straints and requirements, it is difficult to do the de-ployment process manually, and some automated toolsand techniques are required. This paper presents agraph-based approach for this purpose that is not depen-dent on any specific component technology and does thedeployment planning with respect to the communica-tion resources required by application components andcommunication resources available on the hosts in thetarget environment. In our approach, component-basedapplications and distributed environments are modeledwith the help of graphs. Deployment of an applicationis then defined as the mapping of the application graphto the target environment graph.

1 Introduction

In the past, software applications were stand-alonesystems, without any connections to other software ap-plications. In recent years, software applications havebecome more and more complex. They may consistof a large number of different components distributedover a large number of computers, and large networks

have moved to the center of software applications. Fur-thermore, with the arrival of the Internet and new ad-vances in Internet infrastructure, it is possible to havecompletely distributed applications that may consistof many heterogeneous components. In these appli-cations, since different components provide their func-tionality with different constraints and requirements,they should be installed on proper hardware resourcesin the distributed environment so that their constraintsare satisfied and they provide the desired quality of ser-vice (QoS). In addition, different resources have differ-ent computational capabilities, making it impossibleto install any kind of software components on them.Thus, after the development of an application, a se-quence of activities should be done to place that ap-plication into its target environment and bring thatapplication into an executing state. This sequence ofactivities is referred to as the software deployment pro-cess, and includes the following activities: acquiringthe developed application from its producer; planningwhere and how different components of the applicationshould be installed in the target environment, resultingin a deployment plan; installing the application into itstarget environment according to its deployment plan;configuring it; and finally executing it.

For simple stand-alone software systems that shouldbe deployed only to a single computer, deployment ac-tivities can be easily done manually. But, supposea complex component-based application is being de-ployed into a large distributed environment so thatsome QoS parameters, such as performance or relia-bility, are also maximized. In this situation, the de-ployment process is not so straightforward, and auto-mated tools and techniques are required for this pur-pose. Consequently, the software deployment processhas been given special attention both in research and

1

industry in recent years and it is possible to find manytools and papers addressing different activities of thesoftware deployment process from different perspec-tives [1, 2, 3, 4, 5]. However, to our knowledge, few ifany of these deployment approaches notices the char-acteristics (e.g., behavior, cost, speed, security, etc.)of interconnections among the components of the ap-plication. However, these characteristics have signifi-cant effects on application’s QoS. This paper presentsa graph-based approach that focuses on these proper-ties for planning the deployment of loosely coupled,component-based applications into distributed envi-ronments. For this purpose, the concept of channelis used to model intercommunications among compo-nents. A channel is a point-to-point communicationmedium with well-defined behavior. A component-based application is then modeled as a graph of com-ponents connected by a number of channels, possiblywith different characteristics. A distributed environ-ment is also modeled as a graph of hosts connectedby different channel types that can exist between ev-ery two hosts. Then, deployment planning is definedas the mapping of the application graph to the targetenvironment graph so that the desired QoS parame-ter is maximized. As an example of this approach, wepresent how this mapping can be effectively done sothat the cost of a deployment is minimized.

This paper is organized as follows: Section 2 talksabout the Reo coordination model which is usedas an example of channel-based coordination modelsthroughout this paper. In Section 3, the inputs of thedeployment planning process are discussed. In Section4, our graph-based approach for deployment planningis described and finally in Section 5, concluding re-marks are provided.

2 Case Study: Reo CoordinationModel

Reo is a channel-based coordination model that ex-ogenously coordinates the cooperative behavior of com-ponent instances in a component-based application [6].From the point of view of Reo, an application con-sists of a number of component instances communicat-ing through connectors that coordinate their activities.The emphasis of Reo is on connectors, their composi-tion and their behavior. Reo does not say much aboutthe components whose activities it coordinates. In Reo,connectors are compositionally constructed out of a setof simple channels. Thus, channels represent atomicconnectors. A channel is a communication mediumwhich has exactly two channel ends. A channel endis either a source channel end or a sink channel end.

A source channel end accepts data into its channel. Asink channel end dispenses data out of its channel. Al-though every channel has exactly two ends, these endscan be of the same or different types (two sources, twosinks, or one source and one sink). Reo assumes theavailability of an arbitrary set of channel types, eachwith well-defined behavior provided by the user. How-ever, a set of examples in [6] show that exogenous co-ordination protocols that can be expressed as regularexpressions over I/O operations correspond to Reo con-nectors which are composed out of a small set of onlyfive primitive channel types:

• Sync: It has a source and a sink. Writing a valuesucceeds on the source of a Sync channel if andonly if taking of that value succeeds at the sametime on its sink.

• LossySync: It has a source and a sink. The sourcealways accepts all data items. If the sink doesnot have a pending read or take operation, theLossySync loses the data item; otherwise the chan-nel behaves as a Sync channel.

• SyncDrain: It has two sources. Writing a valuesucceeds on one of the sources of a SyncDrainchannel if and only if writing a value succeeds onthe other source. All data items written to thischannel are lost.

• AsyncDrain: This channel type is analogous toSyncDrain except that the two operations on itstwo source ends never succeed simultaneously. Alldata items written to this channel are lost.

• FIFO1: It has a source and a sink and a channelbuffer capacity of one data item. If the buffer isempty, the source channel end accepts a data itemand its write operation succeeds. The accepteddata item is kept in the internal buffer. The ap-propriate operation on the sink channel end (reador take) obtains the content of the buffer.

In Reo, a connector is represented as a graph ofnodes and edges such that: zero or more channel endscoincide on every node; every channel end coincideson exactly one node; and an edge exists between two(not necessarily distinct) nodes if and only if there ex-ists a channel whose channel ends coincide on thosenodes. As an example of Reo connectors, Fig. 1 showsa barrier synchronization connector in Reo. In thisconnector, a data item passes from A to C only simul-taneously with the passing of a data item from B to Dand vice versa. This is because of the “replication onwrite” property in Reo, and different characteristics of

2

Figure 1. Barrier synchronization connectorin Reo

different channel types. In Reo, it is easily possible toconstruct different connectors by a set of simple compo-sition rules out of a very small set of primitive channeltypes [7].

2.1 Example: Modeling a Flight Reserva-tion System with Reo

In this section, we provide a simple example of aflight reservation system which is used as the runningexample throughout this paper. In this example, thebarrier synchronization connector in Reo is used tocompose a number of Web services together. Web ser-vices refer to accessing services over the Web [8]. Inthis example, they are treated as black-box softwarecomponents.

Suppose a travel agency wants to offer a FlightReservation Service (FRS). For some destinations, aconnection flight might be required. Suppose someother agencies offer services for International FlightReservation (IFRS) and Domestic Flight Reservation(DFRS). Thus, FRS commits successfully wheneverboth IFRS and DFRS services commit successfully.This behavior can be easily modeled by a barrier syn-chronization connector in Reo (Fig. 2). The FRS ser-vice makes commit requests on channel ends A and B.These commits will succeed if and only if the reserva-tions at the IFRS and DFRS services succeed at thesame time. This behavior is because of the semantic ofthe barrier synchronization connector in Reo.

3 Deployment Planner Inputs

To generate deployment plans, the following inputsshould be specified: (1) the component-based applica-tion being deployed, (2) the distributed environmentin which the application will be deployed, and (3) theuser-defined constraints regarding this deployment. Inthe following, these inputs are described in more detail.

3.1 Specification of the Application beingDeployed

Any loosely coupled, component-based applicationconsists of a number of components and interconnec-tions that connect them. The nature of these compo-nents and interconnections are irrelevant to this spec-ification. For example, components could be threads,processes, services, Java beans, CORBA components,and so on. In our model, a software component isviewed as a black-box software entity which reads datafrom its input port and writes data to its output port.How it manipulates the data, or its internal detailsare not important. The communication among theseblack-box entities is done via their interconnections.Again, these component interconnections could be any-thing connecting them; for example, glue code, middle-ware, connectors, and so on. Regardless of the typeof these interconnections, different components senddata/messages to other components and receive data/messages from other components of the application.Thus, it is possible to assume that the communicationamong the application components is done via a num-ber of channels with different characteristics. Specially,it is proved that the primitives of other communicationmodels (such as message passing, shared spaces, or re-mote procedure calls) can be easily modeled by thechannel-based communication model [6].

In summary, the specification of the applicationshould specify different components of the applicationand the channel types among them (e.g., Fig. 2).

3.2 Specification of the Target Environ-ment

In this paper, the target environment for the deploy-ment of the application is a distributed environmentconsisting of a number of hosts with computational ca-pabilities (e.g., PCs, laptops, servers, etc.) connectedby a network. Furthermore, the required software forthe communication among the application components

Figure 2. Modeling a flight reservation sys-tem with Reo

3

Figure 3. A sample target distributed environ-ment for the deployment of the flight reserva-tion system

(e.g., the Reo coordination middleware) has been al-ready installed on them. However, since different hostsmay have different hardware properties, it might beimpossible to install some sorts of communication soft-ware on them, or they may not be able to support somefeatures of the communication software installed onthem. It is also possible that different features/versionsof the communication software are installed on differ-ent hosts because of some reasons (e.g., cost, security,etc.). With respect to this discussion, available hostsin the target environment may provide different sortsof communication resources required to interconnectapplications’ components. In particular, since we aremodeling the interconnections among the applicationcomponents as a set of channels with different charac-teristics, different hosts might be able to support dif-ferent sets of channel types (or implementations) withdifferent behaviors and QoS characteristics. Thus, inthis paper, communication resources available on dif-ferent hosts are different channel types (or implementa-tions) they can support. As an example, Fig. 3 showsa sample target environment for the flight reservationsystem consisting of five hosts H1 − H5, connected bya network (solid lines). In this figure, Tds representdifferent channel types (or implementations) that dif-ferent hosts can support. For example, in the case ofusing Reo coordination model, T1−T5 could be definedas the following channel types (or implementations):

• T1: Sync channel type implemented by sharedmemory;

• T2: Sync channel type implemented by encryptedpeer-to-peer connection;

• T3: Sync channel type implemented by simple

peer-to-peer connection;

• T4: SyncDrain channel type;

• T5: SyncSpout channel type.

Logically, T1−T3 are all implementations of the samechannel type (Sync). However, their hardware require-ments and QoS characteristics differ.

3.3 Specification of the User-defined Con-straints and Requirements

Users may have special requirements and constraintsregarding the deployment of the application thatshould be taken into account during the deploymentplanning. For example, users may want a special com-ponent to be run on a certain host, or they may havecertain QoS requirements such as security, cost, or reli-ability. The deployment planner needs this informationto generate a plan that answers these requirements too.

For example, in the flight reservation system, sup-pose users require the transfer of data between FRSand IFRS to be encrypted. In addition, they wantFRS to be run on H1, IFRS to be run on either H2 orH3.

4 Deployment Planning

After specifying the deployment planner inputs,they can be used to generate the actual deploymentplan. Fig. 4 shows one sample deployment for theflight reservation system. As can be seen in this figure,different components of the application and channelsamong them are mapped to different hosts in the tar-get environment and network links among them for thepurpose of this deployment. In this section, we showhow graphs can be used to solve this mapping problem.

4.1 Modeling the Deployment Planner In-puts

The deployment planner inputs should be modeledwith well-defined structures in order to be used for ef-fective deployment planning purposes. In this section,we show that it is easily possible to develop graph rep-resentations of these inputs. This graph-based model-ing can have several advantages. First, it is possibleto have visual representation of the inputs. Second,graph theory algorithms can help us in designing de-ployment planning algorithms. Third, it is possibleto use graph theory symbols to formally represent de-ployment planner inputs and to prove the correctnessof designed deployment planning algorithms.

4

Figure 4. A sample deployment for the flightreservation system

4.1.1 Modeling the Application Being De-ployed

In section 3.1, we mentioned that loosely coupled,component-based applications can be viewed as a num-ber of components connected by a number of chan-nels with different characteristics through which theycommunicate. With respect to this description ofcomponent-based applications, it is possible to modelany loosely coupled, component-based application as agraph whose nodes are application components and itsedges are channels among these components.

Definition 4.1 (Application Graph) Suppose Cisrepresent different components of the application, andTds represent different channel types. Then, applica-tion graph AG = (VAG, EAG) is defined as a graph onVAG = {C1, C2, ..., Cn} in which each edge e ∈ EAG

has a label le ∈ {T1, T2, ..., Tk}.For example, Fig. 5 shows the application graph for

the flight reservation system. This graph is built withrespect to both the specifications of the applicationbeing deployed, and user-defined constraints regardingthis deployment. For example, in the specification ofthe application (Fig. 2), Sync channels are used to con-nect FRS and IFRS components. But, as mentioned

Figure 5. Application graph for the flightreservation system

in section 3.3, users want the transfer of data betweenFRS and IFRS to be encrypted. Thus, in the applica-tion graph presented in Fig. 5, Encrypted Sync channeltype is used between FRS and IFRS components.

4.1.2 Modeling the Target Environment

As mentioned in section 3.2, in this paper the targetenvironment for the deployment of the application is anumber of hosts with different computational capabil-ities connected by a network in a distributed environ-ment and each of them can support a set of channeltypes. With respect to this description of the targetenvironment, it is possible to model the target envi-ronment with the help of a graph in which:

• Nodes represent available hosts in the distributedenvironment;

• Edges represent different channel types that canexist between every two hosts.

To generate such a graph, first it is required to noticeto the following definitions.

Definition 4.2 (Adjacent Hosts) Two distincthosts Hx and Hy are adjacent if there is a direct phys-ical link between them in the distributed environment.

As an example, hosts H1 and H4 in Fig. 3 are ad-jacent.

Definition 4.3 (Virtually Connected) Two dis-tinct hosts Hx and Hy are virtually connected if thereis not any direct physical link between them in the dis-tributed environment. But, they are connected indi-rectly through intermediate hosts.

As an example, hosts H1 and H2 in Fig. 3 are vir-tually connected.

5

Definition 4.4 (Transitive Channel Type) Sup-pose two hosts Hx and Hy are virtually connected. Achannel type Td is transitive if it is possible to create achannel of type Td between them when (1) both of themcan support channel type Td, and (2) all intermediatehosts between them can also support channel type Td.

For example, in the Reo coordination model, chan-nel type Sync is a transitive channel type.

Definition 4.5 (Non-transitive Channel Type) Achannel type Td is non-transitive if it is possible to cre-ate a channel of type Td between two hosts Hx and Hy

only when (1) both of them can support channel typeTd, and (2) they are adjacent.

As an example, in the Reo coordination model,channel type SyncDrain is a non-transitive channeltype.

With respect to the above definitions, target envi-ronment graph is defined in the following way:

Definition 4.6 (Target Environment Graph)Suppose His represent different hosts in the targetenvironment, Tds represent different channel types,and eHx,Hy,Td

represents an edge from node Hx tonode Hy with label Td. Then, the target environmentgraph TG = (VTG, ETG) is defined as a graph onVTG = {H1,H2, ...,Hm} in which the set of edgesETG =

⋃{eHx,Hy,Td} is determined in the following

way:

• If Td is a transitive channel type, then there existsan edge eHx,Hy,Td

between two distinct nodes Hx

and Hy only if (1) both of them are adjacent or vir-tually connected, (2) both of them support channeltype Td, and (3) if they are virtually connected, allintermediate hosts support channel type Td.

• If Td is a non-transitive channel type, then thereexists an edge eHx,Hy,Td

between two distinct nodesHx and Hy only if (1) they are adjacent, (2) bothof them support channel type Td.

• If Td can be supported by host Hx, then there is anedge eHx,Hx,Td

from Hx to Hx (loopback edge).

As an example, Fig. 6 shows the target environmentgraph generated by this method for the distributed en-vironment presented in Fig. 3. To make the figuresimpler, loopback edges are not shown. For a morespecific example, consider hosts H1 and H2 which arevirtually connected (i.e., through host H4). As men-tioned in section 3.2, in this example, T1 − T3 are dif-ferent implementations of the Sync channel type which

Figure 6. Target environment graph for thedistributed environment presented in Fig.3. T1 − T3 are transitive channel types.T4 − T5 are non-transitive channel types.For simplicity, loopback edges are notshown.

is a transitive channel type. Thus, it is possible tohave channels of types T1 − T3 between H1 and H2.Furthermore, both H1 and H2 support channel typeT4 (i.e., SyncDrain) which is a non-transitive channeltype. However, since H1 and H2 are not adjacent, it isimpossible to have a channel of type T4 between them.

4.1.3 Target Environment Graph for a Peer-to-Peer Distributed Environment

In a peer-to-peer (P2P) distributed environment (e.g.,Internet), two or more computers (called nodes) can di-rectly communicate with each other, without the needfor any intermediary devices [9]. In this situation, it isnot required to consider the issues related to the phys-ical connectivity among hosts, i.e., transitive propertyof channel types. In this case, the definition of thetarget environment graph becomes much simpler.

Definition 4.7 The target environment graph TG =(VTG, ETG) for a P2P distributed environment is agraph on VTG = {H1,H2, ...,Hm} in which there ex-ists an edge eHx,Hy,Td

between two not necessarily dis-tinct nodes Hx and Hy if and only if both of them cansupport channel type Td.

4.2 Deployment Planning Algorithms

As mentioned at the beginning of section 4, duringthe deployment planning, different application compo-nents and channels among them are mapped to differ-ent hosts in the target environment and network links

6

Component Name Candidate HostsFRS H1

IFRS H2, H3

DFRS H1, H2, H3, H4, H5

N1 H1, H2, H4, H5

N2 H1, H2, H4, H5

Table 1. Candidate hosts for the deploymentof the flight reservation system components

among them so that all requirements and constraintsare satisfied. If consider the sample deployment pre-sented in Fig. 4 again, you may notice that in thisdeployment, different nodes and edges of the applica-tion graph AG shown in Fig. 5 are mapped to differentnodes and edges of the target environment graph TGpresented in Fig. 6. In this way, it is possible to seethe deployment planning as a graph mapping problemfrom the application graph to the target environmentgraph. In this section, we talk about the required algo-rithms to solve this graph mapping problem. However,before everything, we begin with defining some generalterms which are used in the rest of this paper.

Definition 4.8 (Candidate Host) Let TCi=

{Td|Td ∈ T,∃{Ci, Cj} ∈ EAG : l{Ci,Cj} = Td} repre-sent all required channel types by component Ci in theapplication graph AG = (VAG, EAG) and let THx

=support(Hx) represent the set of channel types thathost Hx can support. Then, host Hx is a candidatehost for the deployment of component Ci, only if (1)TCi

⊆ THx, and (2) host Hx satisfies user-defined con-

straints regarding the deployment of component Ci.

This definition implies that a host Hx is a candidatehost for the deployment of component Ci if it supportsall required channel types by component Ci in the ap-plication graph and also the deployment of componentCi on host Hx meets user-defined constraints. As anexample, Table 1 shows the candidate hosts for the de-ployment of the flight reservation system components.For a more specific example, consider component IFRS.In the application graph presented in Fig. 5, IFRS justrequires channel type T2 and all of the hosts in thetarget environment presented in Fig. 3 support thischannel type. But, as mentioned in section 3.3, userswant IFRS to be deployed on either hosts H2 or H3.So, with respect to this constraint, candidate hosts forthe deployment of component IFRS are H2 and H3.

Definition 4.9 (Candidate Deployment) SupposeCHCi

represents the set of candidate hosts for the de-ployment of component Ci. Then, a candidate deploy-

ment Dc is a set of pairs (Ci,Hx) in which every com-ponent Ci in the application graph AG = (VAG, EAG)is mapped to a host Hx in the target environmentgraph TG = (VTG, ETG) so that host Hx is a can-didate host for the deployment of component Ci, i.e.,Dc = {(Ci,Hx)|Ci ∈ VAG,Hx ∈ VTG,Hx ∈ CHCi

}.For example, {(FRS �→ H1), (IFRS �→

H2), (DFRS �→ H3), (N1 �→ H4), (N2 �→ H5)} and{(FRS �→ H1), (IFRS �→ H3), (DFRS �→ H3), (N1 �→H4), (N2 �→ H5)} are two candidate deployments forthe flight reservation system.

Definition 4.10 (Valid Deployment) A candidatedeployment Dc is a valid deployment, if for all edgeseCi,Cj ,Td

in the application graph AG = (VAG, EAG) ifcomponents Ci and Cj are mapped to two not neces-sarily distinct hosts Hx and Hy in the target environ-ment, then it should be possible to create a channel oftype Td between hosts Hx and Hy, i.e., there shouldbe an edge eHx,Hy,Td

in the target environment graphTG = (VTG, ETG). Formally speaking, ∀eCi,Cj ,Td

∈EAG ⇒ ∃eDc(Ci),Dc(Cj),Td

∈ ETG.

As an example, Dc = {(FRS �→ H1), (IFRS �→H2), (DFRS �→ H1), (N1 �→ H1), (N2 �→ H2)} is aninvalid deployment for the flight reservation system.Because, there is an edge eN1,N2,T4 in the applicationgraph presented in Fig. 5. But, there is not an edgeeDc(N1),Dc(N2),T4 = eH1,H2,T4 in the target environmentgraph presented in Fig. 6. In other words, with respectto the specification of the target environment presentedin Fig. 3, it is impossible to create a channel of typeT4 between hosts H1 and H2.

With respect to above definitions, it is typically pos-sible to deploy a complex component-based applicationinto a large distributed environment in many differ-ent ways. As an example, consider again the candi-date hosts for deploying each of the components of theflight reservation system shown in Table 1. As canbe understood from this table, it is possible to deploythis application into the target environment in at most160 = 1× 2× 5× 4× 4 different ways (because some ofthem are invalid deployments). Obviously, this numberis much bigger for complex applications deployments.However, when some QoS parameters, such as cost,performance, reliability, etc., are considered, some ofthese candidate deployments are equivalent, some arebetter than others and only a few of them may accom-modate the constraints and requirements of the appli-cation. Thus, when QoS of the application is impor-tant, it should be tried to deploy the application sothat its desired QoS parameter is maximized.

One naive solution to this problem is to generateall candidate deployments by permuting the sets of

7

candidate hosts for different components of the ap-plication. Then, the desired QoS parameter of allvalid candidate deployments is measured and the bestone is selected. The complexity of this algorithm isO(mn+mn) = O(mn), where m is the number of avail-able hosts in the target environment and n is the num-ber of components of the application. As we see, this isan exponentially complex solution to the deploymentproblem. Thus, when the number of candidate deploy-ments is large, it is impractical to generate all of themand then select the best one. So, a set of algorithmsand heuristics should be designed and applied to ef-fectively solve such an exponentially complex problem.The following definition, provides a formal definition ofthe deployment problem we intend to solve.

Definition 4.11 (Deployment Problem) Supposedeployment planner inputs are used to build the ap-plication graph and the target environment graph ac-cording to the methods presented in section 4.1. CHCi

also represents the set of candidate hosts for the deploy-ment of component Ci. Then, for the given applicationgraph AG = (VAG, EAG), target environment graphTG = (VTG, ETG), and QoS parameter Q, the problemis to find a polynomial time function D : VAG → VTG

such that the following three conditions are satisfied:

1. Application’s Q parameter is maximized;

2. D(Ci) = Hx ⇒ Hx ∈ CH(Ci). This means thatall components of the application must be mappedto one of their respective candidate hosts for thedeployment;

3. ∀eCi,Cj ,Td∈ EAG ⇒ ∃eD(Ci),D(Cj),Td

∈ ETG.This means that the deployment D must be a validdeployment.

This definition implies that during the deployment,it is possible to map several application components toa single host if that host is a candidate host for the de-ployment of those components. Furthermore, if thereexists a channel of type Td between two componentsin the application graph, then those components canbe mapped to two different hosts only if there exists achannel of type Td between them in the target environ-ment graph.

As an example of how such efficient algorithms andtechniques can be applied to effectively solve the de-ployment problem, in the following section, polynomialtime algorithms for minimizing the cost of a deploy-ment when the target environment is a P2P distributedenvironment are provided.

for each component Ci in the application doFind the set of candidate hosts, CHCi

;if CHCi

== null thenreturn “No Answer!”;

endelse

Hx = cheapest host in the set CHCi;

Output: Ci �→ Hx

endend

Figure 7: Cost-effective deployment algorithmwhen the cost should be paid for each component

4.2.1 Cost-effective Deployment

Suppose different hosts in the target environment havedifferent costs and whenever they are being used, theircosts should be paid to their administrator(s). In thissituation, one QoS parameter of a deployment is itscost and should be minimized in the deployment plan.For this, two different cases can be considered:Case 1: The cost should be paid for each component. Inthis case, for every component to be run on each host,its cost should be paid separately. For example, foreach component to be run on host H1, $1000 should bepaid to its administrator(s). Thus, if five componentsto be run on host H1, 5×$1000 = $5000 should be paid.The required algorithm of this case is simple. In thiscase, in the set of candidate hosts for the deployment ofeach of the application components, the cheapest oneis selected and that component is deployed on it. Thepseudocode of this algorithm is shown in Fig. 7. Thisalgorithm has the polynomial complexity O(mn).Case 2: The cost should be paid for each host, no mat-ter how many components will be run on it. In thiscase, the number of components will be run on eachhost is not important; if the cost of one host is paid, itis possible to run as many components as you want onit. The complexity of this case is much more than theprevious one. In this case, it should be tried to select asubset of available hosts in the target environment sothat the total cost of the deployment is minimized andall the components of the application are also assignedto a host. It is easily possible to prove that this prob-lem is equivalent to the Minimum Set Cover problem[10].

Definition 4.12 (Minimum Set Cover Problem)Given a finite set U of n elements, a collection of sub-sets of U , S = {s1, s2, ..., sk} such that every elementof U belongs to at least one si, and a cost functionc : S −→ R, the problem is to find a minimum costsubset of S that covers all elements of U .

8

X = Ø, τ = Ø;while X �= U do

Find the set ω ∈ S that minimizesc(ω)/|ω\X|;X = X ∪ ω, τ = τ ∪ {ω};

endOutput: τ

Figure 8: Greedy approximation algorithm for theminimum set cover problem

This case of the cost-effective deployment problemcan be converted to a minimum set cover problem inthe following way:

• Set U = {C1, C2, ..., Cn}, i.e., the components ofthe application are set as the elements of the uni-verse;

• Set S = {CSH1 , CSH2 , ..., CSHm} in which each

CSHxcorresponds to host Hx and it represents

the subset of application components that can berun on host Hx. In other words, each CSHx

is asubset of application components which Hx is intheir lists of candidate hosts for the deployment.

• Define c : S −→ R so that c(CSHx) = c′(Hx).

Function c′ : H −→ R returns the cost of eachhost.

Theorem 4.1 If we define the elements of the mini-mum set cover problem as mentioned earlier, then thesolution of the minimum set cover problem satisfies allconditions of the deployment problem defined in defini-tion 4.11.

To save space, the proof of this theorem is not pro-vided here. However, it is proved that minimum setcover problem is a NP-hard problem and it can not besolved in polynomial time [11]. But, there exist somegreedy approximation algorithms that can find reason-ably good answers in polynomial time. One of the keyalgorithms for solving this problem is provided in Fig.8 [11]. The main idea in this algorithm is to iterativelyselect the most cost-effective si ∈ S and remove thecovered elements until all elements are covered. Thecomplexity of this algorithm is O(log(|U |)) [11].

To solve this case of the cost-effective deploymentproblem, first it should be converted to the minimumset cover problem as mentioned earlier. Then, it iseasily possible to use the greedy approximation algo-rithm presented in Fig. 8 to find a reasonably goodsolution for the problem. In other words, by using thisalgorithm, all components of the application will be

assigned to at least one host and total cost of the de-ployment will be close to minimum too. As an exampleof using this greedy approximation algorithm, considerthe flight reservation system example. With respect toTable 1, the elements of the minimum set cover prob-lem are defined in the following way:

• U = {FRS, IFRS,DFRS,N1,N2};• S = {{FRS,DFRS,N1,N2}, {IFRS,DFRS,N1,N2},{IFRS,DFRS}, {DFRS,N1,N2}, {DFRS,N1,N2}};

• c′(H1) = $1000, c′(H2) = $2500, c′(H3) = $2000,c′(H4) = $1500, c′(H5) = $1000.

By applying the greedy approximation algorithm,we will have the following results and the minimumcost will be $3000:

• {(FRS �→ H1), (DFRS �→ H1), (IFRS �→H3), (N1 �→ H1), (N2 �→ H1)};

• {(FRS �→ H1), (DFRS �→ H3), (IFRS �→H3), (N1 �→ H1), (N2 �→ H1)}.

Note that it is possible to use the algorithm pre-sented here more generally for some other QoS param-eters too, when you want to minimize the total usageof some resources of available hosts in the target envi-ronment. In this situation, it is possible to define thecost function c to return the amount of that resourcefor each host and then use the greedy approximationalgorithm presented in Fig. 8 to find the solution.

5 Conclusions and Future Work

The software deployment process is defined as a se-quence of related activities for placing a developed ap-plication into its target environment and making theapplication available for use. For simple stand-aloneapplications that should be installed only on a sin-gle computer, this process is easy. But, for complexcomponent-based applications that should be deployedinto a large distributed environment and some QoS pa-rameters should also be maximized, the deploymentprocess is not that straightforward. This paper pre-sented a graph-based approach for this deploymentplanning which uses the concept of channels to cap-ture the properties of interconnections among the com-ponents of the application. The approach presentedin this paper is general and is not dependent on anyspecific component technology or model (e.g., COM,CORBA, EJB, etc.) and can be used for deploying anykind of loosely coupled, component-based applicationsinto distributed environments.

9

This paper also presented the required algorithmsfor minimizing the cost of a deployment when somecosts must be paid upon using the hosts in the tar-get environment. For future work, we plan to designefficient algorithms for other QoS parameters such asreliability, performance, security, and so on. We alsoplan to devise some specification languages for specify-ing the application being deployed, the target environ-ment, and user-defined constraints.

References

[1] Hnetynka, P. Making Deployment of DistributedComponent-based Software Unified. In Proceed-ings of CSSE 2004 (Part of ASE 2004), AustrianComputer Society, Linz, Austria, Sep. 2004, 157-161.

[2] Lestideau, V. and Belkhatir, N. Providing HighlyAutomated and Generic Means for Software De-ployment Process. In Proceedings of the 9th Inter-national Workshop on Software Process Technol-ogy (EWSPT 2003), Helsinki, Finland, September1-2, 2003, 128-142.

[3] Mikic-Rakic, M., Malek, S., Beckman, N. andMedvidovic, N. A Tailorable Environment for As-sessing the Quality of Deployment Architecturesin Highly Distributed Settings. In Proceedings ofthe Second International Working Conference onComponent Deployment (CD 2004), Edinburgh,UK, May 20-21, 2004.

[4] Carzaniga, A., Fuggetta, A., Hall, R. S., Hoek, A.V. D., Heimbigner, D., Wolf, A. L. A Characteri-zation Framework for Software Deployment Tech-nologies. Technical Report CU-CS-857-98, Dept.of Computer Science, University of Colorado,April 1998.

[5] Object Management Group, Deploy-ment and Configuration of Component-based Distributed Applications Specification.http://www.omg.org/docs/ptc/04-05-15.pdf.

[6] Arbab, F. Reo: A Channel-based CoordinationModel for Component Composition. Mathemati-cal Structures in Computer Science, 14, 3 (June2004), 329-366.

[7] Arbab, F. and Mavaddat, F. Coordinationthrough channel composition. In Proceedings ofthe 5th International Conference on Coordina-tion Models and Languages (Coordination 2002),LNCS 2315, Springer-Verlag, 21-38.

[8] Web Services Conceptual Architecture.http://www-306.ibm.com/software/solutions/webservices/pdf/WSCA.pdf.

[9] Schollmeier, R. A Definition of Peer-to-Peer Net-working for the Classification of Peer-to-Peer Ar-chitectures and Applications. In Proceedings of theIEEE 2001 International Conference on Peer-to-Peer Computing (P2P2001), Linkping, Sweden,August 27-29, 2001.

[10] Hassin, R. and Levin, A. A Better-Than-GreedyApproximation Algorithm For The Minimum SetCover Problem. SIAM Journal on Computing, 35,1 (2005), 189-200.

[11] Cormen, T.H., Leiserson, C.E., Rivest, R.L., andStein, C. Introduction to Algorithms, Second edi-tion, MIT Press, 2001.

10