Minimising Lifecycle Transitions in Service-Oriented Business Processes

1. Minimising Lifecycle Transitions in Service-Oriented Business Processes Roland Ukor and Andy Carpenter School of Computer Science, University of Manchester, UK 10th International BPMDS Workshop, 2009

2. Introduction • SOA based inter-organizational business processes • Service provider – consumer relationship • Outsourced business capabilities • e.g. credit rating, shipping. • Web services based interaction • Arbitrarily complex interaction protocols • Services advertised in registries

3. Example: Order fulfillment process Business Process (of consumer) Business Capability Service Providers Agency 1 Credit Check Agency L1 Order FulfillmentProcess Shipper 1 Shipping Shipper L2

4. Service Description in Registries • Abstract Service Definitions (ASD) • Functional, Non-functional and Behavioral description • Interface on which process interaction is based • Concrete Service Definitions (CSD) • Provider-specific description • Location and access information • Quality of Service (QoS) characteristics

5. Service Selection Activities • Initiation and Analysis • Determine business capabilities to outsource. • Discovery • Find services with required capabilities • Ranking and Selection • Based on QoS metrics (e.g. cost, availability) • Performance Monitoring

6. Service Selection and Process Lifecycle

7. QoS based Selection in Operation Phase • Selects a CSD from discovered CSDs: • Case 1: Based on the same ASD for which the process is designed to interact. • Case 2: Based on a different ASD from that for which the process is designed to interact.

8. Case 2: Selection of different CSD • Drivers • Performance • Context-Aware Selection • Issues • Potential data and behavioral incompatibilities • Can occur for multiple instances at the same time

9. Addressing Compatibility Issues • Direct application of compatibility notions • Bi-similarity, Behavioral congruence, Behavioral inheritance, etc • Can result in smaller than desired set of service candidates • Candidates with “good” QoS may not make the shortlist

10. Addressing Compatibility Issues • Mediator-based compatibility • Resolves data and behavioral incompatibility using mediators • Based on incrementally defined knowledge base • Mediators can be semi-automatically generated and are reusable • Allows for manual resolution of syntactic and semantic gaps • Triggers transient lifecycle transitions • Comes at a “notional cost” Process Mediator Protocol Service

11. Mediator-based Compatibility • Determining the “notional cost” • Structural complexity • Syntactic and structural gap: • e.g. graph edit distances • Semantic gap: differences in meaning of concepts used • Policy-based constraints: • e.g. delivery before payment vs. payment before delivery.

12. Relative Compatibility Based Selection • Objective: Minimize transient lifecycle transitions • Using mediator-based compatibility • Based on two principles: • Ignore marginal QoS improvements for candidates requiring mediators • Design least costly mediator with maximal impact

13. Ignore Marginal QoS Improvements • Given a process that requires n capabilities {c1..cn} • There are two categories of candidates for each ci: • Ki0: Candidates requiring no mediation or for which mediators already exist • Ki1: Candidates requiring mediation but no mediator exists • All candidates Ki = Ki0 UKi1 • A candidate k in Ki1 is only selected if it provides better QoS than all candidates in Ki0 enough to justify the “notional cost” of the required mediator.

14. Ignore Marginal QoS Improvements • A candidate k  Ki1 is only selected if: • it provides better QoS than all candidates in Ki0 enough to justify the “notional cost” of the required mediator. • Implementation • bias the utility of each candidate in the objective function based on the “notional cost” (costmedij)normalized to a value in the range [0,1]. • max Σ Σ uij. (1 – costmedij) . xij • uij is the computed utility of candidate kijKi, and xij = 1 if kij is selected for ci, otherwise 0. • (1 – costmedij) will be neutral for candidates in Ki0

15. Least Costly Mediator with Maximal Impact • If a candidate to be selected requires mediation, then • Design least costly mediator with maximal impact • For each ci, • Let Pi represent the set of protocols for all candidates in Ki, where Pij is the protocol for candidate kij

16. Horizontal Protocol Compatibility • Two protocols Pij and Pik are horizontally compatible w.r.t. a process BP, if: • A mediator M can be designed so that BP can safely interact with services that use Pij and Pik respectively. Pij Services BP M Pik Services

17. Least Costly Mediator with Maximal Impact • If a candidate to be selected requires mediation, then • Design least costly mediator with maximal impact • For each ci, • For each PijPi, let HijPi represent horizontally compatible protocols. • For each p 2Hij, a candidate mediator Mp can be designed that will support all Pik p • Each candidate Mp has a “notional cost” and coverage (e.g. |p| or weighted by no of services using protocols in |p|). • Selection of a mediator to generate can be formulated as an optimization problem based on cost and coverage.

18. Ongoing Work • Implementation • Evaluate different models for determining notional cost of constructing mediators. • Modify the bias factor to take horizontal compatibility into consideration.

19. Conclusion • Dynamic service selection is a driver of lifecycle transitions • These transitions may be costly, but can be minimized using two principles for service selection and mediator design: • Ignore marginal QoS improvements • Design least costly mediators with maximal impact

20. Thank you!