Formal Methods for Service Composition

1
Formal Methods for Service Composition

• Antonio Bucchiarone

Monday, November 24
joint work with Maurice ter Beek and Stefania
Gnesi (ISTICNR)
2
Outline

• Background
• WS composition approaches
• Syntactic WS composition
• Semantic WS composition
• WS composition characteristics
• Connectivity, correctness and QoS
• Compare standardization approaches w.r.t.
  characteristics
• Formal methods for WS composition
• Automata, Petri nets and process algebras
• Compare formal methods w.r.t. characteristics
• UMC Approach
• Conclusions

3
Background

• Service-Oriented Computing (SOC)
• An emerging cross-disciplinary paradigm for
  distributed computing
• Changes the way in which software applications
  are designed, architected (SOA), delivered and
  consumed
• Web Services (WSs)
• Autonomous, platform-independent computational
  elements, possibly managed by different
  organizations
• Described, published, discovered, orchestrated
  and programmed to build networks of collaborating
  applications, distributed both within and across
  organizational boundaries

• We survey and compare WS composition approaches
  (both industrial and academic)

4
Syntactic WS Composition Approaches

• WS Orchestration (like BPEL4WS)
• Combines available WSs by adding a central
  coordinator
• This orchestrator is responsible for invoking and
  combining WSs
• WS Choreography (like WS-CDL)
• No central coordinator
• Complex tasks defined by conversations of the
  participating WSs
• Composition of peer-to-peer interactions among
  the collaborating WSs

5
BPEL vs. WS-CDL

• Both XML-based
• BPEL coordination/composition of WSs
  (WSDL-based)
• Processes model the flow of WSs by connecting
  activities that communicate with external WS
  providers
• WS-CDL choreography description of WSs
• Interactions describe the information exchange by
  specifying participants, information and channel
• Exception handling and compensations supported
  through exception and finalizer work units
• Contrary to BPEL, WS-CDL describes a global view
  of the behavior of the message exchanges of all
  WSs (rather than behavior defined from viewpoint
  of one WS)

6
Semantic WS Composition Approaches

• Aim the automation of WS discovery, invocation,
  composition, interoperation and execution
  monitoring
• Describe WSs by explicit, machine-understandable
  semantics
• Often rely on ontologies to formalize the domain
  concepts shared among WSs (like OWL-S, WSMO,
  etc..)
• The Internet is seen as a globally linked
  database in which web pages are marked with
  semantic annotations

7
OWL-S vs. WSMO

• Both ontology-based
• OWL-S
• defines a WS ontology with four main elements
  service concept, service profile, service model
  and service grounding
• no clear distinction between choreography and
  orchestration
• WSMO
• defines a model to describe semantic WSs with
  four main elements ontologies, WSs, goals and
  mediators
• conceptual design in WSMF, annotations in WSML,
  execution environment WSMX for dynamic
  discovery/selection/invocation
• OWL-S more mature in certain aspects
  (choreography), while WSMO provides a more
  complete conceptual model

8
WS Composition Characteristics I

• Connectivity
• Reliability
• The ability to deliver responses continuously in
  time
• The ability to correctly deliver messages between
  two endpoints
• Accessibility
• The percentage of responses per WS request
• Exception handling/Compensations
• What happens in case of an error and how to undo
  the already completed activities
• The ability to manage compensations of WS
  invocations (in case of a failure)

9
WS Composition Characteristics II

• Correctness
• Safety/Liveness
• Assertions that some bad event never happens in
  the course of a computation
• Assertions that some event does eventually happen
  in the course of a computation
• Security/Trust
• The ability of a WS (composition) to provide
  proper authentication, authorization,
  confidentiality and data encryption
• The assurance that a WS (composition) will
  perform as expected despite possible
  environmental disruptions, human and operators
  errors, hostile attacks and design and
  implementation errors

10
WS Composition Characteristics III

• Quality of Service (QoS)
• Accuracy
• The error rate of a WS, measured as the number of
  errors generated by a WS in a certain time
  interval
