1. Minimising Lifecycle Transitions in Service-Oriented Business Processes Roland Ukor and Andy Carpenter School of Computer Science, University of Manchester, UK 10 th 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 Order Fulfillment Process Credit Check Shipping Agency 1 Agency L1 Shipper 1 Shipper L2 Business Process (of consumer) Business CapabilityService Providers

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 {c 1..c n } There are two categories of candidates for each c i : –K i 0 : Candidates requiring no mediation or for which mediators already exist –K i 1 : Candidates requiring mediation but no mediator exists –All candidates K i = K i 0 U K i 1 A candidate k in K i 1 is only selected if it provides better QoS than all candidates in K i 0 enough to justify the “notional cost” of the required mediator.

14. Ignore Marginal QoS Improvements A candidate k  K i 1 is only selected if: –it provides better QoS than all candidates in K i 0 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” (cost med ij ) normalized to a value in the range [0,1]. –max Σ Σ u ij. (1 – cost med ij ). x ij u ij is the computed utility of candidate k ij  K i, and x ij = 1 if k ij is selected for c i, otherwise 0. –(1 – cost med ij ) will be neutral for candidates in K i 0

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 c i, –Let P i represent the set of protocols for all candidates in K i, where P ij is the protocol for candidate k ij

16. Horizontal Protocol Compatibility Two protocols P ij and P ik 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 P ij and P ik respectively. BP M M P ij P ik 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 c i, –For each P ij  P i, let H ij  P i represent horizontally compatible protocols. –For each p  2 Hij, a candidate mediator M p can be designed that will support all P ik  p –Each candidate M p 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!

21. Service Ranking and Selection Service Selection Problem is a tuple (C, Q, C Q,Q C,R) –C is the set of required capabilities –Q is the set of QoS metrics –C Q : C -> 2 Q defines the set of QoS metrics used to select a service for each c i  C. –Q C is a set of linear constraints on the QoS metrics –R is a registry containing ASDs and CSDs For each c i, –each candidate is associated with values for each m in C Q (c i )