Towards Realizing Dynamic QoS-aware Web Service Composition

George BaryannisSupervisor: Dimitris Plexousakis

Towards Realizing Dynamic QoS-aware

Web Service Composition

Computer Science DepartmentUniversity of Crete

Institute of Computer ScienceFoundation for Research &

Technology - Hellas

PhD Symposium, ECOWS ‘10

OutlineIntroduction• Research on Web Services• Formal Specification of Web services and service compositions• Automated Web Service Composition

Formal Web Service Specifications• Addressing the Frame Problem• The Ramification and Qualification Problems in Web Service Specifications• Automatic Derivation of Composite Specifications

Automated Web Service Composition• Requirements for Automated Web Service Composition• Classification and Comparison of Existing Approaches• QoS-Awareness, Dynamicity and Scalability in AI Planning techniques

Research Plan & Conclusions

2Towards Realizing Dynamic QoS-aware Web Service Composition George Baryannis

Research on Web Services

• The last decade has seen an exceptional wealth of research on service-related topics

• European Union FP6 and FP7 funded projects and networks

• Research covers the full life-cycle of a Web service or a Service-based Application:– Service description– Service discovery– Service composition– Service deployment

Towards Realizing Dynamic QoS-aware Web Service Composition George Baryannis 3

− Service execution− Service monitoring− Service adaptation

Formal Specification of Web Services

• Complete formal specifications are crucial for both– Service providers, to advertise more effectively the offered services– Service consumers, to make informed choices by knowing the exact

way in which a service is expected to perform• Automatically processing specifications facilitates faster

service matchmaking and composition– Provided that a right balance between formality and tractability is

achieved• A series of issues need to be addressed

– The frame, ramification and qualification problems– The problem of automatically deriving specifications for service

compositions


Automated Web Service Composition

• Service composition is the process of combining and coordinating a set of services in order to achieve functionality unachievable by any single service

• Many approaches that involve automation have been proposed, with varying degrees of success

• We conducted an extensive comparative literature review based on a series of requirements– No approaches satisfy the complete spectrum of said requirements– AI Planning techniques seem to be more successful

• The following issues were identified– Lack of dynamicity in existing AI Planning approaches– Introducing QoS-awareness in AI Planning techniques– Providing a detailed account of how scalability may be achieved







The Frame, Ramification and Qualification Problems


• A common characteristic of major Web service description frameworks, such as OWL-S and WSMO, is the use of logic-based knowledge representation for the description of service functionality (IOPEs)

• This makes them vulnerable to three well-known problems– The Frame Problem: how to state, in a concise way, that nothing

else changes, except when stated otherwise– The Ramification Problem: how to represent and infer

information about the knock-on and indirect effects of an action or an event

– The Qualification Problem: how to list all preconditions that must be satisfied for an action to have a desired effect and how to update them when new statements become part of our knowledge

Addressing the Frame Problem


• The Frame Problem stems from explicitly stating which predicates or functions each procedure (in our case, service) does not change– Instead, we can state which services change each predicate or

function– Extend first-order predicate logic with:

• Special predicate Occur, of arity 1 and special variable α• Occur(α) is true iff the service denoted by variable α has executed

successfully

• This solution was successfully applied to OWL-S service descriptions– An algorithm was implemented, to automatically transform existing

service descriptions accordingly• No effort has been made to address the qualification and

ramification problems in the same context

The Ramification Problem in Web Service Specifications (1)


• We want to create a specification for a money withdrawal service:– The balance of the account should at least be equal to the amount of money about

to be withdrawn. Also, the credit card used for the withdrawal must be valid.– There is a daily limit for the amount of money an account holder can withdraw in a

day. – A successful execution means that the new balance is equal to the old one minus

the amount of money withdrawn. – Also, the total money withdrawn for the day should be increased by the same

amount.



• As it has been shown in previous work, such a specification is incomplete due to the frame problem– A representation that handles the frame problem is shown below

• Suppose that a ramification of the increase in the total amount withdrawn from the account due to the execution of the service is that if the daily limit is surpassed, the credit card must be temporarily made invalid.



