An Integrated Approach for the Run-Time Monitoring of BPEL Orchestrations

1. An Integrated Approach for the Run-Time Monitoring of BPEL Orchestrations Luciano Baresi, Sam Guinea, Raman Kazhamimakin, and Marco Pistore

2. Outline The Monitoring Problem Monitoring Examples Our Monitoring Approaches Dynamo Astro Integration Conclusion and Future Work

3. The Monitoring Problem • BPEL – service composition • centralized server • distributed third-party services • Concrete processes • Abstract processes • concrete services are chosen at run time • Distributed ownership • Unknown configuration Design-time validation is not enough…

4. Continuous Monitoring • Monitoring consists of mainly two things: • data probing • data analysis • BPEL supports primitive forms of: • probing (internal variables / timeouts) • exception handling (BPEL code) • Hard to define behavioral properties • Impossible to define properties that depend on more than one process execution

5. Process Example

6. Property Examples • Changes in insulin dose • Difference between maximum and minimum within 20% range (considering last ten changes) • Hospitalization after three insulin dose changes? • Number of times three dose changes has led to hospitalization

7. Dynamo • Using AOP we add pre- and post-conditions to the interactions the process has with the outside world • Made up of three parts: • location – “where” to monitor • monitoring parameters – “when” to monitor • WSCoL property – “what” to monitor • JML meets XML • Three types of variables – internal, external, historical • Aggregate functions - max, min, avg, sum, numof, etc.

8. Dynamo example location = [INVOKE]changeDose/postcondition; let $stored= retrieve(pID, uID, iID, ‘[INVOKE]changeDose/postcondition’, ‘$doseStored’,10); let $min = (min $d in $stored; $d); let $max = (max %d in $stored; $d); $min > $max*0.80;

9. Astro • Monitors are modules that run in parallel to the process • Looks at input/output messages • Two kinds of monitors • Instance monitors • Class monitors – aggregate information • Monitors are automatically generated • State-transition system • Initial version is in RTML • events – msg(TA.output = changeDose) • past-time linear logics – f1 Since f2 / Once f • numeric functions – count, time

10. Astro example Instance monitor msg(TA.output = sendAmbulance) & count(Once(msg(TA.output = changeDose)) = 3 Class monitor Count(msg(TA.output = sendAmbulance) & count(Once(msg(TA.output = changeDose)) = 3)

11. Integration • Basic event – based on WSCoL variables • declaration – name/parameters/type • location • property • Property is a WSCoL expression • boolean – classic WSCoL • numeric • let $ratio = $doseNew/$doseOld; $ratio • tick – a given event has occurred • ($ratio>0.95 && $ratio<1.05 ? NOTICK : TICK)

12. Integration • Composite Properties - based on ASTRO ratio(uID:string):numeric hospitalization(uID:string):tick Instance monitor hospitalization & count(Once(ratio>1)) >=3 Class monitor Count(hospitalization(%pat=uID) & count(Once(ratio(%pat=uID)>1)) >=3)

13. Integration

14. Result of the Integration

15. Conclusions and Future Work • The integration has covered • basic language characteristics • architecture • Outcome • complementary strengths and weaknesses • Future work • formal definition of the language • implementation and evaluation • extend work to reactions/adapations