Tools for Design of Composite Web Services Presented Version June 17, 2004 http:www'cs'ucsb'edusutut

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

2
Outline

• Introduction and positioning
• Standards
• Models of Web Services and Composition
• Approaches to Automated Composition
• Analysis and Verification
• Future Directions

3
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, . . .

4
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

5
Anatomy of Web Services Composition
Goal(s)
Activities
Orchestration, Monitoring
Info sharing (Messaging)
Discovery/ Self-description

• No unified model, e.g.,
• BPEL Strong on orchestration, info sharing
• OWL-S Strong on goals, activities, discovery
• Roman model Strong on activities, orchestration

6
Key dimensions in web service composition
OWL-S
semantics
CTR-S
Commitment Protocols
?-Calc
WSCL
Mealy
BPML
Complexity of glue language
Roman
CSP
WSDL
Complexity of component services
7
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

8
Goals of this Tutorial Tools for Composition

• Describe the playing field
• Key standards that well 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

9
Outline

• Introduction and positioning
• Standards
• Models of Web Services and Composition
• Approaches to Composition
• Analysis and Verification
• Future Directions

10
Web Services Standards Stack Key Elements
UDDI
Discovery
WS-Choreorgaphy
Choreography
BPEL4WS
OWL-S ServiceModel
Composition
WSCL
(Individual)ServiceDescription
OWL-S ServiceProfice
WSDL
XMLMessaging
SOAP
HTTP, SMTP, FTP, etc.
Network
11
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

Web Server
SOAP Envelope
External Service
Web Service
12
RPC Messages

• Typically two messages

Request Message
SOAPClient
SOAPServer
Response Message
SOAP Envelope

• RPC style SOAP body encodes
• the operation name and parameters
• return result
• XMLified

SOAP Header
SOAP Body
13
An RPC-style SOAP Message
public Float getQuote (String symbol) ltsEnvelop
e xmlnsshttp//www.w3.org/2001/06/soap-envelope
gt ltsHeadergt ltmtransaction
xmlnsmsoap-transaction smustUndersta
ndtruegt lttransactionIDgt1234lt/transactionIDgt
lt/mtransactiongt lt/sHeadergt ltsBodygt ltnget
Quote xmlnsnurnQuoteServicegt ltsymbol
xsitypexsdstringgt IBM lt/symbolgt lt/n
getQuotegt lt/sBodygt lt/sEnvelopegt
BACKUP
14
SOAP Response
ltsEnvelope xmlnsshttp//www.w3.org/2001/06/soap
-envelopegt ltsBodygt ltngetQuoteResponse
xmnlsnurnQuoteServicegt ltvalue
xsitypexsdfloatgt 98.06 lt/valuegt lt/n
getQuoteResponsegt lt/sBodygt lt/sEnvelopegt
BACKUP
15
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

Supports
Operation
Port Type
How to invoke
Input Output
Formats Protocols
How to encode
Message
Binding
Implements
Provides
Port
Service
from Leymann BTW 2003 talk
16
Main Structure of WSDL
ltdefinitions namespace http// gt lttypesgt
XML schema types lt/typegt ltmessagegt definition
of a message lt/messagegt ltportTypegt a set of
operations lt/portTypegt ltbindinggt communication
protocols lt/bindinggt ltservicegt a list of binding
and ports lt/servicegt lt/definitionsgt
BACKUP
17
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_payment out bill in payment
order
order
bill
Supplier
Supplier
receipt
payment
receipt

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

18
Operation Types

• The request-response type is the most common
  operation type, but WSDL defines four types
• One-way The operation can receive a message but
  will not return a response
• Request-response The operation can receive a
  request and will return a response
• Solicit-response The operation can send a
  request and will wait for a response
• Notification The operation can send a message
  but will not wait for a response
• WSDL 1.2 adds requestmultiple responses
• WSDL 2.0 allows additional types

BACKUP
19
WSDL Ports

• The ltportTypegt element is the most important WSDL
  element it defines
• a web service
• the operations that can be performed, and
• the messages that are involved
• The ltportgt defines the connection point to a web
  service, an instance of ltportTypegt
• It can be compared to a function library (or a
  module, or a class) in a traditional programming
  language
• Each operation can be compared to a function in a
  traditional programming language

BACKUP
20
Binding

• Binding defines how message are transmitted, and
  the location of the service
