Adaptive information systems Prof. Barbara Pernici Department of Electronics and Information Politecnico di Milano April 24, 2007

Adaptive information systems Prof. Barbara Pernici

Department of Electronics and Information

Politecnico di Milano

April 24, 2007

2

Barbara Pernici, DEI

Outline

• Introduction and Motivations

• Flexible services

• Service discovery, negotiation, optimization

• Self-healing services

• Flexible service design

• Discussion

3


Scenarios

4


General Scenario

5


microMAIS

6


Archeological site of Castelseprio

7


Matera et al., 2006 (MAIS project)

8


MultiLezi

HTTP + SOAP

HTTP

Lezi . NET

Lezi . NET CMS

pocketLezi . multimodalLezi aacLezi Services, , Contents, , Users,

Register

Direct access interface

MultiACC RClient

Service access interface

Contents DBMS

Internal Service access inte rface S I

Distributed reflective system

Interfaces

vocalLezi .

Mainetti, Sbattella et al, 2006

9


MultiLezi - aacLezi

10


Business processes based on services

Send Order Receive Order

Split Order

Check AvailabilityOn Warehouse

Check AvailabilityOn Supplier

Calculate Cost

Supply

Check Availability

Calculation

Split

CUSTOMER SHOP WAREHOUSE

11


Mobile Adaptive Information Systems

Mobile devices, varying context• PDA’s, smartphones, ….

Wireless networks• ad hoc (MANET)

Networked services (SOA)

MAIS: Multichannel Adaptive Information Systems

Italian Project

http://www.mais-project.it

12


Quality of Service in adaptive IS

t

QoS

Accepted quality threshold

Quality dimensions

13


Flexible web-service

environment

Adaptive network

Adaptive hw/sw architectureVSDB

Web applications

Front-end environme

nt

Reflective architecture

MAIS: Reference Architecture

14


MAIS front-end components

MAIS back-end components

MAIS Reflective Architecture

MAIS Core

front-end (traditional client)

Web service

MAIS-enabled node

MAIS front-end components


MAIS Core

MAIS-enabled node

MAIS back-end components


MAIS Core

MAIS-enabled node

network

Non MAIS-enabled node

Non MAIS-enabled node

MAIS nodes

15


Interdisciplinary research

• Adaptation to several channels, mobility, context-awareness

• QoS guarantee

• Computer science Information systems Service engineering Software engineering Database technology Architecture design

• Telecommunications Networks Modems

• Business Science User and service profiling Costs and tariffs evaluation

Focus in the talk on:•business processes •service research •middleware

16


Adaptivity in Information systems

Research areas

Life cycle

Levels

Mechanisms

17


Lyfe cycle

Design time

Deployment/configuration time

Run time

18


Levels

Context independent

Context

Quality of Service, Quality of Experience

19


Mechanisms

Matchmaking

Wrapping/mediation

Monitoring

Adaptation, self-*, Recovery, Management (WS/Business Processes)

20


Research in IS group at Politecnico di Milano

21


Research topics at Politecnico – IS group

1. Adaptive information systems

2. Service design and engineering

3. Cost evaluation

Projects:- EU WS-Diamond on Self-healing web services- Italian basic research project: MAIS (Multichannel Adaptive

Information Systems)- Other applied research projects: services for virtual enterprises

(textile, dangerous goods transportation, services for SMEs)

22


Wrt SOC research roadmap “grand challenges”

Service foundations Dynamic connectivity capabilities, service discovery(Concrete Service Invoker, URBE)

Service composition QoS-aware service composition(optimization algorithms for service selection in processes,

negotiation of QoS)

Service management Self-healing services(SH-BPEL)

Service design and development Design principles (user-oriented design)

23


Positioning

Research areas Service, Business Processes

Life cycle Run time (towards design)

Levels User context QoS

Mechanisms Matchmaking Wrapping/mediation Recovery (WS/Business Processes) Monitoring

Life cycle

Mechanisms

Levels

Run time

Deployment

Design

matchmakingWrapping/mediation)

Recovery, self*

Context QoS No context

Moving from run time to deploy/design time research problems

monitoring

24


Adaptive Services in PAWSProcesses with Adaptive Web Services

• Service model • Registry and matchmaking• Optimization with QoS constraints• QoS negotiation and contracting• Service adaptation and invocation• Service Repair • Self-Healing services

25


E-service model

Abstract service

Flexible service Concrete service Concrete service

26


Concrete Service Invoker - Scenario

MAIS Client

Concrete Service Invoker

Platform Invoker

MAIS Reflective

Architecture

MAIS Reflective

Architecture

FlightService

Lufthansa

Alitalia

MAIS Front-End

Concrete Service Invoker

Location = Italy

Location = Italy

Location = Germany

Wrapper

