Current state of WSMO Choreography and Orchestration

Overview• WSMO Overview– Ontologies– Service Descriptions: Conceptual Level:• Capabilities• Interfaces:– Choreography– Orchestration• Requirements on behavioral and functional description ofservices• Modeling choreography interfaces using ASMs – currentapproach• Open issues3

WSMO Overview: Conceptual Model4

Ontology Example:In WSML you can define:• Rules/axioms over these concepts andattributes• Integrity constraints• Taxonomies (i.e. subconcept relationships)• Instancesetc.6

WSMO Overview: Web Service Descriptions• Capability– Precondition• Information space prior execution– Assumption• State of the world prior execution,• "usual assumptions" as opposed to "checked conditions"– Postcondition• Information space after execution• can also be conditional wrt. the the pre-cond's/ass– Effect• Real World State of the world after execution• can also be conditional wrt. the pre-cond's/ass• Interface– Choreography• interface offered by the WS to communicate with the client– Orchestration• How the Web service uses other Web services to achieve its functionality8

Web Services: Capability and Interfaces- Advertising of Web Service- Support for WS DiscoveryCapabilityfunctional descriptionRealization of WSfunctionality by usingother Web Services- Functional decomposition- WS CompositionChoreographyOrchestrationBehavior Interfacefor consuming WS- Messages- External VisibleBehavior- ‘Grounding’Web ServiceImplementation(not of interest in WebService Description)WSWS9

Capability example, current approach:•maybe better exists ?order10

Scope of capability• facilitate discovery without exposing full functionality ofthe service, accept a certain level of abstraction• web service as „function“ or set of state transitionsdescribed by– currently: precondition + postcondition, assumption+effects– state invriants missing? temporal statements missing?e.g. „the service does not charge my credit card before areservation has been made“12

Scope of choreography• Define the behavioral interface of the service (inputs expected,outputs, possible message exchange patterns) in a way that allowsto automatize interaction with the service• Should facilitate composition:– Should on the one hand allow me to infer in which way to interact withthe service in order to achieve a certain output (as far as specified)– Should on the other hand not duplicate the internal functionality of theservice.--> Tradeoff needed between precise description of what the servicedoes and ease of modeling.• Should not define exact content of messages exchanged or bind toone particular comm paradigm, but facilitate different groundings(e.g. to WSDL, TripleSpace (future))13

Overview• WSMO Overview• Requirements on behavioral and functional description ofservices• Modeling choreography interfaces using ASMs –current approach– "Ontologized" ASMs– Ontologies as state signatures– Instance updates instead of function updates– Example• Open issues14

WSMO: Current Choreography description• ASM Model as the basis• State Signature– State as an extension of a WSMO ontology, defined through set of instanceof Concepts and Relations of an ontology– Concept and Relations have assigned roles in, out, shared, controlled• Transition Rules– Condition• Currently restricted to WSML Logical Expression to support onlyconjunctions/disjunctions of instance membership and attribute value statements• Describes the current state in terms of the attribute-values of the instance data• Question: How to create new instances, or repsectively how to later on reference them?– Updates• Define the changes of the attribute values and instance data in the state• Macros:– add– delete– Update• Attention: Via axioms in ontologies, updates can have non-local effects!15

Choreography: State Signature• State– Defined by a set of imported ontologies• Modes– in: modified by the environment, read by the choreographyinstance– out: read by the environment, modified by the choreographyinstance– shared: read by both the environment and choreographyinstance– controlled: read and modified by the choreography instance only– static: cannot be modified by neither the choreography instancenor the environment16

Choreography: Transition Rules• If condition then rules– The condition is a quantified WSML Core logical expressionmade up of memberOf and hasValue atoms only.– The rules take the form of normal transition or update rules• Forall variables with condition do rules endForall– The variables are WSML variables– The condition is a WSML Core logical expression made up ofmemberOf and hasValue atoms only.– The rules take the form of normal transition or update rules• Choose variables with condition do rules endChoose– Same as Forall except that rules are to be executed are chosennon-deterministically17

Choreography: Update Rules• Instead of assignments for functions we define Basic updates of theinstances of an ontology:– add(fact)– delete(fact)– update(fact new)– update(fact old=> fact new)• A fact takes the following form:– a[b hasValue c]– a memberOf b– …together with syntactic variants• update(a[b hasValue from => to]) :-delete(a[b hasValue from])add(a[b hasValue to])18

Few descriptions, current approach seems toverbose… one try here:• Header:19

Few descriptions, current approach seems toverbose… one try here:• Suggestion: in order to model control flow, make use of control stateASMs:• Allows to "emulate" control flow, sequence, etc.• Allows graphical modeling• Syntax proposal for WSMO in the next slide…20

Few descriptions, current approach seems toverbose… one try here:21

Open discussions about thissyntax proposal, too verbose?Can we reason about suchdescriptions?How does the ASM Model alignwith ontology reasoning?22

