Supporting the Composition of Distributed Business Processes Paolo Traverso ITC-IRST

1. Supporting the Composition of Distributed Business Processes Paolo Traverso ITC-IRST Trento, Italy traverso@itc.it

2. Context of the talk • Service oriented composition: • business models “from products to services” • software constructed by composition and configuration of software services that are available by “third parties” • Services as distributed business processes: • services that “do” things, beyond information acquisition • services are very rarely “atomic” • services are processes that require a flow of interaction • The challenge: • supporting the composition of distributed business processes that are available as services

3. Focus of the Talk • Automated Composition at Design Time: automatic generation of compositions of distributed business processes from their business requirements • Run-Time Monitoring during Execution: run-time (or simulation-time) analysis to detect violations of expected behaviors or to collect information about service executions

4. Outline • Automated Composition • Run-time Monitoring • Some Applications • Future Research • Conclusions

5. supplier service Interaction Flow supply & pay service Interaction Flow bank service Design Time: Automated Compostion Composition requirement Interaction Flow Composed Service

6. A Working Hypothesis • Interaction Flows and Executable Composed Services in WS-BPEL (Business Process Execution Language) • BPEL offers a set of core process description concepts that permit to represent the behavioral aspects of business process interaction at two level of abstractions: • Interaction Flow in Abstract BPEL: defines the interaction protocol (or Interface) of a service without exposing the internal behavior • Composed Service in Executable BPEL: defines the actual code of a service; it can be deployed and executed on web service execution engines • Embedding in existing business process development platforms: Active WebFlow platform http://www.activebpel.org

7. supplier service Abstract BPEL supply & pay service Abstract BPEL bank service Design Time: Automated Compostion Composition requirement Abstract BPEL Executable BPEL

8. The Automated Composition Problem • Inputs: • Interaction Flows (Abstract BPEL) of • available component services • the desired composed service • Composition requirements • Output: • Executable Composed Service (Executable BPEL) that, by interacting with available services (described in abstract BPEL), makes available an interaction flow (in abstract BPEL) of the composed service and satisfies the composition requirements

9. Interaction Flows in Abstract BPEL: an Example

10. Interaction Flows in Abstract BPEL (cont.)

11. request t Check CC invalid valid amount t Availability? Confirm req No availability confirm cancel Interaction Flows as State Transition Systems • We translate Abstract BPEL processes into State Transition Systems • Input actions I(reception of messages) • Output actions O(message sent) • Internal actiont(internal evolutions that are not visible to external services)

12. cancelled cancelled cancelled ordered sold paid The Composition Problem Revisited Composition requirements supplier service supply & pay service bank service

13. The Automated Composition Problem • Inputs: • Interaction Flows (Abstract BPEL) of • available component services • the desired composed service • Composition requirements • Output: • Executable Composed Service (Executable BPEL) that, by interacting with available services (in abstract BPEL), makes available an interaction flow (in abstract BPEL) of the composed service and satisfies the composition requirements

14. Composition Requirements Two Aspects of Composition Requirements • Control Flow Requirements: Temporal Conditions on the flow of the execution • Data FlowRequirements: requirements on data that are exchanged among component services

15. cancelled cancelled cancelled ordered paid sold Control Flow Requirements Control Flow requirements supplier service supply & pay service Trysold&ordered&paidUpon Failureallcancelled bank service

16. Data Flow Requirements Data Flow requirements supplier service supply & pay service bank service

17. Data Flow Requirements: Example

18. The Automated Composition Problem • Inputs: • Interaction Flows (Abstract BPEL) of • available component services • the desired composed service • Composition requirements • Output: • Executable Composed Service (Executable BPEL) that, by interacting with available services (in abstract BPEL), makes available an interaction flow (in abstract BPEL) of the composed service and satisfies the composition requirements

19. ?z t ?w ?x t !d !a ?y !c !b The Composition Algorithm: Intuitions • The Parallel Product of the State Transitions Systems (STSs) of Available Interaction Flows (Components + Composed) • Search the Product STS to satisfy the Composition Requirement • Find a subgraph of the Product STS which satisfies the following conditions (example with reachability condistion): • All terminal states satisfy the condition • If a state belongs to the subgraph, then • all outgoing taus • all outgoing outputs • one outgoing inputs belong to the subgraph • remove non deadlock-free components • Product STSs can be extremely large: we use BDD-based exploration primitives from the “Planning as Model Checking” framework

