E-Services: In Search of the Fundamentals *

1. E-Services:In Search of the Fundamentals* Rick Hull Michael Benedikt Bell Labs Research Lucent Technologies {hull,benedikt}@lucent.com Jianwen Su U. of California, Santa Barbara su@cs.ucsb.edu Vassilis Christophides Foundation for Research and Technology-Hellas (FORTH) christop@ics.forth.gr May 21, 2003 *Based on a paper to appear in PODS 2003; see http://db.bell-labs.com/project/e-composition Fundamentals of E-Services

2. The E-Services Paradigm • E-services: Network-resident software services accessible via standardized protocols • In e-commerce, telecom, science • Possibility of automatic discovery, composition, invocation, monitoring • Primary roots of e-services paradigm (a) Process description formalisms, including automata and workflow (b) Data management (including models, transforms, mediation, txns) (c) Distributed computing middleware • What makes e-services “new” • More flexible, less structured than CORBA • Thus, the interest in describing e-service behavior in machine-readable form • Data management has larger role in (a) and (c) • Process descriptions typically in XML, allowing for use of XML query and constraint languages • Distributed processes, especially in e-commerce, will need txnal properties • Optimization important for data-intensive e-services, especially e-science • There is more motivation to create a “standard” workflow/process model Fundamentals of E-Services

3. Analogy of e-services and XML • Evolution of data models • Structured data (hierarchical, relational) • Web  “unstructured” data, and “semi-structured” data models • XML • Provides some structure • Provides tools for self-description: DTDs, XML Schema • Typed query languages (Xpath 2.0, XQuery) • Expected evolution in distributed object computing • Structured object-based distributed computing (e.g., CORBA) • Web  very flexible forms of distributed computing (SOAP, WSDL) • More structure is emerging • “Glue” languages: WSFL, XLANG, BPEL4WS, BPML • “Behavioral” signatures: automata-based, WSCL, “session types” [Honda et.al. ’98] • Formalisms to describe e-services: DAML-S pre- and post-conditions Increased structure will enable deeper theoretical investigation Fundamentals of E-Services

4. Key directions of this survey • How to describe e-services? • Various foci: I/O signature, automata-based, pre-/post-conditions • How to build composite e-services from atomic ones (part 1)? • Various standards proposed; different disciplines addressed • Most pursue a procedural approach • Formal foundations not yet clear • How to analyze composite e-services? • Tools for analysis of compositions; some old, some new • How to build composite e-services from atomic ones (part 2)? • Approaches to “synthesize” e-compositions from desired global properties • How to exploit the fact that service descriptions are XML? • Novel ways to use XML query and constraint languages Note: many topics will not be addressed including: • Txns, optimization, ontology-based reasoners, service discovery, planning, … Fundamentals of E-Services

5. Outline • Intro • Describing Atomic E-Services • Traditional I/O signatures • Pre- and post-conditions • Signatures with behavior • E-services with data • Describing Composite E-Services • Analysis of E-Compositions • Automated Composition of E-Services • Specifications as Data Fundamentals of E-Services

6. WSDL: Traditional I/O signatures • Peer-to-peer: e-service can act as client or server • Reactive (as client): one-way send request request-response send request, block till response • Proactive (as server): notification receive request solicit-response receive request, send response bill_payment out: bill in: payment Warehouse’ Warehouse order order bill receipt receipt payment (a) 2 one-way and 2 notification operations (b) 1 one-way, 1 notification, and 1 request-response operation • Port: mechanism to cluster operations • Port as unit of interoperation between services • E.g., order+receipt as one port, bill+payment as another Fundamentals of E-Services

7. Warehouse order bill receipt payment Signatures with Behavior (1) • WSDL gives argument types, but not sequencing of operations • DAML-S provides for pre- and post-conditions (in situation calculus) • (Simplified) example post-condition for Order • Order(requester_id, invoice_id, …, part_id) has post-condition ClientOf(requestor_id)  Bill(requester_id, invoice_id, amount) • Example post-condition for Payment • Payment(requester_id, invoice_id, amount) has post-condition Receipt(requester_id, invoice_id, amount) • Assume also a Bank service where • Bill(requester_id, invoice_id, amount) has post-condition account_balance(requester_id, b)  b  amount  Payment(requester_id) • Then we can infer • “an order from a valid client with a sufficient account balance will result in a receipt” • Reasoning with pre- and post-conditions • Different models will lead to different complexity -- largely unexplored • [Narayanan+McIlraith ’02] With DAML-S and Petri-net model as “glue”, intractable except for very restricted subsets of DAML-S Fundamentals of E-Services

