Presentation on theme: "Towards a DecSerFlow mapping to SCIFF Federico Chesani, Paola Mello, Marco Montali, Sergio Storari."— Presentation transcript:
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
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
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
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 A EN(A,T B ) T B >T A T B
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
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 (?)