discovery of soa patterns via model checking

20
Discovery of SOA patterns via Model Checking Authors: M. Di Penta, A. Santone, M.L. Villani

Upload: seth-perkins

Post on 31-Dec-2015

24 views

Category:

Documents


2 download

DESCRIPTION

Discovery of SOA patterns via Model Checking. Authors: M. Di Penta, A. Santone, M.L. Villani. Patterns. A design pattern describes a commonly recurring structure of communicating components that solve a general design problem in a particular context - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Discovery of SOA patterns via  Model Checking

Discovery of SOA patterns via Model Checking

Authors: M. Di Penta, A. Santone, M.L. Villani

Page 2: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 2

Patterns

A design pattern describes a commonly recurring structure of communicating components that solve a general design

problem in a particular context[Gamma et al.,. Design Patterns – Elements of Reusable Object – Oriented

Software, Addison – Wesley, 1995.]

Why to use them They document existing, well-proven design experience

To provide a common vocabulary and understanding for design principles

They support the construction of software with defined properties

……

Page 3: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 3

Patterns in SOAA SOA pattern describes a commonly recurring structure of

communicating services …

Need to account for the new features of service-centric systems Dynamicity:

partner services might not be decided at design time;

both services and their interactions can be defined dynamically. Self-adaptation:

the system behavior adapts to specific execution contexts, e.g. user location and device

Self-healing: recovery actions activated in case of problems/exceptions

Multiparty interactions: e.g., many partner services can fulfill some request

Page 4: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 4

Some examples

C P

S1

S2

Sn

op_req op_req

Proxy

op_resp op_respC F

S1

S2

Sn

op1_reqop2_req

FaÇade

op1_resp

op_req

op2_resp

op2_req

op2_resp

C1 Pq

op_req get_req

Load balancing

op_resp op_resp

S1

S2

SnC2

op1_resp

op1_req

op_resp

get_req

op_resp

CSop_req

op_req

Logger

op_resp

L

op_resplog_op_req

log_op_resp

AS

Page 5: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 5

Catalogues of SOA patterns Patterns for service compositions [SeCSE A3D5, 2005]

Architectural Patterns Workflow patterns [van der Aalst et al., Distributed and Parallel Databases, 14(1):5-51,

2003] process control constructs, tasks synchronization, etc.

Service interaction patterns [Barros et al., Technical Report Queensland Univ of Technology, 2005]

how services communicate synchronous/asynchronous bilateral interaction (direct or through delegation); multilateral interaction, e.g., racing incoming messages; multi-transmission interaction, e.g., if a request is not fulfilled by a service within a

timeframe, that request is sent to another service; routing, e.g., request with referral (a request to a service indicates some other

services to which the response needs to be sent).

Service engineering design patterns [Milanovic, Proceedings of SOSE‘06]

Interpretations of classical design/architectural patterns proxy and variations, faÇade, load balancer, logger publish-subscribe producer-consumer

Page 6: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 6

Detecting SOA patterns Static vs dynamic data From the system implementation

Advantage Accuracy: full knowledge of the system structure/code

Disadvantages Applicability: the system implementation might not be

available Complexity: related to the size of the system

From the system logs built from SOAP messages Disadvantages

Accuracy: the system structure has to be inferred, leading to probabilistic results

Advantages Applicability: always applicable given logs availability Complexity: analysis of the part of the system actually (or

most frequently) used

Page 7: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 7

Detection through model checking SOA patterns formalization

SOAP messages mapped to actions Patterns specified by abstract TL formulas

System representation Execution traces re-constructed from SOAP

messages Formal model built from trace analysis

“Exact” identification of given patterns

Model Checking

Page 8: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 8

Formal LanguagesSystem Description Language: CCS

P ::= nil | a.P | P+P | P|P | P\L | P[f] | XProperties Specification Language: Selective - Calculus* (Branching) Temporal logic to express properties [Barbuti, De Francesco, Santone,

Vaglini. Journal of Computer and System Sciences, 59(3), 1999.]