8. order order !b bill bill !r ?p ?o ?o !b ?p !r !r !b !r payment ?p receipt payment receipt Signatures with behavior (2) • What is an appropriate abstraction of behavior, to allow more tractable reasoning? • Automata-based is appealing, but Turing machine would be too rich • A useful abstraction: focus on message “classes” and finite state automata • Follows spirit of process algebras, communicating processes • Formalize as Mealy Machine (Q, q0, F, I, O, ) • Transitions on input letter (?), output letter (!), or both or neither • Can model single enactment or sequenced enactments • If all domains are finite, then model can represent all messages (b) “trusting” warehouse (bill-payment and send receipt are interleaved) (a) “cautious” warehouse (don’t send receipt until payment is received) Fundamentals of E-Services

9. Automata and Verification • Automata model permits verification, e.g., with propositional LTL • Assume that these warehouses repeat arbitrarily often • I.e., include a null transition from end state to start state • “If an order has been received in one state, then in the next state a bill has been sent” G([?o] X [!b]) • “If an order has been received then eventually a bill will be sent” G([?o]  F([!b]) • Cautious warehouse satisfies both, trusting warehouse satisfies second • Verification for fsa’s and propositional LTL is linear time in state space order order !b bill bill !r ?p ?o ?o !b ?p !r !r !b !r payment ?p receipt payment receipt (b) “trusting” warehouse (a) “cautious” warehouse Fundamentals of E-Services

10. Web Services Conversation Language (WSCL) • Alternative automata-based approach for describing behavior of e-services • States are the WSDL operations (input and/or output) • Transitions are pairs of operations, with associated condition • Condition refers to type of documents passed as input or output • Relationship of Mealy machine vs. WSCL machine remains open • Mealy machine formalism given above could be extended to include conditions based on types of documents passed • Number of states in WSCL machine bounded by number of WSDL operations • So Mealy machines (with conditions) appear more expressive than WSCL machines Fundamentals of E-Services

11. E-services with data • Store e-service with 2 primary activities • Customer_care receives “buy” requests, and enables “take” • Inventory_replenishment • Set up line of credit with bank using “authorize”, “ok” • Place orders against Warehouse1 and Warehouse2 when stock is low • Store_database used as shared data store buy ?y !t take customer_care store_inventory part qty . . . store_database ?r1 ?r2 order1 !o1 !o2 authorize receipt1 ?k !a ok order2 !o1 !o2 inventory_ replenishment receipt2 ?r1 ?r2 Store e-service Fundamentals of E-Services

12. Abstract model fore-services with data • Variation of relational transducer [Abiteboul et al ’00] • Extend Mealy machine to (Q,q0, F, I, H, O, ) • Input schema I (can hold data associated with incoming messges) • Internal/hidden schema H • Output schema O •  has tuples (q, q’, G, T) • G is “guard” -- boolean query on I and H • T is “transform” - queries that create new H and output O • Can use different data models (relational, XML, …) • General decision problems are undecidable • E.g., if use relational calculus as data manipulation language • Restricted cases are decidable, tractable • E.g., reachability of a state, if using conjunctive queries • E.g., “Spocus” transducers of [Abiteboul et al ’00] have PTIME decidability results Fundamentals of E-Services

13. Outline • Intro • Describing Atomic E-Services • Describing Composite E-Services • A framework for studying e-compositions • Building e-compositions • E-commerce, e-science, telecom, peer-to-peer databases • Analysis of E-Compositions • Automated Composition of E-Services • Specifications as Data Fundamentals of E-Services

14. 1 2 6 5 3 4 • As a closed system, there are no operations from external environment • Analysis, synthesis generally easier for closed systems Composition: peer-2-peer authorize • As shown, this is an open system • There are operations invoked by the external environment • The external environment may be advesarial buy store bank ok take payment1 receipt2 payment2 receipt1 order2 order1 bill1 bill2 ware- house2 ware- house1 Fundamentals of E-Services

15. Peer 1 Peer 2 …… Peer n A composition framework • A peer: autonomous process executing an e-service • Assume reliable asynchronous communication • E-composition Schema (ec-schema): (M,P,C) • M: finite set of message classes (order, bill, …) • P: finite set of (abstract) peers • C: finite set of one-way communication channels • Peer implementation • Map each peer to a (non-deterministic) computable function • Important parameters: • Expressive power of peer implementations: we focus on Mealy machines • Single input queue per peer vs. multiple input queues • Open vs closed • Bounded queues vs unbounded queues • Restricted topologies/control: peer-2-peer,hub-and-spoke, hierarchical, … • Standards (e.g., BPEL4WS, BPML) not explicit re bounded/unbounded Fundamentals of E-Services

16. Building E-Compositions • Specifying links between ports • Using WSDL, it is possible to specify these linkages at setup-time, without re-compiling the e-service (cf. WSIF) • Most approaches to date build e-compositions assume • A “controlling” service • That service is built in a “procedural” manner • Four application areas • Business processes and E-commerce • Based on a mediated or “hub-and-spoke” approach • Standards: WSFL, XLANG, BPEL4WS, BPML • E-Science • Based on a brokered approach: centralized control but peers may communicate directly • Emerging standard: GSFL • Telecom • Must incorporate asynchronous event handling at a fundamental level • Peer-to-Peer databases -- more declarative in general • ActiveXML combines XML, queries, and web services paradigm Fundamentals of E-Services

17. store bank k’ a’ a k r b p o media- tor p2 o1 b2 r1 r2 b1 o2 p1 ware- house1 ware- house2 Mediated Approach • Mediator controls the processing of composition, message exchanges, data exchanges • BPEL4WS, BPMLare essentially languages to program mediators Fundamentals of E-Services

18. Example Mediator (based on BPEL4WS) receive authorize [from Store]; send authorize’ [to Bank]; receive ok [from Bank]; send ok’ [to Store]; • Flowcharts “with parallelism” • “Pick” construct to enable waiting for input (or time out) • Synchronization within parallel threads begin parallel do until flag Receive Bill1 [from Warehouse1] send Order [to Warehouse1] pick first true send Bill [to Bank] end_date has been reached receive order [from Store] receive Receipt1 [from Warehouse1] case: warehouse flag := true receive Payment [from Bank] Warehouse1 Warehouse2 send Receipt [to Store] module for processing Warehouse2 order send Payment1 [to Warehouse1] module for processing Warehouse1 order end parallel end case (b) Module for processing Warehouse1 order (a) Main body Fundamentals of E-Services

19. Mediator Languages: Discussion • Several standards have emerged, including • WSFL: close to IBM’s MQ Series Workflow • Acyclic graph with limited loops • XLANG: close to MS’s BizTalk Orchestrator • Block-structured, several basic control flow structures, pick construct • BPEL4WS: “combination” of WSFL and XLANG • BPML: supports spawning of processes • All of these borrow heavily from the Workflow community • Comparison of supported constructs: see [van der Aalst ’03] • Expressive power of compositions • With bounded queues, a composition of Mealy machines using core of BPEL4WS can be simulated by a Mealy machine • Exact characterization for BPEL4WS remains open • With BPML, this result does not hold, because of process spawning • With unbounded queues, even BPEL4WS can have unexpected behaviors • Note: what is structure of a mediated composition of mediated compositions? • In general, a tree-based structure, whose leaves are atomic e-services Fundamentals of E-Services

20. Broker control and calibrations Sea Circu- lation Atmo- spheric Simu- lation Waste Transport notifications and/or experimental data Brokered Approach for E-Science • Example: determining best location for waste treatment plant • Sea Circulation takes input from Atmospheric Simulation • Waste Transport takes input from Atmospheric Simulation and Sea Circulation • Calibrations* (e.g., coastal boundary conditions) act as additional input data • Size difference: calibrations (small) and experimental data (large) • GSFL: much simpler than BPEL4WS, because scientific computations typically simpler than business processes • Basically, GSFL supports directed acyclic graph • Composition of compositions: Basically a tree, leaves can communicate *At present, services must be re-compiled for each calibration, but we expect will be parameters in the future Fundamentals of E-Services

21. Presence Service Internet Text Chat Service Telephony Service Billing Service 1 Teleconference Service Broker 2 Teleconference Session Response to asynchronous event: 1) Vassilis becomes present (Akhil, Ming, Gregory) Internet Text Chat Session (Akhil, Gregory) 2) Vassilis added to conference (not actively participating) (not present on any network) Telecom and Converged services:Importance of Asynchronous Events Services . . . Sessions . . . 10 AM 11 AM Participants Rick Akhil Ming Geliang Vassilis Gregory Fundamentals of E-Services

