Overview of Web Service Models and Frameworks Web

Overview of Web Service Models and Frameworks Web Services: Overview

Web Services The Web: Flexible human-machine interaction n Web services: Flexible machine-machine interaction n Working Definition: Network-resident software services accessible via standardized protocols l Simple Object Access Protocol (SOAP): very flexible remote procedure call n n Lots of interest in trade press, academic community, standards bodies, . . . n Applications in e-commerce, telecom, science, GRID, government, education, . . . Web Services: Overview 2

7 Principles of Service-Oriented Development [Bloomberg ’ 02] n Dynamic services replace static components n Service exposure and reflection replaces traditional system integration l Bottom up replaces top down n Coding for broad applicability supercedes coding for reusability l Far beyond reuse in object-oriented programming n Ad hoc upgrades supplant disruptive upgrades n Scalability handled bottom up, instead of top down n Platform dependence gives way to platform irrelevance n The federation model of software replaces the dictatorship model Web Services: Overview 3

E-Commerce authorize ok t eip 1 rec r 1 e ord re or cei de pt r 2 2 supplier 1 bank nt 1 e ym pa ill 1 b ym en bill t 2 2 store pa buy get supplier 2 Web services paradigm driven by e-commerce n Today: front-end; Tomorrow: back-end n Enactments with different life-cycles l E. g. , one credit authorize for many orders n Add new services dynamically n Web Services: Overview 4

Telecom/Collaborative Services Session Coordinator Profile Data Pre-Pay Media Server (video) Media Server (voice) Presence Server n Emerging standards will enable l Flexible, dynamic incorporation of features l Convergence of telecom and web services n Bearer traffic vs. signaling/control traffic n Asynchronous events, feature interaction Web Services: Overview 5

E-Science Controller control and calibrations Sea Circulation Atmospheric Simulation notifications and/or experimental data Waste Transport n E. g. , find best location for waste treatment plant n Possibly 100 s of nodes, and running for weeks n Data size difference: l Control and calibrations (small) l Experimental data (large) n Provenance: need to access derivation history Web Services: Overview 6

Web Services: Goals Simplify and/or automate web service n Discovery What properties should be described? l How to efficiently query against them? l n Composition Specifying goals of a composition l Specifying constraints on a composition l Building a composition l Analysis of compositions l n Primary focus of this course Invocation Keeping enactments separated l Providing transactional guarantees l n Monitoring How to track enactments l Recovering from failed enactments Web Services: Overview l 7

The Web Services Paradigm n Primary roots of web services paradigm a) Process description formalisms b) Distributed computing middleware c) Data management n What makes web services “new” l More flexible, less structured than CORBA l Data management has larger role in (a) and (b) l Importance of standards to enable interoperation and analysis Web Services: Overview 8

Web Services Protocol Stack* Web service composition: WSFL, XLANG, BPEL 4 WS, BPML W 3 C Choreography Publishing and discovery: UDDI Service Description Layer: WSDL, WSCI XML messaging layer: SOAP Transport layer: HTTP, SMTP, FTP, etc. * Based on [van der Aalst ’ 03] Web Services: Overview 9

Web Service Standards Stack WSDL Message SOAP Type XML Schema Data XML Web Service Standards Web Services: Overview IBM Web. Sphere Interface Sun J 2 EE BPEL, DAML-S, WSCI Microsoft. Net Behavior [Fu-Bultan-Su CIAA ’ 03] Implementation Platforms 10

Web Service Standards Stack Web Services: Overview [Turner-Budgen-Brereton CACM ’ 03] 11

Web Services Standards Stack: Key Elements Discovery Choreography Composition (Individual) Service Description UDDI WS-Choreorgaphy BPEL 4 WS OWL-S Service. Model WSCL WSDL OWL-S Service. Profice XML Messaging SOAP Network HTTP, SMTP, FTP, etc. Web Services: Overview 12

Simple Object Access Protocol A W 3 C standard n Originally developed for Biz. Talk n A light weight replacement for complicated distributed object technology n n “XML-RPC”, typically through HTTP, also JMS … l Lowest level of service interaction External Service Web Services: Overview SOAP Envelope Web Server Web Service 13

RPC Messages n Typically two messages SOAP Client SOAP Envelope SOAP Header SOAP Body Web Services: Overview Request Message Response Message SOAP Server “RPC style” SOAP body encodes l the operation name and parameters l return result XMLified 14

Web Service Definition Language (WSDL) n WSDL provides a framework for defining l Interface: operations and input/output l Access specification: SOAP bindings (e. g. , RPC) l Endpoint: the location of service Port Type Formats & Protocols Binding Supports oke inv Operation o wt Ho How to encode Input & Output Provides Service Message Implements Port [from Leymann BTW 2003 talk] Web Services: Overview 15

