tools for design of composite web services -- presented version (june 17, 2004) --...

Tools for Design ofComposite 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)

June 17, 2004SIGMOD'04 2

Outline

Introduction and positioning StandardsModels of Web Services and

Composition Approaches to Automated

Composition Analysis and Verification Future Directions


Web Services

The Web: Flexible human-machine interaction Web Services: Flexible machine-machine

interaction Working Definition: Network-resident software

services accessible via standardized protocolsSimple 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: The Big QuestionsSimplify and/or automate web service Discovery

What properties should be described?How to efficiently query against them?

CompositionSpecifying goals of a compositionSpecifying constraints on a compositionBuilding a composition Analysis of compositions

InvocationKeeping enactments separatedProviding transactional guarantees

MonitoringHow to track enactmentsRecovering from failed enactments

Primary focusof this tutorial


Anatomy of Web Services Composition

No unified model, e.g., BPEL: Strong on orchestration, info sharingOWL-S: Strong on goals, activities, discovery“Roman” model: Strong on activities, orchestration

Goal(s)

Activities

Infosharing(Messaging)

Orchestration,Monitoring

Discovery/Self-description


Key dimensions in web service composition

OWL-S

“sem

anti

cs”

Roman

Complexity of component services

Complexity of glue languageMealy

-CalcWSCL

CTR-S

BPMLBPEL

CSP

WSDL

Commitment Protocols


Key Disciplines for Web Services Composition Science of Design, e.g.,

WorkflowService-oriented computingReactive systemsProcess algebrasVerification

AI, e.g., Knowledge RepresentationAgentsPlanning

Database, e.g., XMLDomain-specific query languages IndexingTransaction Management


Goals of this Tutorial: Tools for Composition

Describe the playing fieldKey standards that we’ll all build uponPromising models and formalisms

Results on CompositionOWL-S communityAutomata-theoretic approaches

Results on Analysis and VerificationWorkflow communityOWL-S communityAutomata-theoretic

Future directions


Outline


Composition Approaches to Composition Analysis and Verification Future Directions


Web Services Standards Stack: Key Elements

HTTP, SMTP, FTP, etc.

SOAP

OWL-S ServiceProfice

Network

XMLMessaging

(Individual)Service

Description

WSCL

WSDL

Composition BPEL4WS

Choreography WS-Choreorgaphy

Discovery UDDI

OWL-S ServiceModel


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

ExternalService

WebService

WebServer

SOAP Envelope


RPC Messages

Typically two messages

SOAPClient

SOAPServer

Request Message

Response Message

SOAP Envelope

SOAP Header

SOAP Body

“RPC style” SOAP body encodesthe operation name and

parametersreturn result

XMLified


Web Service Definition Language (WSDL)

OperationPort Type

MessageBinding

Port Service

Supports

Input & Output

Provides

How to encode

Formats & ProtocolsHow to invoke

Implements

WSDL provides a framework for defining

Interface: operations and input/output

Access specification: SOAP bindings (e.g., RPC)

Endpoint: the location of service

[from Leymann BTW 2003 talk]


Traditional I/O signatures (using XML Schema)Four operation typesProactive : send request send request, block till responseReactive : receive request receive request, send response

order

receipt

bill

payment

order

receipt

bill_payment out: bill in: payment

Port: mechanism to cluster operationsPort as unit of interoperation between services

Supplier Supplier’

WSDL Operations


Business Process Execution Language (BPEL) Allow specification of compositions of Web

servicesbusiness processes as coordinated

interactions of Web services Allow abstract and executable processes Influences from

Traditional flow modelsStructured programmingSuccessor of WSFL and XLANG

Assumes WSDL ports

Standardization through OASIS


ReceivePurchase

Order

ArrangeLogistics Complete

ProductionScheduling

CompletePrice

Calculation

DecideOn

Shipper

InitiateProductionScheduling

InitiatePrice

Calculation

InvoiceProcessing

Price Calculation

portType

PurchaseOrderportType

BPEL in Action

operations

[from BPEL 1.1 standard]

Purchase Order service coordinates other services using ports in WSDL


