Algorithm 1 HA Weak-Point Analysis Algorithm with Alter- Algorithm 2 COMB native Resource Selection Input:ResourceList,WorkflowList,UtilityFunction Input:ResourceList,UtilityFunction,Topology,Work- Procedure: fowList Evaluate the computing complexity C for current case Procedure: if C<Cthreshold then MinCost MaxNumber (n1,...,nm)=IterationbasedCalculation(ResourceList, OptimizedSolution=Null WorkflowList) for every Resource Ci in ResourceList do else if NumofCandidateResource(Ci)>1 then (n1,.,nm =OptimizedSolutionCalculation //This resource has alternative component selection (ResourceList,UtilityFunction,WorkflowList) for every CandidateResource CRj in Resource Ci end if do Output (n1,n2,...,nm) CR;=GetCandidateResource(Ci) ResourceList=GenerateResourceList(CRj,Ci) UtilityFunction=GenerateUtilityFunction(CRj,Ci) Two kinds of relationships are defined in the core meta- AddtoResourceListPool(ResourceList) model:HostingLink and DependencyLink.HostingLink spec- AddtoUtility FunctionPool(Utility Function) ifies that one Unit will be the host for another Unit (e.g.,a end for end if server will be the host for an operating system).These links are restricted according to the Capabilities of the hosting Unit end for and the Requirements of the hosted Unit.DependencyLink for every ResourceList and counterpart UtilityFunction in specifies that one Unit (the source)has some (non-hosting) dependency on another Unit (the target);again,these are ResourceListPool and UtilityFunctionPool do [Cost,Solution ]=WeakPointAnalysis(ResourceList, restricted according to the Requirements of the source and the Capabilities of the target.The core metamodel is further UtilityFunction,Topology,WorkflowList) extended by domain-specific metamodels;for example,server, if Cost<MinCost then operating system,and database domains can be further defined. MinCost=Cost The defined HostingLink and DependencyLink are directly OptimizedSolution=Solution end if used for our workflow mapping as described in Section II. Based on these metamodels,an implementation of this SOA end for deployment framework has been built to help create SOA Output MinCost,OptimizedSolution deployment topologies [11]. B.Weak-Point Analysis Tool First,we evaluate the computing complexity C for the As depicted in Fig.9,our weak-point analysis tool is added current case,according to the number of IT resources and their to the SOA deployment framework.We use BPEL to specify maximum cluster sizes.Next,we compare it with a threshold business workflows,which are further mapped over the SOA value Cthreshold to decide whether to use the iteration method deployment topology.Business workflows can be described in or our weak-point analysis methodology. two ways:executable business workflows that model the actual behavior of a participant in a business interaction;or abstract IV.IMPLEMENTATION AND LESSONS LEARNED business workflows that fulfill a descriptive role and usually To assess the usefulness of our weak-point analysis method-hide some of the concrete operational details.BPEL business ology in real-life scenarios,we implemented it as an extension workflows refer here to abstract workflows,and therefore do to IBM's SOA deployment framework [11]. not capture detailed interaction behaviors. As described in SectionsⅡandIⅡ，the tool includes three A.SOA Deployment Framework modules.The Workflow Specification Module takes a deploy- The underlying SOA deployment framework is a model- ment topology and business workflows expressed in BPEL driven platform based on a core metamodel and various as inputs,and constructs the workflow-resource relationship domain-specific metamodels.The core metamodel is a rep- matrix.The Weak-Point Analysis Module uses this matrix to resentation that captures the common aspects of the IT in- identify availability weak points in the deployment topology, frastructure configuration syntax,structure,and semantics.In and produces HA enhancement parameters.Finally,using this core metamodel,the type"Unit"is defined to capture the these parameters,the HA Pattern Mapping Module generates IT resource components (e.g..database systems or operating proper patterns for each weak point and automatically trans- systems).The function of a resource component is defined forms the SOA deployment topology. via Capabilities attached to its representative Unit;its require- In the Weak-Point Analysis Module,two methods are im- ments are defined by formal Requirement specifications on the plemented:the exhaustive iteration method and our weak-point Unit. analysis methodology.Algorithm 1 HA Weak-Point Analysis Algorithm with Alter￾native Resource Selection Input: ResourceList, UtilityFunction, Topology, Work- flowList Procedure: M inCost = M axNumber OptimizedSolution=Null for every Resource Ci in ResourceList do if NumofCandidateResource(Ci)>1 then //This resource has alternative component selection for every CandidateResource CRj in Resource Ci do CRj=GetCandidateResource(Ci) ResourceList=GenerateResourceList(CRj , Ci) UtilityFunction=GenerateUtilityFunction(CRj , Ci) AddtoResourceListPool(ResourceList) AddtoUtilityFunctionPool(UtilityFunction) end for end if end for for every ResourceList and counterpart UtilityFunction in ResourceListPool and UtilityFunctionPool do [Cost,Solution]=WeakPointAnalysis(ResourceList, UtilityFunction, Topology, WorkflowList) if Cost<MinCost then M inCost=Cost OptimizedSolution=Solution end if end for Output M inCost,OptimizedSolution First, we evaluate the computing complexity C for the current case, according to the number of IT resources and their maximum cluster sizes. Next, we compare it with a threshold value Cthreshold to decide whether to use the iteration method or our weak-point analysis methodology. IV. IMPLEMENTATION AND LESSONS LEARNED To assess the usefulness of our weak-point analysis method￾ology in real-life scenarios, we implemented it as an extension to IBM’s SOA deployment framework [11]. A. SOA Deployment Framework The underlying SOA deployment framework is a model￾driven platform based on a core metamodel and various domain-specific metamodels. The core metamodel is a rep￾resentation that captures the common aspects of the IT in￾frastructure configuration syntax, structure, and semantics. In this core metamodel, the type “Unit” is defined to capture the IT resource components (e.g., database systems or operating systems). The function of a resource component is defined via Capabilities attached to its representative Unit; its require￾ments are defined by formal Requirement specifications on the Unit. Algorithm 2 COMB Input: ResourceList, WorkflowList, UtilityFunction Procedure: Evaluate the computing complexity C for current case if C < Cthreshold then (n1, ..., nm)=IterationbasedCalculation(ResourceList, WorkflowList) else (n1, ..., nm) =OptimizedSolutionCalculation (ResourceList, UtilityFunction, WorkflowList) end if Output (n1, n2, ..., nm) Two kinds of relationships are defined in the core meta￾model: HostingLink and DependencyLink. HostingLink spec￾ifies that one Unit will be the host for another Unit (e.g., a server will be the host for an operating system). These links are restricted according to the Capabilities of the hosting Unit and the Requirements of the hosted Unit. DependencyLink specifies that one Unit (the source) has some (non-hosting) dependency on another Unit (the target); again, these are restricted according to the Requirements of the source and the Capabilities of the target. The core metamodel is further extended by domain-specific metamodels; for example, server, operating system, and database domains can be further defined. The defined HostingLink and DependencyLink are directly used for our workflow mapping as described in Section II. Based on these metamodels, an implementation of this SOA deployment framework has been built to help create SOA deployment topologies [11]. B. Weak-Point Analysis Tool As depicted in Fig. 9, our weak-point analysis tool is added to the SOA deployment framework. We use BPEL to specify business workflows, which are further mapped over the SOA deployment topology. Business workflows can be described in two ways: executable business workflows that model the actual behavior of a participant in a business interaction; or abstract business workflows that fulfill a descriptive role and usually hide some of the concrete operational details. BPEL business workflows refer here to abstract workflows, and therefore do not capture detailed interaction behaviors. As described in Sections II and III, the tool includes three modules. The Workflow Specification Module takes a deploy￾ment topology and business workflows expressed in BPEL as inputs, and constructs the workflow-resource relationship matrix. The Weak-Point Analysis Module uses this matrix to identify availability weak points in the deployment topology, and produces HA enhancement parameters. Finally, using these parameters, the HA Pattern Mapping Module generates proper patterns for each weak point and automatically trans￾forms the SOA deployment topology. In the Weak-Point Analysis Module, two methods are im￾plemented: the exhaustive iteration method and our weak-point analysis methodology