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

Service Selection and Process Lifecycle

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

Thank you!