Invokes an operation on a partner serviceSend to WSDL port, wait for a response

Receives invocation from a partnerWait for a message

Sends a reply message in partner invocationSend 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

BPEL Activities


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]

Initialize

pick

flag := true

end_datereached

receive order

case

suppl2order

suppl1order

end case

beginparallel

send Order

Receive Bill1

SendBill

ReceivePayment

SendPayment1

endparallel

do until flag

send Receipt

receive Receipt1

BPEL Examples


A key to web service composition:Interactions between services

WSCL specifies a conversation (behavior signature) as a labeled graph:Nodes: interactions, individual units of responsesEdges: transitions, sequencing of interactionsEdge labels: conditions on transitions

Web Service Conversation Language (WSCL)

ShippingInfo

ShippingPOAccepted

InvalidPayment PurchasePurchaseOrder POAccepted

InvalidPayment

OutOfStock


WS Choreography An emerging standard from W3C

Drawing inspiration from the -calculus Global view of composite service interactions

Global model: interactions and choreographyChoreography Definition Language (WS-CDL)

Key technical elementsParticipants and roles: what services are involvedChannels: where and how the messages are sentInteractions: message exchange patternsActivities and control structures: sequencingChoreography: a global description of a

composition Interactions, exceptions, finalizer composable


BPEL meets WS-Choreography

A scripted composition usingWSDL messagesControl structures

with constrained parallelism

More procedural Executable or

abstract

Favor centralized composition

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)


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

Resource

Service

ServiceProfile

ServiceModel

ServiceGrounding

communication protocol (RPC, HTTP, …) port number marshalling/serialization

input types output types preconditions effects

process flow composition hierarchy process definitions

provides presents

(what it does)

describedby(how it works) supports

(how to access)


Service profile defines what the service provides:Functional descriptions: In/Output, Preconditions, EffectsNon 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)

OWL-S Service Profiles

Service

ServiceProfile

Input types Output types Preconditions Effects

presents(what it does)


OWL-S Service Model


Constructs for composite processesSequenceConcurrency: Split; Split+Join; UnorderedChoiceIf-Then-ElseLooping: Repeat-Until; Iterate (non-deterministic)Note: In spirit of Golog, these can be viewed as

constraintsData Flow

No explicit variables, no internal data storePredicate “sameValues” to match input of composite

service and input of subordinate service Less refined than, e.g., BPELMessage behavior of composed OWL-S services not

well-understood

Service

ServiceModel

process flow composition hierarchy process definitions

describedby(how it works)

OWL-S Process Model


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


OWL-S Profile Ontology is Analogous to the Concept of UDDI Taxonomy


Outline





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”


First Impressions: Topology

Two common approaches:

ware-house1

ok

bill2

paym

ent2

orde

r 1

rece

ipt 1

order2receipt

2

payment 1

bill 1

bank

ware-house2

storeauthorize

ak’

ro

b2

p2

r2o2

r1

o1

b1p1

ka’

bp

mediator

store

ware-house1

bank

ware-house2

Mediated, or “hub and spoke”

Peer-to-peer


First Impressions: Enactments

“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

ware-house1

ok

bill2

paym

ent2

orde

r 1

rece

ipt 1

order2receipt

2

payment 1

bill 1

bank

ware-house2

store

authorize


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

hiddenComposite service: Need mechanism for associating

activities of component services with appropriate global enactment BPEL uses the phrase “correlation sets”


Models we describe here

Mealy/Conversation yes Automata, message-based

Roman yes Automata, activity-based

Data-Driven yes Automata (specified by rules)

PSL/Situation Calculus

yes yes First-order Logic, activity-based

CTR/CTR-S yes Stylized Logic

Commitment yes Constraints, message-based

ModelEmphasizeIndividual

serviceStyle

EmphasizeComposite

service


Mealy Service Model [Bultan et al WWW’03]

Individual service as a Mealy (finite state) machine:Input and output messages onlyFinite state control

Describes behavioral signaturesAbstraction of WSCL

Composition: connecting related services

ware-house1

ok