::= tt | ff | | | [K]R | KR | Z | νZ. | Z.

c] b tt[ {a} “for each c, not preceded by a

it is possible to perform b preceded by any action ”

[c]{a} ff“it is not possible to perform

if has not been previously performed”

ca

a

c b

a

c

TRUE FALSE

Page 9: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 9

The approach

System Traces

LTS

YES

…..

…..

…..

…..

SOAP msg^^^^^^^^^^^^^^^

SOAP msg^^^^^^^^^^^^^^^

SOAP msg^^^^^^^^^^^^^^^

T

Patterns Catalogue

P1 templateP2

templatePntemplate

P1P2

Pn

Model Checker

YES

YES

PN1

PN2

PNj

NO

PY1

PY2

PYi

Patterns as TL formulas

CCS system description

^^^^^^^^^^^^^^^^^^^^

Page 10: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 10

Example: the Proxy Pattern

Client ProxyService Service1 Service2

req_msg

req_msg

{OR}

resp_msg

req_msg

resp_msg

resp_msg

Abstract Specification A triple (C, P,(Si)) s.t., after each

req_cp_msg from C to P eventually P forwards it to some

Si through the action req_psi_msg

before that P does not send a response to C nor can receive a response

after P has sent req_psi_msg to Si

without having received another request, eventually it will receive a response resp_sip_msg from Si

dual constraints as above now holds for resp_sip_msg

Page 11: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 11

Proxy Fault Tolerance

Variation of the Proxy pattern

Client ProxyService Service1 Service2

req_msg

req_msg

resp_msg

req_msg

resp_msg

resp_msg

{CONCURRENT}

What changes Each message from C to

P is concurrently forwarded to all the available services

This pattern is not a simple proxy if an execution trace exists where after req_cp_msg, eventually req_psi_msg is

performed for more than one i

Page 12: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 12

Case study: Image Manipulation Process

Page 13: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 13

DeploymentServices and process distributed on two web server installationsSOAP Monitor

incoming/outcoming SOAP messages captured through a monitoring mechanism (using AXIS APIs) and stored on a DB

Page 14: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 14

Method application: First check

Considered a set of logs covering all pathsClient represented by the BPEL process

ResultProxyImageManipulation detected as serving role P in a proxy pattern

Page 15: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 15

Image Manipulation Process Evolved

ProxyImageManipulation1 behaving as a fault tolerant proxy

Page 16: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 16

Method application: re-do check

Added logs of second deploy of the system

Result Both ProxyImageManipulation

and ProxyImageManipulation1 detected as serving role P in proxy patterns

just one service among the candidates for bindings for ProxyImageManipulation1 operations

Page 17: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 17

Method application: check againAdded more logs

Result Only ProxyImageManipulation

serving role P in a proxy pattern

e.g. proxy formula failed for operation executeAdd mediated by ProxyImageManipulation1

Page 18: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 18

Related workMost approaches developed for design patterns detection from code analysis

Non-formal or theorem-proving based approaches Applicability of model checking-based techniques questionable

because of the state explosion problemRecent work on service-centric systems

Inference of web service interaction protocols from imperfect logs [Motahari Nezhad et al., Proceedings of ICDE, April 2007]

This work First to tackle SOA patterns detection from SOAP message

analysis Uses model checking Method validation on some examples

Page 19: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 19

Future work

Improve limitations on concurrencyModel inference techniques

Analyze and formalize other patterns

More case studies

Compare and possibly combine the model checking “exact” approach with other approaches such as that by Tsantalis et al. [IEEE TSE, 2006], based on graph similarity scoring

Page 20: Discovery of SOA patterns via  Model Checking

IW-SOSWE - 2007 20

Method application: account for data

Also consider valued CCS model (impose proxy service does not change input data)

each action name contains also data valuesmodel check again on the valued model

Result Operation executeDifference of ProxyImageManipulation1,

caused failure of the valued proxy formula while true for the abstract model

one input data of the received request SOAP message was changed in the forwarded message