WSDL Operations n Traditional I/O signatures (using XML Schema) n Four operation types l Proactive : send request, block till response l Reactive : receive request, send response bill order Supplier’ Supplier receipt payment bill_payment out: bill in: payment receipt n Port: mechanism to cluster operations l Port as unit of interoperation between services Web Services: Overview 16

Business Process Execution Language (BPEL) Allow specification of compositions of Web services l business processes as coordinated interactions of Web services n Allow abstract and executable processes n Influences from l Traditional flow models l Structured programming l Successor of WSFL and XLANG n Assumes WSDL ports n n Standardization through OASIS Web Services: Overview 17

BPEL in Action Purchase Order service coordinates other services using ports in WSDL Purchase Order port. Type Receive Purchase Order Price Calculation port. Type operations Initiate Price Calculation Complete Price Calculation Decide On Shipper Arrange Logistics Initiate Production Scheduling Complete Production Scheduling Invoice Processing [from BPEL 1. 1 standard] Web Services: Overview 18

BPEL Activities n n n Invokes an operation on a partner service l Send to WSDL port, wait for a response Receives invocation from a partner l Wait for a message Sends a reply message in partner invocation l Send a message (corresponding to some earlier message) Data assignment between containers l Copy local data Control structures: sequence, flow (possibly with links), pick, loops, etc. Scoping, exceptions, compensation Web Services: Overview 19

BPEL Examples begin parallel Initialize do until flag end_date reached flag : = true pick Receive Bill 1 send Order receive order receive Receipt 1 case suppl 2 order Send Bill suppl 1 order end case Receive Payment send Receipt Send Payment 1 end parallel Flowcharts “with parallelism” n “Pick” construct to enable waiting for input (or time out) n Synchronization within parallel threads n Comparison of supported constructs: see [van der Aalst ’ 03] n Web Services: Overview 20

Web Service Conversation Language (WSCL) A key to web service composition: l Interactions between services n WSCL specifies a conversation (behavior signature) as a labeled graph: l Nodes: interactions, individual units of responses l Edges: transitions, sequencing of interactions l Edge labels: conditions on transitions n Invalid. Payment Purchase ? Purchase. Order !POAccepted !In va lid Pa !Out. Of. Stock ym e POAccepted Shipping !Shipping. Info nt Web Services: Overview 21

WS Choreography An emerging standard from W 3 C l Drawing inspiration from the p-calculus n Global view of composite service interactions l Global model: interactions and choreography l Choreography Definition Language (WS-CDL) n Key technical elements l Participants and roles: what services are involved l Channels: where and how the messages are sent l Interactions: message exchange patterns l Activities and control structures: sequencing l Choreography: a global description of a composition n o o Interactions, exceptions, finalizer composable Web Services: Overview 22

BPEL versus A scripted composition using l WSDL messages l Control structures with constrained parallelism n More procedural n Executable or abstract n n Favor centralized composition Web Services: Overview WS-Choreography n A global description of what and how WDSL messages are exchanged Declarative flavor n Abstract and not executable (yet) n Composition infrastructure neutral n Channels can be passed around (e. g. p-calculus) n 23

