QoS-aware middleware for Web services composition

Abstract

Abstract-The paradigmatic shift from a Web of manual interactions to a Web of programmatic interactions driven by Web services is creating unprecedented opportunities for the formation of online Business-to-Business (B2B) collaborations. In particular, the creation of value-added services by composition of existing ones is gaining a significant momentum. Since many available Web services provide overlapping or identical functionality, albeit with different Quality of Service (QoS), a choice needs to be made to determine which services are to participate in a given composite service. This paper presents a middleware platform which addresses the issue of selecting Web services for the purpose of their composition in a way that maximizes user satisfaction expressed as utility functions over QoS attributes, while satisfying the constraints set by the user and by the structure of the composite service. Two selection approaches are described and compared: one based on local (task-level) selection of services and the other based on global allocation of tasks to services using integer programming.

Preventing Temporal Violations in Scientific Workflows: Where and How

“…However, to ensure that the weather forecast can be broadcast on time (e.g., 6:00 p.m. every day), all scientific workflow instances must be completed within specific time durations. Therefore, a set of global and local temporal constraints is normally set as QoS contracts or Service Level Agreement (SLA) [2], [24] at workflow build time to ensure the efficiency of workflow execution. For the example workflow segment, to guarantee that the radar data can be collected in time and then transferred for further processing, an global upper bound temporal constraint UðW 1 Þ is assigned and specified as 60 minutes; this means that the duration of the entire radar data collection process must be less than or equal to it.…”

“…These sophisticated processes are modeled or redesigned as scientific workflow specifications at the build-time modeling stage. The specifications normally contain a large number of computation and data-intensive activities and their nonfunctional requirements such as Quality of Service (QoS) constraints [24], [26]. Then, at the runtime instantiation stage, scientific workflow instances are normally created with initial resource allocation such as static scheduling and advance reservation [41], [48].…”

DSOL: a declarative approach to self-adaptive service orchestrations

“…Other ASC approaches start from an abstract "template process", expressed either in BPEL, e.g., [48,49], or as a Statechart, e.g, [50] and, taking into consideration QoS constraints and end-user preferences, select the best services among those available to be actually invoked. As mentioned in the Introduction, these approaches focus on a relatively simpler problem than DSOL, as they focus on "selecting the right services at run-time", leaving to the service architect the (complex) task of defining the abstract "workflow" to follow.…”

Evolutionary composition of QoS-aware web services: A many-objective perspective

“…Although this problem was originally formulated as a single-objective optimisation problem, notice that multiple, often conflicting QoS properties need to be simultaneously considered to address this problem (Zeng et al, 2004;Wada et al, 2012). For example, availability, response time, throughput or invocation cost can be clearly opposed, e.g.…”