Transcript Database languages

Overview of Web Service Models and
Frameworks
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, . . .
Web Services: Overview
2
7 Principles of Service-Oriented Development
[Bloomberg ’02]
 Dynamic
services replace static components
 Service exposure and reflection replaces traditional
system integration
 Bottom up replaces top down
 Coding for broad applicability supercedes coding for
reusability
 Far beyond reuse in object-oriented programming
 Ad hoc upgrades supplant disruptive upgrades
 Scalability handled bottom up, instead of top down
 Platform dependence gives way to platform irrelevance
 The federation model of software replaces the
dictatorship model
Web Services: Overview
3
E-Commerce
buy
get
store
authorize
supplier1




ok
bank
supplier2
Web services paradigm driven by e-commerce
Today: front-end; Tomorrow: back-end
Enactments with different life-cycles
 E.g., one credit authorize for many orders
Add new services dynamically
Web Services: Overview
4
Telecom/Collaborative Services
Session
Coordinator
Profile
Data
Pre-Pay
Media
Server
(video)
Media
Server
(voice)
Presence
Server
 Emerging
standards will enable
 Flexible, dynamic incorporation of features
 Convergence of telecom and web services
 Bearer traffic vs. signaling/control traffic
 Asynchronous events, feature interaction
Web Services: Overview
5
E-Science
Controller
control and calibrations
Sea
Circulation
Atmospheric
Simulation
notifications and/or
experimental data
Waste
Transport
 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
Web Services: Overview
6
Web Services: Goals
Simplify and/or automate web service
 Discovery



Composition





Specifying goals of a composition
Specifying constraints on a composition
Building a composition
Analysis of compositions
Primary focus
of this course
Invocation



What properties should be described?
How to efficiently query against them?
Keeping enactments separated
Providing transactional guarantees
Monitoring
How to track enactments
 Recovering from failed enactments
Web Services: Overview

7
The Web Services Paradigm
 Primary
roots of web services paradigm
a) Process description formalisms
b) Distributed computing middleware
c) Data management
 What makes web services “new”
 More flexible, less structured than CORBA
 Data management has larger role in (a) and (b)
 Importance of standards to enable interoperation
and analysis
Web Services: Overview
8
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]
Web Services: Overview
9
Interface
WSDL
Message
SOAP
Type
XML Schema
Data
XML
Web Service Standards
Web Services: Overview
IBM WebSphere
BPEL, DAML-S, WSCI
[Fu-Bultan-Su CIAA ’03]
Sun J2EE
Behavior
Microsoft .Net
Web Service Standards Stack
Implementation Platforms
10
Web Service Standards Stack
Web Services: Overview
[Turner-Budgen-Brereton CACM ’03]
11
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.
Web Services: Overview
12
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
Web Services: Overview
SOAP Envelope
Web
Server
Web
Service
13
RPC Messages

Typically two messages
SOAP
Client
SOAP Envelope
SOAP Header
SOAP Body
Web Services: Overview
Request Message
Response Message
SOAP
Server
“RPC style” SOAP body encodes
 the operation name and
parameters
 return result
XMLified
14
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]
Web Services: Overview
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
bill
order
order
Supplier’
Supplier
receipt
payment
bill_payment
out: bill
in: payment
receipt
 Port:
mechanism to cluster operations
 Port as unit of interoperation between services
Web Services: Overview
16
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
Web Services: Overview
17
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]
Web Services: Overview
18
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
Web Services: Overview
19
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]

Web Services: Overview
20
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
Web Services: Overview
Shipping
!ShippingInfo
21
WS Choreography
An emerging standard from W3C
 Drawing inspiration from the p-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



Interactions, exceptions, finalizer
composable
Web Services: Overview
22
BPEL
versus
A scripted composition
using
 WSDL messages
 Control structures with
constrained parallelism
 More procedural
 Executable or abstract


Favor centralized
composition
Web Services: Overview
WS-Choreography

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. p-calculus)

23
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
 communication protocol (RPC,
HTTP, …)
 port number
 marshalling/serialization
Web Services: Overview




input types
output types
preconditions
effects
Service
Model
 process flow
 composition hierarchy
 process definitions
24
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)

Web Services: Overview
25
OWL-S Focuses on Knowledge
 Conditions
order
bill
on input/output
Supplier
 if valid client sends order,
receipt
payment
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 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
and shipment of the order”
Web Services: Overview
26
OWL-S Service Model
Web Services: Overview
27
OWL-S Process Model
 Constructs
for composite processes
 Sequence
 Concurrency:
 Choice
 If-Then-Else
Split; Split+Join; Unordered
Service
describedby
(how it works)
Service
Model
 process flow
 composition hierarchy
 process definitions
 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
Web Services: Overview
28
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

Web Services: Overview
29
OWL-S Profile Ontology is Analogous to
the Concept of UDDI Taxonomy
Web Services: Overview
30
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”
Web Services: Overview
31
First Impressions: Topology
Two common approaches:
authorize
ok
store
order1
receipt1
warehouse1
warehouse2
store
bank
k’
a’
a

r
Mediated, or
“hub and spoke”
Web Services: Overview
bill2
Peer-to-peer
payment2

bank
o
o1
warehouse1
b1
b
mediator
r1
p1
b2
o2
k
p
p2
r2
warehouse2
32
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

