EService Composition and Behavioral Signatures

1
E-Service Compositionand Behavioral Signatures

• Rick Hull
• Bell Labs Research

October 18, 2003 slides will be available at
http//db.bell-labs.com/user/hull
Based in part on the PODS 2003 talk entitled
E-Services A Look Behind the Curtain,
co-authored with
Michael Benedikt (Bell Labs) Vassilis
Christophides (FORTH, Greece) Jianwen Su (UC
Santa Barbara)
2
The E-Services Paradigm

• Goal Simplify and/or automate e-service
• Discovery
• Composition
• Orchestration (invoke, monitor choreography)
• Provenance (e-science, recovery)
• Primary roots of e-services paradigm
• (a) Process description formalisms
• (b) Distributed computing middleware
• (c) Data management
• What makes e-services new
• Much more de-centralized than workflow
• More flexible, less structured than CORBA
• Data management has larger role in (a) and (b)
• Importance of standards to enable interoperation
  and analysis

3
Outline

• Events, messaging, and sequential behavior are
  facts of life
• We need a notion of behavioral signature
• An automata-based framework
• Inspired by CSPs, ?-calculus, verification theory
• Analysis tools
• Several approaches available
• Automated composition
• Including a bridge to DLs
• Conclusions

4
Web Services Definition Language (WSDL)
Messages and (traditional) I/O signatures

• Peer-to-peer e-service can act as client or
  server
• Proactive send request
• send request, block till
  response
• Reactive receive request
• receive request, send response

bill_payment out bill in payment
order
order
bill
Supplier
Supplier
receipt
payment
receipt

• Port mechanism to cluster operations
• Port as unit of interoperation between services

5
E-Commerce Patterns of Messages
buy
bank
store
get
supplier1

• Certain patterns acceptable, others not
• Enactments with different life-cycles
• E.g., one credit authorize for many orders

6
Using order toinfer IOPA properties
order
bill
Supplier
receipt
payment

• Conditions on input/output
• if valid client sends order, then bill is created
• if payment is received, then receipt is sent
• Conditions on state of world
• Amount of in line of credit
• Supplier ships order when payment is received
• Performing inference (everything else fixed)
• Assume the Bank satisfies if bill received and
  sufficient funds, then payment is sent
• Infer that an order from a valid client with
  sufficient funds will result in a receipt and
  shipment of the order

7
Services use events

• Full plane reservation service includes alerts
  if plane is delayed
• To person flying
• To car rental service, to hotel service,
• Services may have to retain context over a period
  of time
• Will be waiting for incoming event
• Put it into proper context
• Take appropriate actions
• BPEL4WS has explicit constructs for asynchronous
  events
• receive, wait, pick

8
Telecom/Collaborative Services
Profile Data
Session Coordinator
Pre-Pay
Presence Server
Media Server (voice)
Media Server (video)

• Emerging standards will enable flexible, dynamic
  invocation of services incorporation of
  features
• Can be viewed as a special case of web services
• Bearer traffic vs. signaling/control traffic
• Asynchronous events call dropped, person becomes
  present,
• Feature interactions call screening, call
  waiting,

9
Outline

• Sequential behavior and messaging are a fact of
  life
• We need a notion of behavioral signature
• An automata-based framework
• Uses a black-box perspective
• Contrast to white-box formalisms
• Some tools are available
• Including a bridge to DLs
• Conclusions

10
Two perspectives on E-Services

• Black box Signature languages
• Web Services Description Language (WSDL)
• Focus on input/output signatures only
• Pre-/post conditions á la OIL-S
• Behavioral
• Focus on sequencing of messages transmitted
• W3C Choreography group working here
• Focus on sequencing of actions performed
• White box Implementation languages
• Essence of WSFL, XLANG, BPEL4WS, BPML, etc.
  standards
• OIL-S process constructs
• Typically, parallel flowcharts with
  synchronization, scopes, some event handling,
  internal variables

BPEL4WS also supports a black box view of
e-services
11
Modeling I Individual E-services

• In the most general case, an e-service can be a
  Turing machine

inputmessages
to othere-services
message log
local store

• For analysis, optimization, and automation it is
  useful to study more restricted models

12
Behavioral signatures using messages

• Use Mealy Peers Finite State Automata with
  input/output
• Follows spirit of process algebras, communicating
  processes

order
order
bill
bill
!b
!r
?p
?o
!b
?p
!r
?o
!r
!b
!r
?p
pymnt
rcpt
pymnt
rcpt
(a) cautious supplier
(b) trusting supplier

• Can model single or sequenced enactments
• Advantages for analysis, e.g., verifying temporal
  properties, characterizing global behavior