bill2

paym

ent2

orde

r 1

rece

ipt 1

order2receipt

2

payment 1

bill 1

bank

ware-house2

storeauthorize

warehouse2

?o2 !r2

!r2

!r2

!b2!b2

?p2?p2


Asynchronous Communication With Queue

Asynchronous, for example, the following channel:

ware-house1store order1

send Order1

…

o1

send Order1

receive Receipt1

…

Queues are FIFO, unbounded length Can simulate synchronous and also bounded

queues


order2

payment

1

bill 1

Conversations (an abstraction of enactments) Watcher: “records” the messages as they are sent

ok

authorize

receipt2

ord

er

1rece

ipt 1

bill2

paym

en

t 2

Watcher

ware-house2

ware-house1

store bank

a k o1 b1o2

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?

p1r1 r2 b2

p2


Conversation Languages Are Not Regular

?b!a

p1 p2

?a

!b

a

b

CL ab = anbn

Composition languages are not always regularSome may not even be context free

Causes: asynchronous communication & unbounded queue

Bounded queues or synchronous: CL always regular

CLs are always context sensitive


“Roman” model: An automata-based models with activities [Berardi et. al. ICSOC 03]

OnlineMusic Store

Abstract behavior of the Service: Client selects next activity

on-linemusicstore

Client

Service

initsearchlistencartbuy

Model of human-machine web services (e.g., Amazon)

Focus on activities

Do until Client selects “End”1. Give Client a choice of actions to

be performed 2. Wait for Client choice3. Perform action chosen by Client


Roman Model: Automata representation


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

buy

init search cart

search

Music store

listen

cart

search search


Roman model: Composition

init search

search

Web store

cart


??????buy

init search cart

search

Delegatorfor music store

listen

cartWebWeb

Web

Juke

Web

Banksearch search

WebWeb

Web

listenJuke

buy

Bank

Delegator: Activity-basedFSM annotated with delegations


database

Product index page(PIP)

Matching products

Home page(HP)Name passwd

login

Customer page(CP)

DesktopMy order

laptop

Product detail page(PP)

Product detail

Confirmation page(CoP)

Order detail

Desktop Search(SP)

Desktop search

Ram:

Hdd:

search

laptop Search(SP)

Desktop search

Ram:

Hdd:

Display:

search

Past Order (POP)

Past Order

Order status(OSP)

Order status

Cancel confirmationpage(CCP)

cancel

buy

Error message page(MP)

back

Data Driven Web Service [Deutsch et al PODS’04]

Emphasis is on interaction between control flow and database contents

Transitions resembleDatalog rules and update the database

Rules + DB can be used to simulate control structuresRead only

Effects(updatable)


An Abstract Perspective: Rule-based Control

A hybrid combining automata and logic

database

Read only

Effects(updatable)

E

If then run S

E’ S

A complex service:

If then run S: If n then run Sn

Condition basedon database query

Updates tothe database


Situation Calculi and PSL: Logics with Actions and Tree-based models Focus on description of properties, not execution Models:

Trees whose nodes correspond to atomic actions “Fluents”:

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


w1 = withdraw (100, buyer)d1 = deposit (100, seller)

w2 = withdraw (5, buyer)d2 = deposit (5, broker)

w1

d1

transfer(100, buyer, seller)

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

w2

d2

init

w1 w2

w2

d1 d2

d1 d2w1

w2

d2 d1

d1 d2 w1

d1d1d2 d2

Atomicactivities:

PSL: Simple illustration of the model theory

Balance(buyer, 300)

Balance(buyer, 295)

Balance(buyer, 195)


Expressive power of PSL and Situation Calculi

Examples of PSL Activities as terms: x,y,z activity( transfer(x,y,z) ) Composition relationships:

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

Process description for buy_product

Situation Calculi typically less expressive Cannot have variables for composite activities/occurrences Cannot have terms for activities (e.g., transfer(x,y,z))

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


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 E.g., “ w1; w2 ” is satisfied by 3 of the 6 branches

Two-tier “program” specificationFirst tier: use the “constructs” from above