• The lack of knowledge of an indirect effect may lead to the assumption that a composition is valid and correct while that particular effect may contradict a precondition of another participating service

• The specification below precludes any indirect effects. How do we include the previously mentioned ramification?

The Qualification Problem in Web Service Specifications


• Suppose that we are told that there is an initial period after the initial activation of a credit card when it cannot yet be used for purchases (i.e. no money can be withdrawn) in other words a card cannot be valid and at the same time be in a provisional state.

• How can this new knowledge, that may be expressed as

be assimilated in the existing specification? What new precondition must be inferred? What if this leads to an inconsistent specification (especially in the case of composite services)?

Automatic derivation of composite specifications (1)


• No service description frameworks or service composition approaches attempt to derive a complete specification of the inputs, outputs, preconditions and effects (IOPEs) that should be provided to a service consumer– Such specifications promote and facilitate the reusability of composite

services– They also allow for the detection of inconsistencies to decide whether a

set of services is composable• The composite specification is directly linked to the composition

schema and the way the participating services are orchestrated– Which part of the participating services’ specifications should be

exposed?• The full set of preconditions and effects of all participating services?• Only the preconditions of the services whose inputs are exposed (and the

postconditions of the services whose outputs are exposed)?

Automatic derivation of composite specifications (2)


• Let’s examine the following simple example:

• The solution should be somewhere in the middle: find the minimal subset of the participating services’ specifications that should form the composite specification– Insight on this matter can be given by programming language specifications,

weakest precondition and the Craig-Lyndon interpolation theorem

Service IInpI InpI

PreI=true PostI=true

Service AInpA OutA

PreA PostA

Service I Service A Service I

Service CPreC=PreI=true PostC=PostI=true

??? ???






Requirements for Automated Web Service Composition (1)

16George Baryannis

1. Automation– Minimize user intervention and accelerate the process– Approaches should be at least partially automated

2. Dynamicity– Produce an abstract composition schema with service placeholders instead of

actual services, which are only bound at run-time– Dynamic schemas can be consistent and executable long after their initial

design

3. Semantic Capabilities– Allow for more efficient service matchmaking– Semantic descriptions should be exploited, if available

4. QoS-Awareness– Composite services that not only provide the required functionality, but also

guarantee the best possible quality

5. Non-determinism– Support for choice constructs (such as if-then-else) or loops (such as repeat-

while)

Requirements for Automated Web Service Composition (2)


6. Partial observability– Deal with incomplete (or even wrong) information about the initial world

state

7. Scalability– Ensure acceptable performance even when the number of candidate

services or the complexity of the composition schema rise

8. Correctness– Ensure that certain desired properties hold, such as the fact that a certain

set of outputs is guaranteed to be produced given a certain set of inputs and conditions.

9. Domain independence– The same approach should be applicable to different domains, allowing for

the solution of a broad range of problems

10. Adaptivity– Adapt to any unexpected or desired changes in order to satisfy new

requirements or fit to new situations dictated by the environment

Classification of Composition Approaches


The classification is based on the way service compositions are represented

1. Workflow-based approaches– Use workflow languages such as BPEL or YAWL to exploit the fact

that a composite service is conceptually similar to a workflow

2. Model-based approaches– Employ modeling languages (Petri-nets, UML, FSMs) to

represent service compositions

3. Mathematics-based approaches– Use logics, calculi or algebras to represent service compositions

4. AI Planning– Handle service composition as an AI planning problem

Comparison


• Automation, Semantic Capabilities, Correctness and Domain Independence have been well researched, in general

• Non-determinism and Partial Observability have only been successfully handled in more recent work in the ASTRO framework

• Adaptation is out of the scope of this particular survey• Dynamicity, QoS Awareness and Scalability have not been adequately explored, especially when

it comes to service composition as AI planning

QoS-Awareness in AI Planning techniques


• QoS-Awareness has been largely ignored in approaches that employ AI planning techniques

• Introducing QoS-Awareness involves at least 3 fundamental decisions:1. Choose the AI planning technique that will be adapted to be

QoS-aware2. Choose the QoS model that will be employed3. Decide on which phases of the composition process to include

