E-Services: In Search of the Fundamentals*

1
E-ServicesIn Search of the Fundamentals

• Rick Hull Michael Benedikt
• Bell Labs Research
• Lucent Technologies
• hull,benedikt_at_lucent.com

Vassilis Christophides Foundation for
Research and Technology-Hellas (FORTH) christop_at_ic
s.forth.gr
Jianwen Su U. of California, Santa
Barbara su_at_cs.ucsb.edu
May 21, 2003
Based on a paper to appear in PODS 2003 see
http//db.bell-labs.com/project/e-composition
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

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

4
Key directions of this survey

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

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

6
WSDL Traditional I/O signatures

• Peer-to-peer e-service can act as client or
  server
• Reactive (as client) one-way
  send request
• 
  request-response send request, block till
  response
• Proactive (as server) notification
  receive request
• 
  solicit-response receive request, send
  response

bill_payment out bill in payment
Warehouse
Warehouse
order
order
bill
receipt
receipt
payment
(a) 2 one-way and 2 notification operations
(b) 1 one-way, 1 notification, and 1
request-response operation

• Port mechanism to cluster operations
• Port as unit of interoperation between services
• E.g., orderreceipt as one port, billpayment as
  another

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
• NarayananMcIlraith 02 With DAML-S and
  Petri-net model as glue, intractable except for
  very restricted subsets of DAML-S

8
Signatures with behavior (2)

• What is an appropriate abstraction of behavior,
  to allow more tractable reasoning?
• Automata-based is appealing, but Turing machine
  would be too rich
• A useful abstraction focus on message classes
  and finite state automata
• Follows spirit of process algebras, communicating
  processes

(a) cautious warehouse (dont send
receipt until payment is received)
(b) trusting warehouse (bill-payment and
send receipt are interleaved)

• 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

9
Automata and Verification

• Automata model permits verification, e.g., with
  propositional LTL

order
order
!b
bill
bill
!r
?p
?o
?o
!b
?p
!r
!r
!b
!r
payment
?p
receipt
payment
receipt
(b) trusting warehouse
(a) cautious warehouse

• 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 fsas and propositional LTL is
  linear time in state space

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

11
E-services with data

• Store e-service with 2 primary activities
• Customer_care receives buy requests, and
  enables take
• Inventory_replenishment
• Set up line of credit with bank using
  authorize, ok
• Place orders against Warehouse1 and Warehouse2
  when stock is low
• Store_database used as shared data store

buy
?y
!t
take
customer_care
store_inventory
part
qty
. . .
store_database
?r1
?r2
order1
!o1
!o2
authorize
receipt1
!a
?k
ok
order2
!o1
!o2
inventory_ replenishment
receipt2
?r1
?r2
Store e-service
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

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

14
Composition peer-2-peer
authorize
buy
store
bank
ok
take
payment1
receipt2
payment2
receipt1
order2
order1
bill2
bill1
ware- house2
ware- house1

• As shown, this is an open system
• There are operations invoked by the external
  environment
• The external environment may be advesarial

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

• 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

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

17
Mediated Approach

• Mediator controls the processing of composition,
  message exchanges, data exchanges
• BPEL4WS, BPML are essentially languages to
  program mediators

18
Example Mediator (based on BPEL4WS)
receive authorize from Store send authorize
to Bank receive ok from Bank send ok to
Store
begin parallel
do until flag
Receive Bill1 from Warehouse1
send Order to Warehouse1
pick first true
send Bill to Bank
end_date has been reached
receive order from Store
receive Receipt1 from Warehouse1
case warehouse
flag true
receive Payment from Bank
Warehouse1
Warehouse2
send Receipt to Store
module for processing Warehouse2 order
module for processing Warehouse1 order
send Payment1 to Warehouse1
end parallel
end case
(b) Module for processing Warehouse1 order
(a) Main body

• Flowcharts with parallelism
• Pick construct to enable waiting for input (or
  time out)
• Synchronization within parallel threads

19
Mediator Languages Discussion

• Several standards have emerged, including
• WSFL close to IBMs MQ Series Workflow
• Acyclic graph with limited loops
• XLANG close to MSs 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

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

At present, services must be re-compiled for
each calibration, but we expect will be
parameters in the future
21
Telecom and Converged servicesImportance of
Asynchronous Events
Services
. . .
Sessions
. . .
10 AM
11 AM
Participants
Rick
Akhil
Ming
Geliang
Vassilis
Gregory
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 fsas 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

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

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

25
Analysis for I/O Signatures

• Case 1 signatures between peers must match
  exactly
• Trivial to verify

• Case 2 source signature is XML subtype of target
  signatures