Identifies a set of possible execution sequencesSecond tier: arbitrary constraints

Further restricts set of possible execution sequences

init

w1 w2

w2

d1 d2

d1 d2w1

w2

d2 d1

d1 d2 w1

d1d1d2 d2


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 transactionsAn abstract notion of “update” to shared storeA model theory based on sequences of statesA Horn clause fragment with proof theoryA 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


CTR Constructs (which are constraints)

(selected) Constructs and intuition : precedes in any successful execution | : and are to be interleaved and both

execute : either or is true in each successful

exec. : “isolation” – nothing can interleave with

A simple workflow

and

or

ab

c

d

e f

gcond1

cond2

cond3

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 ”


CTR: Model Theory and Horn fragment

Updates against shared “external” worldSimple example: can use standard relational db

updatesComplex example: can use abstract data types as the

outside world CTR models are “multi-paths”, i.e., sequences of

paths of (traditional) models( M1 M2 M3 , M4 M5 , M6 M7 M8 M9 )

Separations correspond to “break-points”, where other CTR program executions might be interleaved

Horn fragmentBottom_part ( c ( d ( e f ))) Workflow a ( b | Bottom_part ) g

There is a proof theory and inference algorithm for Horn fragment

andor

a

cd

e f

gcond1

cond2

cond3

b


CTR-Services

New construct: -- “opponent’s choice” Intuition: The external world will choose one of or So, you have to verify your theory against both

possibilitiesUseful 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 CTRNew models are sets of m-pathsCorresponds to the multiple possibilities created by

As with CTR, a Horn fragment, a proof theory for

it, and an inference algorithm


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 underpinningsPropositional temporal logic (CTL)Assign meanings (as commitments) to messages

Framework developed to verify whether an enactment satisfies the protocols


Commitments

Commitment has form: c = (x, y, G, p)x = debtory = creditorG = “social group” that enforces the

commitmentp = “discharge condition” for the commitment