22. Brokering with asynchronous event handling • In AZTEC [Christophides et. al. ’01], the broker: • Maintains state of all sessions • Maintains queue for incoming asynchronous events • Launches instance of event-handling flowchart for each external event • Multiple flowcharts can execute simultaneously • Supports synchronization between flowcharts • Flowcharts have priority, and can interrupt other flowcharts (e.g., if prepay account runs out of money) • Common data store can be used to delay flowchart operation • Possible extension • Provide more structure for the family of flowcharts, e.g., • Provide explicit constructs for “session” and “sub-session” • Permit specification of fsa’s for each session being maintaining, and allow that some flowcharts describe what to do on state transitions • Simulation of AZTEC by, e.g., BPEL4WS • Would require use of exception-handling mechanisms to deal with asynchronous events Fundamentals of E-Services

23. Peer-to-peer databases • Basic premise of several systems (e.g., [Gribble et. al. ’01]): • Data is distributed across multiple peers • Query against one peer can take advantage of data in other peers • A query is essentially a “declarative” composition; the system finds a way to answer the query • ActiveXML: a novel combination of data and web services (e.g. [Abiteboul et.al. ’03]) • ActiveXML document can hold “pointers” to other (Active)XML documents • Three ways to treat remote data: • Remote data is virtual, and materialized when queried • Pass data pointer as part of query response • Materialize remote data periodically • Cycles permitted in basic model • E.g., pointers to “my favorite music” including my friends’ favorite music, which point to mine • Current analysis and optimization work focuses on hierarchical case Fundamentals of E-Services

