minimising lifecycle transitions in service-oriented business processes roland ukor and andy...
Post on 22-Dec-2015
215 Views
Preview:
TRANSCRIPT
Minimising Lifecycle Transitions in Service-Oriented Business Processes
Roland Ukor and Andy CarpenterSchool of Computer Science, University of Manchester, UK
10th 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
Order FulfillmentProcess
Credit Check
Shipping
Agency 1
Agency L1
Shipper 1
Shipper L2
Business Process(of consumer)
Business Capability Service Providers
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
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
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.
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” QoS 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 MediatorMediator ProtocolProtocol 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 QoS improvements for candidates requiring mediators
– Design least costly mediator with maximal impact
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 U Ki
1
• 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.
Ignore Marginal QoS Improvements
• A candidate k Ki1 is only selected if:
– it provides better QoS than all candidates in K i0 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” (costmed
ij) 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.
BP MM
PijPij
PikPik
Services
Services
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.
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 QoS improvements
– Design least costly mediators with maximal impact
top related