![Solution
(3) goals to STS
Composition goal
T => readys(box) ≻ disposeds(box)
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 STSs
the formula is satisfied.
We use these completion actions for
composing the formulas. !ed
!eT !er
The preconditions on the activities will be [readys(box) ] [disposeds(box)]
carried over as guards also in the goal
STSs ρ l0
?eT ρ = (l0, l1, l2)
?eT
?eT
l1 ?er ?ed l2](https://image.slidesharecdn.com/jra-2-2-cluster-1-fragmentcomposition-lpfbk-111202090108-phpapp02/85/S-CUBE-LP-AI-planning-based-composition-of-pervasive-process-fragments-27-320.jpg)
![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).](https://image.slidesharecdn.com/jra-2-2-cluster-1-fragmentcomposition-lpfbk-111202090108-phpapp02/85/S-CUBE-LP-AI-planning-based-composition-of-pervasive-process-fragments-38-320.jpg)
S-CUBE LP: AI planning based composition of pervasive process fragments
- 1. 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 www.s-cube-network.eu
- 2. Learning Package Categorization S-Cube Adaptable Coordinated Service Compositions Automated Service Composition AI planning based composition of pervasive process fragments
- 3. Learning Package Overview Problem Description Application Representation Automated composition of process-fragments Evaluation and discussion Related Works Conclusions
- 4. Problem Description Pervasive applications require processes to be discovered and used depending on the context (location, time, situation, user preferences) Pervasive process Automated composition fragments allow to model allow to synthesize a incomplete and contextual process on-the-fly given a process knowledge set of components Automated composition of pervasive process fragments into a complete executable process, according to a goal and a specific context
- 5. Scenario: Box at the airport (1) Box at the Airport Flow Goal: Release box Check box origin Take to baggage claim Charge and collect tax Unload from airplane Check box content
- 6. Scenario: Box at the airport (2) Box at the Airport Flow Goal: Release box The process knowledge for handling a box is distributed at different locations in the airport Check box origin Take to baggage claim Charge and collect tax and depends on context information. Unload from airplane Check box content 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 )
- 7. Scenario: Box at the airport (3) Object Diagrams Goals Knowledge Box Domain Primary: Box.released Recovery: Box.disposed 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
- 8. Scenario: Box at the airport (3) Object Diagrams Goals Knowledge Box Domain Primary: Box.released Recovery: Box.disposed Pervasive Process Fragments Pervasive Process Fragments Fragment modeling represent the dynamic and concrete process knowledge: They are concrete processes discovered at run time and targeted to a specific context
- 9. Scenario: Box at the airport (3) Object Diagrams Goals Knowledge Box Domain Primary: Box.released Recovery: Box.disposed Pervasive Process Fragments Context Where? Verona International Airport Process execution Fragment modeling What? Flammable content Who? DHL Box Delivery Process ?
- 10. Scenario: Box at the airport (3) Object Diagrams Goals Knowledge Common Box Primary: Box.released Recovery: Box.disposed Pervasive Process Fragments Context Where? Verona International Airport Process execution Fragment modeling What? Flammable content Who? DHL Fragment selection Box Delivery Process ? ?
- 11. Learning Package Overview Problem Description Application Representation Automated composition of process-fragments Evaluation and discussion Related Works Conclusions
- 12. Application Representation Object diagrams knowledge Domain Stable and abstract Goals knowledge Process E: … Pervasive process P: … fragments annotated with Dynamic and P: … preconditions and effects concrete E: … (domain knowledge)
- 13. Object diagrams Object diagrams An object diagram is a simple state transition system containing states which encode properties of the Goals entity, and transitions between states triggered by P: … E: … P: … E: … Pervasive process fragments annotated with preconditions and effects events. (domain knowledge) 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
- 14. Object diagrams (2) Object diagrams in the Box at the airport scenario box at the airport tax invoice 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
- 15. Goals Object diagrams We express goals in terms of entities and their evolution. Goals can be used to specify desirable situations to be Goals reached at the end of the execution, as well as rules that P: … E: … Pervasive process fragments annotated with should be maintained throughout the execution. P: … E: … preconditions and effects (domain knowledge) 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. 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
- 16. Goals (2) Control flow goal for the Box at the airport scenario box at the airport tax invoice Composition goal Primary Goal Recovery Goal T => readys(box) ≻ disposeds(box) 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.
- 17. Pervasive Process Fragments Object diagrams Process fragments represent a tool for modeling incomplete and local process knowledge. Goals The knowledge is incomplete since the modeler is P: … E: … P: … Pervasive process fragments annotated with E: … preconditions and effects allowed to specify just one aspect of the entire (domain knowledge) 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.
- 18. Pervasive Process Fragments (2) (some) APFL activities Pervasive process fragments receive -> incomplete contextual process knowledge: Specified in APFL = BPEL + extensions for pervasive domain reply, Not required to have a start activity one-way invoke Control connectors may have either no source or no target two-way invoke activity Modeler has freedom to not model control connectors at all human interaction Can contain gaps -> Region element context event Research work on pervasive process fragments: H. Eberle, T. Unger, and F. Leymann, “Process fragments” in OTM 2009, Part I, pp. 398–405. event-based exclusive A. Bucchiarone, A. L. Lafuente, A. Marconi, and M. Pistore, “A formalisation decision (pick, of adaptable pervasive flows” in 6th Int. Workshop on Web Services and apfPick) Formal Methods (WS-FM), 2009 A. Marconi, M. Pistore, A. Sirbu, F. Leymann, H. Eberle, and T. Unger, region “Enabling Adaptation of Pervasive Flows: Built-in Contextual Adaptation” in Proc. ICSOC 2009, pp. 445–454.
- 19. Pervasive process fragments (3) P: unloadeds(box) Check box E: approvee(box) Receive EU origin origin ack P: unloadeds(box) Check EU origin Check box origin Receive EU origin nack P: unloadeds(box) P: taxeds(box) Check box content E: evaluatee(box) E: approvee(box) Content Charge Mark ack tax box Check box content P: unloadeds(box) Check content P: unloadeds(box) P: rejecteds(box) E: rejecte(box) E: disposee(box) Content Dispose nack Charge and collect tax Charge and collect tax P: unloadeds(box) ʌ not-exists(inv) P: evaluateds(box) ʌ opens(inv) E: {evaluatee(box), createe(inv)} P: opens(inv) E: {taxe(box), closee(inv)} Charge tax Send notice Payment with invoice of assessment completed Unload box P: inits(box) Unload box P: inits(box) Unload from Bring to E: unloade box) Box at Box on airplane carrier terminal termina l Bring to claim P: approveds(box) P: approveds(box) E: releasee(box) Take to Box at baggage Bring to claim baggage claim claim
- 20. Pervasive process fragments (4) P: unloadeds(box) box at the Check box E: approvee(box) airport Receive EU origin origin ack P: unloadeds(box) Check EU origin Receive EU origin nack P: unloadeds(box) P: taxeds(box) Check box content E: evaluatee(box) E: approvee(box) Content Charge Mark ack tax box P: unloadeds(box) Check content P: unloadeds(box) P: rejecteds(box) E: rejecte(box) E: disposee(box) Content Dispose nack Activities of pervasive process Charge and collect tax P: unloadeds(box) ʌ not-exists(inv) P: evaluateds(box) ʌ opens(inv) fragments can be annotated with E: {evaluatee(box), createe(inv)} P: opens(inv) E: {taxe(box), closee(inv)} Charge tax Send notice Payment Preconditions: constraints on the with invoice of assessment completed context where the activity can be executed Unload box P: inits(box) P: inits(box) E: unloade box) Effects: changes that the activity Unload from Bring to Box at airplane Box on carrier terminal termina execution produces on the l context Bring to claim P: approveds(box) P: approveds(box) E: releasee(box) Take to Box at baggage baggage claim claim
- 21. Learning Package Overview Problem Description Application Representation Automated composition of process-fragments Evaluation and discussion Related Works Conclusions
- 22. Solution overview Pervasive process fragments Object diagrams Automated Composed Box Composition executable flow Goals T => readys(box) ≻ disposeds(box)
- 23. Solution overview Pervasive (1) Table APFL-2-STS process fragments STS Action (2) Object diagrams OD-2-STS Box Composed flow STS (3) Construction Planning goal G-2-STS GOAL Goals ρ T => readys(box) ≻ disposeds(box) STS
- 24. Solution overview Background Pervasive (1) Table APFL-2-STS process A state transition system (STS) is a tuple fragments <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, STS is the transition relation, Action SF is the set of accepting states, (2) is the labeling function. Object diagrams OD-2-STS Box Composed STS flow (3) Construction Planning goal G-2-STS GOAL Goals ρ T => readys(box) ≻ disposeds(box) STS
- 25. Solution (1) pervasive process fragments to STS 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 STS P: unloadeds(box) Check box E: approvee(box) Receive EU origin origin ack P: unloadeds(box) Check EU origin Receive EU origin nack Action table entry <unloads(box), !Receive_EU_origin_ack, {approvee(box)}>
- 26. Solution (2) object diagrams to STS New STS: - no events - all states are final - labels for states
- 27. Solution (3) goals to STS Composition goal T => readys(box) ≻ disposeds(box) 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 STSs the formula is satisfied. We use these completion actions for composing the formulas. !ed !eT !er The preconditions on the activities will be [readys(box) ] [disposeds(box)] carried over as guards also in the goal STSs ρ l0 ?eT ρ = (l0, l1, l2) ?eT ?eT l1 ?er ?ed l2
- 28. Solution overview (1) Table APFL-2-STS Pervasive process fragments (5) Planning STS domain Action (4) (2) (6) Object diagrams Controlled OD-2-STS STS STS-2-APFL domain Planner Box Composed flow STS (3) Planning Constructio goal G-2-STS ρ GOAL Goals n T => readys(box) ≻ disposeds(box) STS
- 29. 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
- 30. 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
- 31. Solution (5) obtaining the composed STS Unload box Composed STS for the Box at the airport scenario Bring to claim Charge and collect tax Check box content Bring to claim
- 32. 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
- 33. Learning Package Overview Problem Description Application Representation Automated composition of process-fragments Evaluation and discussion Related Works Conclusions
- 34. Evaluation 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.
- 35. Evaluation Tradeoff regarding the number of activities in a fragment: large => higher burden on the designer small => longer composition time
- 36. 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
- 37. 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
- 38. 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).