B - Lia

Choreography fragment (2)Two main interaction phasesorder placement1. the customer makes up an order by choosing one or more items2. before placing the order, the customer can cancel it3. in case of cancelation, no further item can be choosen anymore4. after having placed the order, the customer expects an answer fromthe sellerorder confirmation/refusal5. the seller can confirm the order only if the warehouse has previouslyconfirmed the shipment6. if the warehouse states that it is unable to ship the order, then theseller should refuse (have refused) the order

Required abstractionsActivitiesDifferent relationships abstractionscardinality constraintstime-ordered relationshipsunordered relationshipsnegative relationshipsopaque choicesthe customer makes up an order by choosing one or moreitemsbefore placing the order, the customer can cancel itin case of cancelation, no further item can be choosenanymoreafter having placed the order, the customer expects ananswer from the sellerthe seller can confirm the order only if the warehouse haspreviously confirmed the shipmentif the warehouse states that it is unable to ship the order, thenthe seller should refuse (have refused) the order

State of the artState-of-the-art approaches follow a typicalprocedural style of modeling, inspired byworkflow/business process paradigmsSee for example WS-CDL, BPMN Collaborative Models,WS-BPEL (and its variant BPEL4Chor)Closed approaches: all what is not explicitlymodeled is forbidden

Modeling in BPMN (1)Let us focus only on the second phase (order confirmation/refusal)A first attempt...SOME ACCEPTABLE INTERACTIONSseller...contactwarehousewarehouseconfirmshipmentconfirmshipmentrefuse orderrefuse orderconfirmorderrefuseorderacceptorderrefuseshipmentconfirmshipmentrefuse orderrefuseshipmentrefuseshipmentrefuse order

Modeling in BPMN (1)Let us focus only on the second phase (order confirmation/refusal)A first attempt...premature commitment➪over-specificationSOME ACCEPTABLE INTERACTIONSseller...contactwarehousewarehouseconfirmshipmentconfirmshipmentrefuse orderrefuse orderconfirmorderrefuseorderacceptorderrefuseshipmentconfirmshipmentrefuse orderrefuseshipmentrefuseshipmentrefuse order

Modeling in BPMN (1)Let us focus only on the second phase (order confirmation/refusal)A first attempt...premature commitment➪over-specificationlack of abstractions➪over-constrainingSOME ACCEPTABLE INTERACTIONSseller...contactwarehousewarehouseconfirmshipmentconfirmshipmentrefuse orderrefuse orderconfirmorderrefuseorderacceptorderrefuseshipmentconfirmshipmentrefuse orderrefuseshipmentrefuseshipmentrefuse order

Modeling in BPMN (2)Let’s try to augment flexibility (i.e. accept more traces)Many different possibilities, but over-specificationincreases dramatically...sellerwarehouseseller...warehousecontactwarehousecontactwarehouserefuseorderrefuseshipmentconfirmshipmentcancelrequestrefuseshipmentconfirmshipmentrefuseordercancelrequestacceptorderacceptorder

Drawbacks ofprocedural approachesBasically, they do not provide the required abstractionsonly sequence orderingsIn case of complex relationships, this leads to explicitlyenumerate all the possible interactionse.g. activities A and B cannot co-existABPROCESSFRAGMENT

The need ofdeclarativenessDifferent authors claims the importance of adopting declarativeand open paradigms to model interactionvan der Aalst (BPM / SOA)Singh and theOur work within the SOCS EU Project (Multi-agent systems) and PRIN projects(with UNITO)Declarative choreographiescapture the essential of interaction abstracting away from implementation detailsfocus on the domain problem rather than on a specific (procedural) solutionOpen approachespeers should be let freely act where not explicitly forbiddencloseness undermines flexibilityAvoiding to over-specify and over-constrain interaction is ofkey importance!Need of an underlying formal semantics

Declarative languagesLet’s consider again the not coexistencerelationship: A should not co-exist with BWe can exploit logic-based formalism to expresssuch a constraintLTL: A ¬B (and viceversa)SCIFF: H(performed(A), T) → EN(performed(B), T2) (and viceversa)Very potential formalisms, but not suitable for non-IT experts ➪DecSerFlow [van der Aalst and Pesic, 2006]

DecSerFlowGraphical declarative language for specifyingservice flowsA DecSerFlow models is described byA set of activities (messages)A set of relationships among activities, a là policies / business rulesRelationships constrain the way activities should be performedSemantics of the model as the conjunction ofrelationships