V. De Antonellis, M. Melchiori, L. De Santis, M. Mecella, E. Mussi, B. Pernici, P. Plebani. (2006). A layered architecture for flexible e-service invocation”, Software & Practice Experience. vol. 36(2),

C. Cappiello, M. Comuzzi, E. Mussi, B. Pernici: Context Management for Adaptive Information Systems. Electr. Notes Theor. Comput. Sci. 146(1): (2006)

27


Receivefind-travel

Receivebook-travel

Travel-Servicebook-travel

find-travel

pay-travel

Receivepay-travel

Service interface model

(+ 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" />

28


QoS model

Multiattribute

User/provider preferences (weights)

Dimensions definition Names, ranges

Community defined dimensions

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

request

Qi

29


Service discovery

Selection criteria • User context and preferences• Fitness of functionality• QoS constraints

30


Abstract Service level

QoS

QoS

QoS

QoS

QoS

QoS

QoS

E-service ontology

De Antonellis et al, Inf. Sys., 2006

31


URBE

URBE = Uddi Registry By ExampleUDDI Service discovery is driven by:

Keyword-based query Pre-defined taxonomies browsing

URBE extends UDDI also supporting a content based query Client submits a WSDL UDDI 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)

32


Web service Similarity

URBE considers both “structural” and “semantic” similarity

Semantic similarity discover relationships among terms Using domain specific term ontology Using generic term ontology, i.e. Wordnet

Structural similarity Is calculated by analyzing terms in WSDL at different levels:

portType, operation, and message part names More terms at the same level are related more similar are the Web

services

33


Matching: further aspects and future work

Functional Classification of services according to reference abstract services

(clustering)

QoS Weighted user preferences

• Hierarchical analytical processingM.G. Fugini, P. Plebani, F. Ramoni, ICSOC 2006

Quality of Experience (in context)• As perceived by user in the execution context, not as published

in registry

Semantic annotations Semantic plugin to increase recall Design of semantic annotations

Process matching

34


Concrete Service Invoker – Wrapper Generation

Wrapper

FlightService WSDL

Alitalia WSDL

Similarity Engine

Similarity Evaluation

35


Wrapper generation

Semi-automatic constructionSimilarity 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

Research towards wrapper and mediation engines

Enrico Mussi PhD Thesis, Politecnico di Milano, 2007

36


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

37


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 Cycles – peeling vs unfolding Reoptimization Negotiation if unfeasible

Danilo Ardagna, Barbara Pernici: IEEE Trans. Sw. Eng., July 2007

38


Other issues to be investigated

Advanced optimization: Stateful services

Reoptimization Reoptimization rules

WS on local grids Broker Business processes D. Ardagna, G. Giunta, N. Ingraffia, R. Mirandola, B. Pernici, QoS-

driven Web Service Selection in Autonomic Grid Environments, (GADA'06), Montpellier, France, 2006

39


Negotiation

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

B) Negotiation to set up a contract for service provisioning (QoS)• With each selected service

40


Negotiation - Introduction

Automated negotiation Negotiation is faster when performed by software agents The number of potential partners naturally grows Remove emotional and psychological tricks

First approaches in the field of multi-agent computing Planning problems Economic transactions (dynamic pricing, e-auctions)

Lack of comprehensive approaches in SOA context Algorithm and strategies already defined Web Service based infrastructures for automated negotiation

41


Negotiation for web service selection

Our approach

• automatic negotiation (user and provider profiles)

• multiattribute (QoS dimensions)

• WS infrastructure (negotiation service)

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

42


Future work: Web services contracting

Contract specification (WSLA language, WS-Agreement) Describe service elements touched by the contract (portTypes,

operations,…) Report guarantees (SLOs), recovery actions, penalties,… Identify monitoring third parties

Multi-party interaction

43


Flexible services (towards self*)

Dynamic service selection and invocation

Service Repair

Service self-healing

44


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

Enrico Mussi

Descrizione del progetto Ws-Diamond ed elenco dei suoi obiettiviUtilizzo di gran parte del lavoro svolto in mais ripreso in un ambito diverso

45


Exceptions and self-healing

46


Ws-Diamond: Nodes

Enrico Mussi

Presentazione dell'arcihtettura generale dei nodi ws-Diamond.Serve per chiarire come possono essere distrubuite le funzionalità tra i vari nodiNon tutti i nodi fanno tutto

47


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

Enrico Mussi

Dettaglio di un nodo WS-Diamond completoMette in risalto la natura comunque distribuita dei singoli nodi.Ogni modulo esegue un compito preciso.I risultati sono comunicati agli altri moduli secondo opportune interfacce che, nel caso dei Web service monitorati, sono rappresentate da interfacce di management

48


WS-Diamond and Choreography


Web Service

ManagementInterface

RecoverySelector Diagnoser

Web Service

ManagementInterface


Web Service

ManagementInterface

Enrico Mussi