QoS characteristics• QoS aspects can be used to speed up the plan generation by pruning

the search space (excluding services that don’t meet QoS thresholds)• QoS aspects can be included in the planning goals, although, at first

glance, this would complicate the goals and make them harder to satisfy

Dynamicity in AI Planning techniques


• The vast majority of AI Planning approaches produce static composition schemas

• Only Peer and Klusch include some form of dynamicity. Peer’s approach supports generating new plans but only at design time

• OWLS-XPLAN (Klusch et al.) and its replanning module are a step in the right direction– However, it offers no support for nondeterminism and partial

observability, QoS-awareness, scalability and any proof of correctness

• It is challenging to explore how dynamicity at run-time via replanning can be applied to planning techniques that support most of these features, such as planning as model checking

Scalability in Automated Web Service Composition approaches


• While some of the approaches explicitly mention scalability and provide details, the majority does not provide a comprehensive examination of the problem– Any scalability claims should be supported by experimental

evaluation• Achieving scalability involves identifying causes of

inefficiency and attempting to remove them– This should be done only after evaluating the significance

of limiting the approach that way– Trying to achieve scalability may sometimes lead to

crippling the overall applicability of the approach.






Research Plan (1)


• We have identified two major goals for our research plan• The first goal: define and formalize a novel specification

language for Web services and service compositions– Taking into account the frame, ramification and qualification

problems, similarly to the way Kakas et al. provided Modular-E, an action language that solves these problems by definition

– Providing support for the derivation of composite specifications based on a composition schema

• Two initial milestones are identified1. Explore the challenge of automatically deriving composite

specifications2. Identify the cases where the frame, ramification and

qualification problems appear and examine the effects they may have

Research Plan (2)


• The second goal: design and implement a dynamic, QoS-aware automated service composition framework– This framework will rely on the results of the first goal

• Services will be specified using the language produced in the first goal

• The same language will be used to describe the resulting composition

• A tentative roadmap for this goal is the following:– Introduce QoS characteristics in the specification language

by exploring the work of Kritikos and Plexousakis on OWL-Q– Based on the literature review, select the most successful

planning technique (e.g. planning as model checking) and attempt to introduce dynamicity by applying run-time replanning methods.

Conclusions


• Two major problems in the fields of service description and composition were identified– The inability of current service description and composition frameworks

to provide complete formal service specifications– The lack of an effective Web service composition approach that

combines most desired requirements, such as QoS-awareness and dynamicity

• Addressing these major issues is crucial for the realization of primary principles of Service-Oriented Architecture such as service reusability, discoverability and composability

• Realizing scalability, dynamicity and QoS-awareness in automated Web service composition may prove to be the necessary incentive for the wider adoption of automated techniques– Of course, the eventual adoption of such approaches depends on the

availability of semantically-enabled services and effective discovery techniques

Questions


BACKUP SLIDES

28Towards Realizing Dynamic QoS-aware Web Service Composition

George Baryannis

Composition Models (1)


• Orchestration: – a description of how the services that participate in a composition interact at the message level,

including the business logic and the order in which the interactions should be executed. – An orchestration should define which message is sent when and by which participating service.

• Choreography: – associated with the globally visible message exchanges, rules of interaction and agreements that

occur between multiple business processes. – Partners are in full control of their internal business processes and do not expose them to other

partners, unless they are essential to the communication• Coordination:

– involves temporarily grouping a set of service instances following a coordination protocol. This protocol dictates the way participating services interact and also the outcome of the interaction, whether it was successful or not.

– All communication is done through a third party, called the coordinator, who ultimately is responsible for the upholding of the protocol and the decision and dissemination of the outcome, once the activity ends.

• Component Model:– involves the actual linking between inputs and outputs when services are being composed

together.

Composition Models (2)


• Orchestration vs. Composition Synthesis – Composition synthesis concerns synthesizing a specification of how to coordinate

the component services to fulfill the client request, generating a plan that dictates how to achieve a desired behavior by combining the abilities of multiple services.

– Orchestration is about executing the result of composition synthesis by coordinating the control and data flow among the participating services and also about supervising and monitoring that execution.

