In this paper, we propose a proactive approach that searches for an optimal plan with a lower risk of violating the constraints in the event that re-composition is needed. Our approach introduces replaceability as a metric applied to plan composition. We define replaceability as the degree to which a plan or a service is exchangeable with one that accomplishes the same goal or processing, respectively.
We significantly reduce the potential violation of constraints during plan execution that can result from QoS changes requiring service reselection. A major challenge is the impact of service reselection on the plan, since substituting a service for one who’s QoS values have caused the plan to violate at least one constraint consumes time. Pre-knowledge of alternatives based on replaceability values counteracts this added factor and reduces the time spent in the process.
This paper proposes an approach to composing web services that both performs reselection and avoids the violation of QoS constraints after replanning by defining and evaluating a placeability property. Replaceability factors directly into the algorithm’s original service selection process considering all QoS constraints. Introducing Replaceability into Web Service Composition
Existing problem with such web service composition is that QoS values can also change at execution time from original estimations. The service may become unavailable, unreliable, or no longer provide the best solution fit. Other services must be dynamically evaluated to complete the plan. These services are chosen from the same abstract type, a group of services with functionalities that can substitute or replace any service in changing.
QoS values can disrupt the expected compliance of the plan to maintain certain thresholds, such as costs and response time. The impact is even more dramatic if the service lies within a loop with a large number of iterations in the composition. These non-periodic changes require a dynamic planning environment in which certain events force reselection from the physical services of the same abstract type(s) in which the service change(s) occurred to form a new, yet compliant plan.
QoS attributes are increasing-dimension or decreasing dimension. Availability and reliability are increasing-dimension attributes because the resulting plan should incorporate the highest values associated with them. Cost and response time are decreasing-dimension attributes because the plan should incorporate the lowest values associated with them. Techniques for web services composition based on QoS optimization aim to maximize increasing-dimension attributes and minimize decreasing-dimension attributes, while at the same time maintaining any quality constraints imposed on the plan itself.
This paper proposes an approach to composing web services that both performs reselection and avoids the violation of QoS constraints after replanning by defining and evaluating a replaceability property. Replaceability factors directly into the algorithm’s original service selection process considering all QoS constraints.
Our approach focuses on staged composition because it provides loose coupling between the services and better fits the typical service-oriented architecture. Fig. 2 shows the phases of staged composition. The first phase generates an abstract workload based on web service types, called a logical composition is a set of K abstract workflows selected after logical composition. The function RankAW ranks the abstract workflows.
Given a specific feature or function needed from an abstract service type, several concrete service instances implementing the feature may be available in the second phase selects the appropriate web service instances to form the physical composition where WF ¼ fW1; . . . ;WLg is a set of L executable workflows final runtime phase executes the selected concrete plan. We target the physical composition in which replanning is performed.
The ranking of RIW of physical compositions is normally based on QoS attributes since they are the distinguishing factor for service instances. Table 1 shows the aggregation function for each QoS attribute, given four workflow patterns in which loop size is determined by annotating the loops with the number of iterations (k). N, M, and P are the number of sequential, probabilistic, and parallel invocations, respectively. Thus, each aggregation function calculates the QoS attribute value for the workflow depending on the pattern of execution of its services.