E-Services: In Search of the Fundamentals *

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

[email protected]

*Based on a paper to appear in PODS 2003; see http://db.bell-labs.com/project/e-composition


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


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


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,

…


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


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


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


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


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


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


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


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


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





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


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


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


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


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


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


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


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


(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


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


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


Outline

•Intro


•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




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


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])


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



end case


“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

……


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


!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


Outline

•Intro




•Automated Composition of E-Services– Applying synthesis results from verification community– Using reachability in Petri Nets– A language-based approach



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)


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


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


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


Outline

•Intro





•Specifications as Data– Because everything is in XML, it is possible to use new tools


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


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


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


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


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


Backup Slides


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


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


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


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


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


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

Documents

E-Services: In Search of the Fundamentals *