Barbara Pernici, Politecnico di Milano

Flexible and self-healing e-services

February 6, 2007

Outline

Introduction and Motivations

Scenarios

Flexible services

Service selection and optimization

QoS negotiation

Service repair

Flexible service design

Future work

Adaptivity in web-based Information systems

Information systems perspective: business processes, stateful services, autonomous interacting partners

Projects:MAIS (Multichannel Adaptive

Information Systems) 2002-2006WS-Diamond (EU FET STREP) 2005-

2008

Research problems

Service research: WS selection, dynamic invocation, adaptation

Workflows, business processes: recovery design and execution

Looking at Biplav’s terminology: Online information services scenario Composition offline design, template based Trying to improve its low adaptation and

recovery characteristics

Flexible services

Dynamic service selection and invocation

Service Repair

E-service model

Abstract service

Flexible service Concrete service Concrete service

Receivefind-travel

Receivebook-travel

Travel-Servicebook-travel

find-travel

pay-travel

Receivepay-travel

Service interface

(+ Port types)

behavior

QoS<maxTime value="6.767389" /><minTime value="5.767389" /><price value="0.123061776" /><reputation value="0.82627237" /><availability value="0.9903379" /><dataQuality value="0.9857625" />

QoS model

Multiattribute Dimensions definition

Names, ranges

User/provider preferences (weights)

Carlo Marchetti, Barbara Pernici, Pierluigi Plebani: A quality model for multichannel adaptive information. WWW 2004

C. Cappiello, B. Pernici, P. Plebani. “Quality-agnostic or quality-aware semantic service descriptions?”. W3C Workhsop on Semantic Web Service Framework, Innsbruck, June 2005

Selection criteria

User context and preferences Fitness of functionality QoS constraints

Mapping informations abstract -> concrete

URBE

URBE = Uddi Registry By Example UDDI Service discovery is driven by:

Keyword-based queryPre-defined taxonomies browsing

URBE extends UDDI also supporting a content based queryClient submits a WSDLUDDI returns a list of similar Web

services

D. Bianchini, V. De Antonellis, M. Melchiori, B. Pernici, P. Plebani. (2006). Ontology based methodology for e-service discovery. INFORMATION SYSTEMS. vol. 31(4-5)

Web service Similarity

URBE considers both “structural” and “semantic” similarity

Structural similarity Is calculated by analyzing terms in WSDL at different

levels: portType, operation, and message names More terms at the same level are related more

similar are the Web services Semantic similarity discover relationships among

terms Using domain specific term ontology Using generic term ontology, i.e. Wordnet

Semantic plug-ins (OWL-S, WSDL-S)

Affinity: e-service publication

rif XXX IS

Wrapper/mediator generation Semi-automatic construction Similarity of parameters and operations

Thesaurus (terms, simple semantic annotations) Reference services

Transformation of parameters structure and names Restructuring String concatenation

Designer support to extract semantics derived from user interface (web page) Structural analysis of page Thesaurus

Mechanism for interaction with stateful asychronous services through a flexible service are provided

Rif: Enrico Mussi PhD Thesis, Politecnico di Milano, 2007

Web Service Substitution:Mediator execution

Mediation Service

External DataRetriever

Translation Engine

Input message(Warehouse 1 WSDL)

Input message(Warehouse 2 WSDL)

Output message(Warehouse 1 WSDL)

Output message(Warehouse 2 WSDL)

Quality constraints (hard and global):

cost <1000 train.reservation.cost<600

Invoke hotel.reservation

Invoke train.reservation

Preferred:

- ACMEHotels- ItalianHotels

Negotiate:

- lowest price - offer request

Invoke flight.reservation

not late late

Probability=0.8 Probability=0.2

Service composition

Optimization problem

Multi-attribute -> Simple Additive Weighting (SAW) Scoring function, scaling, weighting

Transformation to a linear model, with binary variables Multiple-choice Multiple-dimension Knapsack (MMKP) Solution:

decomposition (execution paths, extension of Zeng et al. 2004), Admissible solution, HEU heuristic for MMKP

Constraints for stateful services Cycles – peeling vs unfolding Reoptimization Negotiation

Danilo Ardagna, Barbara Pernici: Global and Local QoS Guarantee in Web Service Selection. Business Process Management Workshops 2005