13
Modeling II A composition framework

• A peer autonomous process executing an e-service
• Assume reliable communication

14
E-Composition Schema

• An E-C schema is a triple (P, C, M)
• Specifies the infrastructure of composition

• Many variations on this base model possible,
  e.g.,
• Different levels of granularities
• Assume finite domains ? can model parameters
  explicitly

15
Combining Peer and Composition Models
store
bank
. . .
. . .
supplier2
supplier1
. . .
. . .

• Peer fsas begin in their start states

16
Executing a Mealy Composition (cont.)
store
bank
a
. . .
. . .
supplier2
supplier1
. . .
. . .

• STORE produces letter a and sends to BANK

17
Executing a Mealy Composition (cont.)
store
bank
. . .
. . .
supplier2
supplier1
. . .
. . .

• BANK consumes letter a
• Execution successful if all queues are empty and
  fsas in final state

18
State and Conversation
store
bank
b2
b1
. . .
r2
. . .
supplier2
supplier1
. . .
. . .
r2
o2
o2
o1

• The state of the composition is based on
• state of each peer
• contents of the queues
• Conversation one enactment of global process
• Can have sub-conversations of a conversation
• Little known about formal properties of
  conversations

19
Important Choices for Message-based
Composition Model

• Representation formalism for peer implementations
• Expressive power of peer implementations
• Bounded vs unbounded queues
• Several queues vs one queue vs heap vs
• Open vs closed
• Restricted topologies/control peer-to-peer,
  hub-and-spoke, hierarchical,
• Show full language or subset

20
Composition Infrastructure

• Peer-to-peer (distributed control)

• BPEL4WS, BPML, GSFL useful to define mediators
• Composition of compositions ?? hierarchy . . .

21
BPEL4WS Example white-box language
begin parallel
Initialize
Receive Bill1
do until flag
send Order
end_date reached
pick
receive order
Send Bill
receive Receipt1
flag true
case
Receive Payment
send Receipt
suppl2 order
suppl1 order
Send Payment1
end case
end parallel

• Flowcharts with parallelism
• Pick construct to enable waiting for input (or
  time out)
• Synchronization within parallel threads
• Comparison of supported constructs see van der
  Aalst 03

22
OIL-S Process Model

• Process class
• Atomic, composite (mediator), or simple (virtual)
• Inputs, outputs, effects
• Pre-conditions, post-conditions
• Constructs for composite processes
• Sequence
• Concurrency Split SplitJoin Unordered
• Choice
• If-Then-Else
• Looping Repeat-Until Iterate (non-deterministic)
  
• Data Flow
• No explicit variables, no internal data store, no
  wait
• Predicate sameValues to match input of
  composite service and input of subordinate
  service
• Less refined than, e.g., BPEL4WS

23
Outline

• Events, messages, and sequential behavior are
  facts of life
• An automata-based framework
• Analysis tools
• Petri nets
• Tools using temporal logics
• Bounded vs. unbounded queues
• Automatic composition
• Conclusions

24
Verifying Properties of DAML-S Processes via
Petri nets NarayananMcIlraith 02

• Specify a DAML-S semantics using a situation
  calculus
• Includes Knows, Kwhether, Kref for condition
  testing
• Captures completion assumptions essentially
  prevents world from changing without e-service
  knowing about it
• Operational semantics via Petri nets
• Assume finite domains
• Map to 1-safe Petri nets, which corresponds to
  bounded queue case
• Verify properties such as reachability,
  termination
• Complexity depends on constructs and model
• Range from PTIME to EXPSPACE-hard

25
Verifying Temporal Properties of Mealy
Compositions
store
bank
. . .
. . .
warehouse2
warehouse1
!b2
. . .
?r2
. . .

• Label states with propositions
• Level of indirection between states and
  observables
• Express temporal formulas, e.g.,
• shipment just made only after line-of-credit
  avail

26
Results on Temporal Verification

• Long history, e.g., Clarke et.al. 00
• E.g., verification for fsas and propositional
  LTL
• Complexity PSPACE in size of formula fsa
• linear time in size of fsa
• Application to Mealy compositions
• Results apply to open and closed case
• Bounded queues
• Composition can be simulated as Mealy machine
• Verification is decidable
• Standard techniques to reduce cost
• Unbounded queues
• In general, undecidable
• Approximation techniques can be applied

27
Qualitative Analysis of Unbounded Queue
Compositions

• Conversation Languages Bultan et.al.
  WWW03
• Assume a watcher that observes all messages
  sent
• In contrast to previous approach, the
  observables here are simply the messages sent
• Language of peer implementation is set of words
  formed by successful executions of the
  implementation