20. Composition Results: Example

21. Composition Results: Example (cont.)

22. Focus of the Talk • Automated Composition at Design Time: automatic generation of compositionsof distributed business processes from their business requirements • Run-Time Monitoring during Execution: run-time (or simulation-time) analysis to detect violations of expected behaviors or to collect information about service executions

23. Run-Time Monitoring: Motivations • Need to check the behavior of the partners of a composition, in order to: • detect unexpected changes in the behavior • detect violations to service-level agreements • Need to monitor performance & quality of the composition: • react to business problems and opportunities at real time

24. Run-Time Monitoring of Compositions Inputs: • A set of component services (defined as Abstract BPEL interfaces)… • A composed service (defined as Executable BPEL) … • A monitoring specification Output: • Notification of violation of expected behavior … • Notification of situations of interest … • Aggregated/statistical information on process(es) behaviours

25. Examples of Properties to be Monitored • Check if the partners respect the expected behaviors: • The Bank does not refuse the credentials of the Store • Statistical and performance information: • Count the number of times a given event occurs • Count the number of items offered to the Client before the Client accepts to buy • Measure durations and time intervals • Measure the time requested to finalize the payment with the Bank Properties Related to Single Process Instance

26. Examples of Properties to be Monitored (cont.) • Aggregated information on correct behavior • The Bank never refuses the credentials of the Store • Aggregated performance measurement • Average duration of the interactions with the Bank for the payment procedure • QOS • The average time required by the Bank to complete the payment procedure should be less than 1500 ms Properties Related to Process Classes

27. Run-Time Monitoring of Compositions • Monitors are programs executed in parallel to BPEL processes • They intercept messages from/to these processes • They report boolean or statistical information • Instance monitor: associated to a specific instance of a BPEL process • Violation of interaction protocols • Violation of functional requirements • Performance analysis • Class monitor: associated to all instances of a BPEL process • Aggregated information on protocol/requirements violations • Statistical information on process behavior • QoS • Monitors can be: • written by hand, or • generated from a high-level description of the condition to be detected

28. Architecture for Run-time Monitoring

29. Process Monitoring Console

30. Monitor Specification Language • The language is defined in 3 steps: • events specification • allows to specify the events that are relevant for the monitor evolution • instance level formulas • specifies boolean/numerical formulas on process instances corresponding to suitable patterns of events • class level formulas • specifies boolean/numerical formulas on process classes by aggregating instance level formulas

31. Instance Level Properties: Examples • The Bank does not refuse the credentials (account no) of the Store! O (msg(Bank.output = invalid_target_account)) • Count the number of items offered to the Client before the Client accepts to buyO (msg(Client.output = buy)) ?count(msg(Client.output = refuse_offer)) : 0 • Measure the time requested to finalize the payment with the Banktime((msg(Bank.output = ok) | msg(Bank.output = error)) S msg(Bank.input = start_payment))

