Tools for Design of
Composite Web Services
-- Presented Version (June 17, 2004) --
http://www.cs.ucsb.edu/~su/tutorials/sigmod2004.html
Richard Hull (Bell Labs)
Jianwen Su (UC Santa Barbara)
Outline
Introduction and positioning
 Standards
 Models of Web Services and Composition
 Approaches to Automated Composition
 Analysis and Verification
 Future Directions

SIGMOD'04
June 17, 2004
2
Web Services
The Web: Flexible human-machine interaction
 Web 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, . . .
SIGMOD'04
June 17, 2004
3
Web Services: The Big Questions
Simplify and/or automate web service
 Discovery
 What properties should be described?
 How to efficiently query against them?
 Composition
 Specifying goals of a composition
 Specifying constraints on a composition
 Building a composition
 Analysis of compositions
 Invocation
 Keeping enactments separated
 Providing transactional guarantees
 Monitoring
 How to track enactments
 Recovering from failed enactments
SIGMOD'04
June 17, 2004
Primary focus
of this tutorial
4
Anatomy of Web Services Composition
Goal(s)
Activities
Discovery/
Self-description

Orchestration,
Monitoring
Info
sharing
(Messaging)
No unified model, e.g.,
 BPEL: Strong on orchestration, info sharing
 OWL-S: Strong on goals, activities, discovery
 “Roman” model: Strong on activities, orchestration
SIGMOD'04
June 17, 2004
5
Key dimensions in web service composition
“semantics”
OWL-S
Commitment
Protocols
CTR-S
WSCL
Roman
CSP
Mealy
BPEL
-Calc
BPML
WSDL
SIGMOD'04
June 17, 2004
6
Key Disciplines for Web Services Composition



Science of Design, e.g.,
 Workflow
 Service-oriented computing
 Reactive systems
 Process algebras
 Verification
AI, e.g.,
 Knowledge Representation
 Agents
 Planning
Database, e.g.,
 XML
 Domain-specific query languages
 Indexing
 Transaction Management
SIGMOD'04
June 17, 2004
7
Goals of this Tutorial: Tools for Composition
Describe the playing field
 Key standards that we’ll all build upon
 Promising models and formalisms
 Results on Composition
 OWL-S community
 Automata-theoretic approaches
 Results on Analysis and Verification
 Workflow community
 OWL-S community
 Automata-theoretic
 Future directions

SIGMOD'04
June 17, 2004
8
Outline
Introduction and positioning
 Standards
 Models of Web Services and Composition
 Approaches to Composition
 Analysis and Verification
 Future Directions

SIGMOD'04
June 17, 2004
9
Web Services Standards Stack: Key Elements
Discovery
Choreography
Composition
(Individual)
Service
Description
UDDI
WS-Choreorgaphy
BPEL4WS
OWL-S ServiceModel
WSCL
WSDL
OWL-S ServiceProfice
XML
Messaging
SOAP
Network
HTTP, SMTP, FTP, etc.
SIGMOD'04
June 17, 2004
10
Simple Object Access Protocol
A W3C standard
 Originally developed for BizTalk
 A light weight replacement for complicated distributed
object technology


“XML-RPC”, typically through HTTP, also JMS …
 Lowest level of service interaction
External
Service
SIGMOD'04
SOAP Envelope
June 17, 2004
Web
Server
Web
Service
11
RPC Messages

Typically two messages
SOAP
Client
SOAP Envelope
SOAP Header
SOAP Body
SIGMOD'04
Request Message
Response Message
SOAP
Server
“RPC style” SOAP body encodes
 the operation name and
parameters
 return result
XMLified
June 17, 2004
12
Web Service Definition Language (WSDL)

WSDL provides a framework for defining
 Interface: operations and input/output
 Access specification: SOAP bindings (e.g., RPC)
 Endpoint: the location of service
Port Type
Supports
Formats & Protocols
Binding
Operation
Input & Output
How to encode
Message
Provides
Service
Implements
Port
[from Leymann BTW 2003 talk]
SIGMOD'04
June 17, 2004
15
WSDL Operations
 Traditional
I/O signatures (using XML Schema)
 Four operation types
 Proactive : send request
send request, block till response
 Reactive : receive request
receive request, send response
order
bill
order
Supplier’
Supplier
receipt
payment
bill_payment
out: bill
in: payment
receipt
 Port:
mechanism to cluster operations
 Port as unit of interoperation between services
SIGMOD'04
June 17, 2004
17
Business Process Execution Language (BPEL)
Allow specification of compositions of Web services
 business processes as coordinated interactions of
Web services
 Allow abstract and executable processes
 Influences from
 Traditional flow models
 Structured programming
 Successor of WSFL and XLANG
 Assumes WSDL ports