Watcher
28
Example Conversation Language
store
bank
!o1
?k
!a
. . .
. . .
!o2
supplier2
supplier1
. . .
. . .

• Language ak SH( (o1 r1 b1 p1), (o2
  SH(r2,b2p2)) )
• First ak, then a shuffle of orders against
  Supplier1 and orders against Supplier2
• Supplier1 is cautious and Supplier2 is
  trusting
• This language is regular
• Same language for bounded or unbounded queues

29
Unbounded Queues ? Unexpected Behaviors
(c) Bank
(a) Store
(b) Supplier

• Abstract versions of previous e-services
• But, no handshakes for messages
• Conversation language L
• L ? aob aonbn n ? 0 , i.e., L is not
  regular
• Take aways
• Bottom up design of compositions may lead to
  undesirable global behaviors
• Service mediators can have important role in
  preventing undesirable behaviors

30
How bad is it ?

• In general, conversation language with Mealy
  peers and unbounded queues is context-sensitive
• Accepted by a quasi-realtime automaton with 3
  queues
• All conversation languages are closed under two
  key properties
• Join if w is generated, then certain shuffle
  products of w are also generated
• Prepone interchange order of input and output
  messages of a peer p under certain conditions
• For hierarchical ec-schemas

Conversation language is join-prepone closure of
a regular language
?
Each peer is a Mealy implementation
31
Outline

• Events, messaging, and sequential behavior are
  facts of life
• An automata-based framework
• Analysis tools
• Automatic composition
• Hierarchical composition
• Results from DAML-S community
• Results using Mealy machines
• A bridge to DLs
• Conclusions

32
Hierarchical Composition

• A pragmatic approach to automating e-service
  composition

Customized Travel Service
Travel Service Templates
Air Travel Templates
Airport Transfer
Hotel Reservation
33
Hierarchical Composition (cont.)

• Approach
• Assume a library of e-service templates and
  ground specs
• Based on input criteria select a root template,
  then fill in gaps with other templates and/or
  ground specs
• Christophides et.al. 01 does this for
  structured workflows
• Take-away Hierarchical structuring is important
  for e-service formalisms
• Need to incorporate this into OWL-S, Mealy model

34
Automatic Composition for DAML-S

• NarayananMcIlraith 02 Search over all
  combinations
• Recall simulation of DAML-S via 1-safe Petri nets
• For set of atomic e-services, create Petri Net
  that represents all possible combinations of them
• Specify desired goal as a state of this Petri Net
• Determine if this goal state is reachable
• In this framework reachability is PSPACE-
  complete in size of Petri net
• Petri net itself may be exponential in size of
  atomic e-services
• Heuristics can be used to avoid full construction
• McIlraithSon 02 Generic compositions
  customization
• develops mapping of DAML-S into ConGolog, and
  uses to create compositions
• Approach based on 2-level hierarchy

35
Composition for Mealy Peers

• Traditional synthesis problem statement
• Given ec-schema and LTL formula ?
• Create an fsa for each peer so that ? is
  satisfied
• Synthesis results for Mealy implementations with
  bounded queues
• Closed compositions folklore results imply that
  synthesis is decidable
• Propositional LTL description ? PSPACE
• ?-regular set represented as automaton ? PTIME
• Open compositions Undecidable for LTL for
  arbitrary ec-schemas PnueliRosner 90
• Decidable for hierarchical topology, but
  non-elementary even for linear case
  KupfermanVardi 01

36
Reformulation of the Synthesis Problem to use
extended UDDI Repository

• UDDI Repository globally accessible store for
  web service descriptions and locations
• Imagine that it supports Mealy descriptions
• Possible approach
• Given ec-schema, LTL formula ?, UDDI
  repository
• Find peers in repository so that ? is satisfied
• Variation allow creation of a mediator to
  choreograph the selected peers
• Database aspect of this problem
• How to search across large space of Mealy
  descriptions?
• What is appropriate query language?

37
Synthesis for Unbounded, Closed CaseBultan et.
al. 03

• Use conversation language to express global
  behavior
• Problem statement
• Given ec-schema and regular language L over
  messages
• Create an fsa for each peer so that composition
  generates L join-prepone closure
  of L
• Result Mealy peers can be constructed whose
  composition gives global behavior L
• Do a projection on fsa accepting L
• Can again ask UDDI version of synthesis question

38
Recent work from Lenzerinis group (DL 03)

• Based on a different model for peers
• Focus on sequences of actions, not messages
• Includes a user who repeatedly makes choice
  (from limited set) about next action she wants
• All actions visible at top level

• Actions that client can ask for
• initiate, end
• search
• listen
• cart
• buy

