Transcript Database languages

Automated Composition and Analysis
Automated Composition
 Given
a specification of the composite service,
 find individual services and their integration, or
 design the individual services
 Workflow
 Specified as tree or pre- and post-conditions
 Distributed system synthesis
 Web services:
 Activity based FSA
 Conversation protocols
 Golog
Web Services: Design and Analysis
2
Composition in Roman Model
 Deterministic
FSA with activities
p1
a
r
p2
b
r
 Composition?
= product machine
 Composed
service can be represented by FSA
Web Services: Design and Analysis
3
Automated Composition in Roman Model
 Given
:
 a set of FSAs C — existing services
 a single FSA M — desired service
 Can we compose M from C ?
a
a
b
r
M
r
C1
b
r
C2
 All
machines start from initial states
 Each move in M is mapped to a move in one or
more machines in C
 All machines end in final states
Web Services: Design and Analysis
4
Delegator
 Given
M and C, a delegator is a mapping D such that
for each word w accepted by M, D(w) is “accepted” by
C
a
a
b
b
r
r
r
M
C1
C2
a r a r b r a r
C1 C1 C1 C1 C2 C2 C1 C1
Web Services: Design and Analysis
5
Delegators and Mealy Machines
A
a
a
b
b
r
r
r
M
C1
C2
delegator for M
r : C1
r : C2
Web Services: Design and Analysis
6
Another Example
t
t
t
c
s
c
s
M
C3
C4
 Can
we still delegate?
 t c t s t s t c
 Delegator:
c : C3
t:
s : C4
Web Services: Design and Analysis
7
Composition FSA
a set of FSAs C1, ..., Cn, we construct the
composition FSA Comp(C1, ..., Cn)
 Given
 An
FSA M can be composed from C if and only if
L(M)  L(Comp(C1, ..., Cn))
Web Services: Design and Analysis
8
Constructing the Product Machine
are tuples of form (p1, p2, …, pn )
 pi are states of Ci
 States
p1, p2, …, pn
a:S
q1, q2, …, qn
 Transitions
are assumed delegations
 Activity a is delegated to S
 For each Ci in S: di (pi, a) = qi
 For each Ci not in S: pi = qi
Web Services: Design and Analysis
9
Example of Composition FSA
a
C1
b
C2
1
2
1
r
2
r
1,1
1,2
2,1
2,2
Web Services: Design and Analysis
M
a
b
r
10
Another Example of Composition FSA
C4
t
C3
1
c
2
t
1
s
1,1
1,2
2,1
2,2
Web Services: Design and Analysis
M
2
t
c
s
11
Conversation Realizability
authorize
store
warehouse1
ok
bank
warehouse2
 Target
