www.s-cube-network.eu
S-Cube Learning Package
Automated Service Composition:
AI planning based composition of pervasive process fragments
Fondazione Bruno Kessler (FBK),
University of Stuttgart (USTUTT)
Annapaola Marconi, FBK
Learning Package Categorization
S-Cube
Adaptable Coordinated
Service Compositions
Automated Service Composition
AI planning based composition of
pervasive process fragments
Learning Package Overview
Problem Description
Application Representation
Automated composition of process-fragments
Evaluation and discussion
Related Works
Conclusions
Pervasive applications require processes to be discovered and used
depending on the context (location, time, situation, user preferences)
Problem Description
Pervasive process
fragments allow to model
incomplete and contextual
process knowledge
Automated composition
allow to synthesize a
process on-the-fly given a
set of components
Automated composition of pervasive process fragments
into a complete executable process, according to a goal
and a specific context
Unload from airplane Check box content
Charge and collect tax
Take to baggage claim
Box at the Airport Flow
Goal: Release box
Check box origin
Scenario: Box at the airport (1)
Unload from airplane Check box content
Charge and collect tax
Take to baggage claim
Box at the Airport Flow
Goal: Release box
Check box origin
Scenario: Box at the airport (2)
The process knowledge for
handling a box is distributed at
different locations in the airport
and depends on context information.
The complete executable flow model for treating a particular box is not
known from the beginning.
What is known is the goal of the flow, release the box to its owner, and
the steps/milestones that the box should go through to achieve its goal,
e.g. unload from airplane, check box origin, charge and collect tax
The precise flow model that can achieve this goal is created at
execution time, based on the available fragments and on the specific
context (e.g. content of the box, box origin, arriving airport )
Goals
Primary: Box.released
Recovery: Box.disposed
Do
mai
n
Kn
ow
led
ge
Box
Scenario: Box at the airport (3)
Domain knowledge represent the stable and abstract common
knowledge of the context and the of the processes for a specific
pervasive application.
Object diagrams model the macro steps/milestones that a process
should go through
Goals represent the target of the process execution and can contain
preferences among goals and recovery goals
Object Diagrams
Pervasive Process Fragments
Fra
gm
ent
modelin
g
Goals Object Diagrams
Primary: Box.released
Recovery: Box.disposed
Do
mai
n
Kn
ow
led
ge
Box
Scenario: Box at the airport (3)
Pervasive Process Fragments
represent the dynamic and
concrete process knowledge:
They are concrete processes
discovered at run time and
targeted to a specific context
Where?
What?
Who?
?
Box Delivery Process
Pervasive Process Fragments
Pro
ce
ss e
xe
cu
tio
n
Fra
gm
ent
modelin
g
Goals
Context
Object Diagrams
Primary: Box.released
Recovery: Box.disposed
Verona International Airport
Flammable content
DHL
Do
mai
n
Kn
ow
led
ge
Box
Scenario: Box at the airport (3)
Where?
What?
Who?
Box Delivery Process
Pervasive Process Fragments
Pro
ce
ss e
xe
cu
tio
n
Fra
gm
ent
modelin
g
Goals
Context
Object Diagrams
Primary: Box.released
Recovery: Box.disposed
Verona International Airport
Flammable content
DHL
Co
mm
on
K
no
wle
dge
Box
Scenario: Box at the airport (3)
Fragment
selection
? ?
Learning Package Overview
Problem Description
Application Representation
Automated composition of process-fragments
Evaluation and discussion
Related Works
Conclusions
Application Representation
Goals
Stable and
abstract
Pervasive process
fragments annotated with
preconditions and effects
(domain knowledge)
P: … P: …
E: …
E: …
Pro
ce
ss
kn
ow
led
ge
Dynamic and
concrete
Do
ma
in
kn
ow
led
ge
Object diagrams
Object diagrams
Goals
Pervasive process
fragments annotated with
preconditions and effects
(domain knowledge)
P: …
P: …
E: …
E: …
Object diagrams
An object diagram is a simple state transition system
containing states which encode properties of the
entity, and transitions between states triggered by
events.
Research work on object diagrams:
Piergiorgio Bertoli, Raman Kazhamiakin, Massimo Paolucci, Marco Pistore, Heorhi Raik, Matthias
Wagner: Control Flow Requirements for Automated Service Composition. ICWS 2009: 17-24
Raman Kazhamiakin, Massimo Paolucci, Marco Pistore, Heorhi Raik: Modelling and Automated
Composition of User-Centric Services. OTM Conferences (1) 2010: 291-308
Object diagrams (2)
box at the
airport tax
invoice
Object diagrams in the Box at the airport scenario
The diagrams move from one configuration to another on events.
For example, if the box is in configuration INIT and receives the event unload, it will
move to configuration UNLOADED
Goals
Goals
Pervasive process
fragments annotated with
preconditions and effects
(domain knowledge)
P: …
P: …
E: …
E: …
Object diagrams
We express goals in terms of entities and their evolution.
Goals can be used to specify desirable situations to be
reached at the end of the execution, as well as rules that
should be maintained throughout the execution.
Research work on control flow goals:
Piergiorgio Bertoli, Raman Kazhamiakin, Massimo Paolucci, Marco Pistore, Heorhi Raik, Matthias
Wagner: Control Flow Requirements for Automated Service Composition. ICWS 2009: 17-24
A goal is defined with the following generic constraint template:
where
ss(o) defines the fact that diagram o is in configuration s, and ee(o) the fact that event e of o has taken place.
Goals (2)
Composition goal
T => readys(box) ≻ disposeds(box)
box at the
airport tax
invoice
Primary Goal Recovery Goal
Control flow goal for the Box at the airport scenario
The goal for the box is to reach the configuration READY. If this is not possible, we
at least want to have the box disposed of, therefore in configuration DISPOSED.
Process fragments represent a tool for modeling
incomplete and local process knowledge.
The knowledge is incomplete since the modeler is
allowed to specify just one aspect of the entire
process, and to leave gaps in the process specification.
Fragments can be modeled by different people, and therefore may
reflect different perspectives on the same process.
The process knowledge is local, since the availability and usability of a
fragment is determined by the context. For example, the execution of a
process fragment may be bound to a certain location or to a specific
context property.
Process fragment knowledge can be integrated dynamically, either at
design-time or at run-time.
Processes are enriched with goals which specify what is pursued by the
process execution. It also requires enriching the fragments with
information on how they contribute to the outcome of the process.
Pervasive Process Fragments
Goals
Pervasive process
fragments annotated with
preconditions and effects
(domain knowledge)
P: …
P: …
E: …
E: …
Object diagrams
Pervasive process fragments
-> incomplete contextual process knowledge:
Specified in APFL = BPEL + extensions for pervasive domain
Not required to have a start activity
Control connectors may have either no source or no target
activity
Modeler has freedom to not model control connectors at all
Can contain gaps -> Region element
Research work on pervasive process fragments:
Pervasive Process Fragments (2)
H. Eberle, T. Unger, and F. Leymann, “Process fragments” in OTM 2009,
Part I, pp. 398–405.
A. Bucchiarone, A. L. Lafuente, A. Marconi, and M. Pistore, “A formalisation
of adaptable pervasive flows” in 6th Int. Workshop on Web Services and
Formal Methods (WS-FM), 2009
A. Marconi, M. Pistore, A. Sirbu, F. Leymann, H. Eberle, and T. Unger,
“Enabling Adaptation of Pervasive Flows: Built-in Contextual Adaptation” in
Proc. ICSOC 2009, pp. 445–454.
(some) APFL activities
receive
reply,
one-way invoke
two-way invoke
human
interaction
context event
event-based
exclusive
decision (pick,
apfPick)
region
Check EU origin
Receive EU origin ack
Charge tax
Receive EU origin nack
Box at baggage claim
Check box origin
Check box content
Bring to claim
Unload box
Box on carrier
Box at termina
l
Content ack
Mark box
Check content
Dispose
Unload from airplane
Bring to terminal
Take to baggage claim
P: unloadeds(box)
P: unloadeds(box) E: evaluatee(box)
P: taxeds(box) E: approvee(box)
P: unloadeds(box) E: approvee(box)
P: unloadeds(box) E: rejecte(box)
P: rejecteds(box) E: disposee(box)
P: approveds(box) E: releasee(box)
P: inits(box) P: inits(box) E: unloade box)
P: unloadeds(box)
Content nack
P: approveds(box)
Charge and collect tax
Charge tax with invoice
P: unloadeds(box) ʌ not-exists(inv) E: {evaluatee(box), createe(inv)}
Send notice of assessment
P: opens(inv)
Payment completed
P: evaluateds(box) ʌ opens(inv) E: {taxe(box), closee(inv)}
Pervasive process fragments (3)
Check box content
Unload box
Charge and collect tax
Bring to claim
Check box origin
Check EU origin
Receive EU origin ack
Charge tax
Receive EU origin nack
Box at baggage claim
Check box origin
Check box content
Bring to claim
Unload box
Box on carrier
Box at termina
l
Content ack
Mark box
Check content
Dispose
Unload from airplane
Bring to terminal
Take to baggage claim
P: unloadeds(box)
P: unloadeds(box) E: evaluatee(box)
P: taxeds(box) E: approvee(box)
P: unloadeds(box) E: approvee(box)
P: unloadeds(box) E: rejecte(box)
P: rejecteds(box) E: disposee(box)
P: approveds(box) E: releasee(box)
P: inits(box) P: inits(box) E: unloade box)
P: unloadeds(box)
Content nack
P: approveds(box)
Charge and collect tax
Charge tax with invoice
P: unloadeds(box) ʌ not-exists(inv) E: {evaluatee(box), createe(inv)}
Send notice of assessment
P: opens(inv)
Payment completed
P: evaluateds(box) ʌ opens(inv) E: {taxe(box), closee(inv)}
Pervasive process fragments (4)
box at the
airport
Activities of pervasive process
fragments can be annotated with
Preconditions: constraints on the
context where the activity can be
executed
Effects: changes that the activity
execution produces on the
context
Learning Package Overview
Problem Description
Application Representation
Automated composition of process-fragments
Evaluation and discussion
Related Works
Conclusions
Object diagrams
Pervasive
process
fragments
Composed
executable
flow
Goals
Automated
Composition Box
T => readys(box) ≻
disposeds(box)
Solution overview
Object diagrams
Pervasive
process
fragments
Composed
flow
Goals
Box
T => readys(box) ≻
disposeds(box)
OD
-2-S
TS
STS
STS
(2)
G-2
-ST
S
STS
(3)
Acti
on
Tab
le
AP
FL
-2-S
TS
(1)
Solution overview
GO
AL
Co
ns
tru
cti
on
ρ
Planning
goal
Object diagrams
Pervasive
process
fragments
Goals
Box
T => readys(box) ≻
disposeds(box)
OD
-2-S
TS
STS
STS
(2)
G-2
-ST
S
STS
(3)
Acti
on
Tab
le
AP
FL
-2-S
TS
(1)
Solution overview
GO
AL
Co
ns
tru
cti
on
ρ
Planning
goal
Background
A state transition system (STS) is a tuple
<S, S0, I, O, R, Sf, F>
where S is the set of states and S0 is the set of initial states,
I and O are the input and respectively output actions,
is the transition relation,
SF is the set of accepting states,
is the labeling function.
Composed
flow
Solution (1) pervasive process fragments to STS
Check EU
origin
Receive EU origin ack
Receive EU origin nack
Check box origin
P: unloadeds(box)
P: unloadeds(box) E: approvee(box)
<unloads(box), !Receive_EU_origin_ack, {approvee(box)}>
STS
Action table entry
With this translation, we lose the information encoded in the effects of
activities.
We capture this information with a second data structure (action table entry), which
will be used when transforming the object diagrams and the goals
New STS:
- no events
- all states are final
- labels for states
Solution (2) object diagrams to STS
Composition goal
T => readys(box) ≻ disposeds(box)
!eT !er
[readys(box) ]
!ed
[disposeds(box)]
?eT
?eT ?eT
?er ?ed
l0
l1 l2
ρ = (l0, l1, l2)
Solution (3) goals to STS
STSs
For each goal, we construct the STSs
that correspond to the satisfiability of the
goal.
For every formula we define a single
output action e which gets triggered when
the formula is satisfied.
We use these completion actions for
composing the formulas.
The preconditions on the activities will be
carried over as guards also in the goal
STSs ρ
Solution overview
Object diagrams
Pervasive
process
fragments
Composed
flow
Goals
Box
T => readys(box) ≻
disposeds(box)
OD
-2-S
TS
STS
STS
(2)
G-2
-ST
S
STS
(3)
Acti
on
Tab
le
AP
FL
-2-S
TS
(1)
Planning
domain
STS
(4)
GO
AL
Co
ns
tru
cti
o
n ρ
Planning
goal
Pla
nn
er
(5)
Controlled
domain
ST
S-2
-AP
FL
(6)
Solution (4) building the planning domain
The planning domain is the parallel product of the STSs resulting from
the transformation of fragment models, object diagrams, and goals,
capturing their simultaneous evolution.
Background
Let = and = be two STSs with
.
The parallel product is a STS defined as:
Where
and
Solution (5) obtaining the composed STS
We exploit the ASTRO automated composition approach - www.astroproject.org
Sophisticated AI planning techniques (Planning as Model Checking)
Asynchronous domains, non-determinism, partial observability
Complex goals: preferences and recovery conditions (EaGle)
Control and data flow composition requirements
Research work on ASTRO automated service composition:
Annapaola Marconi, Marco Pistore: Synthesis and Composition of Web Services. SFM 2009: 89-157
Annapaola Marconi, Marco Pistore, Paolo Traverso: Automated Composition of Web Services: the
ASTRO Approach. IEEE Data Eng. Bull. 31(3): 23-26 (2008)
Annapaola Marconi, Marco Pistore, Piero Poccianti, Paolo Traverso: AutomatedWeb Service
Composition at Work: the Amazon/MPS Case Study. ICWS 2007: 767-774.
Annapaola Marconi, Marco Pistore, Paolo Traverso: Specifying Data-Flow Requirements for the
Automated Composition of Web Services. SEFM 2006: 147-156
M. Pistore, P. Traverso, P. Bertoli, and A. Marconi, Automated synthesis of composite BPEL4WS web
services” in Proc. ICWS 2005
Un
load
b
ox
Check box content
Bring to claim
Solution (5) obtaining the composed STS
Bring to claim
Ch
arge
an
d c
olle
ct t
ax
Composed STS for the Box at
the airport scenario
Solution (7) result as APFL
The translation from STS to APFL is conceptually simple, and is
performed based on action names.
From the construction of STSs, each action name is unique and
corresponds to at most one appearance of an activity in a fragment model
Such actions can therefore be mapped back to their corresponding
activities
Learning Package Overview
Problem Description
Application Representation
Automated composition of process-fragments
Evaluation and discussion
Related Works
Conclusions
We implemented our approach into a prototype tool.
The tool translates the input object diagrams (XML), and the fragment models and
goals (APFL) into a planning problem.
For the planning problem we use a customized NuSMV language, extended to
allow the specification of goals with preferences.
The planning problem is then passed to WSYNTH, one of the tools in the ASTRO
toolset.
The output returned by WSYNTH is the controlled domain which we then translate
back to APFL.
To evaluate our tool, we consider several features specific to fragment
composition.
First, the set of available fragment models can contain more models then actually
necessary for composition.
Second, there is a tradeoff between designing fragment models with a large
number of activities (a higher burden on the designer) and with a small number
(longer composition time).
Finally, fragment models can include overlapping activities.
Evaluation
Evaluation
Tradeoff regarding the number of activities in a fragment:
large => higher burden on the designer
small => longer composition time
Discussion Comparison to Web Service Composition
Research problem:
Compose pervasive process fragments at run time based on context and
goals
Comparison to Web service composition:
Components are not orchestrated, but integrated into a complete process
model
New problems: fragments can overlap, fragments can have gaps in the
specification
Context plays a key role both in terms of modeling the contextual
information and take contextual constraints into account during the
composition
Further Readings
A. Marconi, M. Pistore, A. Sirbu, F. Leymann, H. Eberle, and T. Unger, Dynamic Composition of Pervasive Process
Fragments in Proc. ICWS 2011.
R. Kazhamiakin, M. Paolucci, M. Pistore, H. Raik: Modelling and Automated Composition of User-Centric Services.
OTM Conferences (1) 2010: 291-308
A. Marconi, M. Pistore: Synthesis and Composition of Web Services. SFM 2009: 89-157
P. Bertoli, R. Kazhamiakin, M. Paolucci, M. Pistore, H. Raik, M. Wagner: Control Flow Requirements for Automated
Service Composition. ICWS 2009: 17-24
P. Bertoli, R. Kazhamiakin, M. Paolucci, M. Pistore, H. Raik, M. Wagner: Continuous Orchestration of Web Services via
Planning. ICAPS 2009
Acknowledgements
The research leading to these results has
received funding from the European
Community’s Seventh Framework
Programme [FP7/2007-2013] under grant
agreement 215483 (S-Cube).
Top Related