D. Ardagna, B. Pernici, Dynamic Web Service Composition with QoS Constraints, special issue on "Business Processes and Services" of the International Journal of Business Process Integration and Management (IJBPIM)

Execution paths

HP: unfolding dei cicli

t1

t2

t4

t5

t7

t3

t6

Composite Service

C1 not(C1)

25% 75%

Execution Path ep2 75%

t1

t2

t4

t7

t3

t6

Execution Path ep1

25%

t1

t2

t4

t5

t7

t3

Global constraints Execution time ≤ R Execution timef ≤RD

Availability ≥A Price ≤ B Reputation ≥T Data Quality ≥Q

Problem formulation

Loops

t1

1-p0

p0

t2

1-p1

p1

1-p2

p2

.

.

.

t

C1

not(C1)<process> <sequence> <while cond=C1> <invoke t> </invoke> </while> </sequence><process>

• peeling

D. Ardagna, B. Pernici, technical report, Politecnico di Milano, 2006

Negotiation

A) Identify an admissible solution• When service selection in optimization

fails

Negotiation to set up a contract for service provisioning (QoS)

• With each selected service

Negotiation for web service selection

Two steps Multi-party negotiation to select the best available

service Direct bilateral negotiation

Marco Comuzzi, Barbara Pernici: An Architecture for Flexible Web Service QoS Negotiation. EDOC 2005

Marco Comuzzi, Barbara Pernici: Negotiation Support for Web Service Selection. TES 2004

Marco Comuzzi, PhD Thesis, Politecnico di Milano, 2007

Negotiation algorithm: example

Bilateral multi-attribute bargaining algorithm Offers are selected according to a compromise strategy Strategy is symmetrical

t

CSOx2 P