• ltbindinggt element has two attributes
• type the port type
• name name of the binding
• ltsoapbindinggt has two attributes
• style either document or rpc
• transport protocol to use, e.g., http

BACKUP
21
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

22
BPEL in Action
Purchase Order service coordinates other services
using ports in WSDL
Purchase Order portType
Receive Purchase Order
Decide On Shipper
Initiate Production Scheduling
Initiate Price Calculation
Price Calculation portType
Arrange Logistics
Complete Production Scheduling
Complete Price Calculation
Invoice Processing
from BPEL 1.1 standard
23
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

24
BPEL Examples
begin parallel
Initialize
do until flag
Receive Bill1
send Order
end_date reached
pick
receive order
Send Bill
receive Receipt1
case
flag true
Receive Payment
suppl1 order
suppl2 order
send Receipt
Send Payment1
end case
end parallel

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

25
Structure of a BPEL Process

• Web services the process interacts with
• Data used by the process
• Used to support asynchronous interactions
• Alternate execution path to deal with faulty
  conditions
• Code to execute when undoing an action
• What the process actually does

ltprocess ...gt ltpartnersgt ...
lt/partnersgt ltcontainersgt ... lt/containersgt ltco
rrelationSetsgt ...lt/correlationSetsgt ltfaultHandl
ersgt ...lt/faultHandlersgt ltcompensationHandlersgt
...lt/compensationHandlersgt (activities) lt/pro
cessgt
BACKUP
26
BPEL Structured Activities
ltsequencegtexecute activities sequentially ltflowgt
execute activities in parallel ltwhilegtiterate
execution of activities until condition is
violated ltpickgtseveral event activities (receive
message, timer event) scheduled for execution in
parallel first one is selected and corresponding
code executed ltlink ...gtdefines a control
dependency between a source activity and a target
BACKUP
27
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

InvalidPayment
POAccepted
28
Conversation Specification

• lt?xml version1.0 encoding"UTF-8"?gt
• ltConversation namesimpleConversation
• version1.01
• xmlnshttp//www.w3.org/2002/02/wscl10
• initialInteractionStart
• finalInteractionEnd
• descriptionConversation for a Store Front
  Service gt
• ltConversationInteractionsgt
• list of all interactions
• lt/ConversationInteractionsgt
• ltConversationTransitionsgt
• list of all transitions
• lt/ConversationTransitionsgt
• lt/Conversationgt

BACKUP
29
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

30
WS-CDL Example (Incomplete)
ltrole name"Consumer"gtltbehavior
name"consumerForRetailer" interface"cnsConsumer
RetailerPT"/gtltbehavior name"consumerForWarehouse
" interface"cnsConsumerWarehousePT"/gt lt/rolegt
ltrelationship name"ConsumerRetailerRelationshi
p"gtltrole type"tnsConsumer" behavior"consumerFo
rRetailer"/gtltrole type"tnsRetailer"
behavior"retailerForConsumer"/gtlt/relationshipgt
ltchoreography name"ConsumerRetailerChoreo"
root"true"gt ltinteraction channelVariable"tns
retailer-channel " operation"handlePurchaseOr
der" align"true" initiateChoreography"true"gtltpa
rticipate relationship"tnsConsumerRetailerRelati
onship fromRole"tnsConsumer"
toRole"tnsRetailer"/gt ltexchange
messageContentType"tnspurchaseOrderType"
action"request"gt ltuse variable"cdlgetVariable
(tnspurchaseOrder, tnsConsumer)"/gt ltpopulate
variable"cdlgetVariable(tnspurchaseOrder,
tnsRetailer)"/gt lt/exchangegt ltexchange
messageContentType"purchaseOrderAckType"
action"respond"gt ltuse variable"cdlgetVariable
(tnspurchaseOrderAck, tnsRetailer)"/gt ltpopulat
e variable"cdlgetVariable(tnspurchaseOrderAck,
tnsConsumer)"/gt lt/exchangegt lt/interactiongt lt
/choreographygt
BACKUP
31
BPEL meets WS-Choreography

• A scripted composition using
• WSDL messages
• Control 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. p-calculus)

32
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

• input types
• output types
• preconditions
• effects

Resource
ServiceProfile
provides
presents (what it does)
Service
describedby(how it works)
supports(how to access)
ServiceModel
ServiceGrounding

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

• process flow
• composition hierarchy
• process definitions

