USTH,

ICT Department
Hanoi, November 6th, 2012

Meriem Ouederni

Associate Professor IRIT - UMR 5505

PhD Student Europen PhD Univ. Malaga INRIA-Rhone Alpes Univ. Californie

Assis. Prof. Univ. Nantes

Assoc. Prof. N7-IRIT

VLab

Hmm! Sounds as SOC?

How enWWes interact in your design? (A)synchronously?

But, which approach you consider to design your system (boRom-up/top-down)?

Man! A good design needs to be veried formally!

All I have to do is to search for the 3 answers .

 Interoperability of Behavioural Interfaces

- Boolean VericaWon using RewriWng Logic - Numerical QuanWcaWon using Metrics

PhD Thesis October 2008-October 2011 CollaboraDon with Francisco DURAN (2009-2010) CollaboraDon with VASY/INRIA 2010-

AdaptaWon and EvoluWon of Behavioural Interfaces

Analysing InteracWons of Asynchronously CommunicaWng SoZware Systems

- Synchronizability of Asynchronous Systems - Realizability of Global CommunicaWon Contracts - Realizability Enforcement => Process algebra-based vericaWon
CollaboraDon with Univ. California 2010- CollaboraDon with VASY/INRIA 4 2011-

 InternaDonal stays: 2010- : Many stays at INRIA Grenoble (VASY, Hubert Garavel and Radu Mateescu) 2011: Winter quarter at Univ. of California (Tevk Bultan and Samik Basu) Seminars: Univ. Malaga (Spain), VTSA (Luxembourg), INRIA (France), Ecole des Mines (France), LINA (France), IRIT (France), USTH (Vietnam) OrganisaDon of internaWonal events and revision of several conference and journal papers (COORDINATION, TASE, ICWS, SAC, JSS, SOCA, TSC, etc.) 13 internaDonal publicaDons: 8 Conferences (POPL, ATVA, ICSE, SAC, etc.), 2 Journals (SCP, IST), 2 Workshops (FOCLASA, WCSI), 1 Technical Report ParDcipaDon in 5 internaDonal and Spanish Research Projects Current CollaboraDons: Gwen Salaun (INRIA), Ernesto Pimentel (Spain), Tevk Bultan (California) 5

1. Interoperability of Behavioural Interfaces a) Service CompaWbility b) RewriWng Logic-based VericaWon c) QuanWfying the CompaWbility of Service Interfaces 2. Asynchronously CommunicaWng SoZware Systems 3. Research Challenges
6

 Services full basic requirements, and can be composed (reused) with each other to work out complex tasks Services must be equipped with public and rich interfaces, enabling external access to their funcWonality Service interfaces disWnguish several interoperability levels: signature, behaviour, QoS, and semanWcs Our model of service interface includes signatures (operaWon names and types) and behaviours (interacWon protocols-Symbolic TransiWon Systems)
Signature login: string * string request: string -> string STS login!(usr,pwd) request!(it1) tau tau

request?(it2)

- Direct composiWon of distributed services cannot oZen be achieved - Service interfaces may present several mismatches, eg. deadlocks - Service incompaWbility forbids the successful communicaWon and the built system cannot meet its requirements

request!(it1)

ComposiDon directe
tau

Signature login: string * string request: string -> string

login!(usr,pwd)

tau

CompaDble? AdaptaDon ou correcDon

request?(it2)

+ We dene the compaWbility of n (n 2) interacWng services + We disWnguish two classes of compaWbility noWons: bidirecWonal and unidirecWonal compaWbility + We implement those noWons into generic frameworks, which can be extended with new noWons
8

1. Interoperability of Behavioural Interfaces a) Service CompaWbility b) RewriDng Logic-based VericaDon c) QuanWfying the CompaWbility of Service Interfaces 2. Asynchronously CommunicaWng SoZware Systems 3. Research Challenges
9

Joint work with Gwen Salaun (INRIA France) and Ernesto Pimentel (UMA, Spain)