• Orchestration vs. Choreography: – Multi-party business process execution (in choreographies) vs. creation of a

business process executed by a single party (in orchestrations).– In choreographies, the internal processes of partners are not exposed– Although orchestration and choreography can be used separately to implement a

service composition, their different viewpoints can be combined for a more complete representation.

– Orchestration can be used to describe participating services in the lower abstraction level and choreography can give a higher level description of how these orchestrations interact with each other and capture the complex conversations between them in order to realize the goal set by the requester.

Workflow-based Service Composition: The PAWS framework (Ardagna et al.)

31

Constraints usually refer to QoS aspectsand are expressed as SLAs

Faulty services are replaced by other candidate servicesand recovery actions areenabled

Towards Realizing Dynamic QoS-aware Web Service Composition

George Baryannis

Model-based Service Composition: The SAM system (Brogi and Corfini)

32

• Web services are represented as CPR Nets, a Petri Net variant– OWLS2PNML translates OWL-S service descriptions to CPR Nets

described using Petri Net Markup Language (PNML)• A two-step analysis is performed:

– Functional: the requester expresses the inputs and outputs of the desired service and SAM attempts to incrementally produce the outputs, starting from the inputs, resulting in a minimal set of participating services

– Behavioral: if the request is purely functional, SAM attempts to create a CPR Net that represents the behavior of the composite service and checks if it is correct. If the request contains a behavior represented as a CPR Net, the bisimilarity of the two Petri Nets is checked.


George Baryannis

Mathematics-based Service Composition: The SPICE ACE engine (Lecue et al.)

33

• Requests are expressed in a formal manner, containing IOPEs, non-functional properties, related ontological schemas and so on.

• The composite services returned by the Composition Factory are ranked based on aggregate non-functional property values and/or semantic similarity between the requested and the produced composite serviceTowards Realizing Dynamic

QoS-aware Web Service Composition

George Baryannis

Mathematics-based Service Composition: The SPICE ACE engine (Lecue et al.)

34

• The authors exploit the fact that OWL-S is based on Description Logics and attempt to compute similarities between such DL descriptions

• Similarities are expressed as causal links (exact, plugin, subsumption, intersection and disjoint, and a matrix of all possible links is constructed

• The causal link matrix is extended with non-functional properties (CLM+)

• Using the CLM+ the output is attempted to be achieved incrementally starting from the input.


George Baryannis

Service Composition as AI Planning


• Given:– S, the set of all possible world states, with s0 the initial state– G, the set of goal states we are attempting to reach– A, the set of all possible actions that can be performed– Γ, a transition relation that describes the resulting state, when an action is executed

at a given state• Then AI planning (in the classical sense) is the problem of reaching G,

starting from s0 by executing actions ∈ A that lead to transitions ∈ Γ from one state ∈ S to another

• AI Planning techniques categorization1. Classical Planning: state-space, or plan-space planning2. Neoclassical Planning: graph-based planning, propositional satisfiability and

constraint satisfaction3. Heuristics and Control Strategies: Partial Order Refinement, Hierarchical Task

Networks4. Other planning techniques: abductive planning, planning based on model

checking

Available service

operations

Messages sent and received

Initial set of inputs

Final set of outputs

Internal process

description

Service Composition as AI Planning: OWLS-XPLAN (Klusch et al.)

36

OWL-S descriptions translated to PDDXML,an XML variant of PDDL

The planner combines graph-planning, to ensure that a planis always found, and HTN, totake advantage of decompo-sition


George Baryannis

Service Composition as AI Planning: The ASTRO project (Pistore et al.)

37

State transition systems describe all possible behaviors of a BPEL process and support non-determinism and partial observability

EaGLe is a formal language for the representation of planning goals

This formula represents all the actions of the component services as they are controlled by the composite service


George Baryannis

More on the ASTRO project (1)

38Towards Realizing Dynamic QoS-aware Web Service Composition George BaryannisBPEL-to-STS transformation

More on the ASTRO project (2)Expressing requirements in EaGLe


Documents

Towards Realizing Dynamic QoS-aware Web Service Composition