• This is suggested in, e.g., BPEL4WS
• For XML Schema types, deciding subtype is
  intractable Siedl 90, SimeonKuper 01
• Conservative tests are feasible, e.g.,
  PierceHosoya 01, XQuery

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

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

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

28
Conversation Model Bultan et.al. WWW03

• 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

29
Language of Peer Implementation Example
(a) trusting warehouse1

• 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

30
Unbounded Queues ? Unexpected Behaviors
?o
?a
!a
!a
!o
!b
?b
!o
(d) Store
(a) Store
(b) Warehouse
(c) Bank

• These are abstract versions of previous
  e-services
• But, no handshakes for messages
• Language of (a), (b), and (c)
• L w w in a(o,b), number of os and bs is
  same, and for each prefix
  v of w, number of os ? number of
  bs
• L ? aob 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. WWW03
• More specifically, each such language is accepted
  by a quasi-realtime automaton with 3 queues

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

32
Synthesis approach

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

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 PnueliRosner90
• Decidable for hierarchical topology, but
  non-elementary even for linear case
  KupfermanVardi 01
• Because of high complexity, perhaps most useful
  in context of synthesizing composition skeletons
  and test harnesses

34
Using Petri Net Reachability NarayananMcIlraith
02

• Based on representation of DAML-S process control
  constructs in Petri Nets
• Captures completion assumptions stating that
  all axioms needed to characterize when a fluent
  can change are explicitly available
• Assumes that all underlying domains are finite
• Approach
• For set of atomic e-services, create Petri Net
  based on DAML-S constructs, that represents all
  possible combinations of the atomic e-services
• Specify desired goal as a state of this Petri Net
  (i.e., in what places tokens should lie)
• Determine if this goal state is reachable
• In Petri net model of NarayananMcIlraith 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

35
Realizing Languages in Unbounded, Closed Case

• Approach
• Start with ec-schema S (M,P,C)
• Specify global language L to be generated
• Build peers that generate this language
• Challenge All languages generated by a peer
  implementation are closed under 2 key properties
• Join if w is generated, then any shuffling of
  the words ??p(w) corresponding to the individual
  peers p can also be generated
• Prepone interchange order of input and output
  messages of a peer p under certain conditions
• A language L over M is realizable if there is
  some peer implementation of S that generates L
• Two results Bultan et.al. WWW03
• 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

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

37
Checking properties of BPEL4WS compositions

• Many different kinds of constraints arise in
  BPEL4WS spec
• Referential e.g., service links should refer to
  peers in composition
• Cardinality e.g., for each synchronization link
  there should be one
  source and one target
• Structural e.g., internal synchronization links
  should not cross while
  scopes
• Value-based e.g., for every request-response
  operation foo, if a
  request foo occurs in a process, then a
  matching reply foo
  should occur on subsequent paths
• XPath output e.g., that output of a given Xpath
  query on an internal
  variable is subtype of a target output variable
• For (a) referential constraints in XML Schema
  suffice
• For (b), (c), (d) not in XML Schema, but studied
  elsewhere, e.g., DeutschTannen 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

38
Simplifying constraint generation

• For a given glue language (e.g., BPEL4WS), each
  well-formed mediator (with associated service
  linkages) will satisfy a set of constraints
• Can we generate those constraints automatically ?

XML Schema (with ???)
(Workflow Model)
Glue language
Mediator Specification
XML Instance (with constraints)
(Workflow Schema)

• Possible approach develop notion of constraint
  template (i.e., fill in the ???)
• Use those to generate the concrete constraints

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

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

41
Challenge Questions

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

42
Backup Slides
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

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
• AtzeniTorlone 96 a meta-model for unifying
  variations on ER model
• Can create each ER model from constructs of
  meta-model
• A mapping between models can extend to map
  schema-instance pair from one model to
  schema-instance pair of the other
• Situation for e-services glue languages (a.k.a.
  process models)

XML Schema (with constraints)
Process Model
Process Schema
XML Instance
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

• Verification in DAML-S NarayananMcIlraith 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

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. WWW03
• 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

47
Using Petri Net Reachability NarayananMcIlraith
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 NarayananMcIlraith 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

48
Drill down definitions of join and prepone

• Let ec-schema S (M,P,C)
• Key properties of languages generated by peer
  implementations
• Closed under join For peer p, let
• ?p be set of messages in or out of p, ??p(w) be
  projection of w onto letters in ?p
• The join of w is v for each p, ??p(v)
  ??p(w)
• Intuitively, any shuffling of the words ??p(w)
  can be generated
• Closed under prepone

wm1m2w is in L, m1 is an output message of p to
some q m2 is an input message to p from some q ?
q
? wm2m1w is in the prepone of L

• Intuitively, p can delay producing m1 until after
  m2 is produced