Automated Composition and Analysis

1
Automated Composition and Analysis
2
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

3
Composition in Roman Model

• Deterministic FSA with activities
• Composition?
• product machine
• Composed service can be represented by FSA

p2
p1
b
a
r
r
4
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 ?
• All machines start from initial states
• Each move in M is mapped to a move in one ormore
  machines in C
• All machines end in final states

b
a
a
b
r
r
r
M
C1
C2
5
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

b
a
a
b
r
r
r
M
C1
C2
a r a r b r a r
C1 C1 C1 C1 C2 C2 C1 C1
6
Delegators and Mealy Machines
b
a
a
b
r
r
r
C1
M
C2

• A delegator for M

r C1
a C1
b C2
r C2
7
Another Example
t
t
t
c
s
s
c
C3
M
C4

• Can we still delegate?
• t c t s t s t c
• Delegator

c C3
e C3
c C3
If tc then t C3
t
If ts then t C4
s C4
e C4
s C4
8
Composition FSA

• Given a set of FSAs C1, ..., Cn, we construct the
  composition FSA Comp(C1, ..., Cn)
• An FSA M can be composed from C if and only
  ifL(M) ? L(Comp(C1, ..., Cn))

9
Constructing the Product Machine

• States are tuples of form (p1, p2, , pn )
• pi are states of Ci
• 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

a S
p1, p2, , pn
q1, q2, , qn
10
Example of Composition FSA
a
b
a
C2
C1
M
b
1
2
1
2
r
r
r
1,1
1,2
2,2
2,1
11
Another Example of Composition FSA
t
t
C4
C3
M
t
c
1
2
1
2
s
c
s
1,1
1,2
2,2
2,1
12
Conversation Realizability
authorize
bank
store
ok
order1
bill2
receipt1
payment1
payment2
order2
receipt2
bill1
ware- house1
ware- house2

• Target conversations
• a k shuff ((o1(shuff (r1, b1p1)), (o2(shuff (r2,
  b2p2)))
• Are there Mealy peers whose conversation language
  is exactly as specified?

13
Not Every Regular Language is Realizable
a
c
p1
p4
p2
e
d
b
p3

• Very simple language abcde
• When can a regular language be realizable?
• Sufficient conditions

14
A Sufficient Condition

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

a
c
p1
p4
p2
e
d
b
p3
15
A Sufficient Condition Part 2

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

a
c
c
p1
p4
p2
b
a
d
e
c
b
e
d
b
p3
16
A Sufficient Condition Part 3

• L is a regular language of a Mealy machine A
• A1, ..., An are projections of A to peer1, ,
  peern
• whose corresponding languages are L1, ..., Ln
• Ais are autonomous can only do only sends, only
  receive, or terminate

pc
a
c
b
pa
a
c
b
a
b
pb
17
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

18
From BPEL to FSA

• BPEL control structure can be translated into FSAs

19
BPEL to Automata

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

ltassign ltfrom yes /gt ltto var
aprvInfo part accept /gt
? request/accept yes
? request approve_Out
ltreceive operation approve variable
request /gt
? approve_Out
20
BPEL to Automata

• Each atomic BPEL activity ? an automaton
• single entry, single exit, and may have several
  exception exits

ltinvoke operationapprove,
invar"request, outvaraprvInfo
gt ltcatch faultnameloanfaultgt lt ...
handler1 ... /gt lt/catchgt lt/invokegt
21
BPEL to Automata

• Control flow constructs assembling automata

ltsequence /gt lt act1/gt lt act2/gt
lt/sequence /gt
fault2
fault1
act1
act2
?
22
BPEL to Automata
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
23
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.amounta ? X (Receipt.ammounta))

24
Semantics of LTL

• A state is a set of propositions
• A sequence of states ww0w1w2 satisfies an LTL
  formula
• w p if w0 p or p ? w0
• w ?? if w ?
• w ??y if w ? and w y
• w X j if w1w2 ?
• w G j if for each i, wiwi1 ?
• w F j if for some i, wiwi1 ?
• w y U j if for some i, wiwi1 ? and
  for each jlti, wjwj1 y

25
Example Traffic Light Controller
S
E
N

• Guarantee no collisions
• Guarantee eventual service

26
Controller Program

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

27
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

28
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

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

30
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
31
Model Checking (Clarke and Emerson)
G(p ? F q)

• input
• temporal logic spec
• finite-state model
• output
• yes
• no counterexample

yes
MC
no
p
p
q
q
32
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)

33
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

34
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
35
Web Service Analysis Tool (WSAT)
Front End
36
OWL-S to Petri-Net

• OWL-S atomic processes
• Pre- and post-conditions
• Each atomic process is translated to a Petri Net

37
OWL-S to Petri Net

• Control structures glue pieces together

38
Choice
39
If-Then-Else
40
Loops
41
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