C

)),(X()),(X( 1111

t

SCt

SCCt

SCt

SCC pQVpQVt

CSO

1

t

SCO

1

t

SCO

P

C

t

CSO1

t

SCO

1

t

SCO

x1

x2

x1

Offer is accepted iff )),(X()),(X( 11 t

CSt

CSCt

SCt

SCC pQVpQV

t

CSO

),()( 1 tgXXt tSC

tCS

Parameters

Concession PatternControlled by parameter β in the g(t) function

Function templates parameterized for quality/utility

Flexible services

Dynamic service selection and invocation

Service Repair

WS-Diamond Web Services DIAgnosability, MONitoring and Diagnosis(EU FET STREP Project 2005-2008) http://wsdiamond.di.unito.it/

Self-healing Web service environment

Ws-Diamond (UE Project) enabling to: detect anomalous situations (network/hardware failures,

Web Service failures, application failures) diagnose faults from the analysis of detected failures select the most suitable recovery action perform the selected recovery actions to reconfigure the

network of services

Ws-Diamond aims at supporting both choreographed and orchestrated Web service environments

Fault-Error-Failure in WS-Diamond

fault

error

failure

alarms, observables, events, symptoms, faulty behaviors,

discrepancies, exceptions and WS fault messages (notification)

cause

state

Faults and self-healing

Faults and repair actions

Permanent and transient faults Stateful services Black box approach for interacting

processes Service management approach Focus on data exchanges

Ws-Diamond: A Diamond-Enabled Node

RecoverySelectorDiagnoser

Web Service

ManagementInterface

Fault Notification

Repair ActionsSymptoms

Event Logs Event Logs

Other Alarms

S. Modafferi, E. Mussi, B. Pernici, SH-BPEL - A Self-Healing plug-in for Ws-BPEL engines, Middleware for Service Oriented Computing (MW4SOC) Workshop, November, 2006, Melbourne, Australia

SH-BPEL: The Process Manager

ManagementEngine

Man

agem

ent

Inte

rfac

eBPEL Interface Mediator

Web ServiceInvoker

SubstitutionManager

Web ServiceRetriever

MediationService

Process Manager

WS-Diamond and Choreography

RecoverySelectorDiagnoser

Web Service

ManagementInterface

RecoverySelector Diagnoser

Web Service

ManagementInterface

RecoverySelectorDiagnoser

Web Service

ManagementInterface

Case 3: Warehouse Fault

Send Order Receive Order

Split Order

Check AvailabilityOn Warehouse

Check AvailabilityOn Supplier

Calculate Cost

Supply

Check Availability

CalculationService

SplitService

CUSTOMER SHOP WAREHOUSE

1. The WAREHOUSE is declared faulty

2. The Recovery Selector stops the SHOP and the WAREHOUSE

3. The Recovery Selector substitutes the WAREHOUSE

4. The Recovery Selector redoes the check availability activity

5. The Recovery Selector redoes all the activities up to the calculate cost activity and then resumes the process

Process-Level Recovery Actions using WS-BPEL

Standard recovery mechanisms Provided by the language Specified by the designer Fault handler, compensation handler, event handler

Pre-Processing recovery mechanisms Based on existing WS-BPEL constructs Inserted by designers using tags Process variable modification, single task or scope retrying, alternative

paths specification, return back to defined safe points

Extended recovery mechanisms Realized by external (with respect to the WS-BPEL engine) recovery

modules Recovery modules interact with both the WS-BPEL engine and invoked

Web services Substitution, ReInvocation, Redoing

Exceptions and Recovery actions patterns Ws-BPEL provides standard patterns for managing exceptions

Specific handlers are associated with a single action or with a Scope, that is, a set of actions:

• Fault handler, Compensation handler, Event handler We define five patterns enabling specific recovery actions:

External variable settings the ability of modifying the value of process variables by means of external messages

Timeout: the specification of a time deadline associated with a task

Redo Pattern: the ability of redoing a single Task or an entire Scope

Future alternative behaviour: the possibility of specifying alternative paths to be followed, in the prosecution of the execution, after the reception of an enabling message

Rollback and conditionally re-execution of the flow: the possibility of going back in the process to a point defined as safe for redoing the same set of tasks or for performing an alternative path.

S. Modafferi, E. Conforti, COOPIS 2006

Some of the new patterns…

Timeout

RedoAlternative pattern

Future Alternate Pattern

S. Modafferi, E. Conforti, COOPIS 2006

SH-BPEL: The ArchitectureS

H-B

PE

L A

PI B-A

PI

M-A

PI

Mes

sage

Mon

itor

Mes

sage

Mon

itor

StandardBPEL Engine

PM-API

Process Manager

E-API

Web Service Substitution: Mediator Configuration

MediationService

Warehouse 1WSDL

URBERegistry

Warehouse 1 WSDL

Warehouse 2 WSDL

WSDL Matcher

Similarity EngineMatching Engine

Warehouse 2WSDL

Warehouse 1WSDL

MappingDocument

Case 3: Warehouse Fault

Send Order Receive Order

Split Order

Check AvailabilityOn Warehouse

Check AvailabilityOn Supplier

Calculate Cost

Supply

Check Availability

CalculationService

SplitService

CUSTOMER SHOP WAREHOUSE

1. The WAREHOUSE is declared faulty

2. The Recovery Selector stops the SHOP and the WAREHOUSE

3. The Recovery Selector substitutes the WAREHOUSE

4. The Recovery Selector redoes the check availability activity

5. The Recovery Selector redoes all the activities up to the calculate cost activity and then resumes the process

Demo Structure (Case 1 and Case 3)

WS-BPELM

anagement

InterfaceWAREHOUSE 1

SH-BPEL

WSDL1 ≠ WSDL2

SHOPClient

SH-BPELAdministrator

WSDM

Subscription

Invocation

Notification

Repair

WAREHOUSE 2Stop

Resume

Methodology for designing self-healing services Design a process on which diagnosis can be performed

and repair actions applied Point of view of repair

Define management actions for process• Pre-defined (safe points, changable variables, replication, …)• Run time (e.g. dynamic invocation/substitution, reallocation,

adjustment of QoS with negotiation…) Make process more reliable/repairable Evaluate improvement of process and costs

Design of exceptions Support to diagnoser

logs Notification of symptoms Local diagnosis

Thank you!

Further referenceswww.elet.polimi.it/people/pernici

QUESTIONS?

Process design: Service redundancy

The service redundancy approach is based on: Identification of weak

points For each weak point

there is the identification of alternative candidates that meet the functional requirements.

Three replacement patterns are proposed

Michael C. Jaeger and Hendrik Ladner, “Improving the QoS of WS Compositions based on Redundant Services” Proceedings of NWeSP’05