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-CDL They are procedural and not very different from classical workflow languages Van der Aalst’s claim: Autonomy  constrained 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 approach LTL:  (  A   B) Compact and expressive… …but difficult to use by non-experts Solution: a graphical declarative language for the specification of service flows (DecSerFlow) AB

DecSerFlow 1/2 Main features: Declarative Graphical Mapping to LTL (inspired from LTL patterns) Dynamic service monitoring (conformance) Service enactment Easy extendible Support 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/2 Main elements: Activity: an atomic logical unit of work Constraint: relationship between activities (policy or business rule) Each constraint is mapped to an LTL template formula credit card notify failure successful booking 0..1 existence formula relation formula negation formula

DecSerFlow Constraints Three families Existence formulae Unary formulae constraining the cardinality of activities (absence, existence, at most…, at least…) Relation formulae Binary formulae specifying “what has to be done” Sub-families: simple relations, alternate relations, chain relations Sub-sub-families: response, precedence, succession Negation formulae Binary formulae specifying “what is forbidden” They are the negated version of relation formulae

Extended notation

Mapping to the SCIFF- framework LTL SCIFF DecSerFlow Conformance verification Enactment extensions Conformance verification Enactment

Translation Example 1/3 Absence_N (N=1) credit card notify failure successful booking 0..1 Atomic model for activities An activity A is mapped to an event performed(A) 0..1

Mutual substitution Translation Example 2/3 Chain response (sequence a là workflow) credit card notify failure successful booking 0..1

2x Responded Absence Translation Example 3/3 Not coexistence credit card notify failure successful booking 0..1 credit cardnotify failure credit cardnotify 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 IC s General abductive formalization, valid for all models Representation 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 IC s (IC DSF ) + a general KB (KB DSF ) valid for all DecSerFlow models Thus DecSerFlow is mapped to an Abductive Logic Program S DSF 

Intensional formalization 3/3 A specific DecSerFlow diagram is then mapped to an ALP of the form S spec where KB spec models the diagram structure same as S DSF KB=KB DSF  KB spec

Example of diagram description KB spec 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..1

General Knowledge Base KB DSF defines knowledge common to all DecSerFlow models In particular, some DecSerFlow constraints are defined in terms of other ones These correspondences are modeled inside KB DSF E.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 representation Formalization of the responded absence negation formula neg_formula(A,B,responded_absence)  H(A,T A )  EN(B,T B ). 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,T A ) E(B,T B )  T B >T A rel_formula(A,B,alt_response)  H(A,T A )  H(A,T A2 )  T A2 >T A E(B,T B )  T B >T A  T B <T A2  rel_formula(A, B, alt_response)  H(A,T A ) E(B,T B )  T B >T A  EN(A,T B )  T B >T A  T B <T A2

Example 1/2 IC DSF neg_formula(X, Y, responded_absence)  H(X, T A )  EN(Y, T B ). KB DSF neg_formula(A, B, responded_absence):- neg_formula(A, B, not_coexistence). neg_formula(B, A, responded_absence):- neg_formula(A, B, not_coexistence). KB spec neg_formula (credit_card, notify_failure, not_coexistence). STEP 1: by unfolding neg_formula(X, Y, not_coexistence)  H(X, T A )  EN(Y, T B ). neg_formula(Y, X, not_coexistence)  H(X, T A )  EN(Y, T B ).

Example 2/2 IC DSF neg_formula(X, Y, responded_absence)  H(X, T A )  EN(Y, T B ). KB DSF neg_formula(A, B, responded_absence):- neg_formula(A, B, not_coexistence). neg_formula(B, A, responded_absence):- neg_formula(A, B, not_coexistence). KB spec neg_formula (credit_card, notify_failure, not_coexistence). STEP 2: by unfolding H(credit_card, T A )  EN(notify_failure, T B ). H(notify_failure, T A )  EN(credit_card, T B ).

Constraints equivalence Some 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/target Van der Aalst et. al have already introduced disjunctions Explicit temporal constraints and deadlines

Temporal Constraints Templates

Formulae factorization relationfamilytemporal constraint responded existencesimplealways responsesimpleafter(0) precedencesimplebefore(0) alternate responsealternateafter(0) alternate precedencealternatebefore(0) chain responsechainafter(0) chain precedencechainbefore(0)

Composite Activities sourcetarget conjunction synchronizing merge parallel split disjunctionsimple mergedeferred choice

Example of Extended Policy Triggers when both sources happens

An extended policy with temporal constraints

Conclusions We have successfully mapped the basic DecSerFlow template formulae to SCIFF A first implementation has been developed And tested on the ACME example Ongoing implementation for extended constraints (conjunctions and temporal aspects) Future works To consider data (!) Service animation through SCIFF (?)

Basta!