24. Outline • Intro • Describing Atomic E-Services • Describing Composite E-Services • A framework for studying e-compositions • Building e-compositions • E-commerce, e-science, telecom, peer-to-peer databases • Perhaps we need multiple “glue” languages … • Analysis of E-Compositions • For I/O signatures • Results from verification community • Language generation with unbounded queues • Automated Composition of E-Services • Specifications as Data Fundamentals of E-Services

25. bill_payment out: bill in: payment Warehouse’ order receipt Analysis for I/O Signatures • Case 1: signatures between peers must match exactly • Trivial to verify • Case 2: source signature is XML subtype of target signatures • This is suggested in, e.g., BPEL4WS • For XML Schema types, deciding subtype is intractable [Siedl ’90, Simeon+Kuper ’01] • Conservative tests are feasible, e.g., [Pierce+Hosoya ’01], XQuery Fundamentals of E-Services

26. Peer 1 Peer 2 …… Peer n Results from Verification Community • Long history, e.g., [Clarke et.al. ’00] • Results apply to open and closed cases • Associate propositional labeling with each state of each peer • Permits “indirection” between states and observables • Bounded queues • Composition can be simulated as Mealy machine • Verification is decidable, e.g., for LTL it is linear in number of states • Standard techniques to reduce constant in case of “product” construction (e.g., [Clarke et.al. ’00]) • Unbounded queues • In general, undecidable because composition can simulate a Turing machine • Approximation techniques (e.g., [Deutsch ’92]) can be applied here • Results also obtained by restricting topology of ec-schema (e.g., [Ibarra ’00]) Fundamentals of E-Services

27. receive authorize [from Store]; send authorize’ [to Bank]; receive ok [from Bank]; send ok’ [to Store]; do until flag pick first true end_date has been reached receive order [from Store] flag := true case: warehouse Warehouse1 Warehouse2 module for processing Warehouse2 order module for processing Warehouse1 order end case E-service mediators as “white boxes”, • Approaches of BPEL4WS, DAML-S allow white-box view • Similar to workflow, can simulate using Petri-nets [van der Aalst ’98] • Generally map to “1-safe” Petri nets, which seem to correspond to bounded queue case • Verification of properties such as reachability, termination • Complexity depends on constructs, model - e.g., up to PSPACE, EXPSPACE • Identification of automata-style signature has not been a focus Fundamentals of E-Services