33
OWL-S Service Profiles

• Input types
• Output types
• Preconditions
• Effects

ServiceProfile
presents (what it does)
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)

34
Functionality Description

• Preconditions
• Set of conditions that should hold prior to
  service invocation
• Inputs
• Set of necessary inputs that the requester should
  provide to invoke the service
• Outputs
• Results that the requester should expect after
  interaction with the service provider is
  completed
• Effects
• Set of statements that should hold true if the
  service is invoked successfully
• Often refer to real-world effects, e.g., Package
  being delivered, or Credit card being debited

BACKUP
35
Non Functional Properties

• Provides supporting information about the service

BACKUP
36
Profile Hierarchy

• Sub-classing the Profile model facilitates the
  creation and specialisation of service categories
• Each subclass can
• Introduce new properties
• Place restrictions on existing properties
• Sub-classing can also be used to specialise
  requests for service
• An example Profile Hierarchy is provided, but
  others could just as easily be defined

BACKUP
37
OWL-S Service Model
38
OWL-S Process Model
Service

• Constructs for composite processes
• Sequence
• Concurrency Split SplitJoin Unordered
• Choice
• 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

describedby(how it works)
ServiceModel

• process flow
• composition hierarchy
• process definitions

39
OWL-S Process Ontology

• Atomic processes directly invokable, no
  subprocesses, executed in a single step
• Composite processes consist of other
  (non-composite or composite) processes
• Simple processes a virtual view of atomic
  process or composite process (as a black box)

BACKUP
40
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 tModels for WSDL descriptions of a
  service, for ebXML,
• When a service registers with UDDI, the technical
  fingerprint includes listing of tModels that it
  uses
• tModels 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

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

• Introduction and positioning
• Standards
• Models of Web Services and Composition
• Approaches to Automated Composition
• Analysis and Verification
• Future Directions

43
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

44
First Impressions Topology

• Two common approaches

• Peer-to-peer

• Mediated, or hub and spoke

45
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

46
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

47
Models we describe here
Emphasize Individual service
Emphasize Composite service
Style
Model
48
Mealy Service Model Bultan et al WWW03

• 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
!b2
!b2
authorize
bank
store
!r2
ok
?p2
?p2
!r2
order1
receipt1
bill2
payment2
payment1
e
order2
bill1
receipt2
ware- house1
ware- house2
warehouse2
49
Asynchronous Communication With Queue

• Asynchronous, for example, the following channel

ware- house1
store
order1
send Order1

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

send Order1 receive Receipt1
50
Executing a Mealy Composition
?o2
!r2
?a
!a
!b2
!b2
?o1
!k
?k
!r2
!o1
?p2
?p2
!o2
!r2



e

warehouse2
bank
store
w1

• Execution halts if
• All mealy peers are in final states
• All queues are empty

BACKUP
51
Conversations (an abstraction of enactments)

• Watcher records the messages as they are sent

authorize
ok
payment1
payment2
order2
receipt1
order1
bill2
a
k
o1
b1
o2
p1
r1
r2
b2
p2
bill1
receipt2

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

52
Example of Specifying A Conversation Protocol
authorize
bank
store
ok
order1
bill2
receipt1
payment1
payment2
order2
receipt2
bill1
ware- house1
ware- house2

• The conversation language allowed