Disegno per mostrare come i vari nodi sono collegati all'interno di una coreografiaSolamente i Diagnosticatori si parlano per decidere in modo coordinatoPur non essendo evidenziato, i Web service comunicano tra di loro per realizzare la coreografiaAzioni di recovery andrebbero coordinate, noi per ora non lo facciamo. Siamo solo nel caso orchestrato

49


Orchestration, Diagnosis, and Recovery

RecoverySelector

Diagnoser

WS-BPEL

Managem

entInterface

Web Service 1

Web Service 2

Web Service N

Symptoms

Event Logs

Fa

ult

No

tific

atio

n

Event Logs

Other Alarms

Repair

Acti

ons

SH-BPEL

50


Ws-Diamond and Orchestration

RecoverySelector

Diagnoser

WS-BPEL

Managem

entInterface

Web Service 1

Web Service 2

Web Service N

(Infrastructure-level recovery actions)

Process-level recovery actions

Enrico Mussi

La figura mostra come è realizzato un singolo nodo in cui è effettuata un'orchestrazioneIl "Web service" è specializzato in un motore BPEL che si occupa di invocare altri serviziLe azioni di riparazione sono dunque effettuate sul motore BPEL e sono funzionali a correggere il processo eseguitoLe riparazioni possono essere a loivello di infrastruttura o process.Noi facciamo processo

51


SH-BPEL: The Process Manager

ManagementEngine

Man

agem

ent

Inte

rfac

eBPEL Interface Mediator

Web ServiceInvoker

SubstitutionManager

Web ServiceRetriever

MediationService

Process Manager

Enrico Mussi

Descriione passo passo dei moduli e delle interfacce

52


Case 1: Customer Fault


Split Order



Calculate Cost

Supply

Check Availability

Calculation

Split


The CUSTOMER is declared faulty

The Recovery Selector stops the SHOP

The CUSTOMER is repaired

The Recovery Selector sets the order variable of SHOP inserting the correct value

The Recovery Selector resumes the SHOP process from the receive order activity

53


Case 2: Shop Fault


Split Order



Calculate Cost

Supply

Check Availability

Calculation

Split


The SHOP is declared faulty

The Recovery Selector stops the SHOP and the WAREHOUSE

The split activity is repaired

The Recovery Selector retries the split activity

The Recovery Selector retries all the activities up to the calculate cost activity and then resumes the process

54


Case 3: Warehouse Fault


Split Order



Calculate Cost

Supply

Check Availability

CalculationService

SplitService


The WAREHOUSE is declared faulty

The Recovery Selector stops the SHOP and the WAREHOUSE

The Recovery Selector substitutes the WAREHOUSE

The Recovery Selector redoes the check availability activity

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

55


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

56


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)

57


Future Work

Introduce Semantics to Enhance recovery actions Enhance service mediation

Define patterns and strategies to recover from common faulty situations

Repair choreographed processes: many autonomous interacting processes

58


Methodology for designing self-healing services

Design a process on which diagnosis can be performed and repair actions applied

Point of view of repair Make process more reliable/repairable Evaluate improvement of process and costs Define management actions for process

• Pre-defined (safe points, changeable variables, replication, …)• Run time (e.g. dynamic invocation/substitution, reallocation,

adjustment of QoS with negotiation…)

Support to diagnoser

59


Design for adaptivity

Benatallah, Casati, Modafferi, Pernici, MOBIS, 2005

60


Our focus on data quality

Focus on process design (orchestrated)

Faults Typing errors Wrong databases/information systems Misalignment of data Unavailable information services

(permanent/temporary)

Multiple perspectives User, provider(s)

61


Process Analysis

In the process analysis, it is important to identify: Relevant processes Actors within their roles and their requirements

In this phase we analyze actors perspectives… what are the relevant aspects for the actors involved in the process?

The most important contributions for diagnosis are: Identification of the user class that is mostly damaged for a

specific fault occured in the process. Identification of the most important dimension in each step of

the process

Cappiello and Pernici, ER workshops, 2006

62


Process Design

Reparaibility and diagnosability of a process can be enabled in its design: Initial flow modification:

• Exceptions, support to pre-defined repair actions

• Service Redundancy Insertion of quality monitoring block

63


Design of run time actions

“configuration” of process execution engine + provide run time mgmt actions

Run time actions we can consider: the failed service: re-invocation, re-negotiation of QoS

parameters, re-allocation of the service resources

The need for a registry, for a QoS annotation

Other services: workaroundThe need for maintaining information about relationships among

services

64


Concluding remarks

• General trends Information systems as composition of interacting services

(design time or run time) Each service can be complex Open world

• Need for research work on design of adaptive IS Flexible components characterization Service management: self-healing

• Repairability

• Diagnosability Economic issues Trust, responsibility

65


Thank you!

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

QUESTIONS?

Documents

Adaptive information systems Prof. Barbara Pernici Department of Electronics and Information Politecnico di Milano April 24, 2007