OWL-S (Formerly DAML-S) An emerging standard to add semantics: l An upper ontology for describing properties & capabilities of web services using OWL n Enable automation: service discovery & selection, invocation, composition & interoperation, execution monitoring n Resource provides Service supports Service ss) w to acce Grounding (ho § communication protocol (RPC, HTTP, …) § port number § marshalling/serialization Web Services: Overview presents ) (what it does describ edby (how it works) Service Profile § § input types output types preconditions effects Service Model § process flow § composition hierarchy § process definitions 24

OWL-S Service Profiles presents (what it does) Service Profile § § Input types Output types Preconditions Effects Service n Service profile defines what the service provides: Functional descriptions: In/Output, Preconditions, Effects l Non functional descriptions: name, category, Qo. S, … l n Can use situation calculi (e. g. PSL) as formal basis for pre-conditions, effects: l Assume a world of “fluents” – typically a set of propositions, where actions make some true, some false Reasoning with pre-conditions and effects n Service profiles are hierarchically organized (example later) n Web Services: Overview 25

OWL-S Focuses on Knowledge n Conditions order on input/output Supplier l if valid client sends order, receipt then bill is created l if payment is received, then receipt is sent bill payment n Conditions on “state of world” l Amount of $$ in line of credit l Supplier ships order when payment is received n Performing inference (“everything else fixed”) l Assume a Bank service such that: if bill received and sufficient funds, then payment is sent l Then we can infer that: “an order from a valid client with a sufficient account balance will result in a receipt and shipment of the order” Web Services: Overview 26

OWL-S Service Model Web Services: Overview 27

OWL-S Process Model n Constructs for composite processes l Sequence l Concurrency: l Choice l If-Then-Else Split; Split+Join; Unordered Service describedby (how it works) Service Model § process flow § composition hierarchy § process definitions l Looping: Repeat-Until; Iterate (non-deterministic) l Note: In spirit of Golog, these can be viewed as constraints n Data Flow l No explicit variables, no internal data store l Predicate “same. Values” to match input of composite service and input of subordinate service n Less refined than, e. g. , BPEL n Message behavior of composed OWL-S services not well -understood Web Services: Overview 28

Universal Description, Discovery and Integration (UDDI) n Directory for web services Communicate via SOAP l Includes descriptions of services, in terms of: l o n Business, services, binding, “technical fingerprints” t. Models l “Schemas” for describing service templates (Port. Types) o o l There are t. Model’s for WSDL descriptions of a service, for eb. XML, … When a service registers with UDDI, the technical fingerprint includes listing of t. Models that it uses t. Model’s can be registered, and incorporated into taxonomies Allows queries over services, t. Models, implementations, and other information n UDDI expected to expand over time, enabling richer service descriptions n Web Services: Overview 29

OWL-S Profile Ontology is Analogous to the Concept of UDDI Taxonomy Web Services: Overview 30

Models of Interoperation Different models focus on different aspects n Automata-based l Intricate structure for atomic services l Rich interleaving between atomic services l Message-based or activity-based n Logic-based perspectives l Frameworks supporting proof and model theories l Different ways of modeling complex services l Natural to incorporate “effect on the world” n Constraint-based l Support partial specification of desired behaviors l Focus on different varieties of “observables” Web Services: Overview 31

First Impressions: Topology Two common approaches: authorize ok p warehouse 1 nt 1 me ay l bil 1 store a n Mediated, or “hub and spoke” Web Services: Overview o o 1 warehouse 1 b 1 ord e rec r 2 eip t 2 a’ r b mediator p 1 warehouse 2 bank k’ r 1 bill 2 Peer-to-peer bank payment 2 n order 1 receipt 1 store b 2 o 2 k p p 2 r 2 warehouse 2 32

First Impressions: Enactments authorize ok receipt 1 pay b ill 1 ord e rec eip r 2 bill 2 warehouse 1 ent 1 m bank payment 2 order 1 store t 2 ware- house 2 “Enactment” = the execution of multiple steps in a (composite) service, corresponding to a single instance of a (possibly complex) business process n Nested enactments: one authorize, several orders n Web Services: Overview 33

Compositions vs. Complex Individual Services n Re-usability of component parts For individual services, this is a design goal, but not enforced l For compositions, this is foundational assumption l n World view Components of individual service can “see” the rest of the service, modulo scoping, etc. l Services in a composition have a limited interface to “see” other services (typically via messages only) l o n Implications on transactional aspects Management of different enactments Individual service: Details of enactment management are hidden l Composite service: Need mechanism for associating activities of component services with appropriate global enactment o BPEL uses the phrase “correlation sets” Web Services: Overview 34 l

Models we describe here Model Emphasize Individual Composite service Style Mealy/Conversation yes Automata, message-based Roman yes Automata, activity-based Data-Driven yes PSL/Situation Calculus yes CTR/CTR-S yes Commitment Web Services: Overview Automata (specified by rules) yes First-order Logic, activitybased Stylized Logic yes Constraints, message-based 35

Mealy Service Model [Bultan et al WWW’ 03] n Individual service as a Mealy (finite state) machine: l Input and output messages only l Finite state control n Describes behavioral signatures l Abstraction of WSCL n Composition: connecting related services !r 2 ? o 2 ent 1 m pay warehouse 1 Web Services: Overview l b il 1 bank ord e rec eip r 2 bill 2 payment 2 receipt 1 store order 1 !b 2 authorize ok t 2 ware- house 2 ? p 2 !b 2 !r 2 ? p 2 !r 2 warehouse 2 36

Asynchronous Communication With Queue n Asynchronous, for example, the following channel: store order 1 o 1 warehouse 1 send Order 1 … Queues are FIFO, unbounded length n Can simulate synchronous and also bounded queues n send Order 1 receive Receipt 1 … Web Services: Overview 37

Conversations (an abstraction of enactments) n Watcher: “records” the messages as they are sent authorize warehouse 1 t 1 en o ym rde r pa r ec 2 ill 1 eipt b 2 bank payment 2 ok bill 2 order 1 receipt 1 store Watcher a k o 1 o 2 b 1 p 1 r 2 b 2 p 2 warehouse 2 A conversation is a sequence of messages the watcher sees in a successful run (or enactment) n Conversation language: the set of all possible conversations n What properties do composition languages have? n Web Services: Overview 38

Example of Specifying A Conversation Protocol authorize ok 1 n bil l 1 ord er 2 rec eip t 2 l 2 bil nt 2 e ym y pa warehouse 1 t 1 en m bank pa ord rec er 1 eip t store warehouse 2 The conversation language allowed: a k shuffle ( ( o 1(shuffle ( r 1, b 1 p 1) )* , ( o 2(shuffle ( r 2, b 2 p 2) )* ) Web Services: Overview 39

Conversation Languages Are Not Regular !a ? b p 1 n a ? a b !b p 2 CL a*b* = anbn Composition languages are not always regular l Some may not even be context free n Causes: asynchronous communication & unbounded queue n Bounded queues or synchronous: CL always regular n CLs are always context sensitive n Web Services: Overview 40

“Roman” model: An automata-based models with activities [Berardi et. al. ICSOC 03] n Model of human-machine web services (e. g. , Amazon) n Focus on activities n Abstract behavior of the Service: Client selects next activity init search listen cart buy Do until Client selects “End” 1. Give Client a choice of actions to be performed 2. Wait for Client choice 3. Perform action chosen by Client Web Services: Overview Online Music Store Client Service on-line music store 41

Roman Model: Automata representation init search listen cart buy Music store search init search listen cart search cart buy search Transitions labeled by activities n More abstract than message-based approach n For a given state, the out-edges represent the set of options that will be presented to the user n Web Services: Overview 42

Delegator: Activity-based FSM annotated with delegations Roman model: Composition init search listen cart buy Delegator for music store init Web search Web listen Juke search Web cart Web ? ? ? search Web cart Web buy Bank Web store init search cart Juke listen Bank buy search Web Services: Overview 43

Data Driven Web Service [Deutsch et al PODS’ 04] is on interaction between control flow and database contents n Transitions resemble Datalog rules and update the database n Rules + DB can be used to simulate Effects control structures (updatable) Home page(HP) n Emphasis Name passwd login Customer page(CP) Error message page(MP) Read only cancel Desktop My order laptop back Desktop Search(SP) Past Order (POP) Past Order laptop Search(SP) Desktop search Ram: Hdd: Display: search Order status(OSP) Order status Cancel confirmation page(CCP) Product index page(PIP) Matching products Product detail page(PP) Product detail buy Confirmation page(Co. P) Order detail Web Services: Overview 44

An Abstract Perspective: Rule-based Control n A hybrid combining automata and logic Condition based on database query Updates to the database A complex service: If then run S database Effects (updatable) E S : E’ If n then run Sn Read only Web Services: Overview 45

Situation Calculi and PSL: Logics with Actions and Tree-based models Focus on description of properties, not execution n Models: n l n Trees whose nodes correspond to atomic actions “Fluents”: Propositions (and predicates) which hold between the actions l Used to test pre-conditions, record effects l n Vocabulary of PSL (a very rich situation calculus) Various layers of reified predicates, e. g. , o activity (a), activity_occurrence (o), timepoint (t) o occurrence_of (o, a), min_precedes (o 1, o 2, a) o holds (f, o), prior (f, o) l Activities and occurrences identified using variables and terms (e. g. , withdraw(x, y)) l First-order logic, with a family of axioms l Web Services: Overview 46

PSL: Simple illustration of the model theory Atomic activities: w 1 = withdraw (100, buyer) d 1 = deposit (100, seller) w 2 = withdraw (5, buyer) d 2 = deposit (5, broker) init Balance(buyer, 300) w 1 w 2 Balance(buyer, 295) w 1 d 1 w 2 transfer(100, buyer, seller) d 1 w 1 Balance(buyer, 195) d 2 w 2 d 1 d 2 w 1 d 2 d 2 d 1 d 1 transfer(5, buyer, broker) Combinations of those transfers Can add constraints, e. g. , that w 1 must precede w 2 n Can use FOL inference or domain-specific reasoning n Web Services: Overview 47

Expressive power of PSL and Situation Calculi Examples of PSL Activities as terms: x, y, z activity( transfer(x, y, z) ) n Composition relationships: n x, y, z subactivity(withdraw(w, y), transfer(x, y, z) a, y ( a = buy_product(y) x, z subactivity( transfer(x, y, z) , a ) ) n Process description for buy_product o, x occurrence_of(o, buy_product(x) ) o 1, o 2, y, z, w, v (occurrence_of( o 1, transfer(y, x, z) occurrence_of(o 2, transfer(w, x, v) subactivity_occurrence(o 1, o ) subactivity_occurrence(o 2, o ) ) Situation Calculi typically less expressive Cannot have variables for composite activities/occurrences n Cannot have terms for activities (e. g. , transfer(x, y, z)) n Web Services: Overview 48

Golog: “Programming” as constraints n Golog: a “programming language” for the situation calculus l “Constructs” such as o o o Sequence: 1 ; 2 Conditional: if then 1 else 2 endif Loop: while do end. While l Interpreted as temporal constraints on permitted paths o n init w 2 w 1 w 2 d 1 w 1 d 2 d 1 d 2 w 1 d 2 d 2 d 1 E. g. , “ w 1; w 2 ” is satisfied by 3 of the 6 branches Two-tier “program” specification l First tier: use the “constructs” from above o Identifies a set of possible execution sequences l Second tier: arbitrary constraints o Further restricts set of possible execution sequences Web Services: Overview 49

CTR/CTR-S: Logics specialized to services n Concurrent Transaction Logic (CTR) [Bonner, Kifer ’ 96] l A logic that extends first-order logic o Three connectives that capture key programming constructs in concurrent transactions An abstract notion of “update” to shared store l A model theory based on sequences of states l A Horn clause fragment with proof theory l A framework for rules-based specification of “programs”, combined with arbitrary constraints n CTR-Services [Davulcu, Kifer, Ramakrishnan WWW’ 04] l Targeted at negotiation (once services are discovered) l One more connective, specific to “adversarial” peer services l Web Services: Overview 50

CTR Constructs (which are constraints) n A simple workflow a cond 1 and c cond 2 or b g d cond 3 f e a ( b | ( c ( d ( e f ))) ) g n Temporal constraint “if e is executed, then b must occur before f ” Trigger “if e is executed and cond 4 , then do h ” (selected) Constructs and intuition l : precedes in any successful execution l | : and are to be interleaved and both execute l : either or is true in each successful exec. l : “isolation” – nothing can interleave with Web Services: Overview 51

CTR: Model Theory and Horn fragment n Updates against shared “external” world Simple example: can use standard relational db updates l Complex example: can use abstract data types as the outside world l n CTR models are “multi-paths”, i. e. , sequences of paths of (traditional) models ( M 1 M 2 M 3 , M 4 M 5 , M 6 M 7 M 8 M 9 ) l n Separations correspond to “break-points”, where other CTR program executions might be interleaved Horn fragment Bottom_part ( c ( d ( e f ))) Workflow a ( b | Bottom_part ) g n a cond 1 and cond 2 b d or e f c g cond 3 There is a proof theory and inference algorithm for Horn fragment Web Services: Overview 52

CTR-Services n New construct: -- “opponent’s choice” Intuition: The external world will choose one of or l So, you have to verify your theory against both possibilities l Useful for modeling different alternatives that may arise in a contract, e. g. , satisfied (ship pay) ( ship insurance_payout) l Allows game-theoretic perspective l n Need to extend model theory of CTR New models are sets of m-paths l Corresponds to the multiple possibilities created by l n As with CTR, a Horn fragment, a proof theory for it, and an inference algorithm Web Services: Overview 53

A constraint-based approach based on Protocols and Commitments [Venkatraman, Singh ’ 99] n Building blocks of the approach: l Commitments: that one service (agent) commits to perform an action for another service (agent) l Protocols: permitted sequences of messages between two services acting in specified roles o Typically expressed as a (finite) “skeleton” Formal underpinnings l Propositional temporal logic (CTL) l Assign meanings (as commitments) to messages n Framework developed to verify whether an enactment satisfies the protocols n Web Services: Overview 54

Commitments Commitment has form: c = (x, y, G, p) l x = debtor l y = creditor l G = “social group” that enforces the commitment l p = “discharge condition” for the commitment n Operations on commitments l Create l Discharge: concurrent with making p true l Cancel: performed by the creditor l Release: typically performed by the social group l Delegate: shifts role of debtor l Assign: shifts role of creditor n Web Services: Overview 55

Example: Message as a commitment Consider an auction with a Seller and Buyers n Some propositional variables in the world n “item_delivered”: becomes true when item delivered l “moneyj-paid”: becomes true if $i is paid to Seller l n Bid-pricei( Buyerj ) can be interpreted as C ( Buyerj, Seller, Auction, AG [ item_delivered AF create ( Buyerj, C ( Buyeri, Seller, Auction, AF moneyi-paid ))]) Intuitively, if Buyerj bids $i, he commits to the Seller that: “If the item is delivered, then eventually Buyerj will create a commitment to eventually pay $i to the Seller” n To make payment: send following message and make payment discharge ( Buyeri, Seller, Auction, AF moneyi-paid ) l Web Services: Overview 56

Other Related Work Process algebras (CSP, CCS, p -calculus, …) l Concurrent processes specified as expressions l Synchronous communications via “channels” l Dynamic creation of channels (p-calculus), processes (spawning) n Relevance to composition: l Formal semantics (e. g. , WS-Choreography and pcalculus) l Reasoning, optimization of processes l Analysis tools n Web Services: Overview Petri nets l Concurrent processes are implicit: o Actions as transitions o Action execution changes one “snapshots” (markings) to another l Used for workflow modeling n Relevance to composition l Analysis and reasoning n 57

Rich on messages Composition Models and Standards Mealy Model WSCL WS-Choreography BPEL 4 WS Commitments WSDL *if interpreted as a composition model Web Services: Overview Golog* Data-Driven* CTR-S* PSL/Situation Calculi OWL-S Roman Rich on activities 58

Automated Composition Why automated composition l Composition “on-the-fly” will enable flexible use of vast numbers of services l E. g. , pick the best services for your immediate need l E. g. , get the job done even if your favorite component service is unavailable n Overview – a nascent field l Roman model: Elegant result in restricted framework l Mealy model: An approach based on synthesis l Golog: An approach based on templates and customization n Web Services: Overview 59

Roman Model: Composition via delegators init search listen cart buy Music store search init search cart buy search “UDDI++”: Available services Web store init listen Desired Service search cart Juke listen Bank buy search Web Services: Overview 60

Delegator: Activity-based FSM annotated with delegations Example delegator init search listen cart buy Delegator for music store init Web search Web listen Juke search Web cart Web ? ? ? search Web buy Bank “UDDI++”: Available services Web store init search Web cart Web search cart Juke listen Bank buy search Web Services: Overview 61

Results on Roman Composition n In some cases, delegator is not simply a labeling of Delegator a target machine Desired S 1 c S 2 b S 2 a c b a S 1 a c n S 2 c b “UDDI++”: Available services Can determine if a delegator exists, and build it, in EXPTIME [Berardi et al ’ 03] l Proof technique uses Description Logics (ALU) l Prototype engine Web Services: Overview implementation of algorithm using DL 62

Conversation Realizability in Mealy model authorize ok pay warehouse 1 l bil 1 ord e rec eip r 2 bill 2 ent 1 m bank payment 2 receipt 1 order 1 store t 2 ware- house 2 n Target conversations as a language L: a k shuffle ((o 1(shuffle (r 1, b 1 p 1))*, (o 2(shuffle (r 2, b 2 p 2))*) n Design question: Given a (regular) language L, can we design Mealy services so that their conversation language is L ? Web Services: Overview 63

A Quick Answer: Some Regular Languages are not Realizable c p 1 a d p 4 e b p 2 p 3 n Very simple language { abcde } l Every Mealy composition allowing conversation abcde will also allow acbde n Two reasons why a language may not be realizable: l Impact of local views — Projection-Join l Impact of send delays — Preponing Web Services: Overview 64

Local View and Join c p 1 a d p 4 e b p 3 p 2 Local views p 1 p 2 p 3 p 4 abcde ace ab bde cd acbde Local view of a peer ppeer(L): the part of conversation the peer participates (receives or sends) n Given languages Li over Si, i n n n Mealy conversation languages L are closed under “projection-join”: Web Services: Overview 65

Delaying Send and Prepone n If the global watcher sees w = … a b … !b … … a b … !a a peer p pp(w) should also allow Web Services: Overview local view at p … b a … 66

A Sufficient Condition for Realizability [Fu et al CIAA ’ 03] n L is a regular language of a Mealy machine A l A , . . . , An are projections of A to peers , …, n 1. Lossless join: JOIN(p (L), . . . , pn(L)) = L Queues are optional: construct a product machine from determined versions of A , . . . , An in which every message sent is ready to be read immediately 3. Each Ai is autonomous: can only do only sends, only receive, or terminate in each state 2. n A conjunction of three conditions implies that L is realizable Web Services: Overview 67

Composition using OWL-S and Golog n Recall: Golog: a “programming language” for the situation calculus init l “Constructs” such as w 1 o o o Sequence: 1 ; 2 Conditional: if then 1 else 2 endif Loop: while do end. While l Interpreted paths n w 2 d 1 w 2 w 1 d 2 d 1 d 2 w 1 d 2 d 2 d 1 as temporal constraints on permitted Con. Golog interpreter l Based on Quintas Prolog l Can search for branches that satisfy a Golog program (and additional constraints) Web Services: Overview 68

Composition with OWL-S and Con. Golog (cont. ) Framework based on two tiers: l Generic programs and Customization via constraints n Start with family of atomic OWL-S services, with preconditions and effects n Write Golog program capturing constraints on generic flow of control and parameter passing n Write additional constraints (in situation calc) to capture personalization l Typically express them as Horn formulas n Use Con. Golog engine to find one (or more) branches in situation calc tree that satisfies all constraints l “Middle-Ground Optimization” based on gathering data in advance of world-altering activities Web Services: Overview 69

Automatic Composition via Petri nets [Narayanan+Mc. Ilraith ’ 02]: Search over all combinations n Recall simulation of OWL-S via 1 -safe Petri nets 1. For set of atomic e-services, create Petri Net that represents all possible (single-use) combinations of them 2. Specify desired goal as a state of this Petri Net 3. Determine if this goal state is reachable n In this framework reachability is PSPACE-complete in size of Petri net l Petri net itself may be exponential in size of atomic e-services l Heuristics can be used to avoid full construction Web Services: Overview 70

Analysis of Web Services Service properties: l Statements on functional logic, service guarantees, … l Statement on execution (deadlock, safety, …) n Analysis may be in more demand: l Dynamic composition l Difficulties in testing l Immature service oriented development environments n Possible approaches: l Static: model checking, theorem proving, … l Runtime monitoring n Web Services: Overview 71

Model Checking The target of interest is given as a state transition system n Properties are specified in some temporal logic, e. g. , linear temporal logic (LTL), branching time logic (CTL), . . n The entire state space is examined systematically n Explicit (automata techniques): e. g. , SPIN, CWB, … l Symbolic, using forward or backward fixpoint: e. g. , SMV o BDDs can be used to symbolically represent sets of states l n Model checking and compositions: The challenge is to map a composition analysis problem to a model checking problem l May need an approximation of the composition model Web Services: Overview 72

Approaches Examined n Model checking l With finite state machines [Fu et al WWW’ 04] [Foster et al ASE’ 03] l With process algebra [Koshikina-van Breugel 2003] n OWL-S services analysis with Petri nets [Narayanan-Mc. Ilraith WWW’ 02] Rule-based services [Deutsch et al PODS’ 04] n Analysis of a Natural Fragment of CTR n [Davulcu et al PODS’ 98] n Dynamic verification of protocol compliance in commitments [Venkatraman and Singh ’ 99] Web Services: Overview 73

Web Services Verification n Model execution as finite state machines [Foster et al ASE ’ 03] [Fu et al WWW ’ 04] Verifying conversation among a set of BPEL composite services [Fu et al WWW ’ 04] warehouse 1 n nt 1 eo m ay rder p 2 r l 1 ecei l pt bi 2 bank bill 2 order 1 receipt 1 store authorize ok payment 2 n warehouse 2 conversation a k o 1 o 2 b 1 p 1 r 2 b 2 p 2 LTL properties: Every authorize followed by some bill? Approach: model BPEL services as “guarded automata” Mealy machines + conditions on Transitions + XML messages + XML local data l Translated to Promela (input language of SPIN) l Web Services: Overview 74

BPEL to Guarded Automata n [Fu et al WWW ’ 04] Each atomic activity an automaton with single entry, single exit <receive … operation = “approve” variable = “request” /> <invoke operation=“approve”, invar="request“, outvar=“aprv. Info” > <catch faultname=“loanfault“> <. . . handler 1. . . /> </catch> </invoke> [request : = approve_Out] ? approve_Out [approve_In : = ! approve_In request] loanfaul ? loanfault t ? approve_Out [aprv. Info : = handler 1 approve_Out] Web Services: Overview 75

BPEL to Guarded Automata n Control flow constructs: assemble Mealy machines <sequence …/> <… act 1…/> <… act 2…/> </sequence …/> <flow …/> <… act 1 …> <source linkname = “link 1” condition = “cond 1 …/> </act 1 > <… act 2 … > <target linkname = “link 1” /> </act 2 > </flow …/> Web Services: Overview act 1 [b_link 1 : = cond 1 ] product act 2 [b_link 1] act 2 76

Partial and Complete Verification (with SPIN) authorize warehouse 1 nt 1 e m ord y er pa r ec 2 ill 1 eipt b 2 bank payment 2 ok bill 2 order 1 receipt 1 store warehouse 2 conversation a k o 1 o 2 b 1 p 1 r 2 b 2 p 2 LTL properties: Every authorize followed by some bill? Promela: input language of SPIN l Concurrent processes communicating with bounded queues n Each guarded automaton a Promela program l Bound the queue length partial verification n Synchronizable complete verification n Web Services: Overview 77

Web Service Analysis Tool (WSAT) Complete verification Guarded Automata Sync. Analysis SPIN Back End Front End WS-Choreography, OWL-S Interacting BPEL Web Services Partial verification SPIN LTL properties other verification tools [Fu et al WWW’ 04, ISSTA’ 04, CAV’ 04] Web Services: Overview 78

Verification with Process Algebra [Koshikina-van Breugel 2003] BPEL control structures BPE-calculus n BPE-calculus PAC and then to CWB n Concurrency Workbench [Cleaveland Sims CAV’ 96] l Model checking tool for CCS and CSP n Checking if a BPEL composition is deadlock-free l In general, temporal properties n Message contents and local data contents are not modeled n Web Services: Overview 79

Verification of OWL-S services Analyzing and automated compositio n Analysis: Does an OWL-S service satisfy some property? [Narayanan-Mc. Ilraith WWW’ 02] An OWL-S service S . . . . ? situation calculus (propositional) Approach: l Simulating S using a Petri net l Conduct Petri net reachability analysis n DAML-S (v 0. 5) analysis is PSPACE complete l Reachability of 1 -safe nets (each place is marked 1 or l n Web Services: Overview 80

Mapping OWL-S to Petri Net n Petri nets: Places: hold tokens l Transitions: consume input tokens and produce output tokens l Marking: a snapshot l Reachability: one marking to another via transitions l n OWL-S to Petri net mapping: Conditions (in situation calculus): places l Atomic services: transitions o Pre- and post-conditions l n Inductive mapping from services to Petri nets Web Services: Overview 81

OWL-S to Petri Net n Control structures “glue” pieces together Web Services: Overview 82

Verification of Rule Based Service [Deutsch et al PODS’ 04] First order temporal properties (FO-LTL) l Verification is in PSPACE for a restricted model (inputbounded services) l Undecidable with slight generalization l Use and extend technique for abstract state machines [Spielman PODS’ 01] Verification of CTL properties l Decidable for the propositional case Web Services: Overview Home page(HP) Name passwd login cancel Customer page(CP) Error message page(MP) My order Desktop laptop back Desktop Search(SP) Past Order (POP) Past Order laptop Search(SP) Desktop search Ram: Hdd: Display: search Order status(OSP) Order status Cancel confirmation page(CCP) Product index page(PIP) Matching products Product detail page(PP) Product detail buy Confirmation page(Co. P) Order detail 83

CTR: Analysis of a Natural Fragment [Davulcu et al PODS’ 98] n Focus on: l a b and c “concurrent Horn goal” – define acyclic workflow or g d f e a ( b | ( c ( d ( e f ))) ) g “unique-event” goals – each event can occur at most once in an execution l (simple) temporal constraints on events (a. k. a. actions) l n Approach to analysis Start with Horn goal G and temporal constraints C n Key transformation*: apply(G, C ) G C l Can construct apply(G, C ) in O( | G | x (# disjuncts)|C| ) l n Example analysis results l G C is consistent iff apply(G, C ) false l n Exists constructive algorithm to test whether every execution of G C satisfies a temporal constraint Extension of approach to CTR-Services [Davulcu et. Al. WWW’ 04] * Second operator, excise, not discussed here Web Services: Overview 84

Verifying Protocol Compliance in Protocols and Commitments model [Venkatraman, Singh ’ 99] n Recall: Bid-pricei( Buyerj ) can be interpreted as C ( Buyerj, Seller, Auction, AG [ item_delivered AF create ( Buyerj, C ( Buyeri, Seller, Auction, AF moneyi-paid ))]) n Goal: enable a service (or group of services) to verify at runtime that the other services are satisfying their commitments l n Assume it can see all messages pertaining to a given protocol Theoretical results Can restrict attention to a linear temporal logic tree, that corresponds what has happened so far l Verify the protocols by testing whether each commitment can be satisfied by extensions of this linear model l Web Services: Overview 85

Web Services: The Big Questions Simplify and/or automate web service n Discovery l What properties should be described? l How to efficiently query against them? n Composition l Specifying goals of a composition l Specifying constraints on a composition l Building a composition l Analysis of compositions n Invocation l Keeping enactments separated l Providing transactional guarantees n Monitoring l How to track enactments l Recovering from failed enactments Web Services: Overview Primary focus of this tutorial 86

Challenge Questions for DB Community Discovery l Large repositories of services will emerge, described according to a variety of models (commitment, automata, …) l How to efficiently query against them? n Monitoring l PSL representation of service enactments has natural representation as a relational database l Can use relational queries to perform run-time monitoring l Can use queries to do data mining on execution logs n Transactions l Providing transactional guarantees remains largely open l What are the building blocks within services? In choreography? l Verifying transactional correctness? n Data-intensive services (e. g. , scientific) l The set of composition specifications is itself a large database n Web Services: Overview 87