Towards a DecSerFlow mapping to SCIFF

Federico Chesani, Paola Mello, Marco Montali, Sergio Storari

Limits of procedural languages 1/2

Recent trends in the web-services world: WS-BPEL, WS-CDLThey are procedural and not very different from classical workflow languagesVan der Aalst’s claim:

Autonomyconstrained freedom

Procedural languages do not fit well with the autonomous nature

of web services

Limits of procedural languages 2/2

We want to express the not co-existence between two activities

“A and B could be executed several times, but they exclude each other”

Procedural approach:

A Over-specification

B How? When?

Procedural vs Declarative Approach

Declarative approachLTL: (A B)Compact and expressive……but difficult to use by non-experts

Solution: a graphical declarative language for the specification of service flows (DecSerFlow)

A B

DecSerFlow 1/2Main features:

DeclarativeGraphicalMapping to LTL (inspired from LTL patterns)

Dynamic service monitoring (conformance)Service enactment

Easy extendibleSupport of hard and soft constraints“Open” perspective

The modeler must explicitly express not only what has to be done, but also what is forbidden

DecSerFlow 2/2Main elements:

Activity: an atomic logical unit of workConstraint: relationship between activities (policy or business rule)

Each constraint is mapped to an LTL template formula

credit card

notify failure

successful booking

0..10..1

0..1existenceformula

relationformula

negationformula

DecSerFlow ConstraintsThree families

Existence formulaeUnary formulae constraining the cardinality of activities (absence, existence, at most…, at least…)

Relation formulaeBinary formulae specifying “what has to be done”Sub-families: simple relations, alternate relations, chain relations

Sub-sub-families: response, precedence, successionNegation formulae

Binary formulae specifying “what is forbidden”They are the negated version of relation formulae

Extended notation

Mapping to the SCIFF-framework

LTLQuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

SCIFF

DecSerFlow

•Conformance verification•Enactment

extensions

•Conformance verification•Enactment

Translation Example 1/3Absence_N (N=1)

credit card

notify failure

successful booking

0..10..1€

H(booking,Ti)i=1

N

∏ ∧Ti > Ti−1

→EN(booking,Tb )∧Tb > TN

Atomic model for activitiesAn activity A is mapped to an event

performed(A)

0..1

Mutual substitution

Translation Example 2/3Chain response

(sequence a là workflow)

credit card

notify failure

successful booking

0..10..1

€

H(credit _card,Tc )→E(booking,Tb )∧Tb > Tc∧ EN(X,TX )∧TX > Tc ∧TX < Tb

€

→ E(credit _card,Tc )∨ E(notify _ failure,Tn ).

0..1

2x Responded Absence

Translation Example 3/3Not coexistence

credit card

notify failure

successful booking

0..10..1

€

H(credit _card,Tc )→EN(notify _ failure,Tn )H(notify _ failure,Tn )→EN(credit _card,Tc )

0..1

credit card notify failure

credit card notify failure

Intensional Formalization 1/3

Instead of mapping each concrete formula to an integrity constraints……we follow van der Aalst’s approach by formalizing template formulae with template ICs

General abductive formalization, valid for all modelsRepresentation of a specific model by simply compiling a knowledge base mapping the diagram structure to a list of facts

Intensional formalization 2/3

Our aim is to translate template formulae into

a general set of ICs (ICDSF)+ a general KB (KBDSF)

valid for all DecSerFlow modelsThus DecSerFlow is mapped to an Abductive Logic ProgramSDSF< KBDSF , ={E, EN}, ICDSF >

Intensional formalization 3/3

A specific DecSerFlow diagram is then mapped to an ALP of the form

Sspec< KB, ={E, EN}, ICDSF >

where KBspec models the diagram structure

same as SDSFKB=KBDSFKBspec

Example of diagram descriptionKBspec

existence_formula(booking, absence_N(1)).existence_formula(credit_card, absence_N(1)).existence_formula(notify_failure, absence_N(1)).rel_formula(notify_failure, credit_card, mutual_substitution).neg_formula(notify_failure, credit_card, not_coexistence).rel_formula(credit_card, booking, chain_response).

credit card

notify failure

successful booking

0..10..1

0..1

General Knowledge BaseKBDSF defines knowledge common to all DecSerFlow modelsIn particular, some DecSerFlow constraints are defined in terms of other onesThese correspondences are modeled inside KBDSFE.g. the coexistence relation…neg_formula(A,B,responded_absence):-

neg_formula(A,B,not_coexistence).neg_formula(B,A,responded_absence):-

neg_formula(A,B,not_coexistence).

Template Integrity Constraints 1/2

The first conjunct of a DecSerFlow integrity constraint is the corresponding template formula representationFormalization of the responded absence negation formulaneg_formula(A,B,responded_absence)H(A,TA)EN(B,TB).Thanks to the universal quantification of A and B, the rule is replicated for each (concrete) responded absence formula

Template Integrity Constraints 2/2

Alternate response

rel_formula(A, B, response)H(A,TA)E(B,TB)TB>TA

rel_formula(A,B,alt_response)H(A,TA)H(A,TA2)TA2>TA

E(B,TB)TB>TA TB<TA2

rel_formula(A, B, alt_response)H(A,TA)E(B,TB)TB>TA

EN(A,TB)TB>TA TB<TA2

Example 1/2

ICDSF

neg_formula(X, Y, responded_absence)H(X, TA)EN(Y, TB).

KBDSF

neg_formula(A, B, responded_absence):- neg_formula(A, B, not_coexistence).neg_formula(B, A, responded_absence):- neg_formula(A, B, not_coexistence).

KBspec

neg_formula (credit_card, notify_failure, not_coexistence).

STEP 1: by unfoldingneg_formula(X, Y, not_coexistence)H(X, TA)EN(Y, TB).neg_formula(Y, X, not_coexistence)H(X, TA)EN(Y, TB).

Example 2/2

ICDSF

neg_formula(X, Y, responded_absence)H(X, TA)EN(Y, TB).

KBDSF

neg_formula(A, B, responded_absence):- neg_formula(A, B, not_coexistence).neg_formula(B, A, responded_absence):- neg_formula(A, B, not_coexistence).

KBspec

neg_formula (credit_card, notify_failure, not_coexistence).

STEP 2: by unfolding

H(credit_card, TA)EN(notify_failure, TB).

H(notify_failure, TA)EN(credit_card, TB).

Constraints equivalenceSome negation formulae are “equivalent”, i.e. express the same interaction pattern

E.g. the responded absence and the not coexistence formulae

We have defined a concept of “equivalence w.r.t. conformance” to capture such a case

And proven that our formalizations satisfy these equivalences

DecSerFlow “extensions”Composite activities

Conjunction and disjunction of activities in relationships source/targetVan der Aalst et. al have already introduced disjunctions

Explicit temporal constraints and deadlines

Temporal Constraints Templates

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Formulae factorizationrelation family temporal

constraintresponded existence simple alwaysresponse simple after(0)precedence simple before(0)alternate response alternate after(0)alternate precedence alternate before(0)chain response chain after(0)chain precedence chain before(0)

Composite Activities

source target

conjunction synchronizing merge parallel split

disjunction simple merge deferred choice

Example of Extended Policy

Triggers when both sources happens

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

An extended policy with temporal constraints

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

ConclusionsWe have successfully mapped the basic DecSerFlow template formulae to SCIFF

A first implementation has been developedAnd tested on the ACME example

Ongoing implementation for extended constraints (conjunctions and temporal aspects)

Future worksTo consider data (!)Service animation through SCIFF (?)

Basta!