Overview• WSMO Overview• Requirements on behavioral and functional description ofservices• Modeling choreography interfaces using ASMs – currentapproach• Open issues– Grounding– Orchestration vs. Composition language– Notions of matching– Formalisms for composition– Model theoretic semantics of chor language– Interesting challenge questions23

Grounding• How does this fit together with existing WS standardssuch as WSDL• Grounding to WSDL means mapping input/output toWSDL operations in a probably pre-existing WSDL file• Ontology instances need to be wrapped into XMLmessages conforming with an XML Schema(lifting/lowering)• Question: What needs to be "sent over the wire"? Thefull object? Only a reference?– How are instances sent over the wire?– (How) are only references sent over the wire?24

Orchestration vs. Composition language• Orchestration currently defined as follows:• "How the Web service uses other Web services to achieve its functionality"• Basic idea based on current approach: Extend the language for choreographyinterface by calls to WW and WG mediators, i.e. mediators which specify howa certain external service or goal maps is invoked by the service itself.• Should also include/realte to grounding• Shall describe how other services or goals are called on an abstractor executable level:1. could be used to describe service templates (which modulo binding ofgoals is even executable)2. executable compositions (where no goals appear)3. loose abstractions which are not executable4. could be tied to/reuse the inputs/outputs described in the thechoreography or not.• How? not clear yet! But there are several requirements:- We need a language to describe 1)+2) for several projects- Should be possible to relate to a graphical representation languagee.g. UML activity diagram style.25

Notions of matching• What does it mean that two capabilities match?– Partly defined, but open questions around semantics forcapabilities• What does it mean that 2 choreographies match?– Basically what needs to be proved is that in all trajectories ofservice x , all trajectories of service y provide necessary input orconsume output of the other service– Process algebras have bi-simulation– How does this extend to collaborations/interleaving of multipleservices26

Formalisms for composition:• Most current approaches to composition doe sequentialcomposition only.• For a service which exposes a complex MEP, this wouldmean (very unlikely) that all service inputs are availableupfront.• More likely: composition by interleaving several complexservices should be possible collaboration!27

Model theoretic semantics of chor language• We need to reason about possible trajectories andexecution histories e.g. for matching• This is possible in FLOWS,• Do ASMs provide this (translation to a formal logic)?• Can we link to FLOWS?28

Interesting challenge questions:• some issues and one use case discussed with RickHull…29