conversations:
a k shuff ((o1(shuff (r1, b1p1))*, (o2(shuff (r2, b2p2))*)
 Are there Mealy peers whose conversation language is
exactly as specified?
Web Services: Design and Analysis
12
Not Every Regular Language is Realizable
p4
c
p1
a
d
e
b
p2
p3
Very simple language { abcde }
 When can a regular language be realizable?
 Sufficient conditions

Web Services: Design and Analysis
13
A Sufficient Condition
is a regular language of a Mealy machine A
 A1, ..., An are projections of A to peer1, …, peern
whose corresponding languages are L1, ..., Ln
 Part 1: Lossless join
JOIN(p1(L1), ..., pn(Ln)) = L
L
p4
c
p1
a
d
e
b
p2
p3
Web Services: Design and Analysis
14
A Sufficient Condition: Part 2
is a regular language of a Mealy machine A
 A1, ..., An are projections of A to peer1, …, peern
whose corresponding languages are L1, ..., Ln
 Queues are optional: construct a product machine from
determined versions of A1, ..., An in which every
message sent is ready to be read immediately
L
p4
c
p1
d
e
a
b
p2
a
b
c
c
b
d
e
p3
Web Services: Design and Analysis
15
A Sufficient Condition: Part 3
is a regular language of a Mealy machine A
 A1, ..., An are projections of A to peer1, …, peern
whose corresponding languages are L1, ..., Ln
 Ai’s are autonomous: can only do only sends, only
receive, or terminate
L
pc
c
pa
a
b
a
b
a
b
c
pb
Web Services: Design and Analysis
16
Analyzing Web Services
 Particularly
important:
 Dynamic composition
 Hard to test/debug
 Service oriented development is more prone to
bugs(?)
 Types of properties:
 Execution (deadlock, live lock)
 Conditions related to the world
Web Services: Design and Analysis
17
From BPEL to FSA
 BPEL
control structure can be translated into FSAs
Web Services: Design and Analysis
18
BPEL to Automata
 Each
atomic BPEL activity  an automaton
 single entry, single exit
<assign …
<from = “yes” />
<to var = “aprvInfo”
part = “accept” />
<receive …
operation = “approve”
variable = “request” />
Web Services: Design and Analysis
 [request/accept := “yes”]
 [request :=
approve_Out]
? approve_Out
19
BPEL to Automata

Each atomic BPEL activity  an automaton
 single entry, single exit, and may have several
exception exits
<invoke operation=“approve”,
invar="request“,
outvar=“aprvInfo” >
<catch faultname=“loanfault“>
< ... handler1 ... />
</catch>
</invoke>
Web Services: Design and Analysis
[approve_In := request]
! approve_In
loanfaul
? loanfault t
? approve_Out

handler1
[aprvInfo :=
approve_Out]
20
BPEL to Automata

Control flow constructs: assembling automata
<sequence …/>
<… act1…/>
<… act2…/>
</sequence …/>
fault2
fault1
act1
Web Services: Design and Analysis

act2
21
BPEL to Automata
<flow …/>
<… act1 …>
<source linkname = “link1” condition = “cond1 …/>
</act1 >
<… act2 … >
<target linkname = “link1” />
</act2 >
</flow …/>
act1
 [b_link1 := cond1 ]
product
Web Services: Design and Analysis
 [b_link1]
act2
22
Linear Temporal Logic (LTL)
A
set of atomic propositions: p, q, r, …
 Logical connectives: , , 
 Temporal operators: X G U F
 Xj : j is true in the next state
 Gj : j is true in every state
 fUj : f is true in every state before the state j is
true
 Fj : j is true in some future state
G ( order  F (Cancel  Receipt))
G ( Payment.amount=a  X (Receipt.ammount=a))
Web Services: Design and Analysis
23
Semantics of LTL
A
state is a set of propositions
 A sequence of states w=w0w1w2… satisfies an LTL
formula:
 w |= p if w0 |= p or p  w0
 w |= j if w |= j
 w |= jy if w |= j and w |= y
 w |= X j if w1w2… |= j
 w |= G j if for each i, wiwi+1… |= j
 w |= F j if for some i, wiwi+1… |= j
 w |= y U j if for some i, wiwi+1… |= j and
for each j<i, wjwj+1… |= y
Web Services: Design and Analysis
24
Example: Traffic Light Controller
S
E
N
 Guarantee
no collisions
 Guarantee eventual service
Web Services: Design and Analysis
25
Controller Program
Module
main(N_SENSE, S_SENSE, E_SENSE, N_GO, S_GO, E_GO);
input N_SENSE, S_SENSE, E_SENSE;
output N_GO, S_GO, E_GO;
reg NS_LOCK, EW_LOCK, N_REQ, S_REQ, E_REQ;
/* set request bits when sense is high */
always begin if (!N_REQ & N_SENSE) N_REQ = 1; end
always begin if (!S_REQ & S_SENSE) S_REQ = 1; end
always begin if (!E_REQ & E_SENSE) E_REQ = 1; end
Web Services: Design and Analysis
26
Controller for North Light
always begin
if (N_REQ)
begin
wait (!EW_LOCK);
NS_LOCK = 1; N_GO = 1;
wait (!N_SENSE);
if (!S_GO) NS_LOCK = 0;
N_GO = 0; N_REQ = 0;
end
end
 South
light is similar
Web Services: Design and Analysis
27
Controller for East Light
always begin
if (E_REQ)
begin
EW_LOCK = 1;
wait (!NS_LOCK);
E_GO = 1;
wait (!E_SENSE);
EW_LOCK = 0; E_GO = 0; E_REQ = 0;
end
end
Web Services: Design and Analysis
28
Specifications in LTL
 Safety
(no collisions)
G  (E_GO  (N_GO  S_GO))
 Liveness
G ( N_GO  N_SENSE  F N_GO)
G ( S_GO  S_SENSE  F S_GO)
G ( E_GO  E_SENSE  F E_GO)
 Fairness constraints
GF  (N_GO  N_SENSE)
GF  (S_GO  S_SENSE)
GF  (E_GO  E_SENSE)
Web Services: Design and Analysis
29
Counterexample
 East
and North lights on at same time...
E_Go
E_Req
E_Sense
NS_Lock
N_Go
N_Req
N_Sense
S_Go
S_Req
S_Sense
Web Services: Design and Analysis
30
Model Checking (Clarke and Emerson)
G(p  F q)
yes
 temporal
MC
no
p
q
Web Services: Design and Analysis
p
q
 input:
logic spec
 finite-state model
 output
 yes
 no + counterexample
31
Verifying Web Service Properties
 Finite
state modeling checking:
 Approximate FSA states with propositions
 Approximate values in finite domain with propositions
 Approximate queues by finite length queues (i.e., FSAs)
Web Services: Design and Analysis
32
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 [ISSTA’04]
 (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

Web Services: Design and Analysis
33
Verification Experience

Handling of XPath helps find intricate bugs!
 Stock Analysis Service [ISSTA’04]
Investor
Broker
regList of stockIDs
Research
Dept.

1 stockID
per request
Find stockID in last
Request;
If last ID in regList
exit;
Else
send its subsequent
stockID;
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
Web Services: Design and Analysis
34
Web Service Analysis Tool (WSAT)
Complete
verification
Guarded
Automata
BPEL2GA
Interacting BPEL
Web Services
Sync.
Analysis
Back End
LTL
Goals
Front End
WS-CHOREGRAPHY,
OWL-S
SPIN
Symbolic
Verification
Partial
verification
SPIN
• Guarded Automata allows flexible
architecture
Web Services: Design and Analysis
35
OWL-S to Petri-Net
 OWL-S
atomic processes:
 Pre- and post-conditions
 Each atomic process is translated to a Petri Net:
Web Services: Design and Analysis
36
OWL-S to Petri Net
 Control
structures “glue” pieces together
Web Services: Design and Analysis
37
Choice
Web Services: Design and Analysis
38
If-Then-Else
Web Services: Design and Analysis
39
Loops
Web Services: Design and Analysis
40
Petri Net based Verification
 Reachability
 Safety:
“unsafe” states are not reachable
 Deadlock
 Results:
 DAML-S
(0.5) is 1-safe (each place is marked 1 or
less)
 Reachability is PSPACE-complete
Web Services: Design and Analysis
41