DecSerFlow relationshipsEach relationship has a semantics given in termsof Linear Temporal Logicformulae on “finite traces”, because the choreography shouldeventually finishExtensible languageThree families of core relationshipsExistence formulas (similar to UML cardinalities)Relation formulas (positive relationships between activities)Negation formulas (negated version of relation formulas)

Existence FormulasConstraints on the number of activities executionSimilar to UML cardinalities...0..NA absence NA should be executed at most N timesN..*ANAexistence Nexactly NA should be executed at least N timesA should be executed exactly N timesABmutualsubstitutionAt least one between A and Bshould be executed

Relation Formulas (1)Constrain the happening of activities w.r.t. otheractivities executionThree basic temporal orderings: no ordering, after,beforeSuccession formula constructed by combining thecorresponding response and precedence versionsNumber of lines determines how much therelationship is “strict”

Relation Formulas (2)AAABBBrespondedpresenceresponseprecedenceif A is executed, B shouldalso be executedif A is executed, B should beexecuted after Aif B is executed, A should beexecuted before BABcoexistenceA BsuccessionABresponseif A is executed, B should beexecuted after AABalternateresponseB is response of A and there shouldexists at least one B between two AsconstraintstrengthABchainresponseif A is executed, B should beexecuted next (immediately after)alternate and chain precedence/succession follow straightforward...

Negation FormulasAAABBBrespondedabsencenegationresponseprecedenceif A is executed, B can neverbe executedB can never be executedafter Aif B is executed, A can neverbe executed before BAABnot coexistenceBnegationsuccessionABnegation response B can never be executed after AABnegation alternateresponseThere can never be a B betweenevery two AsconstraintstrengthABnegation chainresponseB cannot be executed next to A(the sequence A B is forbidden)alternate and chain precedence/succession follow straightforward...

Seller answer in DecSerFlowRemember our example :-) ?CUSTOMER SELLER WAREHOUSEbranching formulasinterpreted in aDISJUNCTIVE waycommitorderafter having placed the order, thecustomer expects an answer fromthe sellerconfirmorderrefuseorderconfirmshipmentthe seller can confirm the order only ifthe warehouse has previously confirmedthe shipmentif the warehouse states that it is unableto ship the order, then the seller shouldrefuse (have refused) the orderrefuseshipment

Completion of the modelCUSTOMER SELLER WAREHOUSEconfirmorderconfirmshipmentcommitorderresponse validityresponse consistencyrefuseorderrefuseshipment

Overall schema of theframeworkspecificationmappingimplementation/executionformalspecificationformal frameworkverification

Overall schema of theframeworkspecificationmappingimplementation/executionformalspecificationformal frameworkverification

Overall schema of theframeworkDecSerFlowspecificationimplementation/executionformalspecificationextensionsformal SCIFF frameworkmappingverification

SCIFFDeveloped by the AI groups of DEIS, University ofBologna, and ENDIF, University of Ferrara, in thecontext of the SOCS EU ProjectA framework based on Computational Logic(Abductive Logic Programming) for thedeclarative specification and verification ofglobal interaction protocols in open agentsocietiesExpressive language for specifying interaction protocols, with anunderlying declarative semanticsProof-theoretic operational counterparts based on the IFF proofprocedure of Fung and Kowalski

Agents and Services (1)SOAs share many similarities with open multiagentsystemsinteracting entitiesMASautonomousheterogeneous agentsSOAautonomousheterogeneous servicescommunication performatives messageslocal view ofinteractionglobal view ofinteraction(external)agent policiesglobal interaction protocolsbehavioral interfacesservice choreographies

Agents and Services (2)MAS[Guerin and Pitt, 2002]SOAType 1an agent will (always)comply to a protocolinteroperabilityType 2verification throughobservationmonitoring a servicecompositionType 3verification of protocolpropertiesverification ofchoreography properties

SCIFF - Basic ideaAgents are autonomous and heterogeneous andact in an open (dynamical/unpredictable)environmentOnly observable events can be constrained!Happened EventsH(Ev, T)Interaction protocolsSocial ExpectationsE(Ev, T), EN(Ev, T)

SCIFF - Basic ideaAgents are autonomous and heterogeneous andact in an open (dynamical/unpredictable)environmentOnly observable events can be constrained!Exchanged messagesH(Msg, T)Service choreographiesSocial ExpectationsE(Msg, T), EN(Msg, T)