28. Peer 1 Peer 2 …… Peer n “Conversation Model”[Bultan et.al. WWW’03] • Study the global behavior of composition • Assume a “watcher” that observes all messages sent • In contrast to approach of verification community, the “observables” here are simply the messages sent • Assume single input queue per peer • Language of a peer implementation is set of words formed by successful executions of the implementation Fundamentals of E-Services

29. authorize store bank !b1 ok order1 !r1 bill1 ?p1 ?o1 !r1 payment1 receipt2 !r1 !b1 receipt1 order1 payment2 order2 bill2 bill1 ?p1 receipt1 payment1 ; null ware- house2 ware- house1 ?r1 ?r2 order1 authorize !o1 !o2 receipt1 ?k !a order2 !o1 !o2 ok receipt2 inventory_ replenishment ?r1 ?r2 (b) (part of) Store bill1 ! p1 ! p2 authorize ?b2 ?b1 payment1 !k ?a ?b1 bill2 ?b2 ok ! p1 ! p2 payment2 (c) Bank Language of Peer Implementation: Example • Language of warehouse example ak SH( (o1 SH(r1,b1p1))*, (o2 SH(r2,b2p2))* ) • This language is regular • Same language whether using bounded or unbounded queues (a) “trusting” warehouse1 Fundamentals of E-Services

30. Unbounded Queues  Unexpected Behaviors ?o ?a !a !a !o !b ?b !o (d) Store’’ (a) Store’ (b) Warehouse’ (c) Bank’ • These are abstract versions of previous e-services • But, no “handshakes” for messages • Language of (a), (b), and (c) • L = { w | w in a(o,b)*, number of o’s and b’s is same, and for each prefix v of w, number of o’s  number of b’s } • L  ao*b* = { aonbn | n  0 }, i.e., L is not regular • Language of (d), (b), and (c) • L’ = {onabn | n  0 } • In general, the language of e-composition with Mealy peers and unbounded queues is context-sensitive [Bultan et.al. WWW’03] • More specifically, each such language is accepted by a quasi-realtime automaton with 3 queues Fundamentals of E-Services

31. Outline • Intro • Describing Atomic E-Services • Describing Composite E-Services • Analysis of E-Compositions • Automated Composition of E-Services • Applying synthesis results from verification community • Using reachability in Petri Nets • A language-based approach • Specifications as Data Fundamentals of E-Services

32. Synthesis approach • Mediated approaches, such as BPEL4WS, are procedural • Synthesis would allow declarative description of desired properties of the composition, and provide automated way to build it • Possible approach • Assume that e-services have behavioral descriptions (e.g., as Mealy machines), and stored in the “UDDI repository” • Problem instance: given desired global behavior (e.g., expressed in LTL) and proposed ec-schema, synthesize behavioral signature needed for each peer • Look for peers with these signatures in UDDI repository • Form composition, and check whether proposed peer implementation satisfies additional properties (e.g., that aren’t captured by the LTL) Fundamentals of E-Services

33. Synthesis approach (cont.) • Synthesis results for Mealy implementations with bounded queues • Closed: folklore results imply that synthesis is decidable • Propositional LTL description  PSPACE • -regular set represented as automaton  PTIME • Open: Undecidable for LTL for arbitrary ec-schemas [Pnueli+Rosner’90] • Decidable for hierarchical topology, but non-elementary even for linear case [Kupferman+Vardi ’01] • Because of high complexity, perhaps most useful in context of synthesizing composition skeletons and test harnesses Fundamentals of E-Services

34. Using Petri Net Reachability [Narayanan+McIlraith ’02] • Based on representation of DAML-S process control constructs in Petri Nets • Captures “completion assumptions” stating that all axioms needed to characterize when a fluent can change are explicitly available • Assumes that all underlying domains are finite • Approach • For set of atomic e-services, create Petri Net based on DAML-S constructs, that represents all possible combinations of the atomic e-services • Specify desired goal as a state of this Petri Net (i.e., in what places tokens should lie) • Determine if this goal state is reachable • In Petri net model of [Narayanan+McIlraith ’02]reachability is in general PSPACE complete in size of Petri net • Based on reduction from 1-safe Petri Nets to Linear Bounded Automaton Acceptance problem • Petri Nets are 1-safe  suggests bounded queue case Fundamentals of E-Services

