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
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
Example: Order fulfillment process Business Process (of consumer) Business Capability Service Providers Agency 1 Credit Check Order Fulfillment Process Agency L 1 Shipper 1 Shipping Shipper L 2
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 (Qo. S) characteristics
Service Selection Activities • Initiation and Analysis – Determine business capabilities to outsource. • Discovery – Find services with required capabilities • Ranking and Selection – Based on Qo. S metrics (e. g. cost, availability) • Performance Monitoring
Service Selection and Process Lifecycle
Qo. S 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.
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
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” Qo. S may not make the shortlist
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
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.
Relative Compatibility Based Selection • Objective: Minimize transient lifecycle transitions – Using mediator-based compatibility • Based on two principles: – Ignore marginal Qo. S improvements for candidates requiring mediators – Design least costly mediator with maximal impact
Ignore Marginal Qo. S Improvements • Given a process that requires n capabilities {c 1. . cn} • There are two categories of candidates for each ci: – Ki 0: Candidates requiring no mediation or for which mediators already exist – Ki 1: Candidates requiring mediation but no mediator exists – All candidates Ki = Ki 0 U Ki 1 • A candidate k in Ki 1 is only selected if it provides better Qo. S than all candidates in Ki 0 enough to justify the “notional cost” of the required mediator.
Ignore Marginal Qo. S Improvements • A candidate k Ki 1 is only selected if: – it provides better Qo. S than all candidates in Ki 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” (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 Ki 0
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
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 BP Services Pik Services M
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 2 Hij, 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.
Ongoing Work • Implementation • Evaluate different models for determining notional cost of constructing mediators. • Modify the bias factor to take horizontal compatibility into consideration.
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 Qo. S improvements – Design least costly mediators with maximal impact
Thank you!
Скачать презентацию Minimising Lifecycle Transitions in Service-Oriented Business Processes Roland
09b3fae069e54fdae40e8f62eb2df9cf.ppt