SCIFFEvents and ExpectationsHappened events: H(Ev, T)H(performed(marco, confirm_payment(i1, 20€)), 12).They dynamically compose the execution trace (history)Expectations: events that should E(Ev, T) or should not EN(Ev, T) happenVariables (also times) could be associated to conditionsand CLP constraintsE(performed(marco, confirm_payment(i1, Price)), T) /\ T > 2 /\ T < 10.EN(performed(Seller, confirm_payment(Item, Price)), T) /\ Price > 20.

SCIFFStatic knowledgeSocial Organizational Knowledge Base (KB) tomodel the static knowledge / reasoningcapabilities of the societyChoreography rolesComplex conditions (e.g. pricing)Composed by (Prolog) clauses, possiblycontaining CLP predicates

SCIFFInteraction specificationInteraction protocols / choreographies specified by meansof forward rules, which relate happened events withexpectationsRules are called Integrity Constraints (ICs) and have theform body → head wherebody contains a conjunction of happened eventshead contains a disjunction of conjunctions of expectationsExampleH(performed(Customer, commit_order), Tc)→ E(performed(Seller, confirm_order), Tconf) /\ Tconf > Tc\/ E(performed(Seller, refuse), Tref) /\ Tref > Tc

Declarative semantics(intuition)Expectations are interpreted as abducibles (set EXP)The society observes occurring events......and makes hypotheses about the course of interaction by meansof expectations on the interacting entitiesAbductive semantics: KB U EXP |= true, KB U EXP |= ICsCoherence of EXP (E-consistency): p E(p), EN(p) EXPInteracting entities should fulfill the expected behaviorp E(p) EXP H(p) HAPp EN(p) EXP H(p) HAP

Mapping DecSerFlowonto SCIFFVery intuitive translationActivities executions mapped onto eventsDecSerFlow relationships mapped onto IntegrityConstraints

Mapping of existenceformula0..NAN..*ANAH(A, T1) /\ H(A, T2) /\ T2 > T1 /\ ... /\ H(A, TN) /\ TN>TN-1→EN(A,T) /\ T > TN.→E(A, T) /\ E(A, T2) /\ T2 > T /\ ... /\ E(A, TN) /\ TN>TN-1.combination of existence_N and absence_N (KB)AB→ E(A, _) \/ E(B, _).

Mapping of relation andnegation formulasStraightforward mapping, by interpreting the natural languagedescriptionThe mapping of negation formulas is the same by substituting Ewith EN and vice-versaABH(A, _) → E(B, _).AABBH(A, TA) → E(B, TB) /\ TB > TA.H(B, TB) → E(A, TA) /\ TA < TB.next(TB, TA) ←EN(X, TX)/\ TX > TA /\ TX < TB.ABH(A, TA) → E(B, TB) /\ next(TB, TA).

Extending branchingformulasDeclarative Specification and Verification of Service Choreographies · 17Table VIII. Formalization of a branching responded existence formula in SCIFF.typeresponded existence(A 1 ∨ A 2 , B)responded existence(A, B 1 ∨ B 2 )responded existence(A, B 1 ∧ B 2 )responded existence(A 1 ∧ A 2 , B)representation!$!"##!"#!"equivalentrepresentation!$!"#formalizationH(performed(A 1 ), T A )→E(performed(B), T B ).H(performed(A 2 ), T A )→E(performed(B), T B ).!$ H(performed(A 1 ), T A )!$!"##!$!"→E(performed(B 1 ), T B1 )∨E(performed(B 2 ), T B2 ).H(performed(A), T A )→E(performed(B 1 ), T B ).H(performed(A), T A )→E(performed(B 2 ), T B ).!$ H(performed(A 1 ), T A2 )∧ H(performed(A 2 ), T A2 )→E(performed(B), T B ).1replicating the corresponding Integrity Constraint for each activity. A more complexcase is the one in which the formula has conjunct source activities: it should

Adding quantitative timeconstraintsDeclarative Specification and Verification of Service Choreographies · 19#$3+,*),4+%("&(&$4+(!#"#7"'"#"#

Monitoring DecSerFlowSCIFF proof procedure: verify whether a set ofhappened events complies with the specificationAt run-time, it dynamically performs reasoning and halts thecomputation waiting for further eventsA-posteriori, by analyzing the entire execution trace of an instanceChoreography specificationSCIFFEXPYESExecution/LogHAPSOCIETY INFRASTRUCTUREfulfillmentNO

