FM-SOA workshop 16 th Feb 2009 Formal Modelling and Analysis of Business Information Systems with Fault Tolerant Middleware Jeremy Bryans, John Fitzgerald, Sascha Romanovsky and Andreas Roth thanks to Son Hoang, Renato Silva and Vitaly Kozura

2 /13 Roadmap of talk Current industrial picture and research question Event-B and Rodin Envisaged toolchain Feasibility study Conclusions

3 /13 Current industrial picture and research question Business protocol design at SAP  Define the services that business objects can provide Range of available middlewares offering various guarantees Important decision at early stage in design  Will my protocol work with this middleware? Can formal methods help in making this decision?

4 /13 Event-B and the Rodin toolset a model-oriented formalism  chain of machines linked with a refinement relation  variables  invariants define datatypes define relationships between variables  events guarded actions modify variables must respect invariants Rodin toolset  generates proof obligations  automatically or manually discharged VARIABLES a b INVARIANTS inv1 a N inv2 b inv3 a b EVENTS Event initialisation = … Event change = any x where x 1..5 then a := a + x b := b + x end  

5 /13 Envisaged toolchain Event-B specification of protocol Event-B specifications Middleware 1 Middleware 2 Correctness criterion for protocol+middleware Combined specification feedback to protocol designer Combined specification fails to meet correctness criterion SAP diagrammatic protocol design language Push-button technology Rodin toolset

6 /13 Envisaged toolchain Event-B specification of protocol Event-B specifications Middleware 1 Middleware 2 Correctness criterion for protocol+middleware Combined specification Combined specification meets correctness criterion Diagrammatic protocol design language Push-button technology Rodin toolset

7 /13 Feasibility study Example protocol: Buyer/Seller negotiation  Two parties  Exchange messages in order to negotiate price of some good or service  P1 signals agreement to P2’s offer by returning the offer to P1  Ends with both parties in agreement on price, or cancellation of protocol SAP middlewares  EO – Exactly Once  EOIO – Exactly Once In Order

8 /13 Event-B modelling Develop Event-B model of Buyer-Seller protocol  with no reference to middleware Develop Event-B model of EO and EOIO middlewares Add middleware machines (separately) to Buyer-Seller machine  BuyerSeller+EO and BuyerSeller+EOIO Formalise key correctness criterion  and attempt to prove it for BuyerSeller+EO, BuyerSeller+EOIO

9 /13 A failed proof attempt Attempts to prove this failed because… current buyer offer current seller offer BuyerAgStatus = Agreement BuyerSeller p2 p1 p2 SellerAgStatus = Agreement initial (partial) statement of correctness criterion:  “when Buyer and Seller both believe they have agreed, they are agreeing on the same value.”

10 /13 Restatement of Correctness Criterion Taking middleware into account Proved with EOIO (Exactly Once In Order) middleware middleware is empty

11 /13 Exactly Once middleware BuyerSeller Agree p1 p2 Failed to prove this with EO middleware This sequence can be demonstrated with an animator plugin for Rodin

12 /13 Further feasibility studies Using protocols models developed by others Using automatically generated protocols Using different refinement techniques Resulted in developing some guidelines for protocol developers wishing to use Rodin

13 /13 Conclusion and Open Issues Technical approach is feasible Interfacing with the designer will be the hard part!  Not all proof obligations are automatically discharged hard to achieve the same level of proof automation as hand-crafted models How to feed back failed proof information to the protocol designer?  How will designer describe correctness criterion? Available as Newcastle University Technical Report No 1131 Formal Modelling and Analysis of Business Information Applications with Fault Tolerant Middleware Bryans, J., Fitzgerald, J., Romanovsky, A., Roth, A.

14 /13 SAP background & requirements Business Information Systems Component development Choreography (protocol) development Choice of pre-built middlewares available, with cost/benefit tradeoff  Exactly Once (EO)  Exactly Once In Order (EOIO) Aim to give the developer the ability to explore the consequences of different middleware choices

15 /13 Objective and Approach Stage one: (completed)  Demonstrate the feasibility of replacing middleware models in protocol development, using an in-house model of B2B protocol Stage two: (completed)  Combine an independently created protocol model with middleware  Outcome: An initial guideline document for developing protocols to be combined with middleware Stage three: (ongoing)  Combine an automatically generated protocol with middleware  Purpose: improve guidelines document Stage four: (future)  Develop a range of middleware models capturing various fault profiles  Purpose: To check protocols against a range of fault assumptions. Objective: An automated method to allow a developer to assess the consequences of choosing from a set of alternative middlewares Approach:

16 /13 Synchronising events in Event-B v e1e1 w e2e2 v w e 12 ANY x WHERE G(x,v) THEN S(x,v) END e 1 =ANY x WHERE H(x,w) THEN T(x,w) END e 2 =ANY x WHERE G(x,v) & H(x,w) THEN S(x,v) || T(x,w) END e 12 = M1 M2

17 /13 Buyer-Seller variables

18 /13 Final middleware machine (EOIO) - two arrays p4p3p2p1 mware_to_seller s_rpos b_wpos b_wpos: The last position at which the buyer wrote s_rpos: The last position at which the seller read No deletion of messages

19 /13 Variables in the combined machine

20 /13 buyer_send_proposal event

21 /13 The “corresponding” middleware event

22 /13 buyer_send_proposal event in combined machine

23 /13 A failed proof attempt BuyerAgStatus = Agreement BuyerSeller p2 p1 p2 SellerAgStatus = Agreement initial (partial) statement of correctness criterion:  “when Buyer and Seller both believe they have agreed, they are agreeing on the same value.