We compute a Boolean result for n interacWon protocols InteracWon protocols are explored and checked on-the-y We propose rewriWng logic-based generic framework Service composiWon can be easily checked
Service Interfaces WSDL+ Abstract BPEL WSDL+ Windows Workflow (WF) Annotated Java Interfaces . . .

Behavioural Models (STSs) (1) Behavioural Model Extraction (2) STS2Maude

Compatibility Notions

Exchanged messages + Value-passing + Tau acDons N services

Maude Specification

Parameter Strategies

(3) Compatibility Checking

Maude

True|False . + . Counterexample .

SCP journal, 2012 10

Joint work with Francisco Duran (UMA, Spain)

We specied service interfaces in Maude sorts and variables We dened rewriWng rules for: Parallel protocol traversal; Reachability computaWon; Deadlock checking; Checking of messages and parameters binding

ExperimentaWons haves been applied to examples with more than 12 services including hundreds of states and transiWons
11

1. Interoperability of Behavioural Interfaces a) Service CompaWbility b) RewriWng Logic-based VericaWon c) QuanDfying the CompaDbility of Service Interfaces 2. Asynchronously CommunicaWng SoZware Systems 3. Research Challenges
12

Joint work with Gwen Salaun (INRIA France) and Ernesto Pimentel (UMA, Spain) Boolean compaWbility may not be helpful to dierenWate between almost compaWble and totally incompaWble services

[ICSOC10] [SAC11]

+ We measure the compaWbility degree as a number in [0..1] + We propose a Divide-And-Conquer measuring

13

 DeniDon: two states are compaWble if their backward and forward neighbouring states are compaWble Measuring techniques: a compaWbility ooding algorithm and an iteraWve computaWon Result: a matrix COMPkCN,D, a list of mismatches, and a global compaWbility measure

COMP7UR,

14

 The compaWbility ooding ensures that the eect of any detected mismatch must be propagated unWl the iniWal states Two interacWon protocols are compaWble i they are compaWble at there iniWal states Otherwise, the (global) compaWbility degree helps for:
Ranking and selecWng services from a huge number of candidates Simplifying further processing to solve interface mismatches

15

 The implementaWon is generic, modular, and extensible Experiments applied on more than 115, some of them consist of hundreds of states and transiWons Comparator has high precision and recall values Comparator is accessible through a Web applicaWon

Serng form

Result form

16

Joint work with Carlos Canal, Javier Camara (UMA, Spain), and Gwen Salaun (INRIA, France)

SoZware adaptaWon promotes the generaWon of an adaptor using abstract specicaWons called adaptaWon contracts The adaptor acts as orchestrator and resolves the mismatches

[QSIC09] IST Journal, 2012

ACIDE: InteracWve Environment for graphical design of adaptaWon contract, based on protocol compaWbility measure Comparator is called to suggest the best state/label bindings

17

Joint work with Carlos Canal, Javier Camara, Javier Cubo, Jos Antonio MarDn, Ernesto Pimentel, and Gwen Salaun
ApplicaWon 1

ApplicaWon 2

ITACA: an Integrated Toolbox for the AutomaWc ComposiWon [QSIC09] and AdaptaWon of Web Services (52000 lines of Python and [ICSE09] IST Journal, 2012 Java) 18

Joint work with Gwen Salaun (INRIA France) and Ernesto Pimentel (UMA, Spain)

We propose an interface update process: => Comparator result is very helpful

We assume some user requirements We implemented our process into Updator prototype tool

[SCC11]
19

1. Interoperability of Behavioural Interfaces

2. VericaDon of Asynchronously CommunicaDng Systems a) Contract-based CommunicaWon b) Synchronizability and Realizability VericaWon

3. Research Challenges

20

Joint work with Tevk Bultan and Samik Basu at UCSB (California)

Sender does not have to wait for the receiver

+ Message is inserted to a message queue + Messaging plasorm guarantees the delivery of the message

Why support asynchronous messaging?

+ Otherwise the sender has to block and wait for the receiver + Sender may not need any data to be returned + If the sender needs some data to be returned, it should only wait when it needs to use that data + Asynchronous messaging can alleviate the latency of message transmission through the Internet + Asynchronous messaging can prevent sender from blocking if the receiver service is temporarily unavailable
21

