EService Composition and Behavioral Signatures Rick Hull Bell
E-Service Composition and Behavioral Signatures Rick Hull Bell Labs Research October 18, 2003 slides will be available at http: //db. bell-labs. com/user/hull Based in part on the PODS 2003 talk entitled “E-Services: A Look Behind the Curtain”, co-authored with Michael Benedikt (Bell Labs) Vassilis Christophides (FORTH, Jianwen Su (UC Santa Barbara) October 18, 2003 Behavioral Signatures and E-Service Composition Greece) 1
The E-Services Paradigm • Goal: Simplify and/or automate e-service • – Discovery Our focus: how to build, analyze – Composition – Orchestration (invoke, monitor; “choreography”) – Provenance (e-science, recovery) Primary roots of e-services paradigm (a) Process description formalisms (b) Distributed computing middleware (c) Data management • What makes e-services “new” – – Much more de-centralized than workflow More flexible, less structured than CORBA Data management has larger role in (a) and (b) Importance of standards to enable interoperation and analysis October 18, 2003 Behavioral Signatures and E-Service Composition 2
Outline • Events, messaging, and sequential behavior are • • facts of life – We need a notion of “behavioral signature” An automata-based framework – Inspired by CSPs, -calculus, verification theory Analysis “tools” – Several approaches available Automated composition – Including a bridge to DLs Conclusions October 18, 2003 Behavioral Signatures and E-Service Composition 3
Web Services Definition Language (WSDL): Messages and (traditional) I/O signatures • Peer-to-peer: e-service can act as client or server – Proactive : send request, block till response – Reactive : receive request, send response bill order Supplier’ Supplier receipt payment bill_payment out: bill in: payment receipt • Port: mechanism to cluster operations – Port as unit of interoperation between services October 18, 2003 Behavioral Signatures and E-Service Composition 4
E-Commerce: Patterns of Messages authorize bank ok t eip 1 rec r 1 e ord re or ce de ipt r 2 2 supplier 1 t 1 n e m y pa ill 1 b 2 store pa ym en bill t 2 buy get supplier 2 • Certain patterns “acceptable”, others not • Enactments with different life-cycles • – E. g. , one credit authorize for many orders Add new services dynamically – Does supplier 2 fit? (what if supplier 2 uses “prepay”) October 18, 2003 Behavioral Signatures and E-Service Composition 5
Using order to infer IOPA properties order bill Supplier receipt payment • Conditions on input/output – if valid client sends order, then bill is created – if payment is received, then receipt is sent • Conditions on “state of world” – Amount of $$ in line of credit – Supplier ships order when payment is received • Performing inference (“everything else fixed”) – Assume the Bank satisfies: if bill received and sufficient funds, then payment is sent – Infer that: “an order from a valid client with sufficient funds will result in a receipt and shipment of the order” October 18, 2003 Behavioral Signatures and E-Service Composition 6
Services use events • “Full” plane reservation service includes alerts • • if plane is delayed – To person flying – To car rental service, to hotel service, … Services may have to retain context over a period of time – Will be “waiting” for incoming event – Put it into proper context – Take appropriate actions BPEL 4 WS has explicit constructs for asynchronous events – receive, wait, pick October 18, 2003 Behavioral Signatures and E-Service Composition 7
Telecom/Collaborative Services Session Coordinator Profile Data Pre-Pay Media Server (video) Media Server (voice) Presence Server • Emerging standards will enable flexible, dynamic • • invocation of services & incorporation of features – Can be viewed as a special case of web services – Bearer traffic vs. signaling/control traffic Asynchronous events: call dropped, person becomes present, … Feature interactions: call screening, call waiting, … October 18, 2003 Behavioral Signatures and E-Service Composition 8
Outline • Sequential behavior and messaging are a fact • • • of life – We need a notion of “behavioral signature” An automata-based framework – Uses a “black-box” perspective – Contrast to “white-box” formalisms Some “tools” are available – Including a bridge to DLs Conclusions October 18, 2003 Behavioral Signatures and E-Service Composition 9
Two perspectives on E-Services • “Black box”: Signature languages – Web Services Description Language (WSDL) • Focus on input/output signatures only – Pre-/post conditions á la OIL-S – Behavioral: • Focus on sequencing of messages transmitted – W 3 C Choreography group working here • Focus on sequencing of actions performed • “White box”: Implementation languages – Essence of WSFL, XLANG, BPEL 4 WS*, BPML, etc. standards – OIL-S process constructs – Typically, parallel flowcharts with synchronization, scopes, some event handling, internal variables *BPEL 4 WS also supports a “black box” view Composition of e-services October 18, 2003 Behavioral Signatures and E-Service 10
Modeling I: Individual E-services • In the most general case, an e-service can be a Turing machine input messages Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice message log to other e-services local store • For analysis, optimization, and automation it is useful to study more restricted models October 18, 2003 Behavioral Signatures and E-Service Composition 11
Behavioral signatures using messages • Use Mealy Peers: Finite State Automata with input/output – Follows spirit of process algebras, communicating processes ? p !r !b ? o !b rcpt pymnt (a) “cautious” supplier rcpt bill ? p !r ? o !b order !r bill !r order pymnt (b) “trusting” supplier • Can model single or sequenced enactments • Advantages for analysis, e. g. , verifying temporal properties, characterizing global behavior October 18, 2003 Behavioral Signatures and E-Service Composition 12
Modeling II: A composition framework Peer 1 Peer 2 . . . Peer n • A peer: autonomous process executing an e-service • Assume reliable communication October 18, 2003 Behavioral Signatures and E-Service Composition 13
E-Composition Schema • An E-C schema is a triple (P, C, M) Specifies the infrastructure of composition to-peer channels ØM : (finite) set of message classes ipt 1 rece r 1 orde ØC : finite set of peer- authorize ok t 1 n re e c m or ei y p de t pa ll 1 r 2 2 bi supplier 1 bank me nt bill 2 2 (e-services) peers store pay ØP : finite set of supplier 2 • Many variations on this base model possible, e. g. , – Different levels of granularities – Assume finite domains can model parameters explicitly October 18, 2003 Behavioral Signatures and E-Service Composition 14
Combining Peer and Composition Models store !a ? k !o 1 bank . . . ? a !k !o 2 supplier 1 ? o 1 !b 1 . . . supplier 2 ? o 2 ? r 2 !b 1 ? b . . . 2 • Peer fsa’s begin in their start states October 18, 2003 Behavioral Signatures and E-Service Composition 15
Executing a Mealy Composition (cont. ) store !a ? k !o 1 . . . a bank ? a !k !o 2 supplier 1 ? o 1 !b 1 . . . supplier 2 ? o 2 ? r 2 !b 1 ? b . . . 2 • STORE produces letter a and sends to BANK October 18, 2003 Behavioral Signatures and E-Service Composition 16
Executing a Mealy Composition (cont. ) store !a ? k !o 1 bank . . . ? a !k !o 2 supplier 1 ? o 1 !b 1 . . . supplier 2 ? o 2 ? r 2 !b 1 ? b . . . 2 • BANK consumes letter a • Execution successful if all queues are empty and fsa’s in final state October 18, 2003 Behavioral Signatures and E-Service Composition 17
“State” and “Conversation” store !a r 2 ! ? k o 1 . . . b 2 b 1 bank ? a 1 ? b !k !o 2 . . . o 1 supplier 1 ? o 1 !b 1 . . . o 2 r 2 supplier 2 ? o 2 ? r 2 !b . . . 2 • The state • of the composition is based on – state of each peer – contents of the queues Conversation : one enactment of global process – Can have “sub-conversations” of a conversation – Little known about formal properties of conversations October 18, 2003 Behavioral Signatures and E-Service Composition 18
Important Choices for Message-based Composition Model • Representation formalism for • • • peer implementations Expressive power of peer implementations Bounded vs unbounded queues Several queues vs one queue vs heap vs … Open vs closed Restricted topologies/control: peer-to-peer, hub-and-spoke, hierarchical, … Show full language or subset October 18, 2003 Behavioral Signatures and E-Service Composition Peer 1 Peer 2 . . . Peer n 19
Composition Infrastructure authorize store supplier 1 b mediator p 1 2 t 2 ym pa ll 1 bi l 2 pt bil de r 2 t 1 en pa ym en ipt 1 b 1 r r 1 e rec a’ a o 1 or re ce i bank k’ o er 1 store ord • Peer-to-peer (distributed control) bank ok b 2 o 2 supplier 1 supplier 2 k p p 2 r 2 supplier 2 • Hub-and-spoke (centralized control) • BPEL 4 WS, BPML, GSFL useful to define mediators • Composition of compositions hierarchy. . . October 18, 2003 Behavioral Signatures and E-Service Composition 20
BPEL 4 WS: Example white-box language begin parallel Initialize do until flag end_date reached flag : = true pick send Order receive order case suppl 1 order suppl 2 order Send Bill receive Receipt 1 Receive Payment send Receipt end case • • Receive Bill 1 Send Payment 1 end parallel Flowcharts “with parallelism” “Pick” construct to enable waiting for input (or time out) Synchronization within parallel threads Comparison of supported constructs: see [van der Aalst ’ 03] October 18, 2003 Behavioral Signatures and E-Service Composition 21
OIL-S Process Model • Process class • • – Atomic, composite (mediator), or simple (virtual) – Inputs, outputs, effects – Pre-conditions, post-conditions Constructs for composite processes – Sequence – Concurrency: Split; Split+Join; Unordered – Choice – If-Then-Else – Looping: Repeat-Until; Iterate (non-deterministic) Data Flow – No explicit variables, no internal data store, no wait – Predicate “same. Values” to match input of composite service and input of subordinate service • Less refined than, e. g. , BPEL 4 WS October 18, 2003 Behavioral Signatures and E-Service Composition 22
Outline • Events, messages, and sequential behavior are • • facts of life An automata-based framework Analysis “tools” – Petri nets – Tools using temporal logics – Bounded vs. unbounded queues Automatic composition Conclusions October 18, 2003 Behavioral Signatures and E-Service Composition 23
Verifying Properties of DAML-S Processes via Petri nets [Narayanan+Mc. Ilraith ’ 02] • Specify a DAML-S semantics using a situation calculus – Includes Knows, Kwhether, Kref for condition testing – Captures “completion assumptions”: essentially prevents world from changing without e-service knowing about it • Operational semantics via Petri nets – Assume finite domains – Map to “ 1 -safe” Petri nets, which corresponds to bounded queue case • Verify properties such as reachability, termination • Complexity depends on constructs and model – Range from PTIME to EXPSPACE-hard October 18, 2003 Behavioral Signatures and E-Service Composition 24
Verifying Temporal Properties of Mealy Compositions store !a ? k ! o 1 bank . . . ? a !k 1 ? b“shipment !o 2 . just. . made” “line-ofcredit warehouse 1 available” ? o 1 !b 1 . . . warehouse 2 ? o 2 ? r 2 !b 2 ? r 2 . . . • Label states with propositions • – Level of indirection between states and “observables” Express temporal formulas, e. g. , – “shipment just made” only after “line-of-credit avail” October 18, 2003 Behavioral Signatures and E-Service Composition 25
Results on Temporal Verification • Long history, e. g. , [Clarke et. al. ’ 00] • E. g. , verification for fsa’s and propositional LTL – Complexity: PSPACE in size of formula + fsa linear time in size of fsa • Application to Mealy compositions – Results apply to open and closed case – Bounded queues • Composition can be simulated as Mealy machine • Verification is decidable • Standard techniques to reduce cost – Unbounded queues • In general, undecidable • Approximation techniques can be applied October 18, 2003 Behavioral Signatures and E-Service Composition 26
Qualitative Analysis of Unbounded Queue Compositions • “Conversation Languages” [Bultan et. al. WWW’ 03] • Assume a “watcher” that observes all messages sent – In contrast to previous approach, the “observables” here are simply the messages sent Peer 1 Peer 2 . . . • Language of peer implementation is set of words formed by successful executions of the implementation October 18, 2003 Peer n a k o 1 o 2 b 1 p 1. . . Behavioral Signatures and E-Service Composition Watcher 27
Example Conversation Language store !o 1 ? k !a bank !o 2 . . . supplier 2 supplier 1 ? o 1 ? a !b 1 . . . ? o 2 !k ? r 2 !b 1 ? b . . . 2 • Language: ak SH( (o 1 r 1 b 1 p 1)*, (o 2 SH(r 2, b 2 p 2))* ) – First ak, then a shuffle of orders against Supplier 1 and orders against Supplier 2 – Supplier 1 is “cautious” and Supplier 2 is “trusting” • This language is regular • Same language for bounded or unbounded queues October 18, 2003 Behavioral Signatures and E-Service Composition 28
Unbounded Queues Unexpected Behaviors !a !o (a) Store’ ? o ? a ? b !b (b) Supplier’ (c) Bank’ • Abstract versions of previous e-services • • – But, no “handshakes” for messages Conversation language L: – L ao*b* = { aonbn | n 0 }, i. e. , L is not regular Take aways: – “Bottom up” design of compositions may lead to undesirable global behaviors – Service mediators can have important role in preventing behaviors 29 October 18, undesirable 2003 Behavioral Signatures and E-Service Composition
How bad is it ? • In general, conversation language with Mealy peers and unbounded queues is context-sensitive – Accepted by a quasi-realtime automaton with 3 queues • All conversation languages are closed under two key properties – Join: if w is generated, then certain “shuffle products” of w are also generated – Prepone: interchange order of input and output messages of a peer p under certain conditions • For hierarchical ec-schemas: Each peer is a Mealy implementation October 18, 2003 Conversation language is join-prepone closure of a regular language Behavioral Signatures and E-Service Composition 30
Outline • Events, messaging, and sequential behavior are • • facts of life An automata-based framework Analysis “tools” Automatic composition – Hierarchical composition – Results from DAML-S community – Results using Mealy machines – A bridge to DLs Conclusions October 18, 2003 Behavioral Signatures and E-Service Composition 31
Hierarchical Composition • A pragmatic approach to automating e-service composition Customized Travel Service Templates Air Travel Templates Airport Transfer Hotel Reservation October 18, 2003 Behavioral Signatures and E-Service Composition 32
Hierarchical Composition (cont. ) • Approach: – Assume a library of e-service “templates” and ground specs – Based on input criteria select a root template, then fill in “gaps” with other templates and/or ground specs – [Christophides et. al. ’ 01] does this for “structured workflows” • Take-away: Hierarchical structuring is important for e-service formalisms – Need to incorporate this into OWL-S, Mealy model October 18, 2003 Behavioral Signatures and E-Service Composition 33
Automatic Composition for DAML-S [Narayanan+Mc. Ilraith ’ 02]: Search over all combinations • Recall simulation of DAML-S via 1 -safe Petri nets 1. For set of atomic e-services, create Petri Net that represents all possible combinations of them 2. Specify desired goal as a state of this Petri Net 3. Determine if this goal state is reachable • In this framework reachability is PSPACE- complete in size of Petri net – Petri net itself may be exponential in size of atomic e-services – Heuristics can be used to avoid full construction [Mc. Ilraith+Son ’ 02] Generic compositions + customization – develops mapping of DAML-S into Con. Golog, and uses to create compositions – Approach based on 2 -level hierarchy… October 18, 2003 Behavioral Signatures and E-Service Composition 34
Composition for Mealy Peers • Traditional synthesis problem statement: • – Given: ec-schema and LTL formula – Create: an fsa for each peer so that is satisfied Synthesis results for Mealy implementations with bounded queues – Closed compositions: folklore results imply that synthesis is decidable • Propositional LTL description PSPACE • -regular set represented as automaton PTIME – Open compositions: Undecidable for LTL for arbitrary ec-schemas [Pnueli+Rosner ’ 90] • Decidable for hierarchical topology, but nonelementary even for linear case [Kupferman+Vardi ’ 01] October 18, 2003 Behavioral Signatures and E-Service Composition 35
Reformulation of the Synthesis Problem to use extended “UDDI Repository” • • • UDDI Repository: globally accessible store for web service descriptions and locations – Imagine that it supports Mealy descriptions Possible approach – Given: ec-schema, LTL formula , “UDDI repository” – Find: peers in repository so that is satisfied • Variation: allow creation of a mediator to choreograph the selected peers Database aspect of this problem – How to search across large space of Mealy descriptions? – What is appropriate query language? October 18, 2003 Behavioral Signatures and E-Service Composition 36
Synthesis for Unbounded, Closed Case [Bultan et. al. ’ 03] • Use conversation language to express global behavior • Problem statement: – Given: ec-schema and regular language L over messages – Create: an fsa for each peer so that composition generates L’ = join-prepone closure of L • Result: Mealy peers can be constructed whose composition gives global behavior L’ – Do a “projection” on fsa accepting L • Can again ask UDDI version of synthesis question October 18, 2003 Behavioral Signatures and E-Service Composition 37
Recent work from Lenzerini’s group • Based on a different model for peers (DL ’ 03) – Focus on sequences of actions, not messages – Includes a “user” who repeatedly makes choice (from limited set) about next action she wants – All actions “visible” at top level Client Service on-line music store Actions that client can ask for: • initiate, end • search • listen • cart • buy • Abstract behavior of the Service: Do until Client selects “End” October 18, 2003 1. Give Client a choice of actions to be performed 2. Wait for Client choice 3. Perform action chosen by Client Behavioral Signatures and E-Service Composition 38
Solve composition by synthesizing mediator • Assuming peers and spec are regular, can – Determine if a composition exists – If one does, then select peers and construct mediator Desired behavior (as FSA) Extended UDDI Mediator (constructed) Services (selected from “UDDI”) • Using standard automata techniques: NEXPTIME • Using reduction to ALU DL: EXPTIME October 18, 2003 Behavioral Signatures and E-Service Composition 39
Conclusions • Sequential behavior and messaging are a fact • of life – We need a notion of “behavioral signature” Automata-based perspective – Provides formal framework that incorporates events and sequencing – Can draw on broad theory of analysis “tools” – Offers a framework for automated composition – Can represent (at least some) in DLs – link to OWL? • Automata-based perspective should be • exploited in semantic web services Results suggest key challenges in composition – Select peers: queries over sets of peers – Mediator crucial: find/build the mediator October 18, 2003 Behavioral Signatures and E-Service Composition 40
We are just getting started … • • • Enhanced Mealy – can we incorporate – Messages + actions – Pre-/post-conditions á la OWL-S – Hierarchical structure for messages (state charts? ) – Temporal constraints – (your favorite) PSL constructs Composition of Mealy++ machines – Can we adapt the Roman approach ? – Augment traditional planning with approach for cyclic behaviors Mealy++ vis-à-vis BPEL 4 WS, OWL-S process model, PSL, FIPA A-UML, … – Jianwen Su et. al. developing tool for translating between Mealy and BPEL 4 WS Searching a large set of Mealy++ signatures – What is appropriate query language? Finding relevant results from various communities: verification, -calculus, planning, DL, DB, agent, … October 18, 2003 Behavioral Signatures and E-Service Composition 41
Backup Slides October 18, 2003 Behavioral Signatures and E-Service Composition 42
E-Services • • • The Web: Flexible human-machine interaction E-services: Flexible machine-machine interaction Working Definition: Network-resident software services accessible via standardized protocols – Simple Object Access Protocol (SOAP): very flexible remote procedure call • Lots of interest in trade press, academic community, standards bodies, . . . • Applications in e-commerce, telecom, science, GRID, government, education, . . . October 18, 2003 Behavioral Signatures and E-Service Composition 43
E-Science Controller control and calibrations Atmospheric Simulation Sea Circulation notifications and/or experimental data Waste Transport • E. g. , find best location for waste treatment plant • Possibly 100 s of nodes, and running for weeks • Data size difference: • – Control and calibrations (small) – Experimental data (large) Provenance: need to access derivation history October 18, 2003 Behavioral Signatures and E-Service Composition 44
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] October 18, 2003 Behavioral Signatures and E-Service Composition 45
Pre-/post-conditions • DAML-S provides for order bill Supplier pre- and post-conditions receipt payment • Examples – if valid client sends Order, then Bill is created – if Payment is received, then Receipt is sent • Performing inference (“everything else fixed”) – Assume a Bank service such that: if bill received and sufficient funds, then payment is sent – Then we can infer that: “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 – [Narayanan+Mc. Ilraith ’ 02] axiomatization in situation calculus for a Petri-net based model • Complexity from PTIME to EXPSPACE-hard October 18, 2003 Behavioral Signatures and E-Service Composition 46
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 October 18, 2003 Behavioral Signatures and E-Service Composition 47
Technical Definition A Mealy peer is an FSA M = (T, s, F, in, out, ) – T : a set of states – s : the initial state – F : a set of final states – in : input message classes – out : output message classes – : transition relation that either Øconsume an input, (s 1, ? m, s 2), or Øproduce output, (s 1, !m, s 2), or Ømake an empty (internal ) move, (s 1, e, s 2) October 18, 2003 Behavioral Signatures and E-Service Composition 48
Abstract model for e-services with data • • Variation of relational transducer [Abiteboul et al ’ 00] Extend Mealy machine to (Q, q 0, F, I, H, O, ) • • Can use different data models (relational, XML, …) General decision problems are undecidable • Restricted cases are decidable, tractable – – 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 – E. g. , if use relational calculus as data manipulation language – E. g. , reachability of a state, if using conjunctive queries – E. g. , “Spocus” transducers of [Abiteboul et al ’ 00] have PTIME decidability results October 18, 2003 Behavioral Signatures and E-Service Composition 49
Data Transducers as White-Box Peers • Add database to fsa (XML, relational) • Store e-service with – Customer_care – Inventory_replenishment – Store_database used as buy take ? y !t customer_care store_inventory part qty . . . shared data store • Cf. , XL [Florescu et. al. ’ 03] – Process + XQuery • Cf. , Relational Transducer authorize [Abiteboul et. al. ’ 00] ok – Analysis undecidable; NEXPTIME for restrictions October 18, 2003 store_database ? r 1 !a ? k !o 1 !o 2 inventory_? r 2 replenishment Behavioral Signatures and E-Service Composition !o ? r 2 2 order 1 receipt 1 order 2 !o 1 ? r 1 receipt 2 50
Parting Challenge: Process + Data store warehouse 1 bank warehouse 2 • Develop a theory for e-service composition that • • incorporates process + data E. g. , “Relational Mealy Machines” (or XML, . . . ) – Cf. Relational Transducers of [Abiteboul et. al. ’ 00] – Focus on restricted query/update languages Extend results previously obtained to include variables, context, large data October 18, 2003 Behavioral Signatures and E-Service Composition 51
E-service “Glue” Languages and Workflow Management • “Computerised facilitation • or automation of a business process, in whole or part” [Wf. MC] Centralized control – State of conversation maintained by WF manager • Delegation of “almost everything” to the app. s • – E. g. , application data is not accessible to WF manager Workflow standardization has mixed success – Web services must interoperate standard likely – Should focus on interfaces, not internals October 18, 2003 Behavioral Signatures and E-Service Composition 52
Active. XML: A data-centric white-box language [Abiteboul et. al. ’ 03] • A novel combination of data and web services • 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 • Alternative to control-flow based languages: – “Outer process flow” dictated by XML query language (and structure of data) – “Remote procedure calls” embedded into XML structure October 18, 2003 Behavioral Signatures and E-Service Composition 53
White-box Analysis via XML • Many different kinds of constraints arise in BPEL 4 WS spec a) b) c) d) e) Referential: service links refer to peers in composition Cardinality: for synchronization links, 1 source and 1 target Structural: internal synchronization links don’t cross while scopes Value-based: requests matched by responses XPath: query on variable is subtype of a target variable • For (a): XML Schema suffices • For (b) - (d): see [Deutsch+Tannen ’ 01, Benedikt et. al. ’ 02] • For (e): Involves a combination of XPath and control flow analysis – If XL used, then “everything” is XQuery, and so XQuery typechecker can assist with type correctness October 18, 2003 Behavioral Signatures and E-Service Composition 54
AZTEC: A white-box language for sessions and asynchronous events [Christophides et. al. ’ 01] • Control is hub-and-spoke • Maintains state of sessions Session Coordinator Profile Data Pre-Pay – Richer than web-service notion of conversation Media Server (video) Media Server (voice) Presence Server • Queue for incoming asynchronous events • Launches instance of event-handling flowchart for each external event • Synchronization between flowcharts – Priority – Via shared data – Can interrupt other flowcharts (e. g. , if prepay account runs out of money) October 18, 2003 Behavioral Signatures and E-Service Composition 55
Agent UML • • • E. g. , [Odell, Bauer, et. al. slide deck, 2000] An exploration of different ways that UML can be used to capture agent interactions Message types based on KQML – request, assert, refuse, … – Subset of messages relevant to e-commerce, alerting services, long-running activities, supply chain life-cycle, manufacturing life-cycle, collaborative technologies, pervasive computing, … October 18, 2003 Winograd-Flores perspective (classical) Behavioral Signatures and E-Service Composition 56
A-UML: focus on modeling • • Diff. levels: Global, interaction, internal Focus not on analysis or automated composition Packages (with nesting) [for global aspects] Collaboration Diagram October 18, 2003 Sequence Chart Behavioral Signatures and E-Service Composition Activity Diagram (with Swim Lanes and Object Flow) Nesting (mix & match) 57
A “Roman” approach to composition that bridges to DLs [Berardi et al ’ 03] • Based on an action-based model • E-commerce example, with focus on actions sell_goods authorize_ line_of_credit store bank ill_ fulf er 1 ord pay_ supplier 1 supplier 2 • Higher level of abstraction than messages • Enactments still have different life-cycles October 18, 2003 Behavioral Signatures and E-Service Composition 58
Focus on one Client, one Server • Drill down on customer buying CDs • Examine sub-actions inside sell_goods initiate search listen cart buy end October 18, 2003 Frontend Backend • Abstract behavior of the Service: Client Service Online Music Store Do until Client selects “End” 1. Give Client a choice of actions to on-line music store be performed 2. Wait for Client choice 3. Perform action chosen by Client Behavioral Signatures and E-Service Composition 59
“Execution Tree” in Roman model • (External) execution tree: all possible sequences of actions supported by service Action supported by service initiate Client search cart buy search State at which client can not stop . . . search . . . Service listen on-line music store State at which client can stop • Children labeled by distinct actions • Tree is equivalent to a language over actions – Typically, focus on regular languages October 18, 2003 Behavioral Signatures and E-Service Composition 60
Composition in Roman Model (sketch) • Internal execution tree holds actions by server and delegates of that server Client initiate, care search, care on-line music store search, care jukebox cart, care cart, buy, care bank search, care bank . . . cust. care . . . Service delegates listen, juke . . . Service • All actions are “visible” to client; none “internal” October 18, 2003 Behavioral Signatures and E-Service Composition 61
Composition in Roman Proposal [Berardi et. al. ’ 03] initiate on-line music store search initiate search cart search listen custcare buy jukebox Internal tree for store listen, juke search, care . . . External trees for cust-care, jukebox, bank buy . . . cart search, care cart, buy, care bank • If trees “regular”, can build composition (if exists) – Includes selecting delegates and constructing mediator • Using standard automata techniques: NEXPTIME • Using reduction to ALU DL: EXPTIME October 18, 2003 Behavioral Signatures and E-Service Composition bank initiate, care . . . search cart . . . listen search, care . . . External tree for store 62
Bridge to DLs… • Assuming peers and spec are regular, can – Determine if a composition exists – If one does, then construct mediator • Using standard automata techniques: NEXPTIME • Using reduction to a DL (ALU): EXPTIME October 18, 2003 Behavioral Signatures and E-Service Composition 63
- Slides: 63