Overview of Web Service Models and Frameworks

1
Overview of Web Service Models and Frameworks
2
Web Services

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

3
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

4
E-Commerce
buy
bank
store
get
supplier1

• 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

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

• Emerging standards will enable
• Flexible, dynamic incorporation of features
• Convergence of telecom and web services
• Bearer traffic vs. signaling/control traffic

6
E-Science
Controller
control and calibrations
Sea Circulation
Atmospheric Simulation
Waste Transport
notifications and/or experimental data

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

7
Web Services Goals

• 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

8
The Web Services Paradigm

• Primary roots of web services paradigm
• Process description formalisms
• Distributed computing middleware
• 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

9
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
10
Web Service Standards Stack Fu-Bultan-Su CIAA
03
BPEL, DAML-S, WSCI
Behavior
WSDL
Interface
SOAP
Sun J2EE
Microsoft .Net
IBM WebSphere
Message
XML Schema
Type
XML
Data
Implementation Platforms
Web Service Standards
11
Web Service Standards Stack Turner-Budgen-Brereto
n CACM 03
12
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
13
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
14
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
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
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

17
Business Process Execution Language (BPEL)

• Allow specification of compositions of Web
  services
• business processes as coordinated interactions of
  Web services
• Allow abstract and executable processes
• Influences from
• Traditional flow models
• Structured programming
• Successor of WSFL and XLANG
• Assumes WSDL ports
• Standardization through OASIS

18
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
19
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

20
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

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

23
BPEL versus 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)

24
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

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

26
OWL-S Focuses on Knowledge
order
bill
Supplier

• Conditions on input/output
• if valid client sends order,then bill is created
• if payment is received, then receipt is sent
• Conditions on state of world
• Amount of in line of credit
• Supplier ships order when payment is received
• Performing inference (everything else fixed)
• Assume 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

payment
receipt
27
OWL-S Service Model
28
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

29
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

30
OWL-S Profile Ontology is Analogous to the
Concept of UDDI Taxonomy
31
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

32
First Impressions Topology

• Two common approaches

• Peer-to-peer

• Mediated, or hub and spoke

33
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

34
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

35
Models we describe here
Emphasize Individual service
Emphasize Composite service
Style
Model
36
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
37
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
38
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?

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

41
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
42
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

43
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
44
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
45
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
46
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

47
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

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

49
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

50
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

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

52
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
53
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

54
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

55
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

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

57
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

58
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
59
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

60
Roman Model Composition via delegators
Desired Service
61
Example delegator
Delegator Activity-based FSM annotated with
delegations
???
62
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

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

64
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

65
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

66
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


67
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

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

69
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

70
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

71
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

72
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

73
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

74
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
75
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
76
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
77
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

78
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
79
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

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

82
OWL-S to Petri Net

• Control structures glue pieces together

83
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
84
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
85
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

86
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

87
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