Joint work with Tevk Bultan, Samik Basu, Gwen Salaun, and Maghias Guedemann

CommunicaWon contract: A specicaWon of how the individual services that

parWcipate into a composite service should interact with each other ProjecWon

Realizability: Checking if the services realize their contract => In general, this is an
UNDECIDABLE problem under ASYNCHRONOUS communicaWon + Realizability is decidable via synchronizability

ContribuDons

[POPL,12] [VMCAI,12] + Synchronizability: the synchronous and asynchronous behaviours are equivalent + Realizability Enforcement + Automated VericaWon using process algebra (LOTOS/CADP) [ATVA,12]
22

 Web Service Choreography SpecicaDons: Global specicaWon of interacWons for composiWon of services (WS-CDL) Singularity Channel Contracts: CoordinaWng inter-process communicaWon in Singularity OS Erlang CommunicaDon Contracts: CoordinaWng interacWons among distributed processes

All these specicaWons can be modeled as state machines and they all specify sequences of send acWons, aka, conversaWons
Conversa)on Protocol Global Communica)on contract

A set of conversaWons, i.e. a specicaWon of how the individual services that parWcipate into a composite service should interact with each other
23

 At UCSB Samik, Tevk, and I were using the following protocol for going to lunch:
SomeWme around noon one of us would call another one by phone and tell him/her where and when we would meet for lunch. The receiver of this rst call would call the remaining peer and pass the informaWon.

Lets call this protocol the First Caller Decides (FCD) protocol. At the Wme we did not have answering machines or voicemail due to budget cuts at UC!

24

1. Possible scenario
a) Tevk calls Samik with the decision of where and when to eat b) Samik calls Meriem and passes the informaWon

2. Another scenario
a) Samik calls Tevk with the decision of where and when to eat b) Tevk calls Meriem and passes the informaWon

3. Yet another scenario

a) Tevk calls Meriem with the decision of where and when to eat b) Maybe Samik also calls Meriem at the same Wme with a dierent decision. But the phone is busy. c) Samik keeps calling. But Meriem is not going to answer because according to the protocol the next thing Meriem has to do is to call Samik. d) Meriem calls Samik and passes the informaWon

25

T->S:D S->M:P
! ? Tevfik
!T->S:D !T->M:D ?S->T:D !T->M:P ?S->T:P ?M->T:P ?M->T:D !T->S:P

Tevfik calls Samik with the lunch decision Samik calls Meriem to pass the decision Meesage send Message receive Meriem
!M->S:D !M->T:D ?S->M:D !M->T:P ?S->M:P ?T->M:P ?T->M:D !M->S:P

Samik
!S->T:D !S->M:D ?T->S:D !S->M:P ?T->S:P ?M->S:P ?M->S:D !S->T:P

Three state machines characterizing the behaviors of Tevk, Meriem and Samik according to the FCD protocol 26

 AZer the economy started to recover, the university installed a voicemail system FCD protocol started causing problems We were showing up at dierent restaurants at dierent Wmes! Example scenario:
1. Tevk calls Meriem with the lunch decision 2. Samik also calls Meriem with the lunch decision
message

=> The phone is busy (Meriem is talking to Tevk) so Samik leaves a

3. Meriem calls Samik passing the lunch decision 1. Samik does not answer (he already leZ for lunch) so Meriem leaves a message 4. Samik shows up at a dierent restaurant! Message sequence is: T->M:D S->M:D M->S:P
=> The messages S->M:D and M->S:P are never consumed => This scenario is not possible without voicemail!

27

FCD Protocol
T->M:D T->S:D S->M:P M->T:D M->S:D S->M:D

TD Protocol

T->S:D

T->M:D

S->T:D T->M:P M->T:P

T->S:P

S->T:P

S->M:P

M->S:P

M->S:P