Standardization through OASIS
SIGMOD'04
June 17, 2004
21
BPEL in Action
Purchase Order service coordinates other services
using ports in WSDL
Purchase
Order
portType
Receive
Purchase
Order
Price
Calculation
portType
operations
Initiate
Price
Calculation
Complete
Price
Calculation
Decide
On
Shipper
Arrange
Logistics
Initiate
Production
Scheduling
Complete
Production
Scheduling
Invoice
Processing
[from BPEL 1.1 standard]
SIGMOD'04
June 17, 2004
22
BPEL Activities






Invokes an operation on a partner service
 Send to WSDL port, wait for a response
Receives invocation from a partner
 Wait for a message
Sends a reply message in partner invocation
 Send a message (corresponding to some earlier
message)
Data assignment between containers
 Copy local data
Control structures: sequence, flow (possibly with links),
pick, loops, etc.
Scoping, exceptions, compensation
SIGMOD'04
June 17, 2004
23
BPEL Examples
begin
parallel
Initialize
do until flag
end_date
reached
flag
:= true
pick
Receive
Bill1
send
Order
receive order
receive
Receipt1
case
suppl2
order
Send
Bill
suppl1
order
end case
Receive
Payment
send
Receipt
Send
Payment1
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]

SIGMOD'04
June 17, 2004
24
Web Service Conversation Language (WSCL)
A key to web service composition:
 Interactions between services
 WSCL specifies a conversation (behavior signature) as
a labeled graph:
 Nodes: interactions, individual units of responses
 Edges: transitions, sequencing of interactions
 Edge labels: conditions on transitions

Purchase
?PurchaseOrder
InvalidPayment
!POAccepted
POAccepted
!OutOfStock
SIGMOD'04
June 17, 2004
Shipping
!ShippingInfo
27
WS Choreography
An emerging standard from W3C
 Drawing inspiration from the -calculus
 Global view of composite service interactions
 Global model: interactions and choreography
 Choreography Definition Language (WS-CDL)
 Key technical elements
 Participants and roles: what services are involved
 Channels: where and how the messages are sent
 Interactions: message exchange patterns
 Activities and control structures: sequencing
 Choreography: a global description of a composition



SIGMOD'04
Interactions, exceptions, finalizer
composable
June 17, 2004
29
BPEL
meets
WS-Choreography
A scripted composition
using
 WSDL messages
 Control structures with
constrained parallelism
 More procedural
 Executable or abstract


Favor centralized
composition
SIGMOD'04

A global description of
what and how WDSL
messages are exchanged
Declarative flavor
 Abstract and not
executable (yet)
 Composition
infrastructure neutral
 Channels can be passed
around (e.g. -calculus)

June 17, 2004
31
OWL-S (Formerly DAML-S)
An emerging standard to add semantics:
 An upper ontology for describing properties &
capabilities of web services using OWL
 Enable automation: service discovery & selection,
invocation, composition & interoperation, execution
monitoring

Service
Profile
Resource
Service
Service
Grounding
input types
output types
preconditions
effects
Service
Model
 communication protocol (RPC,
HTTP, …)
 port number
 marshalling/serialization
SIGMOD'04




 process flow
 composition hierarchy
 process definitions
June 17, 2004
32
OWL-S Service Profiles
presents
(what it does)
Service
Profile




Input types
Output types
Preconditions
Effects
Service

Service profile defines what the service provides:



Functional descriptions: In/Output, Preconditions, Effects
Non functional descriptions: name, category, QoS, …
Can use situation calculi (e.g. PSL) as formal basis for
pre-conditions, effects:

Assume a world of “fluents” – typically a set of propositions,
where actions make some true, some false
Reasoning with pre-conditions and effects
 Service profiles are hierarchically organized (example
later)

SIGMOD'04
June 17, 2004
33
OWL-S Service Model
SIGMOD'04
June 17, 2004
37
OWL-S Process Model
 Constructs
for composite processes
 Sequence
 Concurrency:
Split; Split+Join; Unordered
 Choice
Service
describedby
(how it works)
Service
Model
 process flow
 composition hierarchy
 process definitions
 If-Then-Else
 Looping:
Repeat-Until; Iterate (non-deterministic)
 Note: In spirit of Golog, these can be viewed as constraints
 Data
Flow
 No
explicit variables, no internal data store
 Predicate “sameValues” to match input of composite service
and input of subordinate service
 Less
refined than, e.g., BPEL
 Message behavior of composed OWL-S services not
well-understood
SIGMOD'04
June 17, 2004
38
Universal Description, Discovery and Integration (UDDI)

Directory for web services


Communicate via SOAP
Includes descriptions of services, in terms of:


Business, services, binding, “technical fingerprints”
tModels

“Schemas” for describing service templates (PortTypes)



There are tModel’s for WSDL descriptions of a service, for ebXML, …
When a service registers with UDDI, the technical fingerprint includes
listing of tModels that it uses
tModel’s can be registered, and incorporated into taxonomies
Allows queries over services, tModels, implementations,
and other information
 UDDI expected to expand over time, enabling richer