a k shuffle ( ( o1(shuffle ( r1, b1p1) ) , (
o2(shuffle ( r2, b2p2) ) )
BACKUP
53
Conversation Languages Are Not Regular
?a
a
!a
?b
b
!b
p1
p2

• CL ?? ab 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

54
Summary of Results on Mealy Compositions

• CLs of some Mealy compositions are not
  regular,some not context free
• The prepone and join closure of every regular
  language CL of some composite Mealy web
  services
• The converse of 2. is not true in general, true
  in special cases

• However if bounded queue or synchronous
• CL of every Mealy composition is regular
• Design time decision! Need to be explicit in
  specifications (BPEL, BPML, )

BACKUP
55
Roman model An automata-based models with
activities Berardi et. al. ICSOC 03
Online Music Store

• Model of human-machine web services
  (e.g., Amazon)
• Focus on activities

• Abstract behavior of the Service Client
  selects next activity

Client

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

on-line music store
Service
56
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

57
Roman model Composition
Delegator Activity-based FSM annotated with
delegations
Delegator for music store
search
Web
???
???
listen
cart
Juke
search
init
Web
Web
Web
cart
buy
Web
Bank
search
search
Web
Web
Web store
Juke
Bank
search
cart
init
listen
buy
search
58
Data Driven Web Service Deutsch et al PODS04

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

database
Effects(updatable)
Read only
59
An Abstract Perspective Rule-based Control

• A hybrid combining automata and logic

Condition basedon database query
Updates tothe database
A complex service
If y then run S
If y1 then run S1
database
S
If yn then run Sn
Effects(updatable)
E
E
Read only
60
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

61
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
w1
w2
w1
d1
w2
d1
d2
w1
transfer(100, buyer, seller)
w2
d1
d2
w2
d1
d2
w1
d2
d2
d2
d1
d1
d2
d1
Combinations of those transfers
transfer(5, buyer, broker)

• Can add constraints, e.g., that w1 must precede
  w2
• Can use FOL inference or domain-specific
  reasoning

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

63
(Some) sentences characterizing financial example
? x activity( buy_products(x) ) ?? x,y,z
activity( transfer(x,y,z) ) ?? x,y activity(
withdraw(x,y) ) ?? x,y activity( deposit(x,y) )

• Activities as terms

• Composition relationships

? a,y ( a buy_product(y) ? ? x,z subactivity(
transfer(x,y,z) , a ) ) ?? x,y,z subactivity(
withdraw(x,y), transfer(x,y,z) ) ?? x,y,z
subactivity( deposit(x,z) ), transfer(x,y,z) )

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

• Can represent
• Other composite activities
• Pre-conditions (e.g., transfers only if
  sufficient funds)
• Effects (e.g., of a transfer)

BACKUP
64
PSL Layers of Ontology and Axioms

• Base layer has only activities, occurrences,
  ordered time
• Additional layers build out, e.g., composite
  activity, duration, legal, possible,
• Axioms included for each layer

BACKUP
Gruninger 03
65
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 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

66
Examples of Golog expressions

• Golog program fragments

while ?x(hotel(x) ? goodLoc(x)) do
checkAvailability(x, dest, dDate, rDate) endwhile

• Personalization constraints

If ? hotelAvailable(dest,dDate,rDate) then
bookBB(cust, dest, dDate, rDate)

• Procedure definition

proc Travel( cust, origin, dest, dDate, rDate,
purpose) if registrationRequired then
Register BookTransport(cust, origin, dest,
dDate, rDate) BookAccommodations(cust, dest,
dDate, rDate) UpdateExpenseClaim(cust)
Inform(cust) endproc
BACKUP
67
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
  WWW04
• Targeted at negotiation (once services are
  discovered)
• One more connective, specific to adversarial
  peer services

68
CTR Constructs (which are constraints)

• A simple workflow

Temporal constraint
b
if e is executed, then b must occur before f
cond1
a
g
and
cond2
d
Trigger
or
cond3
c
if e is executed and cond4 , then do h
f
e
a ? ( b ( c ? ( d ? ( e ? f ))) ) ? g

• (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 ?

69
CTR Model Theory and Horn fragment

• Updates against shared external world
• Simple example can use standard relational db
  updates
• Complex 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 fragment
• Bottom_part ? ( c ? ( d ? ( e ? f )))
• Workflow ? a ? ( b Bottom_part ) ? g
• There is a proof theory and inference algorithm
  for Horn fragment

b
70
CTR-Services

• New construct ? ? ? -- opponents choice
• Intuition The external world will choose one of
  ? or ?
• 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

71
A constraint-based approach based on Protocols
and CommitmentsVenkatraman, 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

72
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

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

74
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
  p-calculus)
• Reasoning, optimization of processes
• Analysis tools

• 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

75
Web Service Composition vs. Workflow Management

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

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

BACKUP
76
Composition Models and Standards
Mealy Model
WS-Choreography
WSCL
BPEL4WS
Rich on messages
Commitments
Golog
Data-Driven
CTR-S
PSL/Situation Calculi
OWL-S
WSDL
Roman
Rich on activities
if interpreted as a composition model
77
Outline

• Introduction and positioning
• Standards
• Models of Web Services and Composition
• Approaches to Automated Composition
• Analysis and Verification
• Future Directions

78
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

79
Roman Model Composition via delegators
Desired Service
80
Example delegator
Delegator Activity-based FSM annotated with
delegations
???
81
Results on Roman Composition

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

• 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

82
Second example of Roman Delegator

• Delegator is not simply a labeling of desired
  service

book_train
book_accom_shuttle
book_airtravel
book_plane
book_ accomodation
book_hotel
book_ accom_shuttle
book_hotel
book_limo
book_plane
book_limo
book_plane
register_event
book_residence
book_hotel
book_train
Desired re-usable service
book_accom_shuttle
list_nearby_facilities
book_hotel
book_limo
book_train
book_ traintravel
book_accom_shuttle
book_hotel
book_plane
register_event
book_limo
register_ event
book_accom_shuttle
book_plane
book_ limo
book_limo
book_train
book_hotel
register_event
book_limo
BACKUP
book_ train
UDDI
Delegator (color indicates which FSA performs
action)
83
Conversation Realizability in Mealy model
authorize
bank
store
ok
bill2
payment2
order1
receipt1
payment1
order2
bill1
receipt2
ware- house1
ware- house2

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

84
A Quick AnswerSome Regular Languages are not
Realizable
a
c
p1
p4
p2
e
d
b
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

85
Local View and Join
a
c
p1
p4
p2
e
d
b
p3

• Local view of a peer ppeer(L) the part of
  conversation the peer participates (receives or
  sends)
• Given languages Li over Si, ? ? i ? n
• Mealy conversation languages Lare closed under
  projection-join

86
Delaying Send and Prepone

• If the global watcher sees w

b
a




a
b

!a
!b
local view at p
a peer p
pp(w) should also allow
a
b


87
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
• Queues are optional construct a product machine
  from determined versions of A1, ..., An in which
  every message sent is ready to be read
  immediately
• 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

88
Alternative Realizing the Closure

• Given a regular language L, we can always find a
  Mealy composition whose CL is the closure

• Intuitively given a regular L (e.g., ako1), we
  can find Mealy peers whose conversations are not
  arbitrary
• But some Mealy compositions do not relate to any
  regular languages in this way

BACKUP
89
The Converse Fails for the General Case

• There is an Mealy compositions whose CL is
  notfor every regular languages L
• Example

p1
p3
?b
!b
b
?c
!a
p2
a
c
?a
CL aibci i ?0 Closed under Join and
Prepone
!c
BACKUP
90
The Converse Holds for The Tree Case

• When the schema graph is a tree, then the Mealy
  composition has a composition language equal
  tofor some regular languages L
• Intuitively the global behavior of bottom-up
  composition is still predictable if the
  composition infrastructure is a tree
• In particular, adding an mediator (hub-spoke)
  isnt a bad idea!

BACKUP
91
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 interpreter
• Based on Quintas Prolog
• Can search for branches that satisfy a Golog
  program (and additional constraints)

92
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

93
Automatic Composition via Petri nets

• NarayananMcIlraith 02 Search over all
  combinations
• Recall simulation of OWL-S via 1-safe Petri nets
• For set of atomic e-services, create Petri Net
  that represents all possible (single-use)
  combinations of them
• Specify desired goal as a state of this Petri Net
• Determine if this goal state is reachable
• In this framework reachability is PSPACE-complete
  in size of Petri net
• Petri net itself may be exponential in size of
  atomic e-services
• Heuristics can be used to avoid full construction

BACKUP
94
Outline

• Introduction and positioning
• Standards
• Models of Web Services and Composition
• Approaches to Composition
• Analysis and Verification
• Future Directions

95
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

96
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

97
Approaches Examined

• Model checking
• With finite state machines Fu et al WWW04
  Foster et al ASE03
• With process algebra Koshikina-van Breugel 2003
• OWL-S services analysis with Petri
  nets Narayanan-McIlraith WWW02
• Rule-based services Deutsch et al PODS04
• Analysis of a Natural Fragment of CTR Davulcu
  et al PODS98
• Dynamic verification of protocol compliance
  incommitments Venkatraman and Singh 99

98
Explicit Model Checking

• Transition system R and initial states I ?
  automaton MR
• Property P ? ?P ? automaton M?P
• Question MR ? M?P ? ?

BACKUP
99
Symbolic Model Checking Forward Fixpoint

• Initial states I, Transition relation R, Property
  P
• Question F ? P ?

I
post(I)

union
fixpoint F
BACKUP
100
Symbolic Model Checking Backward Fixpoint

• Initial states I, Transition relation R, Property
  P
• Question B ? I ? ?

pre(?P)
?P

union
fixpoint B
BACKUP
101
Web Services Verification

• Model execution as finite state machinesFoster
  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 data
• Translated to Promela (input language of SPIN)

authorize
store
bank
ok
conversation
payment1
payment2
p1
o2
a
o1
b1
k
order2
receipt1
r1
r2
b2
p2
order1
bill2
bill1
LTL properties Every authorize followed by some
bill?
receipt2
ware-house1
ware-house2
102
BPEL to Guarded Automata Fu et al WWW 04

• Each atomic activity ? an automaton with single
  entry, single exit

? request approve_Out
ltreceive operation approve variable
request /gt
? approve_Out
ltinvoke operationapprove,
invar"request, outvaraprvInfo
gt ltcatch faultnameloanfaultgt lt ...
handler1 ... /gt lt/catchgt lt/invokegt
103
BPEL to Guarded Automata

• Control flow constructs assemble Mealy machines

ltsequence /gt lt act1/gt lt act2/gt
lt/sequence /gt
act1
act2
?
ltflow /gt lt act1 gt ltsource linkname
link1 condition cond1 /gt lt/act1
gt lt act2 gt lttarget linkname link1
/gt lt/act2 gt lt/flow /gt
104
Partial and Complete Verification (with SPIN)
authorize
store
bank
ok
payment1
conversation
payment2
order2
receipt1
order1
bill2
a
k
o1
b1
o2
p1
r1
r2
b2
p2
bill1
receipt2
ware- house2
ware- house1
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

105
Synchronizability Analysis Results
BACKUP
106
Automata ? Promela

• Translate to Promela (input lang. of SPIN)
• 1 web service composition ? 1 Promela
  specification
• 1 Guarded Automaton ? 1 Promela Process
• Each Promela process has one Channel
• Channel are bounded!
• Challenge handling XML Data ISSTA04
• (bounded) XML Schema Type ? Type system in
  Promela
• Symbolic emulation of XPath expression
• Special handling of position() and last()
  functions
• Map each function to an integer variable

BACKUP
107
Verification Experience

• Handling of XPath helps find intricate bugs!
• Stock Analysis Service ISSTA04
• Experience with other examples
• Exhaustive search takes a lot of time
• Performance satisfactory when finding errors
• SPIN does not scale well with data domains
• Use of Symbolic Verification may help

Investor
Broker
Find stockID in last Request If last ID in
regList exit Else send its
subsequent stockID
BACKUP
108
Web Service Analysis Tool (WSAT)
WS-Choreography, OWL-S
Complete verification
SPIN
Back End
Front End
Partial verification
Sync. Analysis
InteractingBPELWeb Services
SPIN
LTL properties
other verification tools
Fu et al WWW04, ISSTA04, CAV04
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
  CAV96
• 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

110
Verification of OWL-S services

• Narayanan-McIlraith WWW02 Analyzing and
  automated composition of OWL-S
• Analysis Does an OWL-S service satisfy some
  property?
• 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)