Conversation set: { T->M:D M->S:P,

T->S:D M->T:D M->S:D S->T:D S->M:D

Not Realizable
! ! ! ! !

S->M:P, T->S:P, S->T:P, T->M:P, M->T:P }

T->M:D, S->M:D, M->S:P

Realizable

Conversation set: { T->S:D S->M:P, ! T->M:D M->S:P}

28

Conversation Protocol (Choreography Specification)

T->S:D

T->M:D

?
S->M:P M->S:P

LTL property
F(S->M:P M->S:P)

Peer Samik
?M->S:P ?T->S:D

Peer Tevfik
!T->S:D

Peer Meriem
?S->M:P ?T->M:D

Input FIFO Queue

!S->M:P

!T->M:D

!M->S:P

Conversation generated by some processes

... ?

F(S->M:P M->S:P)

LTL property

29

 Finite state processes that communicate with FIFO message queues can simulate Turing Machines
=> Many vericaWon and analysis problems are undecidable [Brand and Zaropulo83]

We show that conversaWon protocol realizability problem is decidable We implemented the realizability check and applied it to many specicaWons
=> We demonstrate that realizability can be checked eciently in pracWce

Our realizability condiWon enables us to eliminate specicaWons which cannot be implemented

30

 ConversaWon protocol: C Project the conversaWon protocol C to processes protocols Synchronous System (product): I0 Asynchronous System (product) + with unbounded buer: I + with k size communicaWon buer: Ik

31

 Determinized processes I is synchronizable: checking equivalence between I0 and I1 => if I is synchronizable and I is determinized then I is well-formed C = I1: checking equivalence between C and I1
C is realizable if and only if C is equivalent to determinized I1 obtained from projecWons of C, and I is synchronizable
=> for synchronizable systems, for all k 0: Ik is equivalent to I

[POPL12], [VMCAI12]

32

 Implemented using CADP toolbox AutomaWcally generate a LOTOS specicaWon for the conversaWon protocol Generate determinized projecWons (in LOTOS) Check synchronizability (between I0 and I1) Check equivalence of the 1-bounded asynchronous system and the conversaWon protocol Checked realizability of 9 web service choreography specicaWons: 8 are realizable 9 collaboraWon diagrams: 8 are realizable 86 Singularity channel contracts: 84 are realizable Realizability check takes about 14 seconds on average
33

1. Interoperability of Behavioural Interfaces

2. Asynchronously CommunicaWng SoZware Systems

3. Research Challenges

34

1. SoZware ComposiWon and AdaptaWon

2. VericaWon of Asynchronously CommunicaWng Systems

Repairability

Asynchronous CompaWbility, Timed Automata CompaWbility, AutomaWc AdaptaWon

Enforcement of Contract Realizability, Correct-by-construcWon Contracts,

3. VericaWon of Dynamic Architectures:
Checking the correct architectural evoluWon using rewriWng logic (AADL/ FIACRE/MAUDE)
35

o2 journals:
A Generic Framework for N-Protocol CompaDbility Checking. F. Durn, M. Ouederni, G. Salan. Science of Computer Programming. Elsevier. 77(7-8): 870-886 (2012). InteracDve SpecicaDon and VericaDon of Behavioural AdaptaDon Contracts. J. Camara, G. Salan, C. Canal, M. Ouederni. Informa<on & So>ware Technology. Elsevier. 54(7): 701-723 (2012).

o4 conferences:
Counterexample Guided Synthesis of Monitors for Realizability Enforcement. M. Guedemann, G. Salan, and M. Ouederni. ATVA12. 238-253. 2012 Deciding Choreography Realizability. S. Basu, T. Bultan, M. Ouederni. POPL12. ACM, 191-202. 2012. Measuring the CompaDbility of Service InteracDon Protocols. M. Ouederni, G. Salan, E. Pimentel. SAC11. ACM, pp. 1560-1567. 2011. ITACA: An integrated toolbox for the automaDc composiDon and adaptaDon of Web services. J. Cmara, J.A. Mar{n, G. Salan, J. Cubo, M. Ouederni, C. Canal, E. Pimentel. ICSE09. 627-630. 2009.
36