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

Goal 3 Activity 9 (Workflow)

links with A9 (Selflets), 7, 10, 11

Eugenio ZimeoUniversità del Sannio

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

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”

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

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)

Focus: cultivation process

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

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

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)

Adaptation language (SPL)

· Monitoring rules (observe the external context)

· Management rules (change the current structure of the workflow)

· Constraints

Some benefits of AWs wrt traditional ones

Rules allow to eliminate decision points from the control flow

Decision is not synchronous with the executionNew processes can be built (mining) by inserting

activitiesAutonomic workflow

Traditional workflow

on (Pluviometer > 1) assert Rainon (Pluviometer > 20) assert HeavyRain

on (Rain) drop Irrigationon (HeavyRain) add AgronomistVisit

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

Verification schema

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

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

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 Mutex is checked

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

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

SAWE: ArchitectureIn the case of binding failure, the SAWE manager interacts with a group of Selflets, disseminated in each enterprise, to find an equivalent service

Interaction with other subsystems

Interactions with other subsystems (WSN MW)

Link with A11

Context definition

Interactions with other subsystems (Data base + Portal)

Link with A7

Database of GialloRosso winery

Context definition

Aggregate

Demo deployment diagram

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

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

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

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

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 in the knowledge

base:• on (PowderyMildew) add Pruning;

– The model checker intercepts some problems and the rule insertion is not performed

Part 2.2 and 5 of the book

· Autonomic workflow and business process modelling for networked enterprises (Chapter editors, Gerardo Canfora, Giancarlo Tretola, Eugenio Zimeo)

· Using the ArtDeco approach in the wine business domain (Chapter editor, Eugenio Zimeo, Valentina Mazza, Giorgio Orsi, Elisa Quintarelli, Antonio Romano, Paola Spoletini, Giancarlo Tretola – other authors, Alessandro Almirante, Alessio Botta, Luca Cavallaro, Domenico Consoli, Ester Giallonardo, Fabrizio Maria Maggi, Gabriele Tiotto)