service descriptions

SIGMOD'04
June 17, 2004
40
OWL-S Profile Ontology is Analogous to
the Concept of UDDI Taxonomy
SIGMOD'04
June 17, 2004
41
Outline
Introduction and positioning
 Standards
 Models of Web Services and Composition
 Approaches to Automated Composition
 Analysis and Verification
 Future Directions

SIGMOD'04
June 17, 2004
42
Models of Interoperation
Different models focus on different aspects
 Automata-based
 Intricate structure for atomic services
 Rich interleaving between atomic services
 Message-based or activity-based
 Logic-based perspectives
 Frameworks supporting proof and model theories
 Different ways of modeling complex services
 Natural to incorporate “effect on the world”
 Constraint-based
 Support partial specification of desired behaviors
 Focus on different varieties of “observables”
SIGMOD'04
June 17, 2004
43
First Impressions: Topology
Two common approaches:
authorize
ok
store
order1
receipt1
warehouse1
warehouse2
store
bank
k’
a’
a

r
Mediated, or
“hub and spoke”
SIGMOD'04
bill2
Peer-to-peer
payment2

bank
o
o1
warehouse1
b1
b
mediator
r1
p1
June 17, 2004
b2
o2
k
p
p2
r2
warehouse2
44
First Impressions: Enactments
bank
warehouse2
order1
payment2
warehouse1
bill2
receipt1
store
authorize
ok
“Enactment” = the execution of multiple steps in a
(composite) service, corresponding to a single instance
of a (possibly complex) business process
 Nested enactments: one authorize, several orders

SIGMOD'04
June 17, 2004
45
Compositions vs. Complex Individual Services

Re-usability of component parts
For individual services, this is a design goal, but not enforced
 For compositions, this is foundational assumption


World view


Components of individual service can “see” the rest of the
service, modulo scoping, etc.
Services in a composition have a limited interface to “see”
other services (typically via messages only)


Implications on transactional aspects
Management of different enactments
Individual service: Details of enactment management are
hidden
 Composite service: Need mechanism for associating activities
of component services with appropriate global enactment
 BPEL uses the phrase “correlation sets”
SIGMOD'04
June 17, 2004
46

Models we describe here
Model
Emphasize Emphasize
Individual Composite
service
service
Style
Mealy/Conversation
yes
Automata, messagebased
Roman
yes
Automata, activity-based
Data-Driven
yes
PSL/Situation
Calculus
yes
CTR/CTR-S
yes
Commitment
SIGMOD'04
Automata (specified by
rules)
yes
First-order Logic, activitybased
Stylized Logic
yes
June 17, 2004
Constraints, messagebased
47
Mealy Service Model [Bultan et al WWW’03]
 Individual
service as a Mealy (finite state) machine:
 Input and output messages only
 Finite state control
 Describes behavioral signatures
 Abstraction of WSCL
 Composition: connecting related services
!r2
?o2
SIGMOD'04
receipt1
bank
?p2
bill2
warehouse1
!b2
payment2
order1
store
authorize
ok
warehouse2
June 17, 2004
e
!b2
!r2
?p2
!r2
warehouse2
48
Asynchronous Communication With Queue

Asynchronous, for example, the following channel:
store
order1
o1
warehouse1
send Order1
…
Queues are FIFO, unbounded length
 Can simulate synchronous and also bounded queues

send Order1
receive Receipt1
…
SIGMOD'04
June 17, 2004
49
Conversations (an abstraction of enactments)

Watcher: “records” the messages as they are sent
authorize
warehouse1
bank
payment2
ok
bill2
order1
receipt1
store
Watcher
a
k o1 o2 b1 p1 r1 r2 b2 p2
warehouse2
A conversation is a sequence of messages the watcher
sees in a successful run (or enactment)
 Conversation language: the set of all possible
conversations
 What properties do composition languages have?

SIGMOD'04
June 17, 2004
51
Conversation Languages Are Not Regular
!a
?b
a
?a
b
!b
p2
p1





CL  a*b* = anbn
Composition languages are not always regular
 Some may not even be context free
Causes: asynchronous communication &
unbounded queue
Bounded queues or synchronous: CL always regular
CLs are always context sensitive
SIGMOD'04
June 17, 2004
53
“Roman” model:
An automata-based models with activities
[Berardi et. al. ICSOC 03]
 Model
of human-machine
web services
(e.g., Amazon)
 Focus on activities
 Abstract behavior of the Service:
Client selects next activity
init
search
listen
cart
buy
Do until Client selects “End”
1. Give Client a choice of actions to
be performed
2. Wait for Client choice
3. Perform action chosen by Client
SIGMOD'04
June 17, 2004
Online
Music Store
Client
Service
on-line
music
store
55
Roman Model: Automata representation
Music store
init
search
listen
cart
buy
search
init
search
listen
cart
search
cart
buy
search
Transitions labeled by activities
 More abstract than message-based approach
 For a given state, the out-edges represent the set of