35. Realizing Languages in Unbounded, Closed Case • Approach: • Start with ec-schema S = (M,P,C) • Specify global language L to be generated • Build peers that generate this language • Challenge: All languages generated by a peer implementation are closed under 2 key properties • Join: if w is generated, then any “shuffling” of the words p(w) corresponding to the individual peers p can also be generated • Prepone: interchange order of input and output messages of a peer p under certain conditions • A language L over M is realizable if there is some peer implementation of S that generates L • Two results [Bultan et.al. WWW’03] • If L is a regular language over M, then a closure of L under join and prepone is realized by a Mealy implementation • For hierarchical ec-schemas, the converse is true Fundamentals of E-Services

36. Outline • Intro • Describing Atomic E-Services • Describing Composite E-Services • Analysis of E-Compositions • Automated Composition of E-Services • Specifications as Data • Because everything is in XML, it is possible to use new tools Fundamentals of E-Services

37. Checking properties of BPEL4WS compositions • Many different kinds of constraints arise in BPEL4WS spec • Referential: e.g., service links should refer to peers in composition • Cardinality: e.g., for each synchronization link there should be one source and one target • Structural: e.g., internal synchronization links should not cross while scopes • Value-based: e.g., for every request-response operation foo, if a “request foo” occurs in a process, then a matching “reply foo” should occur on subsequent paths • XPath output: e.g., that output of a given Xpath query on an internal variable is subtype of a target output variable • For (a): referential constraints in XML Schema suffice • For (b), (c), (d): not in XML Schema, but studied elsewhere, e.g., [Deutsch+Tannen ’01, Benedikt et.al. ’02] • For (e): Might involve a combination of XPath analysis and control flow analysis • If XL is used, then everything is in XQuery, and conservative type-checker of XQuery can ensure type correctness Fundamentals of E-Services

38. Simplifying constraint generation • For a given “glue” language (e.g., BPEL4WS), each well-formed mediator (with associated service linkages) will satisfy a set of constraints • Can we generate those constraints automatically ? XML Schema (with ???) (Workflow Model) “Glue” language Mediator Specification XML Instance (with constraints) (Workflow Schema) • Possible approach: develop notion of “constraint template” (i.e., fill in the “???”) • Use those to generate the concrete constraints Fundamentals of E-Services

39. Querying and Splicing of Workflow specifications[Christophides et.al. ’01] • Focus on “structured” workflow [Kiepuszewski et.al. ’00] • These have natural tree-like structure, because constructs such as fork and while are well-structured • Can use XQuery to make conservative status checks of executing enactment • Whether a node can be reached • Whether a variable can be updated again • Can use XQuery to perform simple form of hierarchical planning • Assume a library of “templates” and concrete WF schemas • Based on input criteria select a root template, and then fill in “gaps” with other templates and/or concrete WF schemas • Remains open whether/how to extend this flavor of result to e-service glue languages • Could provide a simple, pragmatic approach to e-service composition Fundamentals of E-Services

40. Summary • For bounded queue case, e-composition can be studied using tools from verification, including • Automata-based models • Temporal logics • Synthesis algorithms • For unbounded queue case: • This seems more relevant to context of e-compositions • Petri Net models are applicable here • Some preliminary results are available; more work is needed • Specifications as XML opens the door for application of XML tools in the context of web services • Again, many topics are not covered in detail here, e.g., discovery, optimization, transactions Fundamentals of E-Services

41. Challenge Questions • Several “glue” language standards have been driven from the commercial sector, close to existing products. A “glue” language from the academic sector is desparately needed !! Also: find a simple formalism for describing the “glue” languages (analogous to the XML Algebra for XQuery) • We argued that telecom “glue” languages must handle asynchronous events at a first-class level Are e-commerce and telecom languages so different? Will long-running e-commerce transactions (e.g., loans, real estate sales, supply chain relationships) need the session-oriented notions of telecom applications? • Theoretical results here show that automated composition is intractable for the bounded queue case, but e-service compositions in practice may be unbounded queue Find a pragmatic approach to support (limited) automatic composition Fundamentals of E-Services

