Goal 3 Activity 9 (Workflow) links with A9 ( Selflets ) , 7, 10, 11

1. Goal 3 Activity 9 (Workflow)links with A9 (Selflets), 7, 10, 11 Eugenio Zimeo Università del Sannio

2. Goal 3 • Activity 9 –Definition of the middleware and the architectural paradigms for service composition • Activity 10 –Application validation and evaluation of QoS parameters • Activity 11 –Definition of the peripheral hardware architecture

3. Networked enterprises and multi-organization Web applications (1/3) • Networked enterprises can significantly benefit from new-generation web applications that are able to share data and services distributed in different organizations • This kind of Web applications can be created by composing distributed services hosted by servers in different administration domains • we name these applications as "multi-organization Web applications”

4. Networked enterprises and multi-organization Web applications (2/3) • In multi-organization web applications, services: • are handled under the assumption of "open world" and are provided by different organizations • can be modified or replaced, they can disappear, and new services with different features may become available • are executed outside their own infrastructure and control, for example at a business partner’s site • Workflow management systems have a particular relevance for the development of these applications

5. Networked enterprises and multi-organization Web applications (3/3) Multi-organization Web application • (WP are web pages, WS are web services, A are workflow activities)

6. Focus: cultivation process

7. Main problem and innovation • Main problem addressed: • Multi-organization web applications are influenced by context events, whose handling could require run-time adaptations for reacting to the changing conditions of the execution context • Proposed solution: • Addressing the need for adaptation in large-scale web applications by proposing a programming paradigm based on "autonomic workflows” • The paradigm exploits two languages: a procedural language and a declarative one

8. Autonomic Workflow • Autonomic Workflow (AW) refers to the ability of • orchestrating both human (i.e. manual) and electronic (i.e. automatic) resources • using process constraints and considering the goal as an invariant • automatically changing an aspect of a workflow for the continuation of the execution towards the termination, even if unexpected anomalies occur during the execution of web applications in a SOA scenario • An AW is supervised by an autonomic workflow engine that is able to self-manage workflow execution • Several aspects of a workflow could be changed for reacting to anomalies occurring at run-time

9. Adaptation language (SPL) • The approach proposed to collect events is based on the concept of checkpoint • This is a point, in the control flow, that triggers the monitoring system to perform a measurement, evaluate the overall state of the running workflow, and eventually program some actions • Monitoring requires measuring the value of some variables during the process execution in order to detect problems • The conceptual behaviour of a checkpoint is based on the Event Condition Action paradigm (ECA rules)

10. Adaptation language (SPL) • Monitoring rules (observe the external context) • Management rules (change the current structure of the workflow) • Constraints

11. Some benefits of AWswrt traditional ones Rules allow to eliminate decision points from the control flow Decision is not synchronous with the execution New processes can be built (mining) by inserting activities Autonomic workflow on (Pluviometer > 1) assertRain on (Pluviometer > 20) assertHeavyRain on (Rain) dropIrrigation on (HeavyRain) addAgronomistVisit Traditional workflow

12. Verifying the workflow • Once workflow, rules and constraints are specified, they have to be checked against • Contradiction • Deadlock • Additional user specified properties This topic is linked with activity 10

13. Verification schema

14. Properties that do NOT hold • When the model checker shows that a property does not hold, it means that there are few evolutions of the system in which it is violated • In some evolution, the property may hold • If the property is critical, the system should be re-designed • If the property is not critical, the system can be released and the property can be monitored at run-time

15. Online verification • Also during the workflow execution a change of the KB triggers the on-line verification • If the property does not hold and it is not critical, verification is performed at run-time

16. Run-time verification • This verification is integrated in the default rules of SAWE • ErrorMutex  Intercepts the presence of two conflicting activities • When an activity is added, a ConstraintViolation of type Mutexis checked

17. Other adaptations: changing an activity binding with another service • Dynamic binding regards the run-time identification and linking of a desired concrete service in a given process • In some execution contexts, binding becomes more complex due to the necessity of satisfying global constraints

18. Other adaptations: changing an activity with a group of equivalent activities • If a concrete implementation of a required service does not exist, then the dynamic binding may not be completed • In this case a possibility is to change the control flow of a workflow instance by substituting an activity with an equivalent composition of activities • The workflow description is changed by performing a re-planning

19. SAWE: Architecture • In the case of binding failure, the SAWE manager interacts with a group of Selflets, disseminated in each enterprise, to find an equivalent service

20. Interactionwithothersubsystems

21. Interactions with other subsystems (WSN MW) Contextdefinition Link with A11

22. Interactions with other subsystems (Data base + Portal) Database ofGialloRossowinery Link with A7 Aggregate Contextdefinition

23. Demo deployment diagram

24. Demo organization • The demo on AWs is organized in three parts: • Part1: some configuration tools are used to prepare the configuration of an autonomic workflow • Part2: the autonomic workflow is executed and some events are monitored • Part3: a new rule/constraint is added to the SAWE KB and an online verification is launched

25. Demo part1 • During the design phase a new process is defined by using a conventional workflow language • The workflow is turned into an autonomic one through the following steps: • Step1: defining the e-context to observe, the events to monitor and the policy to adopt (e-context refers to the environment where the process runs – vineyard in this demo) • Step2: defining the monitoring rules • Step3: defining the management rules • Step4: defining constraints between activities

26. Demo part2.1 • The complete autonomic workflow is loaded into SAWE for the execution • SAWE is initialized to listen events from the e-context • A daily process is started; planning is defined but… • Weather conditions are favorable to the formation of parasites (e.g. PowderyMildew) • The system decides to insert in the process some specific treatments (spraying of pesticides) • Rain is inferred by listening data from a pluviometer (in alternative, humidity sensors could be used) • The system decides to remove the irrigation activity from the daily process

27. Demo part2.2 • Rain becomes heavy • The system decides to insert an agronomist visit in the process • The agronomist visit is executed; the agronomist inserts the status of the vineyard in the system

28. Demo part3 • A daily process is running: • The workflow is managed with the following rules: • on (PowderyMildew) add Spraying; • on (Rain) drop Irrigation; • on (Rain) drop Spraying; • on (HeavyRain) add AgronomistVisit; • and with the following constraint: • Pruning ->! WeedsRemoving; • The model checking of the process is ok • A new management rule is inserted inthe knowledge base: • on (PowderyMildew) add Pruning; • The model checker intercepts some problems and the rule insertion is not performed

29. Part 2.2 and 5of the book • Autonomicworkflow and business processmodellingfornetworkedenterprises (Chaptereditors, Gerardo Canfora, Giancarlo Tretola, Eugenio Zimeo) • Using the ArtDecoapproach in the wine business domain (Chaptereditor, Eugenio Zimeo, Valentina Mazza, Giorgio Orsi, Elisa Quintarelli, Antonio Romano, Paola Spoletini, Giancarlo Tretola–otherauthors, Alessandro Almirante, Alessio Botta, Luca Cavallaro, Domenico Consoli, Ester Giallonardo, Fabrizio Maria Maggi, Gabriele Tiotto)