The rest of the paper is organized as follows.In Section Workflow Specification Module Component II,we describe the basic structure of our availability weak- failure point analysis methodology.In Section III,we present our Availability SOA deployment topology behavior reauirements algorithm for calculating a near-optimal solution.In Section Workflow-based iVVonKTlov Vorkflowy Vorktlowl HA capacity IV,we describe our implementation and evaluate experimental mapping Business mapping results.In Section V,we study related work.In Section VI, matrix checking workflows we conclude the paper and discuss future work. HA Weak Point Analysis Module No Yes are II.WEAK-POINT ANALYSIS Overall utility function Optimal solution calculation In this work,we define a three-level workflow hierarchy for HA enhancement for HA enhancement to enable work-point analysis:business workflow,application The optimal HA enhancement workflow and IT resource workflow.Firstly,we assume that parameters for each IT resource business workflows are defined in some machine-readable format,such as Business Process Execution Language(BPEL) HA Pattern Mapping Module [6],and that a business workflow includes "pointers"(e.g., HA pattern HA pattern HA enhanced SOA Web service references)to the services that support the various repository mapping deployment topology steps of this business workflow.As services are implemented by given applications,we define an application workflow as the Fig.1.Architecture for workflow-based weak-point analysis application chain that supports the given business workflow. Furthermore,secondly,as applications should be supported Worktow1 by their hosted underlying IT resources,we assume that the ws Relafionship hosting and dependency relationships among the various IT Workfow2 resources are also available in some machine-readable format. WsWs either as standard deployment documents from the design phase,or as the result of a discovery process running against WAR EAR the IT infrastructure.By analyzing the hosting and dependency EAR WAREAR relationships,an IT resource workflow is defined as the IT resource chain that supports a given application workflow that further supports the given business workflow. WAS APP Server Server Based on these assumptions,our weak-point analysis Workfow2 methodology can first construct relationships between business WAS APP workflows and IT resources by workflow mapping:then,based WAS APP Server Server on these relationships,it can calculate the optimized HA en- hancement recommendation for the current SOA deployment Fig.2.Workflow mapping over the SOA deployment topology topology. The main building blocks of our methodology are depicted in Fig.1;they are grouped in three modules. relationships is inadequate:business workfow branching and implicit dependency discovery need to be considered. A.Workflow Specification Module Business workflow branching describes a situation when The Workflow Specification Module maps business work- the business workflow contains conditional branches and the flows to IT resources,where each business workflow is anno- branch to be selected next depends on current conditions.For tated with availability requirements.In this paper,availability a business workflow that implements complex business func- requirements are defined by an uptime ratio,which represents tions,it is common to have several conditional branches.Fig.3 the percentage of time a business workflow is available;for illustrates a workflow with two conditional branches at points example,99.9%means that end users tolerate a downtime A and B.When this workflow runs,only one path through the of at most 86.4 seconds per day for this workflow.Such workflow is executed.Therefore,modeling business workflows availability requirements are typically specified by business from an HA standpoint poses a problem in case of branching. architects.The mapping is performed from the business level On the one hand,the availability requirement is specified on to the application and IT resource levels by inspecting the the overall business workflow;on the other hand,only a subset hosting and dependency relationships that are defined in the of the service components are executed for any given runtime SOA deployment topology. invocation,depending on branch conditions. As Fig.2 shows,through the hosting relationships specified Under these circumstances,mapping business-level HA over the SOA deployment topology,Workflow I and Work-requirements to applications and IT resources is not straight- flow 2 are mapped to the IT resource level.However,in a forward.To deal with this problem,we break up a com- more complex scenario,direct mapping based only on hosting plex workflow into several sub-workflows,where each sub-The rest of the paper is organized as follows. In Section II, we describe the basic structure of our availability weak￾point analysis methodology. In Section III, we present our algorithm for calculating a near-optimal solution. In Section IV, we describe our implementation and evaluate experimental results. In Section V, we study related work. In Section VI, we conclude the paper and discuss future work. II. WEAK-POINT ANALYSIS In this work, we define a three-level workflow hierarchy to enable work-point analysis: business workflow, application workflow and IT resource workflow. Firstly, we assume that business workflows are defined in some machine-readable format, such as Business Process Execution Language (BPEL) [6], and that a business workflow includes “pointers” (e.g., Web service references) to the services that support the various steps of this business workflow. As services are implemented by given applications, we define an application workflow as the application chain that supports the given business workflow. Furthermore, secondly, as applications should be supported by their hosted underlying IT resources, we assume that the hosting and dependency relationships among the various IT resources are also available in some machine-readable format, either as standard deployment documents from the design phase, or as the result of a discovery process running against the IT infrastructure. By analyzing the hosting and dependency relationships, an IT resource workflow is defined as the IT resource chain that supports a given application workflow that further supports the given business workflow. Based on these assumptions, our weak-point analysis methodology can first construct relationships between business workflows and IT resources by workflow mapping; then, based on these relationships, it can calculate the optimized HA en￾hancement recommendation for the current SOA deployment topology. The main building blocks of our methodology are depicted in Fig. 1; they are grouped in three modules. A. Workflow Specification Module The Workflow Specification Module maps business work- flows to IT resources, where each business workflow is anno￾tated with availability requirements. In this paper, availability requirements are defined by an uptime ratio, which represents the percentage of time a business workflow is available; for example, 99.9% means that end users tolerate a downtime of at most 86.4 seconds per day for this workflow. Such availability requirements are typically specified by business architects. The mapping is performed from the business level to the application and IT resource levels by inspecting the hosting and dependency relationships that are defined in the SOA deployment topology. As Fig. 2 shows, through the hosting relationships specified over the SOA deployment topology, Workflow 1 and Work- flow 2 are mapped to the IT resource level. However, in a more complex scenario, direct mapping based only on hosting Fig. 1. Architecture for workflow-based weak-point analysis Fig. 2. Workflow mapping over the SOA deployment topology relationships is inadequate: business workflow branching and implicit dependency discovery need to be considered. Business workflow branching describes a situation when the business workflow contains conditional branches and the branch to be selected next depends on current conditions. For a business workflow that implements complex business func￾tions, it is common to have several conditional branches. Fig. 3 illustrates a workflow with two conditional branches at points A and B. When this workflow runs, only one path through the workflow is executed. Therefore, modeling business workflows from an HA standpoint poses a problem in case of branching. On the one hand, the availability requirement is specified on the overall business workflow; on the other hand, only a subset of the service components are executed for any given runtime invocation, depending on branch conditions. Under these circumstances, mapping business-level HA requirements to applications and IT resources is not straight￾forward. To deal with this problem, we break up a com￾plex workflow into several sub-workflows, where each sub-