Towards Realizing Dynamic QoS-aware Web Service Composition

Towards Realizing
Dynamic QoS-aware
Web Service Composition
PhD Symposium, ECOWS ‘10

George Baryannis
Supervisor: Dimitris Plexousakis

Computer Science Department Institute of Computer Science
University of Crete Foundation for Research &
Technology - Hellas

Outline
Introduction
• 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

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

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 execution
– Service discovery − Service monitoring
– Service composition − Service adaptation
– Service deployment
Towards Realizing Dynamic QoS-aware Web Service Composition George Baryannis 3

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


• 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

Outline
Introduction

Specifications



George Baryannis 6
Composition

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:
InpI InpI
Service I InpA
Service A
OutA

PreI=true PostI=true PreA PostA

Service I Service A Service I
PreC=PreI=true PostC=PostI=true
Service C
??? ???
• 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

Outline
Introduction

Specifications



George Baryannis 15
Composition

Requirements for
Automated Web Service Composition (1)
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) George Baryannis 16

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-aware
2. Choose the QoS model that will be employed
3. 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.

Outline
Introduction

Specifications



George Baryannis 23
Composition

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 identified
1. Explore the challenge of automatically deriving composite
specifications
2. 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

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

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.)

Faulty services are replaced
Constraints usually by other candidate services
refer to QoS aspects and recovery actions are
and are expressed as SLAs enabled

Composition

Model-based Service Composition:
The SAM system (Brogi and Corfini)
• 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.

Composition

Mathematics-based Service Composition:
The SPICE ACE engine (Lecue et al.)
• 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
service
Composition

Mathematics-based Service Composition:
The SPICE ACE engine (Lecue et al.)
• 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.

Composition

Service Composition as AI Planning
Messages Initial set
sent and of inputs
• Given: received
– S, the set of all possible world states, with s0 the initial state set of
Final
Available – G, the set of goal states we are attempting to reach outputs
service
operations – A, the set of all possible actions that can be performed
– Γ, a transition relation that describes the resulting state, when an
Internal
process action is executed at a given state
description
• 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 categorization
1. Classical Planning: state-space, or plan-space planning
2. Neoclassical Planning: graph-based planning, propositional
satisfiability and constraint satisfaction
3. Heuristics and Control Strategies: Partial Order Refinement,
Hierarchical Task Networks
4. Other planning techniques: abductive planning, planning based on
model checking

Service Composition as AI Planning:
OWLS-XPLAN (Klusch et al.)
OWL-S descriptions translated to PDDXML,
an XML variant of PDDL

The planner combines graph-
planning, to ensure that a plan
is always found, and HTN, to
take advantage of decompo-
sition

Composition

Service Composition as AI Planning:
The ASTRO project (Pistore et al.)
State transition systems describe all possible
behaviors of a BPEL process and support non- EaGLe is a formal language for the
determinism and partial observability
representation of planning goals

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

Composition

More on the ASTRO project (1)

BPEL-to-STS transformation

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


Towards Realizing Dynamic QoS-aware Web Service Composition

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Towards Realizing Dynamic QoS-aware Web Service Composition

Semelhante a Towards Realizing Dynamic QoS-aware Web Service Composition (20)

Mais de George Baryannis

Mais de George Baryannis (6)

Towards Realizing Dynamic QoS-aware Web Service Composition