32. Class Level Properties: Examples • The Bank never refuses the credentials of the StoreAND (! O (msg(Bank.output = invalid_target_account))) • Average duration of the interactions with the Bank for the payment procedureAVG (time((msg(Bank.output = ok) | msg(Bank.output = error)) S msg(Bank.input = start_payment)) • The average time required by the Bank to complete the payment procedure should be less than 1500 msAVG (time((msg(Bank.output = ok) | msg(Bank.output = error)) S msg(Bank.input = start_payment)) < 1500

33. Monitor Generation • Based on standard techniques for mapping temporal logics into finite state automata • Necessity to deal with enriched automata: • we have to take into account numerical values, not only booleans • updates of class monitors depend on updates of the associated instance monitors • These enriched automata are then emitted as Java code

34. Some Industrial Projects and Collaborations • Logistics: Opera 21 • e-Banking: Monte dei Paschi, BPVR • Telcos: Telecom Italia, DocomoLab Europe • e-Ambient: Siemens, Heidi • e-Government: Engineering spa, SAP, DeltaDator, Italian and Regional Government

35. Information System (e.g. SAP) Transportation Management Warehouse Management Business Intelligence Logistics ERP CRM Some Applications: Logistics • Objectives: • Development of “vertical” services for logistics • High degree of customizability at low cost • Horizontal interoperability with “generic services”

36. Servizio Ragioneria Servizio Tesoreria Servizio Tributi Some Applications: e-Government • Objectives: • e-Government service interoperability • Experimented at the local level • Synthesis, Analysis and Monitoring of service composition

37. Some Applications: e-Government Ragioneria Tesoreria Tributi

38. Gestione Contabile Gestione Contributi Some Applications: e-Government (II) Objective: • process monitoring for governance and notification, e.g., • Number of instances involved in different processes • Statistics and timing of different phases of the processes • Governance and notification of critical situations, • Notification of the status of the procedures • Requirement of minimal change of existing legacy systems

39. Some Future Research Challenges • Present: automated tools that perform time consuming and error prone tasks (e.g., detailed analysis, detect interaction problems, monitor execution step by step,...) • Automated Composition • Automated Analysis • Run-Time Monitoring • Future: supporting the life-cycle of Web services • Design-time (off-line): • Aspect oriented service engineering • Run-time: • “Bounded” autonomics

40. Design Time: requirements • Need to model services at the requirements level Requirements Process

41. Design Time: “Aspects” of Requirements

42. Design Time: Aspects Oriented Software Engineering • Separate models of the different “aspects” of each service • Business logics (central aspects) • Transactions, security, reliability… • SLA, rules, policies… • Composition of aspect-oriented services • Composition of the business logics • Composition of the transactional behavior • Negotiation of SLAs • Deployment of the executable services • BPEL • WS-Transaction • Monitors

43. Run Time: Autonomics • Autonomic systems: systems able to adapt themselves without the intervention of humans • self-configuration • self-optimization • self-healing • self-adaptation • Autonomic services: apply this concept to web services • At the moment: focus on the “technical” aspects of service interactions • Detection of failures in external services • Automated optimization of number of trials • Load distribution among different service providers • … • Challenge: move autonomics at the “service” level

44. Run Time: Autonomic Composition • Self-* of a service composition • Given some business level requirements for the composition, automatically build the implementation: • combine in suitable ways the participating services (self-configuring composition) • guarantee the maximization of some expected reward (self-optimizing composition) • detect requirements that are no longer satisfied (self-healing composition) • adapt to unexpected changes in external services (self-adapting composition) • But, how much self-*? • Unbounded autonomics is dangerous • Autonomic compositions should not take strategic decisions • The control should be in the hand of the analysts • Bounded autonomics: • Set clear bounds to the self-* of a systems • Requirements are needed to define these bounds

45. Aspect Oriented Requirements MODEL Analysis Monitoring Synthesis Autonomics EXECUTION Enriched Processes Overall Model: Run Time

46. Overall Model: Continuous Design DESIGN

47. Some References (see also http://astroproject.org) • Automated Composition • P. Traverso and M. Pistore. Automated Composition of Semantic Web Services into Executable Processes. ISWC 2004 • M. Pistore, P. Traverso, P. Bertoli, and A. Marconi. Synthesis of Composite BPEL4WS Web Services. IEEE ICWS 2005. • M. Pistore, A. Marconi, P. Bertoli, and P. Traverso. Automated Composition of Web Services by Planning at the Knowledge Level. IJCAI 2005. • M. Pistore, L. Spalazzi, and P. Traverso. A Minimalist Approach to Semantic Annotations for Web Processes Compositions. ESWC 2006. • A. Marconi, M. Pistore, P. Traverso. Specifying Data-Flow Requirements for the Automated Composition of Web Services. IEEE SEMF’06. • Monitoring • F. Barbon, P. Traverso, M. Pistore, and M. Trainotti. Run-Time Monitoring of the Execution of Plans for Web Service Compositions. ICAPS 2006. • F. Barbon, P. Traverso, M. Pistore, and M. Trainotti. Run-Time Monitoring of Instances and Classes of Web Service Compositions. IEEE ICWS 2006.

48. Conclusions Thank you for your attention!