• Availability
• The probability that a WS is available at any
  given time, measured as the percentage of time a
  WS is available over an extended time period
• Performance
• Measured as the success rate of WS requests
• Maximum time needed to complete a request
  (response time)
• Number of completed requests over a period of
  time (throughput)
• Time needed by a WS to process a request
  (latency)

11
Comparison of Standardization Approaches

• Neither of these approaches offer any direct
  support for the verification of WS compositions
  at design time
• This is where formal methods come into play !

12
Formal Methods for WS Composition I

• Automata
• Well-known model underlying formal specifications
• I/O automata, timed automata, team automata, etc.
• Their formal basis allows for automatic tool
  support
• Exemplary approaches (see paper for references)
• Frameworks to analyze and verify properties of WS
  compositions of BPEL processes
• Translations from BPEL to Promela (finite
  automata) to use the SPIN model checker to verify
  LTL properties
• Translations from WS-CDL to timed automata to use
  the UPPAAL model checker to verify (timed) CTL
  properties

13
Formal Methods for WS Composition II

• Petri nets
• Well-known framework for modeling concurrent
  systems
• Their ease of conceptual modeling (graphical
  notation) has made Petri nets the model of choice
  in many applications
• Their formal basis allows for automatic tool
  support
• Exemplary approaches (see paper for references)
• Mapping of all BPEL control-flow constructs into
  labeled Petri nets
• Open-source tools BPEL2PNML and WofBPEL
  automatically transform BPEL processes in Petri
  nets and analyze them (including reachability
  analysis)

14
Formal Methods for WS Composition III

• Process Algebras
• Precise and well-studied set of formalisms
• CCS, p-calculus (which inspired BPEL to a certain
  extent), LOTOS, etc.
• Their formal basis allows automatic verification
  of behavioral properties
• Rich theory on bisimulation analysis for
  equivalence testing (to verify substitutivity and
  redundancy in WS compositions)
• Exemplary approaches (see paper for references)
• Specify and compose WSs in CCS to use Concurrency
  Workbench to validate correctness properties
• Translations from BPEL to LOTOS to use CADP
  model-checking toolbox to verify temporal
  properties

15
Comparing Formal Methods

• Paper provides a reference for WS composition
  designers and developers willing to use formal
  methods and tools

16
Behavioural Correctness of WSs Composition by UMC
(Finance Case Study)
17
WSs Behaviour - UML State Machines
18
UMC Classes An Example
Class AuthenticationService is Signals // FROM
Portal authentication(USERToken,PWDToken,CUSTCu
stomer) Vars userToken myPortal
Portal actual_customer Customer State top
s1 Transitions --CUSTOMER AUTHENTICATION-- s1-gts1
authentication(USER,PWD,CUST) /
actual_customerCUST userUSER
myPortal.authorized(user,actual_customer)
s1-gts1 authentication(USER,PWD,CUST) /
actual_customerCUST userUSER
myPortal.notAuthorized(user,actual_custo
mer) end AuthenticationService
19
UCTL Properties some examples

• Each time that the Customer asks for a
• credit, the system provides a response
• RECEIVE OFFER the customer receives a credit
  order
• BALANCE NOT VALID the customer's balance is not
  valid
• UPDATE DATA the system asks to the customer to
  update some data
• NEGATIVE RESPONSE the system processes all data
  and provides a negative response.

20
UCTL Properties some examples

• A Customer can not receive an offer if the
  Supervisor did not give
• a positive assessment.

A Customer receives a negative answer from the
Credit Portal only if he/she receives one of the
following negative notifications - Negative
Supervisor Evaluation - Negative Employee
Evaluation - Negative Balance Evaluation
21
Conclusions

• Most standardization approaches to WS composition
  lack
• Support to verify the (behavioral) correctness of
  WS compositions
• Support to perform quantitative analysis of QoS
  aspects
• Formal Methods and tools allow one to simulate
  and verify the behavior of ones model at design
  time
• Thus enable the detection and correction of
  errors as early as possible and in any case
  before implementation !
• The use of formal methods can increase the
  confidence in the correctness of ones (WS
  composition) design