Monitoring example1..*a(0,10)bH(performed(a),1).H(performed(b),8).H(performed(a),1).H(performed(b),12).c→E(performed(a), Ta).E(performed(a), T1).fulfilled with T1=1fulfilled with T1=1H(performed(b), Tb)→EN(performed(c), Tc).(and viceversa)EN(performed(c), _).fulfilledH(performed(a), Ta)→E(performed(b), Tb)/\ Tb > Ta /\ Tb < Ta + 10.E(performed(b), T2)/\ T2 > 1 /\ T2 < 11.fulfilled with T2=8VIOLATED

Verifying models (1)To verify (extended) DecSerFlow models, we canexploit the generative variant of the SCIFF proofprocedureIntuitively, it checks if a positive expectation hasbeen fulfilled and, if this is not the case,automatically generates a (partially instantiated)happened eventDrawbacks: due to the incompleteness of the CLPsolver, it is mandatory to perform a final “labeling”

Verifying consistencyAim: check whether a DecSerFlow model admitsat least one execution traceIf g-SCIFF is able to find an execution trace, themodel is consistentEXPHAP1..* E(performed(a), T1) H(performed(a), T1)abE(performed(b), T2) /\ T2 > T1E(performed(c), T3) /\ T3 > T1H(performed(b), T2) /\ T2 > T1cviolationEN(performed(c), _)

Discovering deadactivitiesAim: finding activities which can never be executed (i.e.discovering inconsistencies in sub-models)This task can be reduced to the consistency verificationDeclarative Specification and Verification of Service Choreographies · 29Basic algorithm:Input: S M , SCIFF formalization of the DecSerFlow model MOutput: D, the set of dead activitiesD ← ∅;foreach Activity A ∈ M doS M ′ ← S M ∪ existence 1(A);a bif call(g-SCIFF(S M ′ )) fails thenD ← D ∪ A;endcendAlgorithm 1: Detection of dead activities with g-SCIFF.

Discovering deadactivitiesAim: finding activities which can never be executed (i.e.discovering inconsistencies in sub-models)This task can be reduced to the consistency verificationDeclarative Specification and Verification of Service Choreographies · 29Basic algorithm:Input: S M , SCIFF formalization of the DecSerFlow model MOutput: D, the set of dead activitiesD ← ∅;1..*foreach Activity A ∈ M doS M ′ ← S M ∪ existence 1(A);if call(g-SCIFF(S M ′ )) fails thenD ← D ∪ A;endendAlgorithm 1: Detection of dead activities with g-SCIFF.abcinconsistent➭’a’ dead activity

Ongoing works (1)Enactment of extended DecSerFlow modelsThe enactment task aims at supporting users whenexecuting DecSerFlow models, by blocking a-priori thepossibility to violate the modelA0..1BExecuting B leads toblock both A and B!Our basic idea: discovering dead activities with analready acquired (partial) history

Ongoing works (2)Interoperability checking between a DecSerFlowchoreography and a DecSerFlow serviceAs far as now, only an existential interoperability(consistency of the joint model)Our aim is to extend the notation by consideringsender/receiver and to study more complexnotions of interoperability (see [Baldoni et al. 2006,Alberti et al. 2006])

Ongoing works (3)Integrating the SCIFF formalization of DecSerFlow withEvent-CalculusWe already have encoded EC in SCIFFIn this way we have a reactive EC, which initiates/terminatesfluents dynamicallyAdvantages of this integrationPossibility to represent non-atomic activitiesMajor support for enactmentAll formulas can be represented forward in timeABA R ¬BinitiallyHolds(forbidden(B)).terminates(performed(A), forbidden(B)).

ConclusionsThere is a need of declarative languages and tools when developingservice choreographiesWe propose to adopt(an extended version of) DecSerFlow for the graphical specificationSCIFF as the underlying formal frameworkThe mapping of DecSerFlow onto SCIFF is intuitive andautomaticalSCIFF can be fruitfully used to monitor services w.r.t. achoreographic model, to verify consistency of a DecSerFlow modeland discovery dead activities, and even to mine DecSerFlowmodels starting from execution traces [Lamma et al. 2007]Deeply test the usability of the languageFuture works:Modeling data-related aspects (e.g. data-driven conditions)Deeply study the relationships between LTL and SCIFF