HR1: a Hotel Recommendation Service?find_hotel_request(…, city: c, criteria: cr1, …)!hotel_recommendation(hotel_name: hn, city: c, description: d, …)?find_diff_hotel?request_reservation(person_name: pn, hotel_name: hn, start_date: sd, end_date: ed,further_criteria: cr2, …)if fail then!attempt_failed?find_diff_hotel?find_diff_hotel?endattempt_reservation(person_name: pn, hotel_name: hn, start_date: sd, end_date: ed,criteria: cr1+cr2, …)?endif success then!reservation_avail(person_name: pn, hotel_name: hn, start_date: sdend_date: ed, room_type: rt, time_out: to, …)?commit_for_reservation(person_name: pn, hotel_name: hn, start_date: sd,end_date: ed, credit_card#: cc, …)commit_reservation(person_name: pn, hotel_name: hn, start_date: sd,end_date: ed, criteria: cr1+cr2, …)!confirm_reservation(person_name: pn, hotel_name: hn,start_date: sd, end_date: ed,criteria: cr1+cr2, confirm_number: cn)• A guarded automaton defining advertised/observable behavior of webservice Hotel_Recommendation_1 (HR1), in the spirit of Colombo model• Message receives indicated by ‘?’; message sends indicated by ‘!’; atomicprocess invocations have no preceding punctuation symbol• The one (or more) atomic process(es) used to find the “next” recommendedhotel are not included in this advertisement. However, the attempt_reservation and make_reservation atomic processes are explicitly specified• We are not specifying in detail the ontology for “criteria”, “room_type”, etc.30

Ontology Concepts/Relationsmanipulated by HR1• hotels_recommended_so_far(hotel_name)– Internal to each occurrence of service HR1– Ensures that the same hotel is not recommended twice in one occurrence• hotel_room_inventory(hotel_name, city, room_type, quantity, …)– For this example, assumed to be a static relation– It is also assumed to be a single, virtual relation (since in practice different hotels wouldprobably own/administer their own data). We assume that HR1 provides an abstracted,integrated view of the relations of all the hotels– Accessed by occurrences of HR1 (along with accesses to hotel_reservation andhotel_reservation_request) to check on availability of given type of room on given dates– May have additional fields, e.g, for amenities, such as pool, TV, …• hotel_reservation(hotel_name, room_type, person_name, start_date,end_date, credit_card_#)– As with hotel_room_inventory, assumed to be a single, virtual relation– Shared by all occurrences of service HR1 (and possibly other services)• hotel_reservation_request(hotel_name, room_type, person_name,start_date, end_date, time_out)– As with hotel_room_inventory, assumed to be a single, virtual relation– This is used to store commitments made by a hotel, that it will provide a reservation tothe person, once a credit-card number is provided31– The time_out indicates the time when this commitment will expire

Challenge topic 1 (slide 1 of 2)• Can we map the notions of capability and choreographyinto FLOWS, so that we can precisely formulate thequestion “Does choreography Ch achieve capability Ca?”– Notion of “achieve” will need to be defined, of course• This notion will probably focus on the net effect of the choreography onsome set of (accessible) fluents• In the general case we expect that verifying achievability will beundecidable. The results of Vianu et. al. might provide a starting pointfor finding restrictions on Ch and Ca so that achievability becomesdecidable and/or tractable• Solving this challenge can provide one way to formallyspecify/verify that a given service described by achoregraphy satisfies a user-specified goal (capability)• Can ask analogous question for a choregraphy and anorchestration32

Challenge topic 2 (slide 1 of 4)• Recall the service HR1. It would be useful to be able toinfer the following property:– “Once person p makes a hotel reservation using HR1 and receivesa confirmation number, then this reservation cannot be modified orcanceled except by service occurrences invoked by p.”• Note – inferring this property involves two distinct kinds ofreasoning– Reasoning about the effect of occurrences of HR1 on variousfluents– Reasoning about the effects of occurrences of HR1 and otherservices that happen to touch the hotel_reservations relation• It appears that this desire of a client cannot be expressedusing simply the WSMO notion of “goal”33

Challenge topic 1 (slide 2 of 2)• A possible challenge is the parallel execution of ASM rules, e.g., whatto do with two rules of form– If true then x := y– If true then y := x• Here’s a possible approach to representing such parallel execution: InFLOWS (as with PSL) there are the predicates “prior” and “holds”– prior(f,o) means that fluent f is true just prior to the occurrence o– holds(f,o) means that fluent f is true just after the occurrence o• (Here ‘f ’ can range over propositions or predicates. I think these are actuallysyntactic sugar for something that has a more standard first-order logic format.)– Perhaps we can view one execution of (all of) the rules in an ASM spec asan atomic occurrence – let this occurrence be denoted by variable o, anduse the following for the rules above•…∀v ( prior (val(x,v), o) ⊃ holds (val(y,v),o ) ) …•…∀v’ ( prior (val(y,v’), o) ⊃ holds (val(x,v’),o ) ) …– Will have to work out the details here, and develop a “mechanical”translation from a set of ASM guarded transitions to a set of formulas of thiskind34

Challenge topic 2 (slide 2 of 4)• To make this inference possible, some additionalassumptions may need to be built into the framework,including, e.g.,– Notion of “invoker”: That for each occurrence of HR1 there is aninvoker – a person that has invoked the service– Further, that the only other services that can modifyhotel_reservation are “invoker_aware”– That a tuple (…, person_name:pn, …) in hotel_reservation orhotel_reservation_request can be manipulated by an occurrenceof HR1 (and occurrences of other services) only if the personnamed pn is the invoker of that occurrence (or an agent for thatperson…)35

Challenge topic 2 (slide 3 of 4)• One can imagine including a sentence such as thefollowing into an application domain theory for hotelreservations:– “for each service occurrence o, if o modifies or deletes a tuplehotel_reservation(…, pname: p, …), then o was invoked by theperson with name p”, or, more formally∀ s, o, p, pn, hn, rt, sd, ed, cc (service(s) ∧ occurrence_of(o,s)∧ person(p) ∧ has_name(p,pn)∧ prior( hotel_reservation(hn, rt, pn, sd, ed, cc), o)∧¬holds( hotel_reservation(hn, rt, pn, sd, ed, cc), o)⊃ invoker_aware(s) ∧ invoker_of(p,o) )– (of course, I am cheating here with the implicit assumption that aperson_name uniquely identifies a person…)36

Challenge topic 2 (slide 4 of 4)• A possible definition for the notions of “invoker_aware” and“invoker_of”– “a service s is invoker_aware if for each occurrence o of s there isexactly one person who is the invoker_of of o”. More formally,∀ s ( invoker_aware(s)⊃ ( ∀ o ( occurrence_of(o, s)∃ p (person(p) ∧ invoker_of(p,o)∧∀p’ (person(p’) ∧ invoker_of(p’,o)⊃ p’ = p )– (of course, I am cheating with the implicit assumption that aperson_name uniquely identifies a person…)37

Is this complexity of description necessary?„Once person p makes a hotel reservation using HR1 and receives a confirmation number,then this reservation cannot be modified or canceled except by service occurrencesinvoked by p.“If we want to model, that a service would guarantee such a condition it is probably possiblein FLOWS, something like as follows:• Let's assume this is right, then it would imply that in order to be sure that myreservation is unchanged, I may not invoke any other service after doing thereservartion (all services which do not explicitly say they don't change the reservationcould allow for a model where they do. In an open environment like services, we mightnot count on that all services describe all the side effects they imply.38