An OWL-S service S
y ?
. . . . . . .
situation calculus(propositional)
111
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

112
OWL-S to Petri Net

• Control structures glue pieces together

113
If-Then-Else and Loops
BACKUP
114
Verification of Rule Based ServiceDeutsch et al
PODS04
Home page(HP)

• 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 PODS01
• Verification of CTL properties
• Decidable for the propositional case

Name passwd
login
cancel
Customer page(CP)
Error message page(MP)
Desktop My order laptop
back
Desktop Search(SP)
laptop Search(SP)
Desktop search Ram Hdd
Desktop search Ram Hdd Display
Past Order (POP)
Past Order
search
search
Product index page(PIP)
Order status(OSP)
Order status
Matching products
Cancel confirmation page(CCP)
Product detail page(PP)
Product detail
buy
Confirmation page(CoP)
Order detail
115
CTR Analysis of a Natural FragmentDavulcu et
al PODS98

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

Second operator, excise, not discussed here
116
Verifying Protocol Compliance inProtocols and
Commitments modelVenkatraman, 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

117
Outline

• Introduction and positioning
• Standards
• Models of Web Services and Composition
• Approaches to Automated Composition
• Analysis and Verification
• Future Directions

118
Web Services The Big Questions

• Simplify and/or automate web service
• Discovery
• What properties should be described?
• How to efficiently query against them?
• Composition