Client
on-line music store
Service

• Abstract behavior of the Service
• Do until Client selects End
• Give Client a choice of actions to be performed
• Wait for Client choice
• Perform action chosen by Client

39
Solve composition by synthesizing mediator

• Assuming peers and spec are regular, can
• Determine if a composition exists
• If one does, then select peers and construct
  mediator

Desired behavior (as FSA)
Mediator (constructed)
?
Services (selected from UDDI)
Extended UDDI

• Using standard automata techniques NEXPTIME
• Using reduction to ALU DL EXPTIME

40
Conclusions

• Sequential behavior and messaging are a fact of
  life
• We need a notion of behavioral signature
• Automata-based perspective
• Provides formal framework that incorporates
  events and sequencing
• Can draw on broad theory of analysis tools
• Offers a framework for automated composition
• Can represent (at least some) in DLs link to
  OWL?
• Automata-based perspective should be exploited in
  semantic web services
• Results suggest key challenges in composition
• Select peers queries over sets of peers
• Mediator crucial find/build the mediator

41
We are just getting started

• Enhanced Mealy can we incorporate
• Messages actions
• Pre-/post-conditions á la OWL-S
• Hierarchical structure for messages (state
  charts?)
• Temporal constraints
• (your favorite) PSL constructs
• Composition of Mealy machines
• Can we adapt the Roman approach ?
• Augment traditional planning with approach for
  cyclic behaviors
• Mealy vis-à-vis BPEL4WS, OWL-S process model,
  PSL, FIPA A-UML,
• Jianwen Su et. al. developing tool for
  translating between Mealy and BPEL4WS
• Searching a large set of Mealy signatures
• What is appropriate query language?
• Finding relevant results from various
  communities verification, ?-calculus, planning,
  DL, DB, agent,

42
Backup Slides
43
E-Services

• The Web Flexible human-machine interaction
• E-services Flexible machine-machine interaction
• Working Definition Network-resident software
  services accessible via standardized protocols
• Simple Object Access Protocol (SOAP) very
  flexible remote procedure call
• Lots of interest in trade press, academic
  community, standards bodies, . . .
• Applications in e-commerce, telecom, science,
  GRID, government, education, . . .

44
E-Science
Controller
control and calibrations
Sea Circu- lation
Atmo- spheric Simu- lation
Waste Transport
notifications and/or experimental data

• E.g., find best location for waste treatment
  plant
• Possibly 100s of nodes, and running for weeks
• Data size difference
• Control and calibrations (small)
• Experimental data (large)
• Provenance need to access derivation history

45
Web Services Protocol Stack
Web service composition WSFL, XLANG, BPEL4WS,
BPML, W3C Choreography
Publishing and discovery UDDI
Service Description Layer WSDL, WSCL, WSCI
XML messaging layer SOAP
Transport layer HTTP, SMTP, FTP, etc.
Based on van der Aalst 03
46
Pre-/post-conditions
order
bill
Supplier

• DAML-S provides for
  pre- and post-conditions
• Examples
• if valid client sends Order, then Bill is created
• if Payment is received, then Receipt is sent
• Performing inference (everything else fixed)
• Assume a Bank service such that if bill received
  and sufficient funds, then payment is sent
• Then we can infer that an order from a valid
  client with a sufficient account balance will
  result in a receipt
• Reasoning with pre- and post-conditions
• Different models will lead to different
  complexity
• NarayananMcIlraith 02 axiomatization in
  situation calculus for a Petri-net based model
• Complexity from PTIME to EXPSPACE-hard

receipt
payment
47
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

48
Technical Definition

• A Mealy peer is an FSA M (T, s, F, ?in, ?out,
  ? )
• T a set of states
• s the initial state
• F a set of final states
• ?in input message classes
• ?out output message classes
• ? transition relation that either
• consume an input, (s1, ?m, s2), or
• produce output, (s1, !m, s2), or
• make an empty (internal ) move, (s1, e, s2)

49
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

50
Data Transducers as White-Box Peers

• Add database to fsa (XML, relational)
• Store e-service with
• Customer_care
• Inventory_replenishment
• Store_database used as shared data store
• Cf., XL Florescu et.al.03
• Process XQuery
• Cf., Relational Transducer Abiteboul et. al.
  00
• Analysis undecidable NEXPTIME for restrictions

buy
?y
!t
take
customer_care
store_inventory
part
qty
. . .
store_database
order1
?r1
?r2
!o1
!o2
authorize
receipt1
?k
!a
order2
ok
!o1
!o2
inventory_ replenishment
?r1
receipt2
?r2
51
Parting Challenge Process Data
store
bank
warehouse2
warehouse1