options that will be presented to the user

SIGMOD'04
June 17, 2004
56
Roman model: Composition
init
search
listen
cart
buy
Delegator
for music store
init
Web
Delegator:
Activity-based
FSM annotated
with delegations
search
Web
listen
Juke
search
Web
cart
Web
???
???
search
Web
search
Web
cart
Web
buy
Bank
Web store
init
search
cart
Juke
listen
Bank
buy
search
SIGMOD'04
June 17, 2004
57
Data Driven Web Service
[Deutsch et al PODS’04]
is on interaction
between control flow and
database contents
 Transitions resemble
Datalog rules and update
the database
database
 Rules + DB can be
used to simulate
Effects
control structures (updatable)
Home page(HP)
 Emphasis
Name
passwd
login
Customer page(CP)
Error message page(MP)
Read only
cancel
Desktop
My order
laptop
back
Desktop Search(SP)
Past Order (POP)
Past Order
laptop Search(SP)
Desktop search
Desktop search
Ram:
Ram:
Hdd:
Hdd:
Display:
search
search
Order status(OSP)
Product index page(PIP)
Order status
Matching products
Cancel confirmation
page(CCP)
Product detail page(PP)
Product detail
buy
Confirmation page(CoP)
Order detail
SIGMOD'04
June 17, 2004
58
An Abstract Perspective: Rule-based Control

A hybrid combining automata and logic
Condition based
on database query
Updates to
the database
A complex service:
If y then run S
If y1 then run S1
:
database
Effects
(updatable)
E
S
E’
If yn then run Sn
Read only
SIGMOD'04
June 17, 2004
59
Situation Calculi and PSL:
Logics with Actions and Tree-based models
Focus on description of properties, not execution
 Models:



“Fluents”:



Trees whose nodes correspond to atomic actions
Propositions (and predicates) which hold between the
actions
Used to test pre-conditions, record effects
Vocabulary of PSL (a very rich situation calculus)
Various layers of reified predicates, e.g.,
 activity (a), activity_occurrence (o), timepoint (t)
 occurrence_of (o, a), min_precedes (o1, o2, a)
 holds (f, o), prior (f, o)
 Activities and occurrences identified using variables and
terms (e.g., withdraw(x, y))
 First-order logic, with a June
family
of axioms
SIGMOD'04
17, 2004

60
PSL: Simple illustration of the model theory
Atomic
activities:
w1 = withdraw (100, buyer)
d1 = deposit (100, seller)
w2 = withdraw (5, buyer)
d2 = deposit (5, broker)
init
Balance(buyer, 300)
w1
w2
Balance(buyer, 295)
w1
d1
w2
d1
transfer(100, buyer, seller)
w1
Balance(buyer, 195)
d2
w2
d1
d2
w2
d1
d2
w1
d2
d2
d1
d2
d2
d1
d1
transfer(5, buyer, broker)
Combinations of those transfers
Can add constraints, e.g., that w1 must precede w2
 Can use FOL inference or domain-specific reasoning

SIGMOD'04
June 17, 2004
61
Expressive power of PSL and Situation Calculi
Examples of PSL