Web Services: Overview
33
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”
Web Services: Overview
34

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
Web Services: Overview
Automata (specified by
rules)
yes
First-order Logic, activitybased
Stylized Logic
yes
Constraints, messagebased
35
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
receipt1
Web Services: Overview
bank
?p2
bill2
warehouse1
!b2
payment2
order1
store
authorize
ok
warehouse2
e
!b2
!r2
?p2
!r2
warehouse2
36
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
…
Web Services: Overview
37
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?

Web Services: Overview
38
Example of Specifying A Conversation Protocol
authorize
store
ok
bank
warehouse1

warehouse2
The conversation language allowed:
a k shuffle ( ( o1(shuffle ( r1, b1p1) )* , ( o2(shuffle ( r2, b2p2) )* )
Web Services: Overview
39
Conversation Languages Are Not Regular
!a
?b
p1





a
?a
b
!b
p2
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
Web Services: Overview
40
“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
Web Services: Overview
Online
Music Store
Client
Service
on-line
music
store
41
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

Web Services: Overview
42
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
Web Services: Overview
43
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
Web Services: Overview
44
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
Web Services: Overview
45
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 family of axioms
Web Services: Overview

46
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

Web Services: Overview
47
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))
Web Services: Overview
48
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

tier: arbitrary constraints
Further restricts set of possible execution sequences
Web Services: Overview
49
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

Web Services: Overview
50
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 
Web Services: Overview
51
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
Web Services: Overview
52
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
Web Services: Overview
53
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

Web Services: Overview
54
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

Web Services: Overview
55
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 )


Web Services: Overview
56
Other Related Work


Process algebras (CSP, CCS,
p-calculus, …)
 Concurrent processes
specified as expressions
 Synchronous
communications via
“channels”
 Dynamic creation of
channels (p-calculus),
processes (spawning)
Relevance to composition:
 Formal semantics (e.g.,
WS-Choreography and pcalculus)
 Reasoning, optimization of
processes
 Analysis tools
Web Services: Overview


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
57
Rich on messages
Composition Models and Standards
Mealy Model
WS-Choreography
WSCL
BPEL4WS
Commitments
WSDL
*if interpreted as a composition model
Web Services: Overview
Golog*
Data-Driven*
CTR-S*
PSL/Situation
Calculi
OWL-S
Roman
Rich on activities
58
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

Web Services: Overview
59
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
Web Services: Overview
60
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
Web Services: Overview
61
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
Web Services: Overview
implementation of algorithm using DL
62
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 ?
Web Services: Overview
63
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

Web Services: Overview
64
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 ppeer(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
Web Services: Overview
65
Delaying Send and Prepone

If the global watcher sees w  … a b …
π p (w)
!b
…
… a b …
!a
a peer p
pp(w) should also allow
Web Services: Overview
local view at p
… b a …
66
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(p1(L), ..., pn(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
Web Services: Overview
67
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)
Web Services: Overview
68
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
Web Services: Overview
69
Automatic Composition via Petri nets
[Narayanan+McIlraith ’02]: Search over all combinations
 Recall
simulation of OWL-S via 1-safe Petri nets
1.For set of atomic e-services, create Petri Net that
represents all possible (single-use) combinations of
them
2.Specify desired goal as a state of this Petri Net
3.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
Web Services: Overview
70
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

Web Services: Overview
71
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
Web Services: Overview
72
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]
Web Services: Overview
73
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)
Web Services: Overview
74
BPEL to Guarded Automata

[Fu et al WWW ’04]
Each atomic activity  an automaton with single entry,
single exit
<receive …
operation = “approve”
variable = “request” />
<invoke operation=“approve”,
invar="request“,
outvar=“aprvInfo” >
<catch faultname=“loanfault“>
< ... handler1 ... />
</catch>
</invoke>
e [request :=
approve_Out]
? approve_Out
[approve_In := request]
! approve_In
loanfaul
? loanfault t
? approve_Out
e
handler1
[aprvInfo :=
approve_Out]
Web Services: Overview
75
BPEL to Guarded Automata

Control flow constructs: assemble Mealy machines
<sequence …/>
<… act1…/>
<… act2…/>
</sequence …/>
<flow …/>
<… act1 …>
<source linkname = “link1”
condition = “cond1 …/>
</act1 >
<… act2 … >
<target linkname = “link1” />
</act2 >
</flow …/>
Web Services: Overview
act1
e
act1
e [b_link1 := cond1 ]
product
act2
e [b_link1]
act2
76
Partial and Complete Verification (with SPIN)
authorize
warehouse1
bank
payment2
ok
bill2
order1
receipt1
store
warehouse2
conversation
a
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

Web Services: Overview
77
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]
Web Services: Overview
78
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

Web Services: Overview
79
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)

Web Services: Overview
80
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
Web Services: Overview
81
OWL-S to Petri Net

Control structures “glue” pieces together
Web Services: Overview
82
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
[Spielman PODS’01]
Verification of CTL properties
 Decidable for the
propositional case
Web Services: Overview
Home page(HP)
Name
passwd
login
cancel
Customer page(CP)
Error message page(MP)
My order
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)
Product detail page(PP)
Product detail
buy
Confirmation page(CoP)
Order detail
83
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
Web
Services:
Overview
84
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
Web Services: Overview
85
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
Web Services: Overview
Primary focus
of this tutorial
86
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
Web Services: Overview
87