e-services: in search of the fundamentals *
DESCRIPTION
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 [email protected]. Vassilis Christophides Foundation for Research and Technology-Hellas (FORTH) - PowerPoint PPT PresentationTRANSCRIPT
May 21, 2003 Fundamentals of E-Services 1
E-Services:In Search of the Fundamentals*
Rick Hull Michael BenediktBell Labs Research
Lucent Technologies{hull,benedikt}@lucent.com
May 21, 2003
Vassilis Christophides
Foundation for Researchand Technology-Hellas
(FORTH)[email protected]
Jianwen SuU. of California, Santa Barbara
*Based on a paper to appear in PODS 2003; see http://db.bell-labs.com/project/e-composition
May 21, 2003 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
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 4
Key directions of this survey1.How to describe e-services?
– Various foci: I/O signature, automata-based, pre-/post-conditions
2.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
3.How to analyze composite e-services?– Tools for analysis of compositions; some old, some new
4.How to build composite e-services from atomic ones (part 2)?– Approaches to “synthesize” e-compositions from desired global properties
5.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,
…
May 21, 2003 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
May 21, 2003 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
Warehouse
order
receipt
bill
payment
Warehouse’
order
receipt
bill_payment out: bill in: 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
May 21, 2003 Fundamentals of E-Services 7
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
Warehouse
order
receipt
bill
payment
May 21, 2003 Fundamentals of E-Services 8
Signatures with behavior (2)
•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
?o
!r
!b
?p
?p
!r
!r
!border
receipt
bill
payment
order
receipt
bill
payment
!b ?p !r ?o
(a) “cautious” warehouse (don’t send receipt until payment is received)
(b) “trusting” warehouse (bill-payment and send receipt are interleaved)
•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
May 21, 2003 Fundamentals of E-Services 9
Automata and Verification
•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
?o
!r
!b
?p
?p
!r
!r
!border
receipt
bill
payment
order
receipt
bill
payment
!b ?p !r ?o
(a) “cautious” warehouse (b) “trusting” warehouse
•Automata model permits verification, e.g., with propositional LTL
May 21, 2003 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
May 21, 2003 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
!o 1
!o2
?r2?r 1
!o2
!o 1
?r 1?r
2
!a ?k
ok
authorize
take
buy
receipt1
order1
receipt2
order2
?y !t
inventory_replenishment
customer_care
store_inventorypart qty
. . .
store_database
Store e-service
May 21, 2003 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
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 14
Composition: peer-2-peer
•As shown, this is an open system– There are operations invoked by the external environment– The external environment may be advesarial
store
ware-house2
bank
ware-house1
order
1
ok
receipt1
order2
receipt2
bill 2
paym
ent 2
bill 1paym
ent 1
authorize
take
buy
•As a closed system, there are no operations from external environment– Analysis, synthesis generally easier for closed systems
2
1
34
56
May 21, 2003 Fundamentals of E-Services 15
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
Peer 1
Peer 2
Peer n
……
•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
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 17
Mediated Approach
•Mediator controls the processing of composition, message exchanges, data exchanges
•BPEL4WS, BPML are essentially languages to program mediators
bank
ware-house1
ware-house2
store
media-tor
ak’
ro
b2
p2
r2o2
r1
o1
b1p1
ka’
bp
May 21, 2003 Fundamentals of E-Services 18
Example Mediator (based on BPEL4WS)
•Flowcharts “with parallelism”
•“Pick” construct to enable waiting for input (or time out)
•Synchronization within parallel threads
receive authorize [from Store];send authorize’ [to Bank];receive ok [from Bank];send ok’ [to Store];
do until flag
pickfirsttrueend_date has
been reached
flag := true
receive order [from Store]
case:warehouse
Warehouse1 Warehouse2
module forprocessingWarehouse1order
module forprocessingWarehouse2order
end case
(a) Main body (b) Module for processing Warehouse1 order
beginparallel
send Order[to Warehouse1]
receive Receipt1[from Warehouse1]
send Receipt[to Store]
Receive Bill1[from Warehouse1]
send Bill[to Bank]
receive Payment[from Bank]
send Payment1[to Warehouse1]
endparallel
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 20
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
notifications and/orexperimental data
Atmo-sphericSimu-lation
SeaCircu-lation
WasteTransport
Broker
control and calibrations
*At present, services must be re-compiled for each calibration, but we expect will be parameters in the future
May 21, 2003 Fundamentals of E-Services 21
(Akhil, Ming, Gregory)
(Akhil, Gregory)
(not activelyparticipating)
(not present onany network)
1
Response to asynchronous event:
1) Vassilis becomes present
Telecom and Converged services:Importance of Asynchronous Events
Participants
AkhilGregoryMing
Services
Sessions
10 AM 11 AM
. . .
. . .
Geliang VassilisRick
Teleconference Session
Internet Text Chat Session
TelephonyService
InternetText ChatService
BillingService
PresenceService
TeleconferenceServiceBroker
2
2) Vassilis added to conference
May 21, 2003 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
May 21, 2003 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
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 25
Analysis for I/O Signatures
•Case 1: signatures between peers must match exactly
– Trivial to verify
Warehouse’
order
receipt
bill_payment out: bill in: payment
•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
May 21, 2003 Fundamentals of E-Services 26
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
Peer 1
Peer 2
Peer n
……
•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])
May 21, 2003 Fundamentals of E-Services 27
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
receive authorize [from Store];send authorize’ [to Bank];receive ok [from Bank];send ok’ [to Store];
do until flag
pickfirsttrue
end_date has been reached
flag := true
receive order [from Store]
case:warehouse
Warehouse1 Warehouse2
module forprocessingWarehouse1order
module forprocessingWarehouse2order
end case
May 21, 2003 Fundamentals of E-Services 28
“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
Peer 1
Peer 2
Peer n
……
May 21, 2003 Fundamentals of E-Services 29
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
!r 1
!b1
?p1
?p1
!r 1
!r 1
!b1order1
receipt1
bill1
payment1
?o1
; null
(a) “trusting” warehouse1
!o 1
!o2
?r2?r 1
!o2
!o 1
?r 1?r
2
!a ?k
ok
authorize
receipt1
order1
receipt2
order2
(b) (part of) Store
inventory_replenishment
?a !k
! p1
! p2
?b2?b 1
! p2
! p1
?b1?b
2
authorize
ok
bill1
payment1
(c) Bank
bill2
payment2
store
ware-house2
bank
ware-house1
order1
ok
receipt1
order2
receipt2
bill 2
paym
ent 2
bill 1paym
ent 1
authorize
May 21, 2003 Fundamentals of E-Services 30
!b
?o
?b
?a
!o
!a
!o
!a
(a) Store’ (d) Store’’(b) Warehouse’ (c) Bank’
Unbounded Queues Unexpected Behaviors
•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
May 21, 2003 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
May 21, 2003 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 approach1. Assume that e-services have behavioral descriptions (e.g., as
Mealy machines), and stored in the “UDDI repository”2. Problem instance: given desired global behavior (e.g., expressed
in LTL) and proposed ec-schema, synthesize behavioral signature needed for each peer
3. Look for peers with these signatures in UDDI repository4. Form composition, and check whether proposed peer
implementation satisfies additional properties (e.g., that aren’t captured by the LTL)
May 21, 2003 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
May 21, 2003 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
• Approach1.For set of atomic e-services, create Petri Net based on DAML-S
constructs, that represents all possible combinations of the atomic e-services
2.Specify desired goal as a state of this Petri Net (i.e., in what places tokens should lie)
3.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
May 21, 2003 Fundamentals of E-Services 35
Realizing Languages in Unbounded, Closed Case•Approach:
1. Start with ec-schema S = (M,P,C) 2. Specify global language L to be generated3. 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
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 37
Checking properties of BPEL4WS compositions
• Many different kinds of constraints arise in BPEL4WS speca) Referential: e.g., service links should refer to peers in compositionb) Cardinality: e.g., for each synchronization link there should be one
source and one targetc) Structural: e.g., internal synchronization links should not cross while
scopesd) 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
e) 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
May 21, 2003 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 ?
(Workflow Model)
(Workflow Schema)
XML Schema (with ???)
XML Instance (with
constraints)
•Possible approach: develop notion of “constraint template” (i.e., fill in the “???”)
•Use those to generate the concrete constraints
“Glue” language
MediatorSpecification
May 21, 2003 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
May 21, 2003 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
May 21, 2003 Fundamentals of E-Services 41
Challenge Questions1. 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)
2. 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?
3. 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
May 21, 2003 Fundamentals of E-Services 42
Backup Slides
May 21, 2003 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
May 21, 2003 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)
Process Model
Process Schema
XML Schema (with constraints)
XML Instance
May 21, 2003 Fundamentals of E-Services 45
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
Peer 1
Peer 2
Peer n
……
•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
May 21, 2003 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
May 21, 2003 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
May 21, 2003 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 qm2 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