Activities as terms:
x,y,z activity( transfer(x,y,z) )
Composition relationships:
 x,y,z subactivity(withdraw(w,y), transfer(x,y,z)
 a,y ( a = buy_product(y)  x,z subactivity( transfer(x,y,z) , a ) )

Process description for buy_product
 o,x occurrence_of(o, buy_product(x) )

o1,o2,y,z,w,v (occurrence_of( o1, transfer(y,x,z)
 occurrence_of(o2, transfer(w,x,v)
 subactivity_occurrence(o1, o )
 subactivity_occurrence(o2, o ) )
Situation Calculi typically less expressive


Cannot have variables for composite activities/occurrences
Cannot have terms for activities (e.g., transfer(x,y,z))
SIGMOD'04
June 17, 2004
62
Golog: “Programming” as constraints

Golog: a “programming language” for the situation
calculus
 “Constructs” such as



Sequence: 1 ; 2
Conditional: if  then 1 else 2 endif
Loop: while  do  endWhile
 Interpreted
as temporal constraints
on permitted paths


init
w2
w1
w2
d1
w1
d2
d1
d2
w2
d1
d2
w1
d2
d1
d2
d2
d1
d1
E.g., “ w1; w2 ” is satisfied by 3 of the 6 branches
Two-tier “program” specification
 First tier: use the “constructs” from above

Identifies a set of possible execution sequences
 Second

SIGMOD'04
tier: arbitrary constraints
Further restricts set of possible execution sequences
June 17, 2004
65
CTR/CTR-S: Logics specialized to services

Concurrent Transaction Logic (CTR) [Bonner, Kifer ’96]
 A logic that extends first-order logic

Three connectives that capture key programming
constructs in concurrent transactions
An abstract notion of “update” to shared store
 A model theory based on sequences of states
 A Horn clause fragment with proof theory
 A framework for rules-based specification of
“programs”, combined with arbitrary constraints
 CTR-Services [Davulcu, Kifer, Ramakrishnan WWW’04]
 Targeted at negotiation (once services are
discovered)
 One more connective, specific to “adversarial” peer
services

SIGMOD'04
June 17, 2004
67
CTR Constructs (which are constraints)

A simple workflow
a
cond1
and
c
cond2
or
b
g
d
cond3
f
e
a  ( b | ( c  ( d  ( e  f ))) )  g

Temporal constraint
“if e is executed, then
b must occur before f ”
Trigger
“if e is executed and
cond4 , then do h ”
(selected) Constructs and intuition
   y :  precedes y in any successful execution
  | y :  and y are to be interleaved and both
execute
   y : either  or y is true in each successful exec.

 : “isolation” – nothing can interleave with 
SIGMOD'04
June 17, 2004
68
CTR: Model Theory and Horn fragment

Updates against shared “external” world



CTR models are “multi-paths”, i.e., sequences of paths
of (traditional) models
( M1 M 2 M 3 , M 4 M 5 , M 6 M 7 M 8 M 9 )


Simple example: can use standard relational db updates
Complex example: can use abstract data types as the outside
world
Separations correspond to “break-points”, where other CTR
program executions might be interleaved
Horn fragment
Bottom_part  ( c  ( d  ( e  f )))
Workflow  a  ( b | Bottom_part )  g

a
cond1
and cond2 b
d
or
c
e f
g
cond3
There is a proof theory and inference algorithm for
Horn fragment
SIGMOD'04
June 17, 2004
69
CTR-Services

New construct: 





y -- “opponent’s choice”
Intuition: The external world will choose one of  or y
So, you have to verify your theory against both possibilities
Useful for modeling different alternatives that may arise in a
contract, e.g.,
satisfied  (ship  pay)  (  ship  insurance_payout)
Allows game-theoretic perspective
Need to extend model theory of CTR




New models are sets of m-paths
Corresponds to the multiple possibilities created by 
As with CTR, a Horn fragment, a proof theory for it,
and an inference algorithm
SIGMOD'04
June 17, 2004
70
A constraint-based approach based on
Protocols and Commitments
[Venkatraman, Singh ’99]

Building blocks of the approach:
 Commitments: that one service (agent) commits to
perform an action for another service (agent)
 Protocols: permitted sequences of messages
between two services acting in specified roles

Typically expressed as a (finite) “skeleton”
Formal underpinnings
 Propositional temporal logic (CTL)
 Assign meanings (as commitments) to messages
 Framework developed to verify whether an enactment
satisfies the protocols

SIGMOD'04
June 17, 2004
71
Commitments
Commitment has form: c = (x, y, G, p)
 x = debtor
 y = creditor
 G = “social group” that enforces the commitment
 p = “discharge condition” for the commitment
 Operations on commitments
 Create
 Discharge: concurrent with making p true
 Cancel: performed by the creditor
 Release: typically performed by the social group
 Delegate: shifts role of debtor
 Assign: shifts role of creditor

SIGMOD'04
June 17, 2004
72
Example: Message as a commitment
Consider an auction with a Seller and Buyers
 Some propositional variables in the world




“item_delivered”: becomes true when item delivered
“moneyj-paid”: becomes true if $i is paid to Seller
Bid-pricei( Buyerj ) can be interpreted as
C ( Buyerj, Seller, Auction,
AG [ item_delivered 
AF create ( Buyerj,
C ( Buyeri, Seller, Auction, AF moneyi-paid ))])
Intuitively, if Buyerj bids $i, he commits to the Seller that:
“If the item is delivered, then eventually Buyerj will create a
commitment to eventually pay $i to the Seller”
To make payment: send following message and make payment
discharge ( Buyeri, Seller, Auction, AF moneyi-paid )


SIGMOD'04
June 17, 2004
73
Other Related Work


Process algebras (CSP, CCS,
-calculus, …)
 Concurrent processes
specified as expressions
 Synchronous
communications via
“channels”
 Dynamic creation of
channels (-calculus),
processes (spawning)
Relevance to composition:
 Formal semantics (e.g.,
WS-Choreography and calculus)
 Reasoning, optimization of
processes
 Analysis tools
SIGMOD'04


Petri nets
 Concurrent processes are
implicit:
 Actions as transitions
 Action execution
changes one
“snapshots” (markings)
to another
 Used for workflow
modeling
Relevance to composition
 Analysis and reasoning
June 17, 2004
74
Rich on messages
Composition Models and Standards
Mealy Model
WS-Choreography
WSCL
BPEL4WS
Commitments
Golog*
Data-Driven*
CTR-S*
PSL/Situation
Calculi
OWL-S
Roman
WSDL
*if interpreted as a composition model
SIGMOD'04
June 17, 2004
Rich on activities
76
Outline
Introduction and positioning
 Standards
 Models of Web Services and Composition
 Approaches to Automated Composition
 Analysis and Verification
 Future Directions

SIGMOD'04
June 17, 2004
77
Automated Composition
Why automated composition
 Composition “on-the-fly” will enable flexible use of
vast numbers of services
 E.g., pick the best services for your immediate need
 E.g., get the job done even if your favorite
component service is unavailable
 Overview – a nascent field
 Roman model: Elegant result in restricted framework
 Mealy model: An approach based on synthesis
 Golog: An approach based on templates and
customization

SIGMOD'04
June 17, 2004
78
Roman Model: Composition via delegators
init
search
listen
cart
buy
Music store
search
init
search
cart
search
cart
buy
search
“UDDI++”:
Available services
Web store
init
listen
Desired
Service
search
cart
Juke
listen
Bank
buy
search
SIGMOD'04
June 17, 2004
79
Delegator:
Activity-based
FSM annotated
with delegations
Example delegator
init
search
listen
cart
buy
Delegator
for music store
init
Web
search
Web
listen
Juke
search
Web
cart
Web
???
???
search
Web
buy
Bank
“UDDI++”:
Available services
Web store
init
search
Web
cart
Web
search
cart
Juke
listen
Bank
buy
search
SIGMOD'04
June 17, 2004
80
Results on Roman Composition

In some cases, delegator is not simply a labeling of
Delegator
a
target machine
Desired
S1
c
S1
c
S2
b
S2
a
c
b
a
S1
a
c

S2
c
b
“UDDI++”:
Available services
Can determine if a delegator exists, and build it, in
EXPTIME [Berardi et al ’03]
 Proof technique uses Description Logics (ALU)
 Prototype
engine
SIGMOD'04
implementation of algorithm using DL
June 17, 2004
81
Conversation Realizability in Mealy model
warehouse1
bill2
bank
payment2
receipt1
order1
store
authorize
ok
warehouse2

Target conversations as a language L:
a k shuffle ((o1(shuffle (r1, b1p1))*, (o2(shuffle (r2, b2p2))*)

Design question:
Given a (regular) language L, can we design Mealy
services so that their conversation language is L ?
SIGMOD'04
June 17, 2004
83
A Quick Answer:
Some Regular Languages are not Realizable
p4
c
p1
a
d
e
b
p2
p3
Very simple language { abcde }
 Every Mealy composition allowing conversation abcde
will also allow acbde
 Two reasons why a language may not be realizable:
 Impact of local views — Projection-Join
 Impact of send delays — Preponing

SIGMOD'04
June 17, 2004
84
Local View and Join
p4
c
p1
a
d
e
b
p3
p2
Local views
p1 p2 p3 p 4
abcde ace ab bde cd acbde
Local view of a peer peer(L): the part of conversation
the peer participates (receives or sends)
 Given languages Li over Si, 1  i  n

{
i Li  w 1  i  n, πSi (w)  Li

}
Mealy conversation languages L
are closed under “projection-join”:  peers π peer ( L)  L
SIGMOD'04
June 17, 2004
85
Delaying Send and Prepone

If the global watcher sees w  … a b …
π p ( w)
!b
…
… a b …
!a
a peer p
p(w) should also allow
SIGMOD'04
local view at p
… b a …
June 17, 2004
86
A Sufficient Condition for Realizability

[Fu et al CIAA ’03]
L is a regular language of a Mealy machine A
 A1, ..., An are projections of A to peers 1, …, n
Lossless join: JOIN(1(L), ..., n(L))  L
2. Queues are optional: construct a product machine from
determined versions of A1, ..., An in which every
message sent is ready to be read immediately
3. Each Ai is autonomous: can only do only sends, only
receive, or terminate in each state
1.

A conjunction of three conditions implies that L is
realizable
SIGMOD'04
June 17, 2004
87
Composition using OWL-S and Golog

Recall: Golog: a “programming language” for the
situation calculus
init
 “Constructs” such as
w1



Sequence: 1 ; 2
Conditional: if  then 1 else 2 endif
Loop: while  do  endWhile
 Interpreted
paths

w2
d1
w2
w1
d2
d1
d2
w2
d1
d2
w1
d2
d1
d2
d2
d1
d1
as temporal constraints on permitted
ConGolog interpreter
 Based on Quintas Prolog
 Can search for branches that satisfy a Golog
program (and additional constraints)
SIGMOD'04
June 17, 2004
91
Composition with OWL-S and ConGolog (cont.)
Framework based on two tiers:
 Generic programs and Customization via constraints
 Start with family of atomic OWL-S services, with preconditions and effects
 Write Golog program capturing constraints on generic
flow of control and parameter passing
 Write additional constraints (in situation calc) to
capture personalization
 Typically express them as Horn formulas
 Use ConGolog engine to find one (or more) branches in
situation calc tree that satisfies all constraints
 “Middle-Ground Optimization” based on gathering
data in advance of world-altering activities
SIGMOD'04
June 17, 2004
92
Outline
Introduction and positioning
 Standards
 Models of Web Services and Composition
 Approaches to Composition
 Analysis and Verification
 Future Directions

SIGMOD'04
June 17, 2004
94
Analysis of Web Services
Service properties:
 Statements on functional logic, service guarantees,
…
 Statement on execution (deadlock, safety, …)
 Analysis may be in more demand:
 Dynamic composition
 Difficulties in testing
 Immature service oriented development
environments
 Possible approaches:
 Static: model checking, theorem proving, …
 Runtime monitoring

SIGMOD'04
June 17, 2004
95
Model Checking
The target of interest is given as a state transition
system
 Properties are specified in some temporal logic, e.g.,
linear temporal logic (LTL), branching time logic (CTL),..
 The entire state space is examined systematically




Explicit (automata techniques): e.g., SPIN, CWB, …
Symbolic, using forward or backward fixpoint: e.g., SMV
 BDDs can be used to symbolically represent sets of states
Model checking and compositions: The challenge is to
map a composition analysis problem to a model
checking problem
 May need an approximation of the composition model
SIGMOD'04
June 17, 2004
96
Approaches Examined

Model checking
 With finite state machines
[Fu et al WWW’04] [Foster et al ASE’03]
 With
process algebra [Koshikina-van Breugel 2003]
 OWL-S services analysis with Petri nets
[Narayanan-McIlraith WWW’02]
Rule-based services [Deutsch et al PODS’04]
 Analysis of a Natural Fragment of CTR

[Davulcu et al PODS’98]

Dynamic verification of protocol compliance in
commitments [Venkatraman and Singh ’99]
SIGMOD'04
June 17, 2004
97
Web Services Verification

Model execution as finite state machines
[Foster et al ASE ’03] [Fu et al WWW ’04]
Verifying conversation among a set of
BPEL composite services
 [Fu et al WWW ’04]
warehouse1

payment2
bank
bill2
order1
receipt1
store
authorize
ok
warehouse2
conversation
a k o1 o2 b1 p1 r1 r2 b2 p2
LTL properties: Every authorize
followed by some bill?
Approach: model BPEL services as “guarded automata”


Mealy machines + conditions on Transitions
+ XML messages + XML local data
Translated to Promela (input language of SPIN)
SIGMOD'04
June 17, 2004
101
BPEL to Guarded Automata

[Fu et al WWW ’04]
Each atomic activity  an automaton with single entry,
single exit
<receive …
operation = “approve”
variable = “request” />
e [request :=
approve_Out]
? approve_Out
[approve_In := request]
! approve_In
<invoke operation=“approve”,
invar="request“,
outvar=“aprvInfo” >
<catch faultname=“loanfault“>
< ... handler1 ... />
</catch>
</invoke>
loanfaul
? loanfault t
? approve_Out
e
handler1
[aprvInfo :=
approve_Out]
SIGMOD'04
June 17, 2004
102
BPEL to Guarded Automata

Control flow constructs: assemble Mealy machines
<sequence …/>
<… act1…/>
<… act2…/>
</sequence …/>
act1
<flow …/>
<… act1 …>
<source linkname = “link1”
condition = “cond1 …/>
</act1 >
<… act2 … >
<target linkname = “link1” />
</act2 >
</flow …/>
SIGMOD'04
e
act1
e [b_link1 := cond1 ]
product
June 17, 2004
act2
e [b_link1]
act2
103
Partial and Complete Verification (with SPIN)
authorize
warehouse1
bank
payment2
ok
bill2
order1
receipt1
store
conversation
a
warehouse2
k o1 o2 b1 p1 r1 r2 b2 p2
LTL properties: Every authorize
followed by some bill?
Promela: input language of SPIN
 Concurrent processes communicating with bounded
queues
 Each guarded automaton  a Promela program
 Bound the queue length  partial verification
 Synchronizable  complete verification

SIGMOD'04
June 17, 2004
104
Web Service Analysis Tool (WSAT)
Complete
verification
Guarded
Automata
Sync.
Analysis
SPIN
Back End
Front End
WS-Choreography,
OWL-S
Interacting
BPEL
Web Services
Partial
verification
SPIN
LTL
properties
other
verification
tools
[Fu et al WWW’04, ISSTA’04, CAV’04]
SIGMOD'04
June 17, 2004
108
Verification with Process Algebra
[Koshikina-van Breugel 2003]
BPEL control structures  BPE-calculus
 BPE-calculus  PAC and then to CWB
 Concurrency Workbench [Cleaveland and Sims CAV’96]
 Model checking tool for CCS and CSP

Checking if a BPEL composition is deadlock-free
 In general, temporal properties
 Message contents and local data contents are not
modeled

SIGMOD'04
June 17, 2004
109
Verification of OWL-S services
Analyzing and automated
composition of OWL-S
 Analysis: Does an OWL-S service satisfy some
property?
[Narayanan-McIlraith WWW’02]
An OWL-S
service S
.......y?
situation calculus
(propositional)
Approach:
 Simulating S using a Petri net
 Conduct Petri net reachability analysis
 DAML-S (v0.5) analysis is PSPACE complete
 Reachability of 1-safe nets (each place is marked 1
or less)

SIGMOD'04
June 17, 2004
110
Mapping OWL-S to Petri Net

Petri nets:





Places: hold tokens
Transitions: consume input tokens and produce output tokens
Marking: a snapshot
Reachability: one marking to another via transitions
OWL-S to Petri net mapping:
Conditions (in situation calculus): places
 Atomic services: transitions
 Pre- and post-conditions


Inductive mapping from services to Petri nets
SIGMOD'04
June 17, 2004
111
OWL-S to Petri Net

Control structures “glue” pieces together
SIGMOD'04
June 17, 2004
112
Verification of Rule Based Service
[Deutsch et al PODS’04]
First order temporal
properties (FO-LTL)
 Verification is in PSPACE for
a restricted model (inputbounded services)
 Undecidable with slight
generalization
 Use and extend technique
for abstract state machines
Home page(HP)
Name
passwd
login
Customer page(CP)
Error message page(MP)
[Spielman PODS’01]
My order
June 17, 2004
Desktop
laptop
back
Desktop Search(SP)
Past Order (POP)
Past Order
laptop Search(SP)
Desktop search
Desktop search
Ram:
Ram:
Hdd:
Hdd:
Display:
search
search
Order status(OSP)
Product index page(PIP)
Order status
Matching products
Cancel confirmation
page(CCP)
Verification of CTL properties
 Decidable for the
propositional case
SIGMOD'04
cancel
Product detail page(PP)
Product detail
buy
Confirmation page(CoP)
Order detail
114
CTR: Analysis of a Natural Fragment
[Davulcu et al PODS’98]

Focus on:

a
b
and
c
“concurrent Horn goal” – define acyclic workflow
or
g
d f
e
a  ( b | ( c  ( d  ( e  f ))) )  g



“unique-event” goals – each event can occur at most once in
an execution
(simple) temporal constraints on events (a.k.a. actions)
Approach to analysis
Start with Horn goal G and temporal constraints C
 Key transformation*: apply(G, C )  G  C
 Can construct apply(G, C ) in O( | G | x (# disjuncts)|C| )


Example analysis results
 G  C is consistent iff apply(G, C )  false


Exists constructive algorithm to test whether every execution
of G  C satisfies a temporal constraint 
Extension of approach to CTR-Services [Davulcu et. Al. WWW’04]
* Second operator, excise, not discussed here June 17, 2004
SIGMOD'04
115
Verifying Protocol Compliance in
Protocols and Commitments model
[Venkatraman, Singh ’99]

Recall: Bid-pricei( Buyerj ) can be interpreted as
C ( Buyerj, Seller, Auction,
AG [ item_delivered 
AF create ( Buyerj, C ( Buyeri, Seller, Auction, AF moneyi-paid ))])

Goal: enable a service (or group of services) to verify
at runtime that the other services are satisfying their
commitments


Assume it can see all messages pertaining to a given protocol
Theoretical results


Can restrict attention to a linear temporal logic tree, that
corresponds what has happened so far
Verify the protocols by testing whether each commitment can
be satisfied by extensions of this linear model
SIGMOD'04
June 17, 2004
116
Outline
Introduction and positioning
 Standards
 Models of Web Services and Composition
 Approaches to Automated Composition
 Analysis and Verification
 Future Directions

SIGMOD'04
June 17, 2004
117
Web Services: The Big Questions
Simplify and/or automate web service
 Discovery
 What properties should be described?
 How to efficiently query against them?
 Composition
 Specifying goals of a composition
 Specifying constraints on a composition
 Building a composition
 Analysis of compositions
 Invocation
 Keeping enactments separated
 Providing transactional guarantees
 Monitoring
 How to track enactments
 Recovering from failed enactments
SIGMOD'04
June 17, 2004
Primary focus
of this tutorial
118
Challenge Questions for DB Community




Discovery
 Large repositories of services will emerge, described
according to a variety of models (commitment, automata,…)
 How to efficiently query against them?
Monitoring
 PSL representation of service enactments has natural
representation as a relational database
 Can use relational queries to perform run-time monitoring
 Can use queries to do data mining on execution logs
Transactions
 Providing transactional guarantees remains largely open
 What are the building blocks within services? In
choreography?
 Verifying transactional correctness?
Data-intensive services (e.g., scientific)
 The set of composition specifications is itself a large
database
SIGMOD'04
June 17, 2004
119