42. Backup Slides Fundamentals of E-Services

43. Analysis for Behavioral Signatures • Bounded queues • Composition can be simulated as Mealy machine • Verification is decidable, e.g., for LTL it is linear in number of states • Standard techniques to reduce constant in case of “product” construction (e.g., [Clarke et.al. ’00]) • Unbounded queues • In general, undecidable because composition can simulate a Turing machine • Approximation techniques (e.g., [Deutsch ’92]) can be applied here • Results also obtained by restricting topology of ec-schema (e.g., [Ibarra ’00] • E-service mediators as “white boxes”, e.g., BPEL4WS, DAML-S • Similar to workflow, can simulate using Petri-nets [van der Aalst ’98] • Verification of properties such as reachability, termination • Complexity depends on constructs, model - e.g., up to EXPSPACE Fundamentals of E-Services

44. A Theory to Unify “Glue” Languages ? • Several “glue” languages have been proposed • We may have to live with multiple languages going forward • Analogy with semantic data models • [Atzeni+Torlone ’96]: a meta-model for unifying variations on ER model • Can create each ER model from constructs of meta-model • A mapping between models can extend to map schema-instance pair from one model to schema-instance pair of the other • Situation for e-services “glue” languages (a.k.a. process models) XML Schema (with constraints) Process Model XML Instance Process Schema Fundamentals of E-Services

45. Peer 1 Peer 2 …… Peer n Analyzing global behavior • Verification community, e.g., [Clarke et.al. ’00] • Results apply to open and closed cases • Associate propositional labeling with each state of each peer • Permits “indirection” between states and observables • Bounded queue case  verification is tractable, and abstract techniques available to reduce constants in case of compositions • Unbounded queue case  can simulate Turing machines, so undecidable in general case • Verification in DAML-S [Narayanan+McIlraith ’02] • Represent composition using Petri nets • Tractable for subset of DAML-S • PSPACE-complete for full DAML-S 0.5 (assuming finite domains) • Analogous results open for, e.g., BPEL4WS Fundamentals of E-Services

46. Analysis for Behavioral Signatures (cont.) • E-service mediators as “white boxes”, e.g., BPEL4WS, DAML-S • Similar to workflow, can simulate using Petri-nets [van der Aalst ’98] • Verification of properties such as reachability, termination • Complexity depends on constructs, model - e.g., up to PSPACE, EXPSPACE • Identification of automata-style signature has not been a focus • “Conversation Model” [Bultan et.al. WWW’03] • Study the global behavior of composition • Assume a “watcher” that observes all messages sent • Assume single input queue per peer • Language of a peer implementation is set of words formed by successful executions of the implementation Fundamentals of E-Services

47. Using Petri Net Reachability [Narayanan+McIlraith ’02] • Based on representation of DAML-S process control constructs in Petri Nets • Captures “completion assumptions” stating that all axioms needed to characterize when a fluent can change are explicitly available • Assumes that all underlying domains are finite • Approach • For set of atomic e-services, create Petri Net based on DAML-S constructs, that represents all possible combinations of the atomic e-services • Specify desired goal as a state of this Petri Net (i.e., in what places tokens should lie) • Determine if this goal state is reachable • Note: this looks for sequential compositions (no interleaving) • This limitation mainly impacts timing constraints • In Petri net model of [Narayanan+McIlraith ’02]reachability is in general PSPACE complete in size of Petri net • Based on reduction from 1-safe Petri Nets to Linear Bounded Automaton Acceptance problem • Petri Nets are 1-safe  suggests bounded queue case Fundamentals of E-Services

48. Drill down: definitions of join and prepone • Let ec-schema S = (M,P,C) • Key properties of languages generated by peer implementations • Closed under join: For peer p, let • p be set of messages in or out of p, p(w) be “projection” of w onto letters in p The join of w is { v | for each p, p(v) = p(w) } • Intuitively, any “shuffling” of the words p(w) can be generated • Closed under prepone: wm1m2w’ is in L, m1 is an output message of p to some q m2 is an input message to p from some q’  q  wm2m1w’ is in the prepone of L • Intuitively, p can delay producing m1 until after m2 is produced Fundamentals of E-Services