1 / 30

Towards a DecSerFlow mapping to S CIFF

Towards a DecSerFlow mapping to S CIFF. 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

remy
Download Presentation

Towards a DecSerFlow mapping to S CIFF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards a DecSerFlow mapping to SCIFF Federico Chesani, Paola Mello, Marco Montali, Sergio Storari

  2. 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

  3. A How? When? B 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: Over-specification

  4. A B Procedural vs Declarative Approach • Declarative approach • LTL: (A  B) • Compact and expressive… • …but difficult to use by non-experts • Solution: a graphicaldeclarative language for the specification of service flows (DecSerFlow)

  5. 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

  6. 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 0..1 existence formula relation formula negation formula notify failure 0..1 0..1 successful booking credit card

  7. 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

  8. Extended notation

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

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

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

  12. Translation Example 3/3 Not coexistence 0..1 notify failure 0..1 0..1 successful booking credit card 2x Responded Absence credit card notify failure credit card notify failure

  13. 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 models • Representation of a specific model by simply compiling a knowledge base mapping the diagram structure to a list of facts

  14. 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 models • Thus DecSerFlow is mapped to an Abductive Logic Program SDSF< KBDSF , ={E, EN}, ICDSF >

  15. 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 KB=KBDSFKBspec same as SDSF

  16. Example of diagram description KBspec 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). 0..1 notify failure 0..1 0..1 successful booking credit card

  17. General Knowledge Base • KBDSF defines knowledge common to all DecSerFlow models • In particular, some DecSerFlow constraints are defined in terms of other ones • These correspondences are modeled inside KBDSF • 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).

  18. 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,TA) EN(B,TB). • Thanks to the universal quantification of A and B, the rule is replicated for each (concrete) responded absence formula

  19. Template Integrity Constraints 2/2 • Alternate response

  20. Example 1/2 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). ICDSF neg_formula(X, Y, responded_absence) H(X, TA) EN(Y, TB). STEP 1: by unfolding neg_formula(X, Y, not_coexistence)H(X, TA) EN(Y, TB). neg_formula(Y, X, not_coexistence)H(X, TA) EN(Y, TB).

  21. Example 2/2 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). ICDSF neg_formula(X, Y, responded_absence) H(X, TA) EN(Y, TB). STEP 2: by unfolding H(credit_card, TA)EN(notify_failure, TB). H(notify_failure, TA)EN(credit_card, TB).

  22. 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

  23. 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

  24. Temporal Constraints Templates

  25. Formulae factorization

  26. Composite Activities

  27. Example of Extended Policy • Triggers when both sources happens

  28. An extended policy with temporal constraints

  29. 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 (?)

  30. Basta!

More Related