480 likes | 634 Views
Supporting the Composition of Distributed Business Processes Paolo Traverso ITC-IRST Trento, Italy traverso@itc.it. Context of the talk. Service oriented composition: business models “from products to services”
E N D
Supporting the Composition of Distributed Business Processes Paolo Traverso ITC-IRST Trento, Italy traverso@itc.it
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
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
Outline • Automated Composition • Run-time Monitoring • Some Applications • Future Research • Conclusions
supplier service Interaction Flow supply & pay service Interaction Flow bank service Design Time: Automated Compostion Composition requirement Interaction Flow Composed Service
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
supplier service Abstract BPEL supply & pay service Abstract BPEL bank service Design Time: Automated Compostion Composition requirement Abstract BPEL Executable BPEL
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
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)
cancelled cancelled cancelled ordered sold paid The Composition Problem Revisited Composition requirements supplier service supply & pay service bank service
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
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
cancelled cancelled cancelled ordered paid sold Control Flow Requirements Control Flow requirements supplier service supply & pay service Trysold&ordered&paidUpon Failureallcancelled bank service
Data Flow Requirements Data Flow requirements supplier service supply & pay service bank service
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
?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
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
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
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
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
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
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
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
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))
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
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
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
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”
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
Some Applications: e-Government Ragioneria Tesoreria Tributi
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
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
Design Time: requirements • Need to model services at the requirements level Requirements Process
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
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
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
Aspect Oriented Requirements MODEL Analysis Monitoring Synthesis Autonomics EXECUTION Enriched Processes Overall Model: Run Time
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.
Conclusions Thank you for your attention!