• E.g., Relational Mealy Machines (or XML, . . .
  )
• Cf. Relational Transducers of Abiteboul et. al.
  00
• Focus on restricted query/update languages
• Extend results previously obtained to include
  variables, context, large data

52
E-service Glue Languages and Workflow
Management

• Computerised facilitation or automation of a
  business process, in whole or part WfMC
• Centralized control
• State of conversation maintained by WF manager

• Delegation of almost everything to the app.s
• E.g., application data is not accessible to WF
  manager
• Workflow standardization has mixed success
• Web services must interoperate ? standard likely
• Should focus on interfaces, not internals

53
ActiveXML A data-centric white-box language
Abiteboul et.al. 03

• A novel combination of data and web services
• Three ways to treat remote data
• Remote data is virtual, and materialized when
  queried
• Pass data pointer as part of query response

• Materialize remote data periodically
• Alternative to control-flow based languages
• Outer process flow dictated by XML query
  language (and structure of data)
• Remote procedure calls embedded into XML
  structure

54
White-box Analysis via XML

• Many different kinds of constraints arise in
  BPEL4WS spec
• Referential service links refer to peers in
  composition
• Cardinality for synchronization links, 1 source
  and 1 target
• Structural internal synchronization links dont
  cross while scopes
• Value-based requests matched by responses
• XPath query on variable is subtype of a target
  variable
• For (a) XML Schema suffices
• For (b) - (d) see DeutschTannen 01, Benedikt
  et.al. 02
• For (e) Involves a combination of XPath and
  control flow analysis
• If XL used, then everything is XQuery, and so
  XQuery type-checker can assist with type
  correctness

55
AZTEC A white-box language for sessions and
asynchronous events Christophides et. al. 01

• Control is hub-and-spoke
• Maintains state of sessions
• Richer than web-service notion of conversation
• Queue for incoming asynchronous events

• Launches instance of event-handling flowchart for
  each external event
• Synchronization between flowcharts
• Priority
• Via shared data
• Can interrupt other flowcharts (e.g., if prepay
  account runs out of money)

56
Agent UML

• E.g., Odell, Bauer, et. al. slide deck, 2000
• An exploration of different ways that UML can be
  used to capture agent interactions
• Message types based on KQML request, assert,
  refuse,
• Subset of messages relevant to e-commerce,
  alerting services, long-running activities,
  supply chain life-cycle, manufacturing
  life-cycle, collaborative technologies, pervasive
  computing,

Winograd-Flores perspective (classical)
57
A-UML focus on modeling

• Diff. levels Global, interaction, internal
• Focus not on analysis or automated composition

Activity Diagram (with Swim Lanes and Object
Flow)
Packages (with nesting) for global aspects
Collaboration Diagram
Nesting (mix match)
Sequence Chart
58
A Roman approach to composition that bridges to
DLs Berardi et al 03

• Based on an action-based model
• E-commerce example, with focus on actions

bank
store
sell_goods
supplier1
supplier2

• Higher level of abstraction than messages
• Enactments still have different life-cycles

59
Focus on one Client, one Server

• Drill down on customer buying CDs
• Examine sub-actions inside sell_goods

Online Music Store
Back- end
Front- end

• Abstract behavior of the Service
• Do until Client selects End
• Give Client a choice of actions to be performed
• Wait for Client choice
• Perform action chosen by Client

Client
on-line music store
Service
60
Execution Tree in Roman model

• (External) execution tree all possible sequences
  of actions supported by service

Action supported by service
initiate
Client
search
State at which client can stop
cart
listen
on-line music store
Service
State at which client can not stop
search
search
cart
buy
. . .
. . .
. . .

• Children labeled by distinct actions
• Tree is equivalent to a language over actions
• Typically, focus on regular languages

61
Composition in Roman Model (sketch)

• Internal execution tree holds actions by server
  and delegates of that server

Client
on-line music store
Service
cust. care
jukebox
Service delegates
bank

• All actions are visible to client none
  internal

62
Composition in Roman Proposal Berardi et.al.03
External tree for store
on-line music store
cust- care
bank
jukebox
?
Internal tree for store
External trees for cust-care, jukebox, bank

• If trees regular, can build composition (if
  exists)
• Includes selecting delegates and constructing
  mediator
• Using standard automata techniques NEXPTIME
• Using reduction to ALU DL EXPTIME

63
Bridge to DLs

• Assuming peers and spec are regular, can
• Determine if a composition exists
• If one does, then construct mediator
• Using standard automata techniques NEXPTIME
• Using reduction to a DL (ALU) EXPTIME