Operations on commitmentsCreateDischarge: concurrent with making p trueCancel: performed by the creditorRelease: typically performed by the social groupDelegate: shifts role of debtorAssign: shifts role of creditor


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 asC ( 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 paymentdischarge ( Buyeri, Seller, Auction, AF moneyi-paid )


Other Related Work Process algebras (CSP,

CCS, -calculus, …)Concurrent processes

specified as expressionsSynchronous

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

Petri netsConcurrent processes

are implicit: Actions as

transitions Action execution

changes one “snapshots” (markings) to another

Used for workflow modeling

Relevance to compositionAnalysis and reasoning


Composition Models and Standards

WS-Choreography

BPEL4WS

WSDL

WSCL

OWL-S

Mealy Model

Roman

Golog*

PSL/Situation

Calculi

Commitments

CTR-S*

Rich on activities

Ric

h o

n m

ess

ag

es

Data-Driven*

*if interpreted as a composition model


Outline





Automated Composition

Why automated compositionComposition “on-the-fly” will enable flexible

use of vast numbers of servicesE.g., pick the best services for your immediate

needE.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 synthesisGolog: An approach based on templates and

customization


Roman Model: Composition via delegators

listenJukeinit search

search

Web store

cart

buy

Bank


buy

init search cart

search

Music store

listen

cart

search search

DesiredService

“UDDI++”: Available services


“UDDI++”: Available services

Example delegator

init search

search

Web store

cart


??????buy

init search cart

search

Delegatorfor music store

listen

cartWebWeb

Web

Juke

Web

Banksearch search

WebWeb

Web

listenJuke

buy

Bank

Delegator: Activity-basedFSM annotated with delegations


Results on Roman Composition

Can determine if a delegator exists, and build it, in EXPTIME [Berardi et al ’03]

Proof technique uses Description Logics (ALU)Prototype implementation of algorithm using

DL engine

c

b

aDesired

b

a

cS2 “UDDI++”:

Available servicesS1

c

a

S2

aS1

c

cS2

S1

Delegator

b

In some cases, delegator is not simply a labeling of target machine


Conversation Realizability in Mealy model

Target conversations as a language L:

a k shuffle o1shuffle r1b1p1o2shuffle r2b2p2

Design question:

Given a (regular) language L, can we design Mealy services so that their conversation language is L ?

ware-house1

ok

bil

l 2

pay

men

t 2

orde

r 1

rece

ipt 1order

2receipt2

payment 1

bill 1

bank

ware-house2

storeauthorize


A Quick Answer:Some Regular Languages are not Realizable

ac

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-JoinImpact of send delays — Preponing

p1

bd

p3

p4

e

p2


Local View and Join

Local view of a peer peerL: the part of conversation the peer participates (receives or sends)

Given languages Li over i, i n

Mealy conversation languages Lare closed under “projection-join”:

ac p1

bd

p3

p4

e

p2

Local views

p1 p2

p3 p4

abcde

ace

ab

bde

cd

acbde

LL )(πpeerpeers

iii LwniwLi

)(π,1


Delaying Send and Prepone

pw should also allow

a peer p

!a!b … a b …

local view at p

…

)(π wp

ab ……

ba …… If the global watcher sees w


A Sufficient Condition for Realizability [Fu et al CIAA ’03]

L is a regular language of a Mealy machine A AAn are projections of A to peers , …, n

1. Lossless join: JOINLnL L

2. Queues are optional: construct a product machine from determined versions of AAn 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

A conjunction of three conditions implies that L is realizable


Composition using OWL-S and Golog

Recall: 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

ConGolog interpreterBased on Quintas PrologCan search for branches that satisfy a Golog

program (and additional constraints)

init

w1 w2

w2

d1 d2

d1 d2w1

w2

d2 d1

d1 d2 w1

d1d1d2 d2


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 pre-conditions 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


Outline


Composition Approaches to Composition Analysis and Verification Future Directions


Analysis of Web Services

Service properties:Statements on functional logic, service

guarantees, … Statement on execution (deadlock, safety, …)

Analysis may be in more demand:Dynamic compositionDifficulties in testingImmature service oriented development

environments Possible approaches:

Static: model checking, theorem proving, …Runtime monitoring


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 systematicallyExplicit (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 problemMay need an approximation of the composition

model


Approaches Examined

Model checkingWith 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]

June 17, 2004SIGMOD'04 101

Model execution as finite state machines[Foster et al ASE ’03] [Fu et al WWW ’04]

[Fu et al WWW ’04] Verifying conversation among a set of BPEL composite services

Approach: model BPEL services as “guarded automata”Mealy machines + conditions on Transitions

+ XML messages + XML local dataTranslated to Promela (input language of SPIN)

Web Services Verification

order2

payment

1bill 1

ok

receipt2

ord

er

1rece

ipt

1

bill2

paym

ent

2

conversationa k o1 b1o2

p1r1 r2 b2

p2

LTL properties: Every authorize followed by some bill?

authorizestore bank

ware-house1

ware-house2

June 17, 2004SIGMOD'04 102

BPEL to Guarded Automata [Fu et al WWW ’04]

Each atomic activity an automaton with single entry, single exit

<receive … operation = “approve” variable = “request” /> ?? approve_Out

[request := approve_Out]

<invoke operation=“approve”, invar="request“,

outvar=“aprvInfo” > <catch faultname=“loanfault“> < ... handler1 ... /> </catch></invoke>

handler1

!! approve_In

?? approve_Out

? ? loanfaultloanfaul

t

[approve_In := request]

[aprvInfo :=

approve_Out]

June 17, 2004SIGMOD'04 103

BPEL to Guarded Automata

<sequence …/><… act1…/> <… act2…/>

</sequence …/> act1 act2

Control flow constructs: assemble Mealy machines

<flow …/> <… act1 …>

<source linkname = “link1”

condition = “cond1 …/> </act1 ><… act2 … >

<target linkname = “link1” />

</act2 ></flow …/>

act1

[b_link1 := cond1 ]act2

[b_link1]

product

June 17, 2004SIGMOD'04 104

order2

payment

1

bill 1

ok

authorize

receipt2

ord

er

1rece

ipt 1

bill2

paym

en

t 2

conversation

ware-house2

ware-house1

store bank

a k o1 b1o2 p1r1 r2 b2

p2

Promela: input language of SPINConcurrent processes communicating with

bounded queues Each guarded automaton a Promela program

Bound the queue length partial verification Synchronizable complete verification

Partial and Complete Verification (with SPIN)

LTL properties: Every authorize followed by some bill?

June 17, 2004SIGMOD'04 108

Web Service Analysis Tool (WSAT)

Fron

t E

ndGuarded Automata

Back

En

d

Sync. Analysis

Complete verification

Partial verification

SPIN

SPIN

WS-Choreography, OWL-S

other verification

tools

InteractingBPEL

Web Services

LTL properties

[Fu et al WWW’04, ISSTA’04, CAV’04]

June 17, 2004SIGMOD'04 109

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-freeIn general, temporal properties

Message contents and local data contents are not modeled

June 17, 2004SIGMOD'04 110

Verification of OWL-S services

[Narayanan-McIlraith WWW’02] Analyzing and automated composition of OWL-S

Analysis: Does an OWL-S service satisfy some property?

Approach:Simulating S using a Petri netConduct Petri net reachability analysis

DAML-S (v0.5) analysis is PSPACE completeReachability of 1-safe nets (each place is

marked 1 or less)

An OWL-S

service S

An OWL-S

service S

. . . . . . .?situation calculus(propositional)

June 17, 2004SIGMOD'04 111

Mapping OWL-S to Petri Net

Petri nets:Places: hold tokensTransitions: consume input tokens and produce output

tokensMarking: a snapshotReachability: one marking to another via transitions

OWL-S to Petri net mapping:Conditions (in situation calculus): placesAtomic services: transitions

Pre- and post-conditions Inductive mapping from services to Petri nets

June 17, 2004SIGMOD'04 112

OWL-S to Petri Net

Control structures “glue” pieces together

June 17, 2004SIGMOD'04 114

Product index page(PIP)

Matching products

Home page(HP)Name passwd

login

Customer page(CP)

DesktopMy order laptop

Product detail page(PP)

Product detail

Confirmation page(CoP)

Order detail

Desktop Search(SP)

Desktop search

Ram:

Hdd:

search

laptop Search(SP)

Desktop search

Ram:

Hdd:

Display:

search

Past Order (POP)

Past Order

Order status(OSP)

Order status

Cancel confirmationpage(CCP)

cancel

buy

Error message page(MP)

back

Verification of Rule Based Service[Deutsch et al PODS’04] First order temporal

properties (FO-LTL)Verification is in PSPACE

for a restricted model (input-bounded 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

June 17, 2004SIGMOD'04 115* Second operator, excise, not discussed here

CTR: Analysis of a Natural Fragment[Davulcu et al PODS’98] Focus on:

“concurrent Horn goal” – define acyclic workflow 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]

andor

a

cd

e fg

b

June 17, 2004SIGMOD'04 116

Verifying Protocol Compliance inProtocols and Commitments model[Venkatraman, Singh ’99]

Recall: Bid-pricei( Buyerj ) can be interpreted asC ( 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 commitmentsAssume 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

June 17, 2004SIGMOD'04 117

Outline




June 17, 2004SIGMOD'04 118

Web Services: The Big Questions

Simplify and/or automate web service Discovery

What properties should be described?How to efficiently query against them?

CompositionSpecifying goals of a compositionSpecifying constraints on a

compositionBuilding a composition Analysis of compositions

InvocationKeeping enactments separatedProviding transactional guarantees

MonitoringHow to track enactmentsRecovering from failed enactments

Primary focusof this tutorial

June 17, 2004SIGMOD'04 119

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 monitoringCan use queries to do data mining on execution logs

TransactionsProviding transactional guarantees remains largely openWhat 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

tools for design of composite web services -- presented version (june 17, 2004) --...

Documents

standards bodies

info sharingowls

compositionspecifying

playing fieldkey standards

automated compositionanalysis

discoveryroman model

big questionssimplify

key elementshttp