Definizione del modello di rappresentazione degli e

Transcript

Fondo Investimenti per la Ricerca di Base (FIRB)
Programma Strategico Tecnologie abilitanti per la
Società della Conoscenza-ICT
Definizione del modello di rappresentazione degli e-Service
Barbara Pernici∗, Luciano Baresi∗, Daniela Berardi+, Diego Calvanese+,
Valeria De Antonellis@, Giuseppe De Giacomo+, Fabio De Rosa+, Maurizio
Lenzerini+, Massimo Mecella+, Michele Melchiori@, Stefano Modafferi∗,
Pierluigi Plebani∗
∗
PoliMi, + UniRoma1, @ UniBrescia
Abstract
Il documento descrive una proposta per la rappresentazione degli e-Service con riferimento alle caratteristiche di
adattabilità e transazionalità
Data
Tipo di Prodotto
Stato
Unità responsabile
Unità coinvolte
Autore da contattare
Versione
04/11/2003
Rapporto 2.1.1
Bozza
Polimi
Polimi, Roma1, Brescia
Barbara Pernici
1.0
Indice
1
Introduzione
2
Modello per la descrizione degli e-Service
2.1 Rappresentazione di servizi e richieste sui canali . . . .
2.1.1 Qualità del servizio . . . . . . . . . . . . . . .
2.1.2 Qualità del fornitore . . . . . . . . . . . . . .
2.1.3 Qualità del richiedente . . . . . . . . . . . . .
2.2 Requisiti per la costruzione di un’ontologia di servizi .
2.2.1 Analisi delle caratteristiche funzionali di servizi
2.2.2 Analisi delle caratteristiche di qualità di servizi
2.3 Modellazione del comportamento degli e-Services . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
7
9
11
12
13
14
15
Transazioni
3.1 Classificazione e organizzazione delle BT . . . . . . .
3.1.1 BT a breve e a lungo termine . . . . . . . . . .
3.1.2 Business Conversation . . . . . . . . . . . . .
3.1.3 Criteri di atomicità . . . . . . . . . . . . . . .
3.1.4 Divisione in tre fasi . . . . . . . . . . . . . . .
3.2 Stato dell’arte sulle proprietà delle Transazioni . . . .
3.2.1 Proprietà ACID . . . . . . . . . . . . . . . . .
3.2.2 Two Phase Commit nel mondo degli e-Service
3.2.3 Abort di una BT e compensazione . . . . . . .
3.2.4 Stato di una transazione . . . . . . . . . . . .
3.3 Piattaforme e protocolli esistenti per le Transazioni . .
3.3.1 Transaction Internet Protocol . . . . . . . . . .
3.3.2 Tentative Hold Protocol . . . . . . . . . . . .
3.3.3 Business Transaction Protocol . . . . . . . . .
3.3.4 WS-Coordination & WS-Transaction . . . . .
3.3.5 ebXML . . . . . . . . . . . . . . . . . . . . .
3.3.6 WSDx & Transactional Attitudes . . . . . . .
3.4 Considerazioni sulle proposte attuali . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
18
18
18
20
20
20
21
21
21
22
22
23
23
24
25
26
26
3
2
A Articoli allegati
30
1
1. Introduzione
autori Polimi
Gli ultimi anni hanno visto la proliferazione dei Web Service come fattore abilitante per l’interoperabilità di applicazioni
seguendo un paradigma che trasforma il Web da contenitore di informazione a fornitore di servizi.
Prima di entrare nei dettagli, è importante descrivere ad alto livello il ciclo di vita di un Web Service. Ciò viene fatto
basandosi sulla Service Oriented Architecture [21] che individua gli attori e le interazioni principali tra di essi e che mette
in luce l’interazione di tipo push che sta alla base dell’utilizzo dei Web Service.
La letteratura recente [3, 22] ha dato ampio risalto alla comunità dei Web Service in cui sono stati proposti diversi
linguaggi in grado di descriverli sia dal punto di vista delle funzionalità offerte che negli aspetti non funzionali o di qualità.
Proposte più recenti si sono concentrate sulla gestione di insiemi di Web Service analizzando quindi problematiche di
composizione, orchestrazione e transazionalità.
In particolare [5] propone una versione estesa della Service Oriented Architecture, presentata in Figura 1.1, in cui
viene evidenziato il ruolo di una struttura di management per la gestione a run-time di aspetti di fruzione del servizio.
Monitoring: Subscribe to
Market maker
events
or
information
Service operator
produced by the component
Management
Role actions
services, and publish higherMarke
performs
•Certif t
Managed
•Ratin ication
services
level composite events (e.g.,
publishes
•SLAs g
Operatio
ns
uses
•Assuran
by filtering, summarizing,
ce
•S
up
port
becomes
Compo
Composi
sition
and correlating component
te servic
es
•Coordin
a
tio
events).
•Conform n
ance
•Monito
Service provider
ring
Basic se
Conformance: Ensure the
rvices
•QoS
Descrip
integrity of the composite
tion & B
asic Op
•Capab
eration
ility
s
service by matching its
•Publicat
•Inteface
ion
•Discove
•Behavio
ry
r
parameter types with those
•Selectio
•QoS
n
•Binding
of its components, impose
constraints on the component
Service client
services (e.g., to ensure
Service aggregator
enforcement of business
rules), and performing data
Figure 1: Extended Service-Oriented Architecture
fusion activities.
Figura
1.1: layers,
Service functionality,
Oriented Architecture
estesa
service
and roles.
QoS composition: Leverage,
aggregate,Questo
and documento
bundle thepartendo dallo stato dell’arte, dai requisiti descritti nel deliverable WP 1.3.1 e dalle consideracomponent’s
QoS
to derive
the composite
including the dicomposite
service’s
zioni sopra esposte,
propone
un modelloQoS,
di rappresentazione
e-Service dove,
con iloverall
termine e-Service, si sottolinea
cost, performance,
security,
authentication,
privacy,
(transactional)
integrity,
reliability,
la necessità di sganciare il concetto di servizio dallo specifico canale Web aprendo la strada a possibili diversi canali di
scalability,
and availability.
comunicazione
elettronici. Riguardo allo stato dell’arte, [27] propone una vasta panoramica delle iniziative al momento
attive per la definizione degli aspetti caratterizzanti un Web Service in parte affrontati anche in questo lavoro.
anage criticalPerseguendo
applications/solutions
andobiettivi
specific
markets,
SOA del
provides
managed
in di produrre un modello
quindi uno degli
comuni
e fondanti
progetto
MAIS lo services
scopo è quello
rvice management
layer
depicted
at
the
top
of
the
SOA
pyramid.
In
particular,
SOA’s
in grado di catturare le peculiarità di servizi fruibili su diversi canali, questi ultimi descritti a fondo nel WP 1.1.1. Ad alto
tions management
aimed
at supporting
critical
that la
require
livello si può functionality
quindi pensare is
ad un
e-Service
come composto
da unapplications
core che racchiude
logica applicativa del servizio e
rises to damanage
the
service
platform,
the
deployment
of
services
and
the
applications.
uno strato di presentazione all’interno del quale, per ogni canale attraverso il quale si vuole fornire il servizio, vengono
tions management
maycon
provide
detailed
application performance statistics that
trattati i datifunctionality
compatibilemente
il canale
medesimo.
rt assessment
of
the
application
effectiveness,
permit
complete
visibility
individual
Il modello qui presentato si basa su WSDL [10] per
la descrizione
delleinto
funzionalità
dei servizi, in quanto, oltre
ess transactions,
and
deliver
application
status
notifications
when
a
particular
activity
is
ad essere uno standard de-facto, risulta essere già aperto grazie al concetto di binding, alla possibilità
di trattare servizi
eted or when a decision condition is reached. We refer to the organization responsible for
ming such operation management functions as the service2 operator. Depending on the
ation requirements a service operator may be a service client or aggregator.
multicanale. Riguardo agli aspetti non funzionali lo sforzo di modellazione cerca di definire il contributo, delle risorse utilizzate accanto alle caratteristiche del canale, alla definizione di un modello si qualità globale in grado di poter
instaurare un contratto tra il fornitore e l’utilizzatore.
Tutte queste aspetti che caratterizzano un e-Service dovranno essere quindi classificati e catalogati oppurtunamente
allo scopo di arricchire quanto ora viene fornito in termini di ricerca dal registry UDDI [6]. Proponendo quindi una
soluzione distribuita, si vuole permettere ad un servizio di essere trovato, o anche di ricercare altri servizi, sulla base
di parametri sia funzionali (come avviene ora) sia con parametri non funzionali dipendenti dal profilo dell’utente, dal
contesto in cui il servizio opera rispetto al contesto dell’utente e dalla qualità del servizio offerto rispetto alla qualità del
servizio cercato.
Allargando il discorso alla gestione di gruppi di e-Service, il problema della composizione viene affrontato proponendo sia una visione statica con l‘interazione tra e-Service vista come automi a stati finiti, sia una visione dinamica
descrivendo il comportamente in termini di albero di azioni. Anche in questo caso i parametri non funzionali possono
essere presi in considerazione nella scelta di un servizio delegato all’esecuzione di una particolare attività.
Infine, il problema delle transazioni durante l’esecuzione di processi basati su e-Service viene affrontata considerando
i problemi di gestione di transazioni sia distribuite che lunghe.
3
2. Modello per la descrizione degli e-Service
autori Polimi, Brescia e Roma1
In questo capitolo viene riportato il modello per la descrizione degli e-Services, proposto nel contesto del progetto MAIS;
in esso vengono illustrati i concetti generali e la teoria dietro questo modello, rimandando una sua più approfondita
trattazione ai diversi articoli allegati a questo documento.
2.1 Rappresentazione di servizi e richieste sui canali
In questo paragrafo verrano presentati un modello per la rappresentazione dei servizi ed una architettura che supporti la
fornitura secondo criteri di adattatività.
Uno degli obiettivi del progetto MAIS è quello di fornire un modello di e-service che sia funzionale in una realtà
fortemente dinamica. Il modello di canale di distribuzione considerato è quello presentato in [30]. Partendo da lì in [8] (a
cui si rimanda per maggiori approfondimenti) vengono presentate due differenti prospettive del modello legate agli aspetti
di erogazione e richiesta di un e-service. La prospettiva del fornitore specifica chi fornisce il servizio, cosa il servizio fa
e come invocare le sue funzionalità tenendo conto anche degli aspetti legati alla Quality of Service. La prospettiva del
fruitore specifica chi richiede il servizio e tutti gli aspetti ad esso associati come il suo profilo ed il contesto in cui si trova.
CH1
CH2
Requestor
E-Service
PLATFORM
Figura 2.1: Connessione Server-Client
La situazione ottimale è quella in cui indipendentemente da quale lato si affronti il problema tutte le grandezze in
gioco sono note e più o meno controllabili. Questo però è vero in situazioni particolari riferite a reti piccole e/o costruite
ad hoc. La situazione più comune è quella rappresentata in figura 2.1 dove esiste un mondo sconosciuto fra il server ed
il client ed è necessario effettuare studi e ipotesi limitandosi a controllare quello che realmente si può conoscere.
Vengono quindi presi in considerazione separatamente i lati del client e del server. Le Figure 2.2,2.3 presentano le
due diverse prospettive e cercano soprattutto di modellare i vari aspetti, spesso dinamici, che caratterizzano il fornitore e
il fruitore del servizio.
Un e-service è descritto da un nome che lo identifica, una descrizione, una categoria (per esempio, servizio commerciale o servizio informazioni), e da una aggregazione di quattro tipi di elementi:
un Canale, ripreso da [30] su cui l’ e-Service è erogato.
uno o più Service Providers, ciascuno associato ad opportune informazioni che ne permettano la descrizione e
l’individuazione;
una Functional Description che descrive gli aspetti operativi dell’e-Service. Tale descrizione – ispirata da WSDL [10]
– è un insieme di Operazioni, con un nome e una descrizione testuale di “ciò che l’operazione fa”.
4
Provisioning
Abstract
EService
1
1
Compatibility
Class
Has associated
1..n
1
1..n
Composite
EService
EService
1..n
1..n
1..n
1..n
Non-functional
1..n
Parameter
Channel
1..n
1..n
1
Service
Provider
Functional decomposition
1
1..n
Functional
Description
1
1..n
1
Precondition
1..n
1..n
1
1..n
PostCondition
Event
1..n
1..n
1
Operation
1
input
1..n
1
1
output
1..n
Input
Output
Figura 2.2: La prospettiva del fornitore
un insieme di Parametri non Funzionali che caratterizzano il contesto di erogazione. Tali parametri sono mutuati
da DAML-S [11] e sono:
il serviceParameter che è una lista di proprietà che possono accompagnare la descrizione del servizio
la serviceCategory che fa riferimento ad ontologie di servizi.
il QualityRating che fornisce informazioni sulla qualità del servizio.
Un esempio di utilizzo di questio parametri può essere la loro consultazione per la ricerca di servizi localizzati geograficamente. La localizzazione geografica non è infatti un parametro funzionale, ma può rivestire un’importanza
notevole nella scelta del servizio da invocare.
Dal punto di vista del fruitore , figura 2.3, vengono modellati il canale (sempre ripreso da [30]), il profilo dell’utente in
cui sono memorizzate informazioni utili a capire le preferenze e il ruolo svolto dall’utente, il contesto che caratterizza
l’erogazione e la richiesta vera e propria, in cui si nota la presenza di livelli di qualità che l’utente ritiene necessari per
l’erogazione di un servizio che lo soddisfi.
L’utilizzo dello stesso modello di canale sia dal lato fornitore che da quello fruitore consente di avere una visione
omogenea della connessione end to end anche se le informazioni “interessanti” non è detto che siano le stesse per entrambi
i lati.
La modellazione del contesto e degli e-service è propedeutica allo sviluppo di un’architettura capace di supportarli
per sfruttarne a pieno le potenzialità.
Dallo sviluppo del modello di riferimento per i servizi scaturiscono alcune indicazioni sul tipo di architettura. In
particolare si è rivelata necessaria una architettura di tipo riflessivo che sia in grado di svolgere essenzialmente quattro
operazioni principali:
consentire operazioni di get e/o set sugli attributi di un canale cioè permettere il monitoraggio e/o la modifica degli
attributi di un canale per potere effettuare del tuning durante l’erogazione del servizio e controllare che la QoS
dell’erogazione sia effettivamente quella richiesta e/o garantita;
5
Profile
1..n
User
Preference
1..n
Profile
1
Generic
Preference
Expertise
Role
Request
1
1..n
requests
1..n
EService
Actor
1..n
1..n
is in
Quality
Level
cu rre nt
1..n
is in
Channel
Context
1
1..n
1..n
1..n
Application
Protocol
1
1..n
Channel
1..n
1..n
1
Context
Time Zone
1..n
1
1
Network
1
1
1..n
Network
Interface
Device
1..n
Location
1..n
CPU
1..n
Input
Device
0..n
1
Memory
1..n
Property
1..n
1..n
1
1..n
Display
0..n
Geo
Position
Town
1..n
Operating
System
0..n
0..n
Application
District
Figura 2.3: La prospettiva del fruitore
6
Country
effettuare delle operazioni adattative mascherandole al livello applicativo cioè prevedere delle funzioni che effettuino il tuning descritto in automatico senza che l’applicazione se ne accorga, la scelta di quali operazioni effettuare
in tale modalità dipende fortemente dal dominio applicativo e non è sempre possibile;
analizzare il contesto (soprattutto nei casi in cui questo sia dinamico); questo è vero sia come analisi durante
l’erogazione singola che come analisi di più erogazioni da cui trarre informazioni sulla QoS;
supportare la multicanalità cioè consentire in maniera meno traumatica possibile per l’applicazione il passaggio da
un canale logico ad un altro;
La ricerca di queste caratteristiche ha indirizzato il lavoro verso un’architettura che abbia caratteristiche riflessive e sia
in gado di generare eventi che possano essere interpretati a livello applicativo per prendere decisioni sulle modalità di
erogazione del servizio.
L’architettura descritta in [31] e presentata in figura 2.4 costituisce il primo passo in questa direzione. La struttura
proposta è costituita da tre livelli. Tali livelli rappresentano astrazioni via via maggiori, o minori a seconda del punto di
vista, del concreto e-service.
I tre moduli presenti in figura hanno i seguenti compiti
e-Service composition platform, ha il compito di ricevere le richieste del cliente e di conseguenza quello di gestire la ricerca di servizi in grado di soddisfarla. Ha inoltre il compito di supportare ove necessario e/o richiesto
l’invocazione del servizio.
Interaction enabling platform, ha il compito di raccogliere le richieste dell’utente e le offerte del servizio scelto, di
fare colloquiare client e Server gestendo al fase di contrattazione e scelta della QoS. Si occupa anche di selezionare
la n-pla su cui erogare il servizio e di tradurre tutti i parametri eventualmente espressi ad un livello più alto in
parametri espressi in termini di attributi tecnologici del canale.
Reflective platform, deve controllare che vengano rispettati i vincoli di QoS imposti dal livello superiore monitorando il canale durante l’erogazione del servizio. Se ne ha la possibilità gestisce operazioni di tipo adattativo per
consentire il rispetto della QoS. Tali operazioni sono trasparenti per l’applicazione.
Uno dei problemi che si sta cercando di affrontare è come e dove distribuire l’architettura per rendere il sistema il più
possibile distribuito compatibilmente con le capacità operative dei singoli device.
E’ importante notare come il modello presentato in [8] ben si coniughi con l’architettura presentata anche se restano
aperti diversi aspetti legati alla modalità di individuazione e scelta dei servizi, alla contrattazione della QoS e alla scelta
del migliore canale logico su cui erogare il servizio ove ve ne fosse più di uno disponibile.
Due aspetti fortemente connessi con tutto ciò che è stato finora presentato sono quello della definizione e gestione
della QoS e quello della definizione di opportune ontologie che devono essere usate in più punti dell’architettura proposta
come ad esempio nella scoperta dei servizi, nella definizione di regole che permettano la traduzione di vincoli espressi a
livelli diversi e così via. Sia l’uno che l’altro vengono trattati in specifici paragrafi di qeusto documento.
2.1.1
Qualità del servizio
Accanto alla caratterizzazione di un e-Service sulla base delle caratteristiche funzionali, particolarmente importante
risulta essere una caratterizzazione legata alla qualità del servizio. Infatti, una volta individuati i servizi in grado di
garantire un certo tipo di funzionalità, la definizione della qualità di un e-Service, talvolta identificata come la raccolta dei
requisiti non funzionali, aggiunge all’utente un’ulteriore leva decisionale riguardo alla scelta di uno dei servizi disponibili.
Il problema della qualità del servizio, specialmente all’interno della comunità middleware, è fortemente dibattuto e
prende in considerazione le problematiche di misurazione di parametri di performance legati all’architettura che eroga il
servizio stesso. Al contrario, nel mondo applicativo, lo sforzo si concentra nel definire modelli di qualità che permettono
ad un utente di conoscere, principalmente attraverso parametri di tipo economico o di profilazione utente, se il servizio è
utile o, meglio, se risulta adatto alle esigenze dell’utente rispettandone eventuali vincoli.
7
SERVICE
E-Service composition platform
CLIENT
COMPOSITION
E-Service
description
LOCAL
SERVICE
PROFILE
LOCAL
CLIENT
PROFILE
INVOCATION
Interaction enabling platform
QoS
NEGOTIATOR
Rating
class
LOGICAL
CHANNEL
MANAGER
TRANSLATOR
TRANSLATOR
TECHNOLOGICAL
MERGER
MERGING
RULES
Reflective platform
CHANNEL
DESCR.
CONTEXT MANAGER
(GLOBAL PROFILE)
CHANNEL ADAPTER
HARMONIZE
REDUCE_
LEVEL
VALIDATE
ADAPT
CHANNEL
MONITOR
CHANNEL
MANAGER
SERVICE
USER
CONTEXT CONTEXT
MGR.
MGR.
T-UPLES
Figura 2.4: Architettura
All’interno del progetto MAIS, il modello di qualità proposta punta ad integrare questi due differenti punti di vista
con l’obiettivo di arrivare ad un sistema di e-contracting in cui le fasi di definizione e assessment del contratto possano,
per quanto possibile, essere rese automatiche.
Il punto di partenza risulta quindi essere la consapevolezza che anche il modello di qualità debba necessariamente
essere studiato da due punti di vista: lato del richiedente e lato del fornitore del servizio. Viene individuato nel concetto
di canale e di contesto un elemento di integrazione tra i modelli del richiedente e del fornitore in grado di mettere a
disposizione quegli strumenti legati alla contrattualistica e alla ricerca del “miglior servizio necessari.
La definizione della QoS in un sistem basato su Web-Service è un argomento diffusamente affrontato nella letteratura.
Un interessante framework è WSLA (Web Service Level Agreement) [26] in cui sono presentati un linguaggio di specifica
della QoS e un modello per la gestione dei parametri di qualità espressi. In particolare, in questa proposta la QoS viene
affrontata a due differenti livelli come mostrato in Figura 2.5
A basso livello il fornitore del servizio, utilizzando le metriche appropriate, è in grado di misurare la QoS delle risorse
da lui utilizzate per fornire il servizio. Sulla base di tali misura, la qualità dell’e-Service può essere definita secondo una
serie di parametri di QoS.
Ad alto livello, attraverso i cosiddetti Service Level, il fornitore del servizio mette a disposizione dei potenziali utenti
un elenco di possibili configurazioni di qualità che è in grado di garantire (es. alta qualità, media qualità, bassa qualità). In
questo modo l’utente analizza e seleziona un insieme di Service Level allo scopo di definire le Service Level Agreement
(SLA).
Definite le SLA, che possono essere quindi considerate parte integrante dei contratti tra cliente e fornitore, durante la
fornitura del servizio l’utente, o una terza parte fidata, monitorerà i parametri di qualità inseriti nella Service Level. Allo
8
Provider
Service Level
Agreement
User
Service Levels
e-Service
QoS service
parameters
Resources
QoS resources
parameters
Figura 2.5: Framework di riferimento
stesso modo il fornitore del servizio si farà carico di un sistema in grado di attivare le opportune strategie per garantire
quanto promesso nelle SLA.
Riguardo alle risorse, la letteratura propone soluzioni per servizi che si basano solamente sul Web e quindi tralasciando canali alternativi. In [29] vengono identificati i parametri significativi per caratterizzare la qualità di un Web
Service, mentre [38] propone una serie di metriche atte al calcolo dei parametri di qualità sia di un singolo servizio, sia
di una composizione di servizi. Riguardo alla qualità dei dati esportati da un e-Service in [9] sono elencate le dimensioni
significative da considerare e le metriche da utilizzarsi.
Analizzando le risorse ad un livello ancora più basso la comunità middleware e quella legata allo studio degli agenti
offrono spunti significanti circa l’enforcement degli aspetti di qualità. Ad esempio, nella comunità middleware degli
oggetti le specifiche Common Object Request Broker Architecture (CORBA, [17]) presentano una serie di interfacce
standard pensate per la gestione degli aspetti di qualità come Real- Time CORBA (realizzato da TAO object request
broker [34]) che per l’enforce delle proprietà di timeliness; Fault-Tolerant CORBA (realizzato nei sistemi Eternal [32] e
IRL [7]) che permette l’enforcement della disponibilità; CORBA Security [18] riguardo all’enforcement delle proprietà
di sicurezza.
Nella comunità degli agenti, sulla base delle specifiche (FIPA) [37], in [1] viene definito un Monitor Agent e un
Control Agent in grado di monitorare e gestire aspetti di qualità legati alle performance e alla sicurezza predendo in
considerazione aspetti di adattività basati sull’utilizzo di architetture riflessive
2.1.2
Qualità del fornitore
La fornitura di un e-Service è strettamente collegata all’architettura su cui il servizio è eseguito e, di conseguenza,
anche la qualità dell’e-Service (d’ora in poi QoeS) dipende dalle risorse utilizzate. In realtà accanto alle caratteristiche
dell’architettura utilizzata, anche il fornitore stesso così come il tipo di servizio possono influenzare la definizione della
QoeS.
Prendendo a riferimento la Figura 2.6, supponiamo che un fornitore di servizi abbia a disposizione un insieme di
risorse raggruppate in quattro macro-classi:
fisiche: es. pc, memoria, tipi di storage;
dati: es. elenchi, statistiche;
9
Functional
Description
1
1
1..n
1..n
Conceptual 1
Channel
Service
Quality
Context
1..n
EService
1
1..n
1..n
Used
resources
quality
Uses
1..n
1..n
1
Provider
Quality
Service
Provider
1..n
1..n
Physical
Data
Available
Resources
Software
Resources
quality
Channel
Figura 2.6: e-Service provisioning
software: applicativi ad-hoc o general purpose;
canali di distribuzione logico: es. Internet.
Un e-Service utilizzerà quindi un sottoinsieme ben definito di queste risorse sulla base delle proprie caratteristiche.
Concentrandoci in particolare sulla risorsa canale, questa viene definita secondo quanto descritto in [30], grazie a cui è
possibile conoscere in che modo l’e-Service è tecnologicamente fruibile.
Come descritto nelle sezioni precedenti, oltre a quanto appena discusso un e-Service è caratterizzato sia dalle proprie
funzionalità che dal contesto all’interno del quale tali funzionalità vengono offerte. In particolare, le funzionalità sono
descritte prendendo a riferimento il linguaggio WSDL e quindi in termini di messaggi che identificano gli input e gli
output del servizio, e di operazioni.
Grazie al contesto, invece, è possibile conoscere quando e in che luogo l’e-Service è fruibile. A tal proposito è
opportuno sottolineare che, sebbene attraverso Internet un e-Service è disponibile potenzialmente in tutti i luoghi, la
restrizione imposta dal contesto dipende dalla logica del servizio stesso. É infatti possibile, per esempio, che un servizio
di spedizioni on-line possa coprire solo l’Italia e quindi, anche se una sua fruizione via Web risulti fattibile anche in stati
esteri, la sua effettiva esecuzione è limitata al territorio nazionale.
In ultimo, una descrizione del canale attraverso cui un e-Service è fruibile (descritto in modo concettuale, es. Internet
Banking, secondo la definizione in [30]), permette all’utente di avere una conoscenza ad alto livello del tipo di accessibilità del servizio. Questo senza entrare nel dettaglio tecnologico invece presente nella descrizione della risorsa canale. In
questo modo i servizi potranno essere classificati, e quindi anche ricercati, secondo una descrizione del canale in grado
di raggruppare diversi canali tecnologici (es. Web, SMS, Call Center non impongono alcun vincolo sul device o sulla
network).
Gli elementi che caratterizzano la fornitura di un e-Service sinora individuati possono essere ulteriormente caratterizzati da attributi di qualità che contribuiranno alla definizione di una QoeS globale.
Partendo dalla qualità delle risorse, anche se alcune dimensioni (soprattutto quelle economiche) possono risultare
trasversali, non necessariamente lo stesso insieme di parametri è in grado di caratterizzare ogni macro-classe. Dimensioni
come corso o affidabilità possono infatti riferirsi a tutti i tipo di risorse, mentre la larghezza di banda risulta essere una
peculiarità del canale.
La QoeS viene quindi definita partendo da questo insieme di parametri arricchito sia con la qualità propria del fornitore, sia con aspetti di qualità legati alla logica applicativa dell’e-Service stesso. Un fornitore infatti, indipendemente
10
SLS
Provider
Quality
Physical
Service
Quality
Resource
Quality
Data
Software
Channel
Figura 2.7: Service Level Specification (SLS)
SLA
Profile
1
1
1..n
User
1..n
1..n
1..n
1
Context
1..n e-Service
requests
1..n
1
1..n
1..n
Channel
Figura 2.8: e-Service request
dall’e-Service fornito, propone una propria qualità che è spesso collegata alla valorizzazione del proprio brand. Per portare un esempio, tale qualità viene espressa da elementi di prezzo o di affidabilità che mettono a disposizione dell’utente
una importante leva decisionale nella scelta del servizio così come avviene nella realtà. Riguardo invece alla logica applicativa del servizio, questa influenza i parametri di qualità di un e-Service indipendentemente dalle risorse utilizzate e
dal fornitore. Prendendo ad esempio un servizio di video on demand, attributi come framerate o risoluzione definiscono
la qualità del servizio in senso stretto. É a questo punto importante sottolineare che i valori di questi attributi dipendono fortemente dalle caratteristiche delle risorse utilizzate e pertanto possono essere calcolate partendo da esse secondo
modelli in fase di studio.
Presentati quindi tutti gli elementi di qualità, la QoeS viene definita come somma di tutti questi elementi presentati
attraverso la Service Level Specification (SLS) come mostrato in Figura 2.7. Tale specifica è il mezzo attraverso il quale
il fornitore propone ad un potenziale utente una serie di livelli di qualità associati al servizio e naturalmente dipendenti
dalle dimensioni di qualità precedentemente individuate.
2.1.3
Qualità del richiedente
Come mostrato in Figura 2.8 all’interno di MAIS un possibile utente del servizio viene descritto sia dal profilo che lo
caratterizza in termini di abilità e preferenze, sia dal contesto in cui opera in un determinato istante, sia dall’insieme di
contesti in cui ha operato in passato od opererà in futuro. Va sottolineato che il contesto qui definito risulta essere identico
al modello di contesto individuato per il fornitore del servizio.
Prima di affrontare la QoeS dal punto di vista del richiedente, è utile ricordare che il fornitore, secondo quanto
11
espresso in precedenza, affianca al proprio servizio un elenco di livelli di qualità espressi attraverso le SLS. A questo
punto un utente può essere passivo o attivo. Nel primo caso seleziona una delle configurazioni proposte ed inizia la
fruizione. Nel secondo caso, al contrario, la scelta delle SLS viene effettuata solo per avere un punto di riferimento per
una successiva fase di negoziazione.
In entrambi i casi il risultato delle operazioni porta alla definizione della qualità attesa espressa dalla Service Level
Agreement (SLA). Questo è solo un primo passo per la definizione di un contratto che, oltre alla valorizzazione degli
attributi di qualità dovrà affrontare la definizione di un sistema di monitoraggio ed assessment in grado di individuare le
responsabilità atte a garantire il rispetto dei vincoli sia dal punto di vista del richiedente che del fornitore.
Qualità ed adattività
Il modello di QoeS esposto fornisce al progettista uno strumento in grado di governare l’adattività sia dei servizi forniti
sia della fruizione degli stessi con particolare riferimento al cambio di canale.
Prima di tutto la ricerca di un servizio viene estesa anche ad aspetti di contesto e di canale al momento non offerti da
registry quali UDDI.
Una volta individuata una classe di servizi funzionalmente equivalenti, l’utente attraverso i SLS può individuare il
servizio a suo avviso migliore secondo parametri tecnologici (canali offerti) che qualitativi.
Infine, durante l’esecuzione del servizio e limitatamente al fornitore, avendo conoscenza delle risorse utilizzate e
della qualità offerta da esse, può attivare procedure atte a mantenere la qualità totale del servizio all’interno dei limiti
promessi nell’SLA.
Lavoro futuro
Partendo dalla definizione del modello di qualità ora presentato, il lavoro futuro si concentrerà inzialmente sulla individuazione dei parametri di qualità, e delle rispettive metriche, effettivamente utili all’ambito di ricerca MAIS.
Successivamente la definizione delle SLA dovrà essere arricchita con elementi in grado di descrivere un contratto tra
utente e fornitore in cui siano presenti le dimensioni di qualità individuate e le responsabilità nell’effettiva gestione delle
stesse (monitoraggio, assessment ed enforcement).
Concentrandoci inoltre sulle diverse competenze caratterizzanti il fornitore e il richiedente del servizio, è utile descrivere la qualità di un servizio anche ad un livello più astratto. Per esempio, riguardo al costo di un servizio, l’utente
dovrà essere in grado di cercare un servizio attraverso termini generici quali “economico” o “costoso” in cui la relazione
tra i parametri di qualità, profilo utente e contesto risulta centrale.
2.2 Requisiti per la costruzione di un’ontologia di servizi
In un ambiente mobile multicanale è fondamentale poter fornire servizi agli utenti tenendo conto dei diversi possibili
contesti di fruizione e garantendo, allo stesso tempo, le migliori prestazioni possibili. Si rende, quindi, necessario un
approccio alla fornitura di servizi che sia flessibile e adattivo per poter affrontare e superare limitazioni imposte da
cambiamenti di contesto (in relazione a profilo utente, posizione geografica, canali e strumenti a disposizione). Per
essere efficace, un approccio dinamico, flessibile e adattivo alla fornitura di servizi richiede la capacità di individuare
gruppi di servizi compatibili che possano mutuamente sostituirsi, riconoscendo tra loro proprietà di similarità basate
su funzionalità offerte e fattori di qualità. In questo contesto, assumono un ruolo rilevante metodi e strumenti per la
classificazione di servizi in base alle funzionalità offerte e a parametri di qualità.
Nel progetto MAIS, si intende definire un approccio orientato alla costruzione di una ontologia di servizi in grado
di supportare il processo di selezione di servizi da fornire. Nell’ontologia, i servizi devono essere classificati secondo
opportune relazioni semantiche, stabilite analizzando le descrizioni dei servizi di interesse per le caratteristiche sia funzionali che non-funzionali. Tale approccio deve essere basato su tecniche semi-automatiche che supportino l’attività di
classificazione, rendendola applicabile anche ad un numero rilevante di servizi e in un contesto dinamico quale quello
considerato.
12
Nel seguito, si propongono criteri e tecniche per l’analisi di servizi descritti secondo il modello presentato nella
sezione precedente. Tali tecniche consentono di ricavare indicazioni sulla similarità fra servizi quale passo preliminare
per la classificazione e la realizzazione di una ontologia di servizi.
2.2.1
Analisi delle caratteristiche funzionali di servizi
Allo scopo di classificare servizi (e-Service) sulla base delle loro caratteristiche funzionali, vengono considerati gli
aspetti associati alla interfaccia e al comportamento di servizi. In particolare, vengono definiti coefficienti di Similarità
di Interfaccia e proprietà di Similarità di Comportamento.
Per il calcolo dei coefficienti di Similarità di Interfaccia ci si basa su descrittori di e-Service opportunamente definiti.
Un descrittore di e-Service fornisce una rappresentazione delle caratteristiche dell’ e-Service in termini del nome dell’
e-Service stesso e di un insieme di triple della forma:
hoperazione (OP ), entità di input(IN ), entità di output(OU T )i
Dati i descrittori di due servizi, stabiliamo la loro similarità in base al numero di: (i) entità di I/O simili, e (ii)
operazioni simili. In altre parole, in questa fase compariamo i servizi sulla base dell’analisi dei loro descrittori e quindi
delle loro interfacce.
Un coefficiente GSim, che misura il grado di similarità globale è definito come:
GSim(Si , Sj ) = α · ESim(Si , Sj ) + β · F Sim(Si , Sj )
dove:
ESim(Si , Sj ) valuta la similarità sulla base delle entità di I/O che hanno affinità nei servizi Si e Sj . FSim(Si , Sj )
valuta la similarità sulla base dei descrittori di operazione (nome dell’operazione, entità di I/O) che hanno affinità
nei servizi considerati. L’affinità A() fra entità di I/O e fra nomi di operazioni viene calcolata mediante il sistema
ARTEMIS [36] utilizzando un thesaurus terminologico di base.
α e β, con α,β ∈ [0, 1] e α + β = 1 possono essere fissate in modo opportuno per stabilire il peso desiderato per
ciascuna delle similarità considerate.
I servizi possono essere confrontati rispetto ai valori di similarità globale calcolati e, di conseguenza, essere raggruppati in cluster di servizi simili.
Per determinare la Similarità di Comportamento ci si basa sull’analisi del comportamento di e-Service rappresentato
tramite un descrittore (pre-condizione, post-condizione) che fornisce una caratterizzazione semantica degli stati prima e
dopo l’esecuzione dell’ e-Service. Come previsto dal modello di e-Service presentato nella sezione precedente, le pre- e
post-condizioni possono essere associate all’intero e-Service oppure alla singola operazione. Per scopi di classificazione,
consideriamo solo le pre- e post-condizioni associate all’intero e-Service.
La Similarità di Comportamento fra una coppia di servizi può essere esatta o parziale sulla base delle seguenti
definizioni:
Exact-match: un e-Service Si ha un exact-match con Sj se: (i) essi sono simili secondo l’analisi di similarità
di interfaccia; (ii) le pre-condizioni di Si sono logicamente equivalenti alle pre-condizioni di Sj ; (iii) le postcondizioni di Si sono logicamente equivalenti alle le post-condizioni di Sj . Di conseguenza un agente o un utente
può invocare Si qualora Sj non fosse (più) disponibile. La condizione di exact-match è un requisito forte, viene
quindi introdotta anche una relazione più debole:
Partial-match: un e-Service Si ha un partial-match con Sj se: (i) essi sono simili secondo l’analisi di similarità di
interfaccia; ii) le pre-condizioni di Si implicano logicamente le pre-condizioni di Sj ; (iii) le post-condizioni di Sj
implicano logicamente le le post-condizioni di Sj . In questo caso, l’esecuzione di Sj può sostituire l’esecuzione
di Si , ma non viceversa. Infatti, se le pre-condizioni di Si sono soddisfatte prima della sua esecuzione, allora
anche le pre-condizioni di Sj sono soddisfatte di conseguenza, mentre dopo l’esecuzione di Sj sono vere le sue
post-condizioni e perciò soddisfatte anche le post-condizioni di Si .
13
2.2.2
Analisi delle caratteristiche di qualità di servizi
La classificazione e la ricerca di servizi sulla base delle sole caratteristiche funzionali è generalmente considerata incompleta e insufficiente [33, 19] in quanto ci si aspetta che un agente o utente effettui la ricerca e l’utilizzo di un e-Service
in base a parametri quali: il costo, la disponibilità, la velocità, etc., oltre che sulla base del tipo di funzionalità che esso
offre. Per questo, è necessario considerare, nella classificazione, anche aspetti non funzionali legati al livello di QoS che
i servizi possono offrire.
La qualità di un e-Service viene definita in questo contesto come un insieme di attributi non funzionali che permettono di scegliere, fra i servizi che offrono funzionalità simili ma che presentano differenti livelli di qualità, quelli che
soddisfano al meglio i requisiti di qualità che l’utente richiede. Lo standard internazionale ISO 8402 (parte a sua volta
dello standard ISO 9000 [23]) descrive la qualità di e-Service come la totalità delle caratteristiche di un e-Service che
supportano la sua capacità di soddisfare necessità sia esplicitate che implicite [33]. Questo standard fornisce un insieme
di parametri o misure quantificabili (quali ad esempio, il tempo di risposta, di latenza, o l’affidabilità) che possono essere
usate per definire una classificazione, sulla base di criteri di qualità imposti dal canale, sul quale il e-Service viene fornito,
o imposti dal fornitore del e-Service stesso. Tali parametri potrebbero rimanere costanti per uno specifico e-Service o
variare invece nel corso del tempo per effetto dei cambiamenti che avvengono in un contesto di ambiente dinamico e
mobile, quale quello che stiamo considerando.
Al momento attuale, vogliamo considerare a scopo di classificazione, solo quei parametri di qualità che abbiano
la caratteristica di essere essenzialmente stabili nel tempo. Dopo aver definito delle categorie di QoS, un e-Service è
classificato in una particolare categoria sulla base dell’analisi dei valori di tali parametri che lo caratterizzano.
Per stabilire una effettiva classificazione, assumiamo di operare in uno spazio n-dimensionale, dove ognuno di n
parametri di qualità è associato ad un asse ortogonale: questa rappresentazione è possibile dato che consideriamo parametri i cui valori possono essere ordinati. Suddividiamo poi ogni asse in modo da determinare per ciascun parametro un
insieme di intervalli in cui i suoi valori possono ricadere. Lo spazio nel suo complesso risulta in questo modo suddiviso
in parti n-dimensionali (che definiamo categorie di qualità) in cui i servizi possono essere classificati dipendentemente
dai rispettivi valori dei parametri di qualità. Per esempio, se consideriamo solamente due parametri di qualità (tempo di
risposta e costo), viene definito dalla suddivisione in intervalli degli assi, uno spazio bi-dimensionale strutturato in un
insieme di categorie, come mostrato in Fig. 2.9.
cost [$/execution]
service B
high
service C
20
middle
10
service A
low
0
fast
1000
acceptable
2000
slow
response_time [msec]
Figura 2.9: Esempio di classificazione sulla base della QoS di servizi.
Supponiamo che tre servizi A, B e C, che offrono simili funzionalità, siano resi disponibili; il primo a 5 dollari per
ogni esecuzione e con un tempo di risposta garantito di 3000 msec, il secondo e il terzo offrono invece tempi di risposta
più brevi (rispettivamente, 500 e 900 msec), ma più costosi (rispettivamente, 30 e 25 dollari per esecuzione). Questi
servizi verranno classificati come in Fig. 2.9. Se, dal punto di vista dell’untente, il tempo di risposta è rilevante, i servizi
B e C e altri eventualmente classificati nella stessa categoria saranno migliori di A. Rispetto alla prospettiva considerata,
14
ogni categoria sarà identificata da un set di coppie < parametro, classe >; in questo caso i servizi A,B e C vengono classificati
come segue:
A ∈ {< response_time, slow >,< cost, low >}
B ∈ {< response_time, f ast >,< cost, high >}
C ∈ {< response_time, f ast >,< cost, high >}
2.3
Modellazione del comportamento degli e-Services
Un e-Service è un software artifact (dispiegato su Internet). Facendo un’astrazione di questa visione, si possono individuare diverse
forme dell’applicativo software in questione, ognuna delle quali riflette un particolare aspetto dello e-Service durante il suo ciclo di
vita: e-Service schema (aspetto comportamentale), e-Service implementation and deployment (aspetto implementativo) e e-Service
instance (aspetto di esecuzione).
Lo e-Service schema specifica le caratteristiche di un e-Service, in termini di requisiti funzionali e non; i requisiti funzionali
rappresentano cosa un e-Service fa. Tutte le altre caratteristiche degli e-Services, come quelle associate alla qualità, alla
privacy, alle performance, etc. costituiscono i requisiti non-funzionali. Nel nostro modello di e-Service useremo il termine
“e-Service schema”, per riferirci solo alla specifica dei requisiti funzionali.
Lo e-Service implementation e deployment indica come un e-Service è realizzato, in termini di applicazioni software corrispondenti allo e-Service schema, e delle specifiche piattaforme utilizzate. Questo aspetto riguarda la tecnologia sottostante
l’implementazione dello e-Service.
Una istanza di e-Service è una occorrenza di un e-Service che effettivamente viene eseguita e che interagisce con un client.
In generale diverse istanze di un e-Service possono essere eseguite concorremente, ed ognuna eseguita indipendentemente
dall’altra.
Quando si vuole eseguire un e-Service, un generico client ha bisogno di attivare una istanza dello e-Service installato e configurato (deployed); nel nostro modello astratto, il client può quindi interagire con l’istanza dello e-Service scegliendo ripetutamente
azioni e attendendo sia la terminazione del task che il ritorno di qualche informazione. Sulla base dell’informazione ricevuta, il client
sceglie la prossima azione da invocare, che sarà, a sua volta, eseguita dall’istanza dello e-Service in questione. In alcune circostanze,
ad esempio quando il client ha raggiunto il suo scopo, si può dare termine all’istanza dello e-Service. Comunque, in principio, un
data istanza di e-Service può interagire con un client per un numero illimitato di volte, anche infinito, fornendo così un servizio
continuo al client.
In generale quando un client invoca una istanza di un e-Service, è possibile che non tutte le azioni che richiede vengano eseguite
dall’istanza in questione, ma che alcune di esse vengano delegate ad istanze di altri e-Services, appartenenti tutti ad una stessa
comunità; tutto ciò, però, avviene in maniera del tutto trasparente per il client. Il valore aggiunto di una comunità è quello di
permettere ad un e-Service di poter delegare l’esecuzione di alcune o tutte le sue azioni ad altre istanze di e-Services (appartenenti
alla stessa comunità). In tal caso chiameremo un tale servizio e-Service composto; nel caso invece che le azioni vengano eseguite
direttamente dalla istanza dello e-Service in questione, esso verrà definito semplice. In altre parole, un e-Service semplice realizza
le azioni che offre direttamente nella sua implementazione, contrariamente ad un e-Service composto in cui ricevendo le richieste
provenienti dai client le traduce in azioni invocate su altri e-Services. In generale la comunità può essere utilizzata per poter realizzare
un e-Service target, richiesto da un client, componendo parti di istanze degli e-Services della comunità (funzione di composizione di
e-Services). Infatti, un generico utente potrebbe richiedere un servizio non fornito direttamente dalla comunità, che però, è possibile
sintetizzare (creare un nuovo servizio composto), delegando le azioni richieste ad altri e-Services della comunità, fornendo all’utente
richiedente il servizio richiesto.
Da un punto di vista comportamentale, un e-Service può avere:
una visione esterna, cioè quella di un generico client, in cui lo e-Service può essere visto come una scatola chiusa che esibisce
un certo comportamento, sottoforma di sequenze ammissibili di azioni atomiche. In altre parole lo e-Service esibisce un certo
comportamento esportato rappresentato come sequenze di azioni atomiche, con dei vincoli sull’ordine della loro invocazione.
ed una visione interna, in cui si entra nel merito di come le azioni esterne si traducono nell’esecuzione effettiva di programmi
interni o chiamate a procedure esterne di altri e-Services. Nel caso in questione è rilevante specificare se ogni azioni viene
eseguita dallo e-Service stesso o viene eseguita mediante delegazione ad altri e-Services, ovvero invocando azioni di altri
e-Services appartenenti alla stessa comunità.
15
Per catturare questi due punti di vista, si introduce la nozione di e-Service schema, costituito da due differenti parti, chiamate
external schema e internal schema rispettivamente.
Un external schema serve per specificare il comportamento esportato di un e-Service, e questo viene fatto esprimendo tale
comportamento in termini di un albero di azioni, chiamato external execution tree. Un external execution tree rappresenta, in maniera
astratta, tutte le possibili esecuzioni di tutte le possibili istanze di un e-Service; perciò una qualsiasi istanza di un particolare e-Service
esegue un path su tale albero. D’altra parte un internal schema specifica come una istanza di un e-Service esegue ogni data azione;
essa viene modellato introducendo la nozione di internal execution tree. Esso è analogo ad un external execution tree, eccetto che
ogni arco dell’albero viene etichettato oltre che dal messaggio (azione) richiesto, anche dall’istanza dello e-Service della comunità
che lo esegue. Per maggiori approfondimenti riguardo alle definizioni di external ed internal execution tree nonché delle propietà
di tali alberi e come si integrano nel concetto di composizione per e-Services, si rimanda all’articolo “A Foundational Vision of eServices” (Autori: Daniela Berardi, Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, and Massimo Mecella) riportato
in Appendice A.
Riallacciandoci al modello degli external ed internal execution tree, un e-Service schema (sia internal che external), può essere
ben rappresentato utilizzando un numero finito di stati (passaggio da una chiamata di un comando alla chiamata successiva di un’altra
azione), ovvero mediante un Automa a Stati Finiti Deterministico (DFA). Infatti un external execution tree (per il momento ci
limitiamo solo al comportamento esterno dello e-Service) può essere sintetizzato mediante una macchina a stati finiti deterministica;
questo tipo di modello racchiude in sé (mediante gli stati e le transizioni dell’automa) la dinamica, il comportamento di un servizio,
dal punto di vista del client (un path nell’albero esterno di esecuzione corrisponde ad un percorso all’interno della macchina a stati
finiti rappresentante lo e-Service). Ovviamente tale modello, sotto alcuni punti di vista, è limitativo, però, sotto altri, offre una serie di
strumenti formali per poter dimostrare alcune proprietà, soprattutto riguardanti la sintesi di composizione degli e-Services. Secondo
tale modello, il comportamento di un e-Service può essere rappresentato mediante una sequenza di transizioni (in associazione ai
percorsi definiti nello external schema); in tal modo, mediante una analisi della semantica operazionale, si può ragionare sul come gli
e-Services possono evolversi a fronte di determinati input e quali risultati, in accordo alle azioni invocate, possono produrre (in altre
parole si possono effettuare dei ragionamenti predittivi sulla base dello stato attuale dello e-Service - sequenze di azioni eseguite
fino a quel momento - e sull’azione richiesta da un client). Per una maggior trattazione riguardo a tale modello proposto si rimanda
all’articolo “Finite State Automata as Conceptual Model for e-Services” (Autori: Daniela Berardi, Fabio De Rosa, Luca De Santis
and Massimo Mecella), in cui vengono riportate le definizioni formali di e-Service (secondo la definizione di un Automa a Stati
Finiti Deterministici), ed un esempio completo di applicazione di tale modello ad un caso reale.
16
3. Transazioni
Autori Roma1
In questa sezione viene definito il concetto di Business Transaction (BT), nell’ottica della realizzazione di proprietà transazionali per
gli e-Service.
In generale una piattaforma di comunicazione tra e-Service è il punto di appoggio per la conduzione di processi inter-organizzativi.
L’automazione di processi di business complessi non può essere realizzata adeguatamente con gli attuali sistemi di scambi di messaggi ma necessita di un apposito framework che assicuri che le transazioni che costituiscono il processo siano condotte secondo
specifiche regole. Queste piattaforme devono dunque fornire gli strumenti per definire la logica di business, il formato e la sequenza
di messaggi necessari per conseguire il risultato voluto. L’interazione tra diverse parti, sia di tipo Business to Business che di tipo
Commerce to Business, richiede alcune garanzie di sicurezza ed affidabilità del sistema di comunicazione utilizzato. In un ambiente
caratterizzato da una grande vastità di differenti protocolli per scambiare messaggi e informazioni, da meccanismi di comunicazione
essenzialmente asincroni e non affidabili, e in generale da una diffusa eterogeneità, fornire tali garanzie può essere una sfida notevole. Anche la sincronizzazione delle attività che vengono svolte all’interno dei singoli partecipanti al processo deve essere gestita
tenendo conto della natura dello scenario dove avviene la comunicazione (ad esempio il Web); queste attività spesso devono essere
viste come un’unica componente logica di lavoro che presenti un solo risultato visibile all’esterno (commito abort), e cioè devono
essere viste come una Business Transaction.
Con il termine Business Transaction si indica un cambiamento consistente nello stato di un processo condotto tra diverse organizzazioni. Una semplice BT può essere rappresentata da un ordine di alcuni beni presso una compagnia; complicando un po’ di più
le cose si possono aggiungere altre attività, quali il processo di pagamento, la spedizione, la gestione di debiti/crediti ecc.
Il concetto di transazione è molto diffuso nella gestione di grandi collezioni di dati; un sistema di gestione di basi di dati, ad
esempio, conduce le transazioni in modo da garantire la consistenza dei data records anche quando vengono eseguite più operazioni
in concorrenza su di essi. In generale le proprietà delle transazioni sono conosciute come proprietà ACID, ossia che assicurano
Atomicità, Consistenza, Isolamento e Persistenza (Durabilità).
Una BT richiede le stesse proprietà ma, poiché esiste in un ambiente profondamente diverso da quello di un Database, deve
affrontare problematiche di altro tipo. Comunemente le transazioni vengono realizzate tramite protocolli di tipo Two Phase Commit
(2PC), ma nel mondo degli e-Service si incontrano alcuni problemi che ci impediscono di usare tali protocolli in tutte le circostanze.
Infatti una BT può avere una durata molto lunga (anche di ore o giorni se l’esito della transazione deve dipendere da decisioni
umane) e un’organizzazione difficilmente accetterebbe di vedere le proprie risorse bloccate per tutto questo tempo, sia perché ciò
impedirebbe rapporti con altri clienti che vogliono accedere a quelle risorse, sia perché ci si esporrebbe a facili attacchi di Denial of
Service da parte di pirati informatici.
Bisogna poi tenere presente che ogni e-Service avrà dei meccanismi per la gestione dei dati e per la comunicazione che saranno
generalmente diversi da quelli di altri, ma che dovranno necessariamente essere resi compatibili se si vuole raggiungere un buon
livello di integrazione.
Un Business Transaction Framework (BTF) deve quindi essere costruito al di sopra di una piattaforma per l’orchestrazione di
e-Services e deve fornire principalmente:
un business transaction model per definire transazioni a lungo termine, transazioni a breve termine, gestione delle eccezioni
e meccanismi di compensazione.
un set di protocolli di coordinamento (coordination protocols) che permettano di gestire le operazioni eseguite dai vari eServices e creare il contesto necessario per propagare dati e informazioni tra questi. Inoltre i protocolli di coordinamento
permettono di nascondere l’eterogeneità delle tecnologie utilizzate dagli e-Services garantendo un’alta interoperabilità.
un supporto per protocolli di business (business protocols), e cioè protocolli che definiscano l’ordine con cui i partner si
scambiano messaggi e che colgano ogni altro aspetto comportamentale del processo. Protocolli di questo tipo possono anche
servire ai partner per scambiarsi informazioni prima di effettuare la transazione e per prendere accordi sulle modalità di
esecuzione.
Grazie al transaction model, una BT può essere vista come uno script che indica la composizione e l’interazione dei processi
e degli oggetti richiesti per raggiungere un risultato comune. A run-time, un BTF stabilirà quali sono i confini di una BT, gestirà il
flusso dei dati e del controllo del processo e si troverà a dover distinguere tra e-Service atomici (ossia che garantiscono l’atomicità
delle operazioni svolte) e non atomici per prendere (o delegare al cliente) decisioni che assicurino il corretto svolgimento della
transazione.
17
3.1 Classificazione e organizzazione delle BT
Nelle molte trattazioni sull’argomento, quando si parla di BT si distingue sempre tra transazioni a breve termine e a lungo termine,
e spesso si parla anche di Business Conversation. Con questa sezione vogliamo innanzitutto fornire una classificazione illustrando
queste distinzioni, e successivamente vogliamo riportare dei criteri proposti per organizzare le strutture che andranno a concretizzare
le BT.
3.1.1
BT a breve e a lungo termine
A causa della natura dei processi interaziendali e della composizione del Web, una BT può avere tempi di esecuzione molto lunghi.
Generalmente si distinguono due categorie di BT: BT a breve termine e BT a lungo termine.
Le BT a breve termine (o BT atomiche) sono costituite da interazioni su scala ridotta che posso essere eseguite garantendo le
proprietà ACID in modo molto simile alle transazioni classiche. Una BT atomica vedrà come unico risultato o un commit o un abort;
in caso di abort è garantito il ritorno allo stato iniziale o tramite roll-back o tramite una compensazione completa. Le BT a breve
termine possono essere annidate mantenendo tutte le loro caratteristiche.
Le BT a lungo termine (o semplicemente BT) possono essere viste come un insieme di BT, sia a breve termine che a lungo
termine, legate da una logica di business. Le singole transazioni possono avere esiti diversi, nel qual caso il risultato finale della BT
dipende dalla particolare logica o da una decisione esplicita del cliente che ha iniziato la transazione. Anche le BT a lungo termine
possono essere quindi annidate a piacimento; questo garantisce una grande flessibilità e può aiutare a definire transazioni complesse
più robuste e più facili da gestire in caso di errori ed eccezioni.
Quando una transazione è annidata l’esito delle transazioni figlie dipende in ogni caso da quello della BT principale. Come
vedremo meglio in seguito, infatti, una transazione può essere costretta ad abortire anche dopo aver eseguito il commit.
Transazioni atomiche e BT si differenziano per molti aspetti sia tecnici che organizzativi. Quando si sta eseguendo una transazione tra diversi partner ci saranno alcune operazioni che ognuno di questi può svolgere indipendentemente, e ce ne saranno altre
che richiedono il contributo di più parti coinvolte. Principalmente è da questo che nasce la distinzione tra BT atomiche e non. Tutto
ciò che riguarda una sola organizzazione generalmente viene svolto in una transazione atomica mentre le transazioni a lungo termine
si rendono più adatte per gestire le interazioni con gli altri partecipanti, specialmente quando si devono prendere decisioni che non
possono essere automatizzate.
È importante tenere presente che le BT a lungo termine coinvolgono una grande quantità di risorse e quindi sono formate
solitamente da un maggior numero di transazioni più semplici. Di conseguenza la perdita dello stato di una BT ha grosse ripercussioni
su un’organizzazione poiché può racchiudere molte informazioni preziose. Ad esempio, la perdita dello stato di un cliente non solo
può causare l’annullamento di una particolare vendita, ma può costare l’intera relazione con quel particolare cliente. È chiaro
allora che bisogna stare particolarmente attenti all’affidabilità dei mezzi con cui viene condotta una BT. Gli stati della transazione
dovrebbero essere memorizzati su supporti sicuri (ad esempio sistemi RAID) mentre i messaggi scambiati dovrebbero sempre essere
accompagnati da “ack” e numeri di sequenza in modo da assicurare per ogni operazione richiesta una semantica del tipo exactly
once.
3.1.2
Business Conversation
Il mondo degli e-Services comunica tramite conversazioni (conversation). Una business conversation [12] è un’interazione a lungo
termine tra due o più e-Services durante la quale vengono scambiati messaggi e documenti. Questi scambi possono servire per
prendere accordi, compilare ordini di acquisto, comunicare disponibilità, trattare prezzi e modalità di pagamento o per molti altri
scopi. Data la natura di queste conversazioni, spesso cruciale in un rapporto di affari, sorge la necessità di garantire proprietà
transazionali. Una business conversation può allora essere vista come un insieme di BT correlate tra di loro. I messaggi possono
dover essere scambiati sia in modo sincrono che in modo asincrono e spetta al BTF fornire i mezzi per essere sicuri che la sequenza
dei messaggi rispetti delle regole predefinite.
Una caratteristica importante delle business conversation è la possibilità di definire quali parti della conversazioni devono essere
transazionali e quali no. Considerare l’intera conversazione come un’unica BT non è sempre necessario e limiterebbe troppo la
flessibilità delle comunicazioni tra e-Services.
3.1.3
Criteri di atomicità
Abbiamo visto che l’elemento di base di una BT è una transazione atomica. In letteratura sono presenti diversi criteri di atomicità,
divisi in tre categorie, a cui ogni transazione dovrebbe riferirsi a seconda del contesto in cui è immersa:
18
System-level atomicity. Questa categoria comprende un solo criterio di atomicità applicabile ad ogni operazione in un eService che sia dichiarata di natura transazionale
Service request atomicity. Una singola operazione in un e-Service viene eseguita completamente o non viene eseguita affatto,
come se fosse un unico blocco. Questa proprietà viene garantita da un qualche meccanismo interno al sistema che offre il
servizio, senza dover dipendere da fattori esterni
Business interaction-level atomicity. Le primitive di questa categoria servono alle organizzazioni che vogliono condurre un
affare per negoziare i termini del loro rapporto prima di prendere accordi definitivi e iniziare il processo vero e proprio. Queste
primitive si inseriscono nel contesto dei protocolli di business e nello scambio di documenti.
Non-repudiation atomicity. I partecipanti ad una transazione che fa uso di questa primitiva devono essere tutti inizialmente autenticati. La transazione viene poi registrata e firmata con un meccanismo di firma digitale in modo da poter essere analizzata
ed utilizzata per risolvere eventuali dispute legali.
Conversation Atomicity. Questa primitiva comprende i meccanismi di Non-repudiation atomicity e fornisce la possibilità
a due partecipanti di vedere un intera sequenza di messaggi come un unico blocco. L’intera conversazione quindi viene o
accettata da entrambe le parti, o rifiutata. Questo fatto aumenta la robustezza della transazione in quanto in presenza di errori
(crash di sistema, caduta di connessione, eccezioni nella logica di business ecc. . . ) entrambe le parti possono essere sicure
che il rispettivo partner è ritornato allo stato consistente che esisteva prima dell’inizio della conversazione. Per realizzare una
tale primitiva occorrono complessi sistemi di compensazione e di recupero per invertire gli effetti parziali delle transazioni
non completate.
Contract Atomicity. Poiché le interazioni tra diverse organizzazioni avvengono principalmente tramite contratti è utile pensare
ad una primitiva che racchiuda tutte le proprietà che deve garantire, appunto, un contratto. Una contract atomic BT è essenzialmente una transazione conversation atomic che coinvolge due o più partecipanti e stabilisce i termini legali, le condizioni
e gli impegni che questi devono rispettare. Se la transazione va a buon fine tutti i partecipanti devono considerarsi vincolati
legalmente agli accordi presi.
Operational-level atomicity. Le primitive di atomicità a livello operazionale si occupano di gestire gli aspetti dell’effettivo
svolgimento di un processo di business, di cui si siano già fissati tutti i termini. In particolare, poiché la maggior parte delle
BT riguardano processi di commercio elettronico, vengono definite tre primitive relative alla consegna ed alla verifica del
pagamento di prodotti (tangibili o no) acquistati.
Payment atomicity. Questa primitiva riguarda protocolli per il trasferimento di fondi da una società ad un’altra. A seconda
della semantica dell’applicazione che ne fa uso, una transazione supportata da questo tipo di atomicità dovrebbe essere anche
una transazione contract atomic.
Goods atomicity. Oltre a comprendere tutti gli aspetti della payment atomicity, la goods atomicity si interessa anche della
consegna del bene acquistato. Il bene verrà consegnato solo dopo che il pagamento è stato effettuato con successo. La
consegna ed il pagamento sono quindi entrambi parte di una stessa BT. Data la sua complessità, l’abort di una good atomic
BT non può essere gestito in modo automatico ma deve essere supportato da una apposita logica di business nell’applicazione
sovrastante.
Certified delivery atomicity. Questa primitiva aggiunge si basa sulla precedente ed aggiunge la possibilità per il cliente di
esprimere la propria soddisfazione riguardo l’esito della transazione. Una transazione quindi non può considerarsi completata finché tutte le parti coinvolte nello scambio di beni non abbiano verificato di aver ricevuto quello che effettivamente si
aspettavano degli accordi presi.
Questi criteri servono per costruire delle primitive che dovrebbero essere integrate in un’infrastruttura per e-Service transazionali. In questo contesto si raggiunge un punto di contatto tra aspetti tecnici ed organizzativi in quanto si cerca di costruire pochi
metodi che siano invocabili direttamente dalle applicazioni specifiche di un’organizzazione e che siano in grado di garantire ad una
transazione tutte le proprietà richieste. Molte di queste primitive vogliono di gestire aspetti molto particolareggiati di una transazione
e rappresentano esse stesse delle BT a lungo termine. Una piattaforma che le supportasse tutte sarebbe piuttosto potente e permetterebbe di comporre BT complesse con grande facilità. Al di là della loro effettiva implementazione, queste primitive possono essere
viste come un’ulteriore classificazione di ciò che bisogna fornire a delle organizzazione per permettere loro di condurre delle BT.
19
3.1.4
Divisione in tre fasi
Un modo di organizzare lo svolgimento di una BT potrebbe consistere nel distinguere tre fasi diverse. Poiché il momento critico di
una BT è il blocco delle risorse, che costituiscono il cuore dell’attività di un’organizzazione (come il database dei beni in vendita
tramite un e-Service), può essere molto vantaggioso svolgere delle attività di contorno in modo da poter avere un idea dell’esito
della transazione prima ancora di iniziarla a tutti gli effetti. Questa analisi ci permetterebbe di ridurre il tempo in cui le risorse sono
bloccate e limiterebbe il numero delle BT fallite (e quindi il numero delle azioni di compensazione). Più in dettaglio, avremmo:
Una fase preliminare (pre-transaction phase) durante la quale le parti coinvolte si scambiano informazioni sullo stato attuale delle
risorse da trattare nel processo. Prezzi, disponibilità, tempi e modalità di consegna sono esempi di questo genere di informazioni.
Durante questa fase un cliente potrebbe compilare un ordine di acquisto senza bloccare risorse e quindi permettendo ad altri clienti
di compilare altri ordini degli stessi beni contemporaneamente. Se nel frattempo avvengono dei cambiamenti, magari causati da
transazioni di acquisto andate a buon fine con la conseguente diminuzione della disponibilità di un bene, i clienti vengono informati
in tempo reale e possono modificare il loro ordine di conseguenza. Questa modalità offre anche la possibilità di gestire diversi livelli
di priorità ai vari clienti di un’organizzazione, permettendo, ad esempio, solo ad alcuni di bloccare effettivamente le risorse già al
momento della compilazione dell’ordine. Tutte le informazioni scambiate in questa fase possono essere viste come una sorta di
business conversation.
Una fase principale (main-transaction phase) in cui tutte le potenzialità del BTF vengono sfruttate per portare avanti le operazioni
dislocate sui vari sistemi coinvolti e concludere così la transazione vera e propria. In questa fase si potranno svolgere meccanismi di
tipo 2PC, di gestione delle eccezioni e di compensazione.
Una terza fase conclusiva (post-transaction phase) in cui le parti coinvolte verificano che tutto si sia svolto secondo gli accordi e
comunicano il loro livello di soddisfazione. Anche qui si farà uso di business conversation per la comunicazione. Queste conversazioni servono anche per dare la possibilità alle diverse organizzazioni di decidere i provvedimenti da prendere qualora la transazione
effettuata non fosse coerente con i termini stabiliti inizialmente. Volendo fornire una correlazione tra i criteri di atomicità e le tre fasi
di una BT, potremmo dire che le primitive di non-repudiation, conversation e contract atomicity sarebbero di supporto alla prime
e alla terza fase mentre le primitive di non-repudiation, conversation, payment, goods e certified delivery verrebbero utilizzate nella
fase principale.
3.2 Stato dell’arte sulle proprietà delle Transazioni
Dopo aver dato una descrizione di alto livello delle BT e dell’ambiente in cui si inseriscono, andiamo ad analizzare le tecniche
comunemente utilizzate per assicurare le proprietà delle transazioni. Inizieremo ricordando in cosa consistono le proprietà ACID,
per poi addentrarci nei meccanismi dei protocolli di tipo 2PC e di compensazione. Infine forniremo una rappresentazione dello stato
di una transazione abbastanza generale e riscontrabile in molte delle soluzioni presentate.
3.2.1
Proprietà ACID
Abbiamo detto che di base dobbiamo assicurare al meglio delle nostre possibilità le proprietà ACID di una transazione. Di seguito
ne riportiamo una breve descrizione:
L’atomicità rappresenta il fatto che la transazione è un’unita indivisibile di esecuzione; o vengono resi visibili tutti gli effetti di
una transazione, oppure la transazione non deve avere alcun effetto. Viene quindi seguito un approccio “tutto o niente” dove non è
possibile lasciare la transazione in uno degli stati intermedi attraversati durante l’elaborazione
La consistenza richiede che al termine della transazione tutti i dati manipolati siano coerenti con la semantica della transazione
stabilita da una logica di business.
L’isolamento richiede che l’esecuzione di una transazione sia completamente indipendente dalla contemporanea esecuzione di
altre transazioni. In un ambiente distribuito l’isolamento nasconde anche gli stati intermedi di una transazioni rendendoli inaccessibili
dall’esterno.
La persistenza invece richiede che l’effetto di una transazione che abbia eseguito il commit correttamente non venga più perso.
Consistenza e persistenza sono due proprietà che possono essere mantenute senza particolari difficoltà anche nel mondo degli
e-Service. L’isolamento invece in alcune circostanze deve essere necessariamente rilassato e permettere una certa interazione con
l’esterno anche durante lo svolgimento della transazione. La proprietà più importante e difficile da mantenere è però l’atomicità.
Senza atomicità le applicazioni che vogliono concludere una transazione sarebbero costrette ad inviare una grande quantità di messaggi per far fronte adeguatamente ad ogni possibile situazione di errore; anche la consistenza sarebbe una proprietà più difficile da
assicurare e nascerebbe la necessità di logiche ad hoc per gestire l’intero flusso della transazione.
20
3.2.2
Two Phase Commit nel mondo degli e-Service
L’approccio più diffuso nei sistemi locali per garantire le proprietà ACID è l’uso di un protocollo Two Phase Commit. Questo
protocollo funziona grazie ad un coordinatore che dialoga, tramite un canale di comunicazione, con le applicazioni che devono
eseguire la transazione. Quando tutte le applicazioni sono state informate delle operazioni da svolgere, il coordinatore invia un
messaggio prepare. A fronte di questo comando, le applicazioni bloccano le risorse coinvolte nella transazione ed eseguono le
operazioni. In base al risultato ottenuto comunicano al coordinatore la loro capacità di eseguire correttamente il commit o meno. Il
coordinatore quindi riceve queste comunicazioni dai partecipanti e, se tutti possono completare la transazione con successo, invia
un messaggio di commit per far sì che i cambiamenti vengano resi persistenti e le risorse vengano rilasciate. Se anche soltanto un
partecipante non è in grado di svolgere il suo compito, il coordinatore invia un messaggio di abort per tornare allo stato preesistente.
Il punto fondamentale di questo protocollo è quindi il blocco delle risorse finché non si è sicuri che tutto sia stato eseguito
correttamente. Come già accennato nelle precedenti sezioni, questa pratica non è adatta in ambiente Web. In primo luogo il Web
è caratterizzato da comunicazioni asincrone e non affidabili ; questo ostacola l’implementazione di un protocollo 2PC in quanto il
coordinatore non può essere certo del tempo impiegato da un partecipante a rispondere ai suoi messaggi di prepare e di commit e
rischia di attendere indefinitamente. Anche l’uso di timeout per ovviare a questo problema non offre una valida soluzione perché
timeout troppo corti possono causare l’abort di un numero eccessivo di transazioni che invece sarebbero andate a buon fine, mentre
timeout troppo lunghi possono tenere molte risorse bloccate inutilmente per tempi inaccettabili. In oltre, qualora il risultato di una
transazione dipendesse da una decisione umana, un timeout diventerebbe improponibile.
Secondariamente bisogna considerare che un’organizzazione che partecipi ad una transazione difficilmente sarebbe disposta a
bloccare le proprie risorse per lungo tempo. Questo infatti impedisce di gestire in concorrenza più richieste sulle stesse risorse,
limitando quindi la capacità del servizio di soddisfare i clienti, e rende l’organizzazione vulnerabile ad attacchi di Denial of Service.
In un sistema non molto robusto, infatti, basterebbe che un pirata inizi una transazione senza mai dare il comando di commit, per
effettuare un tale attacco.
È principalmente per questi motivi che si è ormai diffusa l’idea di rilassare i vincoli imposti dalle proprietà ACID quando si ha
a che fare con BT a lungo termine che spaziano tra i domini di più organizzazioni diverse.
Data la loro natura, le BT a breve termine possono essere implementate secondo i classici protocolli 2PC. Tipicamente infatti le
operazioni di una BT a breve termine sono completamente automatizzate (e quindi eseguite in tempi brevissimi) e non escono dai
confini di un’organizzazione.
Le BT a lungo termine, invece, vengono affrontate in maniera diversa. Attualmente non esistono molte implementazioni di
sistemi che gestiscono BT di questo tipo, e i modelli proposti seguono più o meno tutti uno stesso approccio. Una BT viene
considerata come un insieme di transazioni a breve termine. Il coordinatore fa in modo che ognuna di queste venga eseguita
indipendentemente dalle altre e raccoglie i vari esiti che gli giungeranno in diversi istanti di tempo. Generalmente alcuni saranno
dei commit e altri degli abort. A seconda di quali transazioni sono andate a buon fine e quali no, verrà presa una decisione (da una
specifica applicazione di business o direttamente dal cliente) sull’esito globale della BT.
3.2.3
Abort di una BT e compensazione
Una BT può quindi effettuare un commit anche se alcune delle transazioni che la compongono hanno effettuato un abort. Il punto
più delicato da affrontare è cosa fare delle transazioni figlie che hanno effettuato il commit se alla fine si è deciso per abortire la BT.
Questo è il problema che deriva dal fatto di non tenere bloccate le varie risorse finché la transazione non è stata completata. L’unica
soluzione, che di fatto rappresenta quasi una scuola di pensiero contrapposta a quella dl 2PC, è la compensazione.
Quando una transazione atomica fallisce viene garantito un roll-back automatico, ma per una BT occorre iniziare delle transazioni di compensazione che svolgano le operazioni inverse di quelle fatte da tutte le transazioni che inizialmente avevano eseguito il
commit. Questo approccio, noto come backward recovery, non è sempre possibile poiché può capitare che alcune operazioni siano
irreversibili. In questo caso si deve procede secondo un altro approccio (forward recovery) che dà il via a nuove transazioni le quali,
preso atto dei cambiamenti ormai avvenuti, riconducono il processo ad uno stato “simile” a quello di partenza. Una situazione di
questo tipo può verificarsi, ad esempio, quando viene annullato un ordine per l’acquisto di merci che sono già state spedite. Infatti,
anche se le merci vengono rimandate indietro, bisogna comunque far fronte alle spese di spedizione e di conseguenza lo stato finale
non potrà mai essere uguale a quello di partenza. E’ chiaro che questi meccanismi necessitano di una logica di business che dipende
completamente dal contesto della transazione.
3.2.4
Stato di una transazione
Nello svolgere una transazione bisogna avere a disposizione degli strumenti per tenere traccia del suo ciclo di vita. Una transazione,
in oltre, ha bisogno di gestire anche una certa quantità di dati aggiuntivi che si accompagnano ai messaggi e ai documenti che
la compongono ; a seconda del processo che viene trattato può essere più o meno importate verificare l’identità dei partecipanti
21
indicandone esplicitamente i ruoli, il numero di sequenza dei messaggi accompagnato magari da time-stamp, o la relazione con
altre transazioni (ad esempio se la transazione è parte di una BT annidata). L’idea comunemente utilizzata per organizzare questo
tipo di dati è la creazione di un contesto (context), ossia di una struttura con i campi necessari per le informazioni da mantenere.
Ogni contesto è legato ad una particolare transazione ed ha un codice unico di identificazione per poter distinguere più transazioni
che avvengono in concorrenza. Il contesto viene quindi scambiato tra i partecipanti, tipicamente inserito in appositi messaggi o
nell’header di quelli richiesti dalla transazione. Tutte le attività svolte vengono registrate nel contesto che così ha anche lo scopo di
tenere traccia dello stato di una transazione. Facendo un analisi ad alto livello possiamo identificare sette stati di una transazione:
Attivo : la transazione è attiva e sta eseguendo le operazioni che la compongono
Preparazione al completamento : la transazione ha svolto tutte le operazioni e sta svolgendo le attività necessarie per rendere
persistenti i cambiamenti. In questo stato rientra anche lo svolgimento dei passi principali del protocollo 2PC per le transazioni
atomiche o il coordinamento delle transazioni figlie per BT annidate.
Completato : la transazione ha eseguito tutte le operazioni con successo
Preparazione all’aborto : la transazione non è andata a buon fine e sta effettuando le operazioni necessarie per tornare allo stato
di partenza. Questo può voler dire dare il via a transazioni di compensazione e coordinare l’abort delle transazioni figlie in caso di
BT annidate.
Abortito : la transazione non è andata a buon fine ed ha svolto le operazione necessarie per tornare ad uno stato consistente.
Preparazione alla compensazione : la transazione sta effettuando le operazioni necessarie per disfare il lavoro precedentemente
completato.
Compensato : la transazione ha compensato con successo tutte le attività precedentemente completate.
È importante notare che gli unici stati finali per una BT sono abortito o compensato. Questo perché, a causa delle ragioni legate
all’annidamento di transazioni che abbiamo già spiegato, può accadere che una BT debba essere annullata anche se ha effettuato con
successo il commit.
3.3 Piattaforme e protocolli esistenti per le Transazioni
3.3.1
Transaction Internet Protocol
Le prime forme di commercio elettronico erano basate su protocolli proprietari, spesso strettamente legati ad una particolare piattaforma middleware. L’interazione tra diverse compagnie era quindi vincolato dalla tecnologia utilizzata e mancava totalmente della
flessibilità e dinamicità necessaria per condurre processi di business complessi. Il Transaction Internet Protocol (TIP) [13] è stato
il primo protocollo standardizzato per supportare transazioni soprattutto commerciali. Il grande vantaggio di TIP è che è completamente basato sulla suite di protocolli Internet ormai presente in ogni sistema. Questo non solo lo rende facilmente implementabile
ma garantisce senza particolari sforzi realizzativi una completa compatibilità.
TIP è basato su TCP/IP e implementa sia il protocollo Two Phase che il protocollo One Phase Commit. Viene stabilita una
differente connessione TCP/IP per ogni nodo partecipante alla transazione. Lo scopo principale di TIP è definire una macchina a
stati finiti per ogni connessione coinvolta in modo da condurre tutti i nodi attraverso gli stessi stati e quindi verso un risultato comune.
I protocolli precedenti TIP erano basati su un unico canale di comunicazione condiviso dai protocolli propri dell’applicazione e
quelli specifici della transazione ; questo li rendeva piuttosto complessi e di difficile implementazione. La novità introdotta da TIP è la
divisione delle comunicazioni in due canali separati. Le applicazioni dialogano attraverso il primo mentre i corrispettivi Transaction
Manager (TM) dialogano attraverso il secondo. Queste connessioni sono essenzialmente di tipo peer-to-peer e permettono di
effettuare un multiplex più transazioni sullo stesso canale.
TIP prevede due modi per propagare una transazione tra i vari nodi. Un modo Push prevede che il TM di chi inizia il processo
propaga verso un altro nodo l’identificatore della transazione prima ancora che siano coinvolti i Resource Managers (RM). Diversamente nel modo Pull il cliente si rivolge al RM di un altro nodo per chiedere una risorsa e questo a sua volta si rivolge al proprio TM
per generare un identificatore di transazione e propagarlo. In entrambi i modi il TM di chi inizia la transazione sarà quello primario
e gli altri saranno i secondari.
La comunicazione tra TM è di tipo command-response, dove il TM primario invia i comandi e i secondari le risposte. I comandi
definiti in TIP realizzano il protocollo 2PC e gestiscono il modo di comunicazione (push/pull), il multiplexing e l’identificazione
delle transazioni.
Attualmente le varie implementazioni di TIP sono fornite tramite delle API, scritte in Java o in altri linguaggi, che le applicazioni
utilizzano per creare e comunicare con i propri TM.
22
3.3.2
Tentative Hold Protocol
Il Tentative Hold Protocol (THP) [24], è stato pensato per lavorare in comunione con altri protocolli di supporto alle BT. THP
realizza quasi completamente la prima delle tre fasi descritte in precedenza. Il protocollo infatti offre la possibilità di acquisire dei
tentative hold sulle risorse, senza quindi bloccarle realmente, in modo da minimizzare il numero di transazioni cancellate e ridurre i
tempi del 2PC.
Nel THP, l’applicazione client interagisce con un Client Coordinator (CC) richiedendo dei nuovi tentative holds, recuperando
informazioni sulle risorse o cancellando holds vecchi. Il CC a sua volta interagisce con i Resource Coordinators (RC) inviando
tutte le richieste per soddisfare le esigenze del client. Sul lato Client viene mantenuto un database (Client-side Persistent Store) che
memorizza lo stato di tutti gli holds acquisiti ed un log delle attività.
Il RC, che ovviamente risiede nel sistema del proprietario delle risorse, risponde alle richieste del CC e invia informazioni su
eventuali cambiamenti dello stato delle risorse. In particolare può capitare che un RC avverte un CC di cancellare un hold perché la
risorsa non è più disponibile.
Il RC interagisce anche con il Rules Integration Module (RIM) per determinare se una richiesta deve essere accettata e per
quanto tempo; inoltre il RC è responsabile di tenere traccia di tutti gli hold attivi, di cancellarli quando scadono i rispettivi timeout e
di informare i CC interessati.
Il proprietario delle risorse deve quindi fornire anche il RIM, un entità che mantiene le regole di business che devono essere
osservate. Il RIM garantisce una grande flessibilità in quanto grazie ad esso è possibile applicare politiche diverse a seconda del tipo
di cliente, fissare time out più o meno lunghi per un dato hold o informare clienti privilegiati quando certe risorse sono state richieste
da altri (in modo da permettergli di iniziare subito un protocollo di tipo 2PC ed assicurarsi la disponibilità delle risorse).
Di seguito mostriamo un diagramma che illustra gli stati attraversati da un singolo tentative hold [25] nel suo ciclo di vita.
Le comunicazioni di THP sono basate su messaggi XML. Qualsiasi protocollo di Internet in grado di veicolare messaggi XML
può quindi essere utilizzato per THP.
I servizi offerti dai client Coordinators e dai Resource Coordinators sono modellati in WSDL e quindi possono essere facilmente
inseriti in contesti di ricerca dinamica come UDDI.
3.3.3
Business Transaction Protocol
L’intento dell’OASIS Business Transaction Protocol (BTP) [28] è quello di fornire un supporto per interazioni di più e-Services su
canali di comunicazione potenzialmente non affidabili, in modo che tutti i partecipanti possano giungere ad un unico risultato per le
transazioni condotte.
Le transazioni all’interno del BTP sono di due tipi:
Transazioni atomiche (atoms), distribuite su scala ridotta e di breve durata, portate avanti da protocolli di tipo 2PC. Queste
transazioni mantengono tutte le proprietà ACID tranne che per un aspetto dell’isolamento ; infatti la visione dello stato interno della
transazione è gestita dal e-Service e può essere consentita anche ad agenti esterni. Gli atoms sono molto simili alle transazioni a
breve termine, ma non possono essere annidate.
Transazioni composite (cohesion), costituite da aggregazioni di atoms e caratterizzate da un vincolo di atomicità rilassato. Le
choesion sono del tutto identiche alle transazioni a lungo termine descritte nella precedente sezione.
Una generica transazione del BTP è iniziata da un’applicazione client che assume il ruolo di initiator. L’initiator invia messaggi
a degli e-Services per invocarne i metodi. Quando un initiator vuole iniziare una transazione invia una richiesta createTransaction
che viene intercettata dal suo transaction coordinator. Il coordinatore è quella componente software che implementa il BTP : gestisce
la lista dei partecipanti autorizzando le varie parti ad unirsi o a lasciare la transazione in corso, invia ai partecipanti i messaggi per
coordinare le fasi della transazione (prepar, vote, confirm, cancel, ecc.) e può decidere l’esito di una transazione atomica.
Il coordinatore dell’initiator tipicamente assume il ruolo di main coordinator (possono esistere delle topologie ad hub dove
il main coordinator è sempre, appunto, quello presente nell’hub), che è unico per ogni transazione. Il main coordinator, guida
l’esecuzione del protocollo per la relativa BT. Ogni altro partecipante sarà supportato dal proprio transaction coordinator che sarà
subordinato al principale. Un partecipante è una specifica applicazione che deve essere in grado di rispondere ai messaggi di
coordinamento e di svolgere le attività necessarie. I partecipanti possono richiedere tramite i propri coordinatori che un set di
operazioni sia svolto in una transazione atomica con un messaggio di enroll o possono annullare l’esecuzione di una transazione
atomica da loro richiesta tramite un messaggio di resing. Inoltre i partecipante devono poter seguire un protocollo di terminazione
della transazione, rendendo permanenti i risultati delle operazioni svolte o facendo roll-back. È importate notare che BTP non indica
esplicitamente come i partecipanti devono effettuare tali operazioni, ma solo che devono poterle svolgere in modo da garantire le
proprietà richieste dal tipo di transazione in corso.
L’initiator nel dare l’avvio alla transazione crea un transaction context che viene propagato insieme ai vari messaggi scambiati
tra tutti i partecipanti. Il transaction context specifica il tipo di transazione (atomic o cohesion), l’identificativo della transazione
e l’identità dell’initiator insieme al suo indirizzo. Ogni partecipante diventa consapevole di essere parte di una transazione solo
23
quando riceve il relativo transaction context. Quando un’applicazione riceve un messaggio contenete un transaction context il suo
coordinatore lo estrae e controlla a quale transazione si riferisce. Se la transazione ancora non è nota, il coordinatore informa
l’applicazione e invia una richiesta per essere registrato tra i partecipanti. Da questo momento il coordinatore si comporterà da
subordinato nei confronti del coordinatore principale di quella transazione.
Quando l’initiator decide di terminare la transazione il main coordinator informa tutti i suoi subordinati ed insieme ad essi
esegue il protocollo di terminazione.
3.3.4
WS-Coordination & WS-Transaction
WS-Coordination [14]e WS-Transaction [15] sono due specifiche che completano il framework di BPEL [16] per la composizione
e l’interazione di e-Services. WS-Coordination fornisce protocolli specifici per coordinare le azioni eseguite sui vari e-Services.
Questi protocolli permettono infatti di creare dei context e di propagarli attraverso un’apposita struttura.
Il framework di WS-Coordination descrive un Coordination Service che è composto da tre componenti principali:
Un Activation Service che definisce le operazioni per creare il Coordination Context.
Un Registration Service che definisce le operazioni necessarie per permettere ad un e-Service di registrarsi per partecipare ad
un determinato protocollo di coordinamento.
Un set di protocolli di che supportino differenti Coordination Types. Sia i Coordination Context che i Coordination Cervices
sono descritti da documenti XML (o più precisamente WSDL nel caso dei service).
Un Coordination Context è usato per propagare le informazioni di coordinamento. Viene inserito nei messaggi scambiati
tra i partecipanti principalmente per indicare il tipo di coordinamento e le eventuali estensioni, e per fornire l’indirizzo del
registration service del relativo coordinatore.
WS-Transaction si posa interamente su WS-Coordination e stabilisce due Coordination Types insieme ai relativi protocolli per
condurre BT.
Il primo definisce delle Atomic Transaction (AT). Le azioni svolte in una AT prima del commit sono provvisorie e quindi non
producono risultati permanenti né visibili alle altre attività. Quando un applicazione termina, richiede al coordinatore di determinare
l’esito della transazione. Il coordinatore quindi chiede ad ogni partecipante di votare per un commit o per un abort a seconda
dell’esito delle loro attività. Se tutti sono d’accordo per il commit le azioni svolte vengono rese persistenti e visibili all’esterno,
altrimenti vengono tutte annullate ed ogni cosa appare come se non fosse mai stata svolta nessuna operazione.
Per realizzare una AT i protocolli devono:
Creare un apposito coordination context, associato con un coordinatore;
Aggiungere coordinatori intermedi ad una transazione esistente;
Propagare il coordination context nei messaggi scambiati tra gli e-Services;
Registrare le applicazioni partecipanti alla transazione.
Esistono diversi protocolli di coordinamento a cui è possibile registrarsi in base al ruolo assunto dall’applicazione. I protocolli
di coordinamento per una AT sono completamente definiti in WS-Transaction e sono:
Completition: Generalmente l’applicazione che inizia al transazione si registra per questo protocollo. Grazie ad esso, infatti,
può comunicare al coordinatore di tentare di effettuare il commit o di forzare il roll-back della transazione. Il coordinatore
informerà poi l’applicazione sull’esito del comando impartito.
Completition with Ack: Identico al precedente, con la sola differenza che il coordinatore mantiene il risultato della transazione
finchè non ha ricevuto un Ack dell’applicazione interessata.
Phase Zero: Un partecipante che ha bisogno di essere informato sullo stato della transazione subito prima dell’esecuzione del
2PC si registra per questo protocollo. Un esempio di una tale partecipante può essere un’applicazione che fa cashing dei dati
manipolati della transazione e che quindi deve effettuare un’operazione di flush verso il database centrale prima che venga
iniziato il 2PC.
2PC: Le applicazioni responsabili della gestione delle risorse coinvolte si registrano per questo protocollo. Se c’è solo una
applicazione registrata il commit viene eseguito direttamente in una singola fase.
Outcome Notification: Le applicazioni registrate per questo protocollo vengono semplicemente informate sull’esito della
transazione. Questo è utile quando bisogna eseguire delle operazioni dopo la transazione che dipendono dal suo esito.
24
Il secondo coordination context definisce le Business Activity (BA). Le BA servono per gestire attività complesse che necessitano
di una particolare logica di business. Esse affrontano tutti i problemi descritti a proposito delle transazioni a lungo termine, come
quelli legati al blocco delle risorse. Una BA è composta da un insieme di task, ognuno dei quali è una AT.
I protocolli per una BA devono:
Creare un apposito coordination context, associato con un coordinatore;
Aggiungere coordinatori intermedi ad una transazione esistente;
Propagare il coordination context nei messaggi scambiati tra gli e-Services;
Registrare i task partecipanti alla transazione.
I protocolli di coordinamento per una BA sono:
Business Agreement: Tramite questo protocollo il task dialoga con il coordinatore della BA. Il coordinatore impartisce principalmente ordini di esecuzione del 2PC e di compensazione, mentre il task risponde a questi comandi e informa il coordinatore
su eventuali eccezioni o sulla sua intenzione di lasciare la transazione. Un task si registra con questo protocollo quando
conosce in partenza tutte le attività che dovrà svolgere.
Business Agreement With Complete: Questo protocollo è identico al precedente con la sola differenza che un task che si
registra con questo protocollo non conosce le attività che dovrà svolgere e fa affidamento sul coordinatore per sapere quando
ha finito il suo lavoro.
Definire all’interno di un coordination context le relazioni tra BA e AT.
Fornire ad una BA la possibilità di scegliere quali task considerare per stabilire l’esito finale della transazione.
Permettere ad un task di lasciare in qualsiasi momento la BA di cui fa parte, anche senza aver votato per l’esito della
transazione.
Permettere ad un task di informare la BA sul suo risultato anche senza l’esplicita richiesta di un voto, in modo da permettere
alla transazione di reagire di conseguenza.
Fornire ad una transazione annidata gli strumenti per gestire le eccezioni lanciate dalle transazioni figlie.
Il flusso dei protocolli (sia per le BA che per le AT) vede un coordinatore per ogni applicazione coinvolta. Chi inizia la transazione crea il relativo context per mezzo del suo coordinatore e lo invia ai partecipanti. Chi riceve il context controlla il tipo di
transazione e decide il ruolo che dovrà svolgere. In base a questo si registra tramite il suo coordinatore al protocollo adatto e propaga
il context ad altri eventuali partecipanti. Ogni coordinatore crea il proprio coordination context copiando i dati comuni relativi alla
transazione ma mettendo l’indirizzo del proprio registration service. In questo modo vengono a crearsi delle catene di registrazione.
Un coordinatore che riceve un context di una transazione da un coordinatore subordinato manderà a questo la sua richiesta di registrazione che a sua volta la inoltrerà al coordinatore principale. Tutti i messaggi successivi continueranno ad essere inviati tramite il
coordinatore interposto.
3.3.5
ebXML
Di seguito ci soffermeremo su come vengono definite le BT in ebXML [4, 35].
La realizzazione dei processi di business in ebXML avviene tramite delle business collaboration. Esistono due tipi di business
collaboration : quelle binarie sono interazioni tra due organizzazioni che assumono i ruoli di acquirente e venditore; quelle multiple
sono semplicemente composizioni di collaborazioni binarie. Ogni organizzazione può quindi assumere più ruoli in una business
collaboration complessa.
Una business collaboration è un insieme di BT. ebXML vede una BT come una coppia di attività, una di richiesta e l’altra di
risposta, ma non si sofferma ad definire le proprietà che queste attività devono soddisfare. Il protocollo con cui vengono condotte
le BT viene deciso dalle singole organizzazioni. Tutte le organizzazioni registrate, infatti, forniscono insieme ai propri dati un
Collaboration Protocol Profile (CPP), e cioè una descrizione dei modi di operare che sono supportati e le corrispondenti proprietà
garantite. ebXML si occupa soltanto di fornire un meccanismo con cui due organizzazioni che vogliono collaborare confrontano i
propri CPP e derivano un Collaboration Protocol Agreement (CPA) facendone l’intersezione. Il CPA guiderà le successive interazioni
tra le due organizzazioni per condurre le BT che compongono la business collaboration.
25
3.3.6
WSDx & Transactional Attitudes
Ogni e-Service gestisce le proprie transazioni come meglio crede, utilizzando protocolli di tipo 2PC, meccanismi di compensazione
o altri sitemi. Quando più e-Services devono collaborare per soddisfare le richieste di un unico cliente, può essere importante
tenere in considerazione questo tipo di differenze. WSDx è un’estensione di WSDL che permette di definire, insieme ai servizi, il
comportamento adottato per gestire le transazioni. Vengono distinti tre tipi di Provider Transactional Attitudes (PTA) [2]: Pending
Commit (PC), Group-Pending Commit (GPC) e Commit Compensate (CC).
Il PC si riferisce all’esecuzione di una singola operazione, e consiste nel lasciare il risultato in sospeso finché il cliente non invia
un comando di commit o abort per renderlo persistente o cancellarlo.
In modo analogo il GPC si riferisce ad un gruppo di azioni. Il cliente invia un comando specifico per iniziare una sequenza di
azioni i cui risultati verranno lasciati in sospeso finché non si verificheranno eccezioni (nel qual caso la transazione abortirà) o finché
il cliente non comunicherà esplicitamente se confermare o cancellare la transazione.
Con il CC invece il e-Service rende immediatamente persistente ogni operazione e, nel caso il cliente opti alla fine per l’abort,
procede con azioni di compensazione.
Insieme alle PTA è importante definire anche i possibili comportamenti del cliente. Con le Client Transactional Attitudes (CTA)
si vuole specificare quali sono le transazioni di vitale importanza per il cliente nello svolgimento del processo complessivo. In genere,
quando un processo coinvolge più servizi contemporaneamente, alcuni non sono indispensabili ed un cliente potrebbe confermare
gli altri anche se questi non possono essere portati a buon fine.
Tutte le azioni richieste dal cliente vengono allora raccolte in un unico blocco denominato Flexible Atom (FA) che tiene conto
della CTA.
Per ottenere tutto questo è necessario uno specifico middleware che faccia da intermediario tra il client ed gli e-Service. Una
possibile realizzazione vede un e-Service che svolge un compito di proxy server: il cliente comunica solamente con il proxy passandogli prima le proprie CTA e gli indirizzi degli e-Service che vuole contattare, e successivamente tutte le operazioni da eseguire;
il proxy contatta gli e-Service ed invoca le operazioni richieste tenendo conto sia delle CTA che delle PTA. In questo modo le PTA
sono completamente trasparenti al client il quale, una volta decise le proprie priorità, si disinteressa totalmente di ogni meccanismo
di commit o abort. Tutti i comandi per cancellare o confermare le singole transazioni sono infatti gestiti dal proxy che comunicherà
al client un unico risultato finale.
3.4 Considerazioni sulle proposte attuali
Le principali tecnologie attualmente proposte per supportare processi di business possono facilmente essere paragonate con il BTF
descritto nelle precedenti sezioni. Il protocollo TIP è stato il primo ad introdurre validi meccanismi per la gestione delle transazioni
in ambiente Web. Come tale però è anche molto limitato. TIP è sostanzialmente un’estensione del 2PC e può essere utilizzato
soltanto come mattone di base per costruire un framework più completo.
L’uso integrato WS-Coordination e WS-Transaction, invece, ricopre completamente il business transaction model ed i coordination protocols richiesti dal BTF, fornendo una solida piattaforma per processi transazionali e non. Stessa cosa si può dire per OASIS
BTP.
Per quanto riguarda i business protocols, il primo modello (WS-Coordination e WS-Transaction) può essere facilmente esteso per
supportarli, grazie soprattutto all’infrastruttura di BPEL su cui poggia, mentre BTP è piuttosto indipendente dallo stack protocollare
sottostante e porterebbe essere facilmente integrato con ebXML per avere un quadro più completo.
ebXML, infatti, offre un sopporto valido soprattutto per i business protocols e per realizzare le fasi pre e post transazione, piuttosto
che per la transazione vera e propria.
Il protocollo THP coglie esattamente tutti gli aspetti della prima fase ma deve essere utilizzato necessariamente insieme ad altri
protocolli.
Un BTF abbastanza soddisfacente può quindi essere ottenuto componendo quello che le attuali tecnologie ci offrono, pagando
un certo prezzo dovuto all’inevitabile overhead che si viene a creare in simili circostanze. In generale, comunque, non esiste ancora
un’unica piattaforma che offre una struttura completa per le BT. BPEL, WS-Coordination e WS-Transaction rappresentano forse
una delle soluzioni più complete, ma questo più per la sua grande flessibilità (che potrebbe permettere di realizzare, ad esempio,
una divisione in tre fasi definendo nuovi protocolli di coordinamento) che per un supporto diretto alle problematiche che abbiamo
discusso.
C’è poi da tenere presente che nessuna soluzione riportata affronta la questione delle primitive di atomicità descritte in precedenza. L’idea di comporre transazioni complesse soltanto mediante l’invocazione di alcuni metodi non può certo essere scartata,
anche se i criteri di atomicità [20] proposti sono forse troppo legati a transazioni di natura economica e perdono di generalità.
Infine vanno esaminati gli algoritmi utilizzati da questi protocolli. Essenzialmente si tratta di estensioni del 2PC o di meccanismi
di compensazione ; quando il 2PC è troppo stringente la transazione viene frazionata e si eseguono “tanti piccoli commit” separata-
26
mente, riservandosi poi di avviare transazioni di compensazione se qualche operazione non può essere completata. In questo contesto
manca quindi una reale innovazione e nasce spontaneo chiedersi se possono essere trovati algoritmi completamente alternativi che
risolvano il problema in modo più efficiente.
27
Bibliografia
[1] Fipa 2000 specification. www.fipa.org.
[2] Transactional Attitudes : reliable composition for autonomous Web Services, Marzo 2002.
[3] ACM. Communications of the acm, October 2003.
[4] P. Levineet al. ebXML Business Process Specification Schema. Available on-line (link checked September, 1st 2003): www.
ebxml.org/specs/ebBPSS.pdf, Maggio 2001.
[5] M. P. Papazoglou D. Georgakopoulos. Service-Oriented Computing. Communication of the ACM, 46(10):25–28, October
2003.
[6] Microsoft ARIBA, IBM. UDDI Technical White Paper. UDDI.org Web Site: www.uddi.org/pubs/Iru\_UDDI\
_Technical\_White\_Paper.pdf.
[7] R. Baldoni and C. Marchetti. Three-tier Replication for FT-CORBA Infrastructures. Software: Practice & Experience - Wiley
InterScience, 8(33):767–797, July 2003.
[8] L. Baresi, D. Bianchini, V. De Antonellis, M. G. Fugini, B. Pernici, and P. Plebani. Context-aware Composition of e-Service.
In Technologies for E-Services : Third International Workshop, TES 2003, Berlin, German, September 7-8, 2003.
[9] C. Cappiello, C. Francalanci, B. Pernici, P. Plebani, and M. Scannapieco. Data Quality Assurance in Cooperative Information
Systems: a Multi-dimension Quality Certificate. In International Workshop on Data Quality in Cooperative Information
Systems in conjunction with ICDT 2003, Siena, Italy, January 10-11, 2003.
[10] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. www.w3.
org/TR/2001/NOTE-wsdl-20010315, March 2001.
[11] DAML Service Coalition. DAML-S: Semantic Markup For Web Services. www.daml.org/services/daml-s/0.7/
daml-s.html, October 2002.
[12] S. Frolund end K Govindarajan. Transactional Conversation in W3C Web Services Workshop. in W3C Web Services
Workshop. Available on-line (link checked September, 1st 2003): www.w3.org/2001/03/WSWS-popa, 2001.
[13] H. Volger end M.L. Moschgath. The Transaction Internet Protocol in practice: reliability for WWW application, 2002.
[14] F. Cabrera et al. Web Services Coordination (WS-Coordination). Available on-line (link checked September, 1st 2003):
www.ibm.com/developerworks/library/ws-coor/, Agosto 2002.
[15] F. Cabrera et al. Web Services Transaction (WS-Transaction). Available on-line (link checked September, 1st 2003): www.
ibm.com/developerworks/library/ws-transpec/, Agosto 2002.
[16] F. Cubrera et al. Business Process Execution Language for Web Services (BPEL4WS) 1.0. Available on-line (link checked
September, 1st 2003): www.ibm.com/developerworks/library/ws-bpel/, Agosto 2002.
[17] Object Management Group. Common object request broker architecture (CORBA/IIOP) v3.0.2, 2003.
[18] Object Management Group. Common secure interoperability (csiv2), 2003.
[19] X. Gu, K. Nahrstedt, W. Yuan, D. Wichadakul, and D. Xu. An XML-based quality of service enabling language for the web. In
Technical Report UIUCDCS-R-2001-2212, University of Illinois at Urbana-Champaign, Computer Science Department, 2001.
[20] M. Hammer. Web Services and Business Transaction. World Wide Web: Internet and Web Information Systems, Kluwer
Academic Publishers, pages 49–91, Marzo 2003.
[21] HP. web services concepts - a technical overview. HP Web Site: www.bluestone.com/downloads/pdf/web\
_services\_tech\_overview.pdf.
[22] IEEE. Computer, October 2003.
[23] ISO. www.iso.ch/iso/en/ISOOnline.frontpage.
28
[24] K Srinivasan J. Roberts. Tentative Hold Protocol part 1: white paper. in W3C Web Services Workshop. Available on-line (link
checked September, 1st 2003): www.w3.org/TR/tenthold-1, Novembre 2001.
[25] K Srinivasan J. Roberts. Tentative Hold Protocol part 2: technical specification. in W3C Web Services Workshop. Available
on-line (link checked September, 1st 2003): www.w3.org/TR/tenthold-2, Novembre 2001.
[26] A. Keller and H. Ludwig. The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services.
Technical Report RC22456(W0205-171), IBM Research Division, T.J. Watson Research Center, May 2002.
[27] F. Leymann. Join the Bus - A Guided Tour to the WS* Landscape. Invited Talk at 4th Workshop on Technologies for EServices in conjunction with 29th International Conference on Very Large Data Base (VLDB 2003), September 7-8, 2003,
Berlin, Germany.
[28] B. Cox end B. Pope M. Potts. Business Transaction Protocol Primer. OASIS Business Transaction Technical Committee,
Giugno 2002.
[29] A. Mani and A. Magarajan. Understanding quality of service of your Web services. IBM Developer Works, January 2002.
Available at: www.ibm.com/developerworks/library/ws-quality.html.
[30] A. Maurino, S. Modafferi, C. Cappiello, L. Negri, M. Brioschi, N. Simeoni, M. Riva, D. Ragazzi, and G. Giunta. Studio delle
caratteristiche dei canali. Deliverable work package 1.1.1, Politecnio di Milano, 2003.
[31] A. Maurino, S. Modafferi, and B. Pernici. Reflective architectures for adaptive information systems. In Proceedings of the
International Conference on Service Oriented Computing (ICSOC’03), Trento, Italy, December 2003.
[32] L.E. Moser, P.M. Melliar-Smith, P. Narasimhan, L.A. Tewksbury, and V. Kalogeraki. The Eternal System: an Architecture
for Enterprise Applications. In Proceedings of the 3rd International Enterprise Distributed Object Computing Conference
(EDOC’99), pages 214–222, Mannheim, Germany, July 1999.
[33] Shuping Ran. A Model for Web Services Discovery With QoS. In ACM SIGecom Exchange, volume 1, pages 1–10, ACM
Press, New York, NY, USA, 2003.
[34] D. C. Schmidt, A. Gokhale, T. Harrison, D. Levine, and C. Cleeland. Tao: A high performance endsystem architecture for
real-time corba. IEEE Communications Magazine, 14(2), 1997.
[35] S. Shlegel. ebXML (electronic business XML). Available on-line (link checked September, 1st 2003): www.schlegel.li/
ebXML/postgraduate\_report/www/ebxml\_report.html, 2001.
[36] The ARTEMIS Project Home Page.
artemis.html.
www.ing.unibs.it/$\sim$deantone/interdata\_tema3/Artemis/
[37] M. Wooldridge. Multiagent systems - A modern approach to artificial intelligence. MIT Press, 1999.
[38] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam, and Q. Z. Sheng. Quality driven web services composition. In Proceedings
of the twelfth international conference on World Wide Web, pages 411–421. ACM Press, 2003.
29
A. Articoli allegati
D. Berardi, F. De Rosa, L. De Santis, M. Mecella. Finite State Automata as Conceptual Model for E-Services. Atti della 7th
World Conference on Integrated Design and Process Technology (IDPT 2003), Special Session on Modeling and Developing
Process-Centric Virtual Enterprises with Web-Services (VIEWS 2003).
L. Baresi and D. Bianchini and V. De Antonellis and M. G. Fugini and B. Pernici and P. Plebani. Context-aware Composition
of E-Services. Atti di Technologies for E-Services : Third International Workshop, TES 2003 (Berlino, Germania, 2003).
C. Marchetti, B. Pernici e P. Plebani. A Quality Model for E-Service-based Multi-channel Adaptive Information Systems. Atti
del 1st Web Service Quality Workshop (WQW) della 4th International Conference on Web Information Systems Engineering
(WISE’03) (Roma, Italia, 2003).
D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, M. Mecella. Automatic Composition of E-Services that Export their
Behavior. Atti della the 1st International Conference on Service Oriented Computing (ICSOC 2003) (Trento, Italia, 2003).
A. Maurino, S. Modafferi e B. Pernici. Reflective Architectures for Adaptive Information Systems. Atti della the 1st
International Conference on Service Oriented Computing (ICSOC 2003) (Trento, Italia, 2003).
30
Integrated Design and Process Technology, IDPT-2003
Printed in the United States of America, June, 2003
°c2003SocietyforDesignandProcessScience
FINITE STATE AUTOMATA AS CONCEPTUAL MODEL FOR E-SERVICES
Daniela BERARDI, Fabio DE ROSA, Luca DE SANTIS and Massimo MECELLA
Dipartimento di Informatica e Sistemistica
Università di Roma “La Sapienza”
via Salaria 113, I-00198 Roma, Italy
E-mail: {berardi,derosa,lucads,mecella}@dis.uniroma1.it
ABSTRACT
Recently, a plethora of languages for modeling and specifying different facets of e-Services have been proposed, and
some of them provides constructs for representing time. Time
is needed in many contexts to correctly capture the dynamics
of transactions and of composability between e-Services.
However, to the best of our knowledge, all the proposed
languages for representing e-Service behaviour and temporal
constraints lack both a clear semantics and an underlying
conceptual model. In this paper, we propose a conceptual
representation of e-Service behaviour, taking time constraints
into account, and a new XML-based language, namely WSTL
(W EB S ERVICE T RANSITION L ANGUAGE), that integrates
well with standard languages in order to completely specify
e-Services. In particular, WSTL allows for specifying an
e-Service starting from its conceptual representation, in a
straightforward way.
INTRODUCTION
Since the last few years, we are witnessing a great change
in business paradigms. Different companies are able to pool
together their services, in order to offer more complex, value
added products and services. Thanks to the spreading of
network technologies and the Internet, that makes services
easily accessible to a vast number of customers, companies
are able to cooperate in very flexible ways, giving rise to the so
called virtual enterprises [Georgakopoulos, 1999]. Although
it started in the business context, the scenario of interorganization cooperation has spread out different contexts,
e.g., e-Government [Elmagarmid and McIver Jr, 2001].
Inter-organization cooperation can be supported by Cooperative Information Systems (CIS’s) [De Michelis et al., 1997].
Many approaches have been proposed for the design
and development of CIS’s: business process coordination and service-based systems [Dayal et al., 2001], agentbased technologies and systems [Castro et al., 2002], schema
and data integration techniques [Rahm and Bernstein, 2001],
[Lenzerini, 2002]. In particular, the former approach focuses
on cooperation among different organizations that export
services as semantically defined functionalities; cooperation
is achieved by composing and integrating services over the
Web. Such services, usually referred to as e-Services or Web
Services, are available to users or other applications and allow
them to gather data or to perform some tasks. In the following,
we will refer to Service Oriented Computing (SOC) as a
new emerging model for distributed computing that enables
to build agile networks of collaborating business applications
distributed within and across organizational boundaries 1 .
Cooperation of e-Services poses many interesting
challenges
regarding,
in
particular,
composability,
synchronization, coordination, correctness verification
[Yang et al., 2002]. Indeed, in order to address such
issues in an effective and correct way, the dynamic
behaviour of e-Services needs to be formally represented.
There have been some preliminary efforts in this
direction: [Mecella et al., 2001] defines the notion of
compatibility and dynamic substitition of e-Services,
[Kuno et al., 2001], [BEA et al., 2002] propose standards to
describe the interfaces and the conversations of e-Services.
Recently, some research efforts are concerned with adding
a fundamental concept: time. Time is needed in many contexts
to correctly capture the dynamics of transactions and of
composability. Many e-Services available on the Internet are
made up of sessions having an associated time-out, as those
that allow a user to check his bank account, or to participate
to an online auction. Analogously, we often face trade-offs
involving time: when we want a fast high quality service,
but no e-Service has both these features, we have to choose
between speed and quality.
In this paper we propose a conceptual representation of
e-Service behaviour that takes time into account, and introduce an XML-based language, that can be integrated with
standard languages in order to completely specify e-Services.
In particular, the proposed language allows for specifying
an e-Service starting from its conceptual representation, in
a straightforward way.
LANGUAGES FOR E-SERVICES
Recently, a plethora of languages for modelling and specifying different facets of service oriented computing have
been proposed; in this section, we discuss some of them,
with respect to the concept of Service Oriented Architecture
(SOA) [HP, 2001], in order to correctly compare all such
1 The
Service Oriented Computing net: http://www.eusoc.net
2
' ! " - ! " # -+ ) -4 # 3 "%! 55" 6# "(4 30" & /8
3 & 0 ' " "/-5 6 92 #% ) 3 " 3 % 5 & "6 7 "+' )) 0 -; " ):
& 0 / ! " # /- " # & ' 9
< = > ? @ A F GN HO IP JQ K R L S G M
B C = D Fig. 1.
$ % ! " & #' (" ) ! ' * , " ) -! "" )# ./ (& 0 + , 1 & E = D Service Oriented Architecture
works. The aim is to show that a conceptual way of representing e-Services is still lacking, and this constitutes the
motivation of our work.
A SOA is the minimal framework for e-Services consisting
of some basic operations and roles (see Figure 1):
– Service Provider: it is the subject providing software
applications for specific needs as services; (i) from a
business perspective, this is the owner of the service
(e.g., the subject which is possibly paid for its services),
and (ii) from the architectural perspective, this is the
platform the service is deployed onto. Available services
are described by using a service description language
and advertised through the publish() operation on a
public available service directory.
– Service Requestor: it is the party that uses the services;
(i) from a business perspective, this is the business
requiring certain services to be fulfilled (e.g., the payer
subject), and (ii) from an architectural perspective, this is
the application invoking the service. A service requestor
discovers the most suitable service in the directory
through the find() operation, then it connects to the
specific service provider through the bind() operation
and finally it uses the chosen service (invoke() operation).
– Service Directory: it is the party providing a repository
and/or a registry of service descriptions, where providers
publish their services and requestors find services.
The transport medium is a parameter of a SOA, therefore
such a framework is easily integrable on different technologies; specifically, an e-Service Architecture is one in which
the transport medium is electronic, whereas in a Web Service
Architecture the transport medium is the Web. All emerging proposals consider the last scenario, in which services
“live” over the Web, on the basis of a common transport
medium, consisting of Web technologies such as HTTP, SOAP
and XML Protocol [W3C, 2002]. They address some basic
technological issues of a SOA, that is the definition (i) of
the service directory, (ii) of the service description language,
(iii) of possible interactions a service can be involved in (i.e.,
the conversations), and (iv) of how to compose and coordinate
different services, to be assembled together in order to support
complex processes (i.e., the orchestration).
In the UDDI initiative, the architecture of a distributed
service directory is proposed [UDDI.org, 2001]. In the context
of the W3C, many service description languages are being
proposed for specific purposes:
Service
Description
Language
– Web
(WSDL, [Ariba et al., 2001]) for describing services,
specifically their static interfaces;
– Web
Service
Conversation
Language
(WSCL, [Kuno et al., 2001]) for describing the
conversations a service supports; the underlying model
is the one of the activity diagrams;
– Web
Service
Choreography
Interface
(WSCI, [BEA et al., 2002]) for describing the
observable behavior of a service in terms of temporal and
logical dependencies among the exchanged messages;
– Web Service Flow Language (WSFL, [Leymann, 2001])
for the design of composite Web Services starting from
simple ones (composition of Web Services); the underlying model is the one of Petri Nets;
– XLANG [Satish, 2001] for both the specification of
the behavior of services and their orchestration;
in [Meredith, 2002], it has been pointed out that this
language is complete, it owns the property of composability and that the underlying theoretical model is the
one of process algebra;
– Business Process Execution Language for Web Services (BPEL4WS, [Curbera et al., 2002]) with the aim
of merging WSFL and XLANG.
With respect to the SOA, the languages WSDL, WSCL
and WSCI concerns the service provider, and are all service
description languages: WSDL addresses only static interface
specifications, whereas WSCL and WSCI considers also behavioral issues and time.
More in details, WSDL, analogously to an interface definition language (e.g., CORBA IDL), describes methods, ingoing
and outgoing messages and data types used by the service.
Moreover, it supplies a mechanism to locate the service (e.g.,
using a URI), the protocol used to exchange messages and
the concrete mapping between the abstract method definition
and the real protocol and data format. WSDL define what
the e-Service does, not how it does it; moreover WSDL does
not express the semantics of message exchange neither their
correct order.
WSCL models the conversation (sequence of exchanged
messages) supported by an e-Service: it specifies the XML
documents being exchanged, and the allowed sequence, in a
fashion similar to an activity diagram. A WSCL document is
composed of four main elements: (i) document type descriptions specifying the types (schemas) of XML documents the
service can accept and send during the conversation, (ii) interactions modelling the actions of the conversation as document
exchanges between two participants (i.e., the e-Service and
its client), (iii) transitions specifying the order relationships
between interactions, and (iv) conversations, listing all the
interactions and transitions that make up the conversation.
WSCI can be considered as a evolution of WSCL: it
describes the observable behavior of an e-Service and how
operations can be choreographed in the context of message
exchanges in which the e-Service participates. WSCI allows
to describe the correct order of the exchanged messages and
permits to define multiple behaviors for the same e-Service
on the basis of the context in which is used. Furthermore,
it provides methods to manage exceptional situations, such
as timeouts and fault messages 2 . WSCI, finally, allows to
define the abstract behavior of a process that involves more
e-Services in term of interfaces and links between operations,
thus giving a view of the process in terms of message
exchanges; with such a respect, WSCI is also an orchestration
language.
As far as the languages WSFL, XLANG and BPEL4WS,
they are orchestration and coordination languages, aimed at
specifying how multiple e-Services are coordinated and the
state and the logic needed for such a coordination; they
provide constructs for limited time modelling, for correlation
of e-Service instances and for exception management. Orchestration languages will be not further addressed in this paper.
C ONCEPTUAL R EPRESENTATION OF e-S ERVICES
From the previous discussion, it stems that some proposals
address the issue of service behavior representation, considering also time; but we argue that (i) a clear semantics of such
languages is missing, and (ii) they are not suitable for service
oriented computing design at a conceptual level.
We argue that in service oriented computing we need
conceptual languages in order to represent e-Services from an
external point of view; such external point of view is the one
to be considered when composing and orchestrating services.
Moreover we need also languages for internal specification,
i.e., specifying the e-Service for designers and implementors.
In this work we concentrate only on the former issue (i,.e., external conceptual representation), since, for the latter purpose,
classic specification languages used in software engineering
practice can be used.
We propose a conceptual way of representing e-Service
behavior, including time, based on finite state automata, and a
new language, namely WSTL 3 (W EB S ERVICE T RANSITION
L ANGUAGE ), that can be used to represent an e-Service specification at a “technological” level, obtained by a straightforward mapping from the e-Service specification at a conceptual
level 4 . In this way, we are able to give a clear and formal
semantics to WSTL constructs. WSTL integrates well with
other languages: e-Service specifications, which are expressed
in WSTL and stored into suitable registries/repositories, complement standard WSDL specifications.
2 Time modelling is delegated to the delay element for represent time
interval and to the onTimeout event handler for timeout situations.
3 The XML Schema is available at http://www.dis.uniroma1.it/
∼mecella/projects/vispo/WSTL/WSTL1.1.xsd
4 Note that the conceptual specification is independent from any technology.
Figure 2 shows the proposed conceptual approach: a cooperative designer, which is interested in searching, reusing,
composing, and orchestrating e-Services (which are all based
on e-Service external facets), defines an e-Service conceptual
specification. Such a specification is then translated into a
technological, i.e., based on standard XML-based languages,
representation; such a representation consists both of a WSDL
file that specifies the static interface of the e-Service, and
of a WSTL file, representing the e-Service behavior. Such
files are then published into service directories, and then
used for future searches, compositions, orchestrations, etc.
Starting from the e-Service conceptual specification, internal
designers and implementers will produce software artifacts
implementing the e-Service.
An initiative which is quite similar to the proposed conceptual approach is the one of the DAML-S Coalition
[Ankolekar et al., 2002]. DAML-S is an ontology for describing Web Services that enables the definition of service content
vocabulary in terms of objects and complex relationships
between them, including class, subclass relations, cardinality
restrictions, etc., including all XML typing information. More
in details, the DAML-S Ontology comprises:
– ServiceProfile. This is like the yellow page entry
for a service. It relates and builds upon the type of
content in UDDI, describing properties of a service
necessary for automatic discovery, such as what the
services offers, and its inputs, outputs, and its side-effects
(preconditions and effects).
– ServiceModel. Describes the service’s process model
(the control flow and data-flow involved in using the
service). It is designed to enable automated composition
and execution of services.
– ServiceGrounding. Connects the process model description to communcation-level protocols and message
descriptions in WSDL.
The part of DAML-S more related to our work is the
process model; its semantics has been defined both through a
translation to (axiomatization in) first-order logic, and through
a translation to an operational semantics using Petri Nets.
WSTL
WSTL is a XML-based description language able to represent the observable behavior of e-Services. WSTL does
not address the implementation that actually drives the interactions; rather, it allows to describe what is observable
from the point of view of the service users. Although simple,
it permits to model complex behaviors, such as loops and
exceptions. WSTL extends the static interface of WSDL
with elements which describe the correct sequence of the
exchanged messages.
The root element of WSTL is the Conversation construct 5 ; it describes the acceptable interactions of the eService in a message exchange scenario. Each WSTL con5 The “?” symbols associated to an element means that the element can
occur zero or one time; the “+” symbol states that the elements must occur
at least once.
Cooperative
Designer
design of external
e-Service
specification
e-Service
Conceptual
Specification
(based on Finite
State Automata)
search into
Service
Directory
translation
store for
advertising, search,
use, composition,
etc.
WSDL
File
refinement for e-Service
implementation (internal
specification)
WSTL
File
Software
Artifact
implementing
e-Service
e-Service Technological
Representation (based on
Web Service / XML
Languages)
Fig. 2.
Conceptual approach to e-Service specification
versation is characterized by a name and it can contain one
or more Transition elements.
<Conversation name = string
version = string
description = string
Transition+
</Conversation>
The Transition construct describes the behavior of the eService when a particular message is received or an internal
event (e.g., a timeout) is triggered. It defines the successor
state and the message that is returned. Details of behavior,
such as WSDL messages (see below) and time constraints,
are encapsulated in this element.
<Transition source = string
target = string
type = synchronous|asynchronous>
(inputMessage|outputMessage|InputOutputMessage)
</Transition>
The type field allows for specifying whether the
interaction is synchronous or asynchronous. Each
Transition element contains exactly one of the
following elements: InputMessage, OutputMessage,
and InputOutputMessage.
<InputOutputMessage>
input = message
output = message
</InputOutputMessage>
<InputMessage>
message
</InputMessage>
<OutputMessage>
message
</OutputMessage>
The InputMessage element is used when a transition allows
for an input message, without any output message. On the
other hand, if the transition consists of an output message only,
the OutputMessage element is used. Note that transitions
containing either InputMessage or OutputMessage must
be asynchronous. Finally, if the transition has both an input
and an output message, InputOutputMessage elements are
used.
<Message>
name = string
TimeConstraint?
</Message>
The various message elements previously described are
based on WSTL Message elements. The value of field
name must refer to a WSDL message type; as detailed in
[Mecella and Pernici, 2002], in our approach the representation of an e-Service consists of a WSTL document plus
a WSDL file containing message type definitions. The field
constraint permits to associate a timeout descriptor with
message, by means of the TimeConstraint element; this
field is optional.
<TimeConstraint
duration = string
reference = string>
</TimeConstraint>
Finally,
the
optional field reference of the
element allows for specifying the
event from which duration is calculated; if no reference
field is specified, it is assumed that the duration is calculated
from the beginning of the transition.
As a final remark, we would like to point out that WSTL
allows to specify e-Service conversations as computations of
a finite state automaton, in which time constraints, as detailed
in next section, can be added; conversely WSCL, that is very
similar from a syntactical point of view, does not allow the
specification of time constraints with a clear semantics, and
specify conversations as activity diagrams.
TimeConstraint
MODELING OF E-SERVICES
In this section we propose a way to conceptually model eServices, focusing on their dynamic, i.e., behavioral aspects,
and we define the semantics of the language previously
presented.
In what follows, we consider an e-Service as a “black box”
software application (delivered over the Web) interacting with
a client (either a human or another e-Service) that wants to
reach a goal. Each interaction consists of three steps:
1) the client invokes a command on the e-Service, by
sending an input message;
2) the command triggers some internal computation,
needed for the execution of the specific task associated
to the command;
3) the client is possibly informed by an output message
about the termination of the task and (possible) requested information.
Therefore, each interaction is described by the triple < input command, internal computation, output message >; however, by adopting a black box approach, we skip over internal
computations and represent only the input/output behavior of
e-Service from the client view point, i.e., that have some effects towards the client: each interaction is therefore described
by the pair < input command, output message > only.
At a given point, the input command that can be sent to
the e-Service depends on the previous ones, and the client
chooses the next command on the basis of the information
returned by the previous output messages. At least in principle, interactions between an e-Service and its client may be
unlimited, as in the case of an e-Service offering a continuous
service, e.g., periodically delivering a product. According
to these considerations, an e-Service can be fully modelled
as an execution tree [Berardi et al., 2003], whose branches
represent all possible sequence of interactions between an eService and its client. However, since execution trees do not
have a finite representation, we decide to resort to classes of
e-Services that can be captured in a finite way.
We propose to represent an e-Service as a Finite State
Automaton (FSA), since Finite State Automata (FSA’s) are a
widely known, simple but powerful formalism, that allow us
to capture a large class of e-Services. FSA’s allow to model the
behavior of a system as a sequence of transitions: in this way,
we focus on the operational semantics of e-Services, i.e., we
represent how they evolve and with which results, according to
which command is invoked. In particular, we consider each
e-Service interaction as a state transition, labeled with the
pair < input command, output message >, where each state
represents the history of executed sequence of interactions
between the client and the e-Service.
Let eS be an e-Service. Its representation as FSA is a tuple
of the form S = < I, O, Γ, s0 , F, δ >, where:
– I is a non empty set of input commands, and O is a non
empty set of output messages; I × O is the alphabet of
the FSA;
– Γ is a finite, non empty set of states;
– s0 ∈ Γ is the initial state;
– F ⊆ Γ is a non empty set of final states, i.e., states
where the client can terminate its interaction with the
e-Service;
– δ : Γ × I × O → Γ is the transition function, that
represents the evolution of the FSA from a state to
another one, for a given pair < input command, output message > 6 ; the transition function can be undefined on the final states.
We assume that s0 ∈ F , since a client may decide not to
start the execution of an e-Service, even if he instantiated the
e-Service. Indeed, an e-Service need to be instantiated before
it can be invoked, and its execution starts when the first input
command is given [Mecella and Pernici, 2002].
A configuration is a pair < s, i, o >, where s ∈ Γ, i
∈ I and o ∈ O. An execution of an e-Service is a finite,
non empty sequence of configurations < s0 , i0 , o0 >, . . . , <
sj , ij , oj >, < sj+1 , ij+1 , oj+1 >, . . . , < sn , in , on >, where
s0 is the initial state, sn is a final state, i.e., sn ∈ F, and such
that δ(sj , ij , oj ) = sj+1 . The set of all executions forms the
behavior of the e-Service.
Example 1: Let S1 be an e-Service that allows a client to sell
and to buy stocks online (see Figure 3). After instantiating
the e-Service, the client inserts its userID and password
(input command userData): the e-Service validates the
client and check the maximum amount that can be spent.
This information is displayed to the client (output message
checkedAccount). If, conversely, the client does not provide valid credentials, the e-Service will output a different
output message notValidClient, thus terminating its interaction with the client.
After visioning its available amount, the client invokes the continue command, in order to proceed to
the stock trading; data on stocks are displayed (message
displayedStockData) and the client can decide to sell
(command sell) or buy (command buy) stocks: after each
of these commands, information on the task result is displayed (message displayedResults). Finally, the client
can decide to stop performing stock exchange transactions
6 State transitions are deterministic, since given a state, an input command
and its corresponding output message, the successor state is univocally
identified.
buy/displayedResults
userData/checkedAccount
s0
continue/displayedStockData
s1
s2
s3
stop/emailNotification
userData/notValidClient
sell/displayedResults
s4
Fig. 3.
“Trading stocks” e-Service
(command stop) and he is notified with an e-mail about his
transactions (message emailNotification).
This e-Service allows for many different executions, as for
example:
– userData/checkedAccount,
continue/displayedStockData,
sell/displayedResults,
buy/displayedResults,
stop/emailNotification, in which a client
operates a stock sale followed by a stock purchase;
– userData/checkedAccount,
continue/displayedStockData,
stop/emailNotification, in which the client
uses the e-Service without any trading;
– userData/notValidClient, in which the client
provides not valid credentials.
The client can terminate the interaction with the e-Service
only in the two final states s3 and s4 .
¤
Usually, e-Services similar to the one of Example 1, have
additional behavior: in some scenarios, just to provide an
example, when an e-Service has not received any command
from the client within a given instant, because of network
overloading or because the client has exceeded the time limit
for invoking the command, an error message is output to the
client. In order to capture also such situations, absence of input
commands or of output messages, as well as time constraints,
need to be captured.
We introduce a new symbol ², that represents the lack of
an input command or the absence of an output message: we
refer to ² as the empty input command/output message. Note
that an empty input command does not imply absence of
internal computations (and therefore of the possible output
message), since it may be the case that a computation starts
with no triggering command, and it correctly returns an output
message. We do not allow for the pair ²/², since no semantics
can be associated to it from a user point of view. Analogously,
each execution of an e-Service consists of at least one nonempty input command or one non-empty output message,
otherwise no semantics can be associated to an execution.
An e-Service with time constraints on transitions can
be modelled by using Timed Finite State Automata
(TFSA’s). TFSA’s have been discussed in many papers, e.g.,
[Henzinger et al., 1994], [Alur and Dill, 1994]: starting from
the discussion in these papers, we will slightly modify the
previous definition in order to cope with time.
We make each transition depending also on the instants
when the input command and the output message are invoked
and returned, respectively. Additionally, we add two timing
functions τ and σ: the former associates an input command
with the duration of time within which this command needs
to be executed by the client; the latter associates an output
message with the duration of time within which the task
triggered by the input command needs to be completed and the
output message has to be returned by the e-Service; duration
are considered starting from the instant in which the current
state is entered. We assume that each e-Service has its own
timing functions.
Let eS T be a timed e-Service. Its representation as TFSA
is a tuple of the form S T =< I, O, Γ, ², s0 , F, T , δ, τ, σ >,
where:
– I, O, Γ, s0 , F are defined as in the previous definition;
– T is the set of timings, denoted by non negative integers;
– ² denotes both the empty input command and the empty
output message;
– τ : Γ × I → T is the starting timing function, that
defines the maximal duration of time by which an input
command should be given in a specific state;
– σ : Γ × O → T is the ending timing function,
that computes the maximal duration of time by which
a computation is executed and the output message is
returned, for a given state and a given output message.
In particular,
• on the final states having no outgoing transition, τ
and σ are undefined;
• on the initial state, τ and σ are defined wrt the
instant when the e-Service is instantiated 7 .
Note that since τ and σ impose timing constraints
transition by transition, we can choose not to impose
any constraint on a transition. Additionally, τ and σ are
undefined on ², since it makes no sense defining a time
constraint in a situation where either the input command
or the output message is absent.
– δ : Γ × [((I ∪ {²}) × (O ∪ {²})) − ({²} × {²})] × T ×
T → Γ is the transition function. In particular, within the
7 We recall that an e-Service needs to be instantiated before it can be
invoked [Mecella and Pernici, 2002].
γ/α
²/β
s1
s2
s3
(a) Case 1
α/β
s1
α/²
s1
²/γ
β/γ
s2
s3
s3
(b) Case 2
α/²
s1
s2
(c) Case 3
²/β
s2
s3
α/β
s1
s2
γ/²
s1
α/β
s3
(d) Case 4
Fig. 4.
s3
(e) Case 5
Analysis of possible cases in which ² labels a timed transition
expression δ(sj , i, o, ti , to ), ti and to have the following
meaning:
• if both i and o are different from ², then the to
is the instant at which the output message o has
been returned, ti is the instant at which the input
command i has been invoked,
• if i (resp. o) is ², we set ti = to , and ti (resp. to ) is
intended as above.
Finally, note that the transition function can be undefined
on the final states.
The notions of configuration, execution and behaviour
of an e-Service can be straightforwardly obtained from the
analogous definitions previously given.
In order to correctly capture timing on e-Services, several
natural properties must be satisfied. In the following, we
discuss them and we show how they can be imposed on δ, τ
and σ:
1) each transition cannot terminate before it has started,
i.e., each output message cannot be returned before the
corresponding input command;
2) each transition cannot start before the previous one has
completed, i.e., each input command cannot be given
before the previous output message has been returned
(if the latter exists);
3) as far as δ is concerned, each input command and output
message within each transition must be returned within
the expected interval (when defined).
Noting that Property 2 is naturally captured by the definition
of transition function, the other properties can be encoded in
δ as follows: ∀sj , sj+1 , i, o, ti , to : δ(sj , i, o, ti , to ) = sj+1 if
ti ≤ to ∧ ti ≤ τ (sj , i) ∧ to ≤ σ(sj , o). If either i or o are
empty, or in general if τ and σ are not defined, this expression
simplify straightforwardly.
As far as τ and σ are concerned, Property 1 can be imposed
as ∀s∀i τ (s, i) ≤ σ(s, o). Property 2 is guaranteed from
the fact that both τ and σ are defined wrt the current state,
transition by transition. However, this holds when both the
input command and the output message are not empty.
If either one of them is ², several cases may happen, as
shown in Figure 4, where α and β denote input message
or output message that are different from ², whereas γ can
denote also ² (when admissible). As far as cases 1 and 2
are concerned, Property 1 is meaningless, since no timing
constraints can be imposed on ². In the situation shown
in Figure 4(c), Properties 1 and 2 express the fact that β
cannot be returned before α is invoked: this is captured by
τ (s1 , α) < σ(s1 , β). Situation in the upper part of Figure 4(d)
needs to be reduced to the situation in the lower part, in which
² is not present. As far as the case 5 is concerned, the presence
of ² does not influence the choice of which transition is to be
taken, since the timing constraints imposed by τ on the input
commands determine the choice. In cases like this we assume
that τ (s1 , α) is greater (or less) than τ (s1 , γ): this implies that
γ is different from α. The same applies for σ and the output
messages.
The proposed formalization naturally allows for capturing
additional time constraints, as those imposing that the interval
between the instant when an input command is invoked and
the instant when the corresponding output message is returned
is less than a given duration. Note that such timing constraints
can be imposed independently from the fact that τ and σ are
defined within a transition or not.
Before concluding the section, we apply our formalization
to an example.
Example 2: Figure 5 shows the e-Service discussed in Example 1, extended with time constraints and ² transitions. In
particular, this e-Service has the following behaviour:
– if the command userData is not given within the expected interval, the output message failed is returned;
– if the output message displayedResult associated
to command buy is not returned before a given time,
the message setStopAndNotify is returned, that
stops the stock trading, notifies the client about this
problem and reports to him about the stocks trade. The
same happens for output message displayedResult
associated to command sell;
Additionally, we impose several temporal constraints on
transitions, defined by τ and σ, as shown in Figure 6.
The transition function δ is also defined in Figure 6. The
constraints on τ and σ are:
τ (s0 , userData) ≤ σ(s0 , checkedAccount)
τ (s0 , userData) ≤ σ(s0 , f ailed)
τ (s0 , userData) ≤ σ(s0 , notV alidClient)
¤
MAPPING
The FSA model of e-Services introduced in previous section
gives us the possibility to exploit the results obtained in the
s4
buy/setStopAndNotify
²/failed
buy/displayedResults
continue/displayedStockData
s0
s1
s2
stop/emailNotification
s6
s3
userData/checkedAccount
sell/displayedResults
sell/setStopAndNotify
userData/notValidClient
s7
s5
Fig. 5.
δ(s0 , userData, checkedAccount, ti1 , to1 ) = s1
δ(s0 , ², f ailed, to2 , to2 ) = s4
δ(s0 , userData, notV alidClient, ti1 , to3 ) = s5
δ(s1 , continue, displayedStockData, ti4 , to4 ) = s2
δ(s2 , buy, displayedResults, ti5 , to5 ) = s2
δ(s2 , buy, setStopAndN otif y, ti5 , to6 ) = s6
δ(s2 , sell, displayedResults, ti7 , to7 ) = s2
δ(s2 , sell, setStopAndN otif y, ti7 , to8 ) = s7
δ(s2 , stop, emailN otif ication, ti9 , to9 ) = s3
Fig. 6.
“Trading stocks” timed e-Service
if
if
if
if
if
if
if
if
if
ti1
to2
ti1
ti4
ti5
ti5
ti7
ti7
ti9
≤ to1 ∧ ti1 ≤ τ (s0 , userData) ∧ to1 ≤ σ(s0 , checkedAccount)
≤ σ(s0 , f ailed)
≤ to3 ∧ ti1 ≤ τ (s0 , userData) ∧ to3 ≤ σ(s0 , notV alidClient)
≤ to4
≤ to5 ∧ to5 ≤ σ(s2 , displayedResults) + ti5
≤ to6
≤ to7 ∧ to7 ≤ σ(s2 , displayedResults) + ti7
≤ to8
≤ to9
Transition function for “trading stock” e-Service
literature about FSA’s in order to prove important properties,
such as the correctness of an e-Service, wrt its intended
behavior, in order to remove unexpected behaviors. This
opportunity, however, would be useless without techniques
for translating this abstract model into a concrete, standardcompliant representation. In this section we aim at illustrating
how to obtain the specification of an e-Service in WSTL,
starting from its conceptual representation as a FSA. In what
follows, we illustrate the rules used to map a FSA into a
WSTL document. The complete e-Service specification is
then constituted by such a WSTL document plus a WSDL
document containing message type definitions.
First, we associate a WSDL message type with each input
command and with each output message. For example, for the
input command ij , we obtain the following message:
<message name ="i_j"
message’s parts
<message>
Note that the structure of the message must be decided at
implementation time, since it depends on the application.
Then, we consider each transition with its associated constraints, and map them to a WSTL Transition element, in
a very intuitive way. Suppose that the transition between si
and sj is captured as follows:
The current state si is mapped to the source field, and
the successor state sj is mapped to the target field. As far
as representation of input commands and output messages are
concerned, three different situation may happen:
1) oh = ² and ik 6= ²: it is captured by an InputMessage
δ(si , ik , oh , ti0 , to0 )
ti0
ti0
to0
=
≤
≤
≤
sj
to0
τ (si , ik )
σ(sj , oh )
element, having the field name equal to ik . The
duration field is set to τ (·), if τ (·) is defined. Finally,
the reference field is used to define additional time
constraints.
2) ik = ² and oh 6= ²: it is represented by an
OutputMessage element, having the field name equal
to oh . The values of the remaining fields are set using
the same rules as before.
3) ik 6= ² and oh 6= ²: it is captured by an
InputOutputMessage element. The values of its fields
are set using the same rules as before.
As an additional example, consider the situation when
ik 6= ², oh 6= ², τ (·) is defined, and σ(·) is not. Applying the
above rules, we obtain the following Transition element.
<Transition source="si"
target="sj"
type="synchronous">
<input>
<name>"i_k"</name>
<constraint duration="tau(s_i,i_k)"/>
</input>
<output>
<name>"o_h"</name>
</output>
</Transition>
Finally, all the Transition elements are encapsulated into
a Conversation element that represents the overall behavior
of the e-Service.
In the following we show the complete translation of the
e-Service in Figure 5, as a WSTL document 8 . This file has
been validated against the WSTL schema.
<?xml version="1.0" encoding="UTF-8"?>
<Conversation name="trading stocks timed eService"
xmlns=".../WSTL/wstl11"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://.../WSTL/wstl11
http://.../WSTL/WSTL1.1.xsd">
<Transition source="s0" target="s1" type="synchronous">
<input>
<name>"userData"</name>
<constraint duration="00:00:25"/>
</input>
<output>
<name>"checkedAccount"</name>
</output>
</Transition>
<Transition source="s0" target="s4" type="asynchronous">
<OutputMessage>
<name>"failed"</name>
</OutputMessage>
</Transition>
<input>
<name>"userData"</name>
</input>
<output>
<name>"notValidClient"</name>
</output>
</Transition>
<input>
<name>"continue"</name>
</input>
<output>
<name>"displayedStockData"</name>
</output>
</Transition>
<input>
<name>"buy"</name>
</input>
<output>
<name>"displayedResult"</name>
<constraint duration="00:01:00" reference="buy"/>
</output>
</Transition>
<input>
<name>"sell"</name>
</input>
<output>
<name>"displayedResult"</name>
<constraint duration="00:10:00" reference="sell"/>
</output>
</Transition>
8 For
simplicity, we omit the WSDL type definitions.
<input>
<name>"buy"</name>
</input>
<output>
<name>"setStopAndNotify"</name>
</output>
</Transition>
<input>
<name>"sell"</name>
</input>
<output>
<name>"setStopAndNotify"</name>
</output>
</Transition>
<input>
<name>"stop"</name>
</input>
<output>
<name>"emailNotification"</name>
</output>
</Transition>
</Conversation>
CONCLUSIONS AND FUTURE WORK
In this paper we have presented a conceptual model for
representing e-Service behaviour and temporal constraints,
based on FSA’s. FSA’s allow us to capture a large class of
e-Services, and to formally verify important properties of eServices [Weikum, 1999], such as correctness, safety (i.e., at
each point in the execution of an e-Service certain logical
invariants hold), liveness (i.e., an e-Service is ensured to move
towards a point where a goal can be reached). In future work
we address such issues in the context of e-Service behavioural
and temporal aspects.
Additionally, we have introduced a new language, WSTL
(W EB S ERVICE T RANSITION L ANGUAGE), that relies on
such a conceptual model. The novelty of our approach is that
WSTL provides constructs to which corresponding elements
of FSA’s can be straightforwardly mapped. At present this
mapping is done manually, but we plan in the future to
automate this step. In such a way, we have defined a precise
semantics for our language and we allow for service oriented
computing at conceptual level.
The issues of conceptual specification of service oriented
computing and translation to technologies has been considered
in this paper for single e-Services. In the future, we will extend
our work by considering them in the context of e-Service
composition and orchestration.
ACKNOWLEDGEMENTS
This work has been partially supported by MIUR
through the “Fondo Strategico 2000” Project VISPO
(Virtual-district
Internet-based
Service
PlatfOrm)
(http://cube-si.elet.polimi.it/vispo/
index.htm) and the “FIRB 2001” Project MAIS (Multichannel Adaptive Information Systems).
The work of Massimo Mecella has been also partially
supported by the European Commission under Contract No.
IST-2001-35217, Project EU-PUBLI.com (Facilitating Cooperation amongst European Public Administration Employees) (http://www.eu-publi.com/).
R EFERENCES
[Alur and Dill, 1994] Alur, R. and Dill, D. L. (1994). A Theory of Timed
Automata. Theoretical Computer Science, 126(2):183–235.
[Ankolekar et al., 2002] Ankolekar, A., Burstein, M., Hobbs, J., Lassila, O.,
Martin, D., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M.,
Payne, T., and Sycara, K. (2002). DAML-S: Web Service Description for
the Semantic Web. In Proceedings of the 1st International Semantic Web
Conference (ISWC 2002).
[Ariba et al., 2001] Ariba, Microsoft, and IBM (2001).
Web
Services Description Language (WSDL) 1.1.
W3C Note.
Available on-line (link checked March, 1st 2003):
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
[BEA et al., 2002] BEA, Intalio, SAP, and Sun (2002).
Web
Service Choreography Interface (WSCI) 1.0.
W3C Document.
http://www.w3.org/TR/wsci/.
[Berardi et al., 2003] Berardi, D., Calvanese, D., De Giacomo, G., and
Mecella, M. (2003). Reasoning about Actions for e-Service Composition.
Technical Report 01-2003, Dipartimento di Informatica e Sistemistica,
Università di Roma “La Sapienza”.
[Castro et al., 2002] Castro, J., Kolp, M., and Mylopoulos, J. (2002). Towards Requirements-driven Information Systems Engineering: the Tropos
Project. Information Systems, 27(6).
[Curbera et al., 2002] Curbera, F., Goland, Y., Klein, J., Leymann, F.,
Roller, D., Thatte, S., and Weerawarana, S. (2002). Business Process
Execution Language for Web Services (Version 1.0). IBM Document.
http://www.ibm.com/developerworks/library/
ws-bpel/.
[Dayal et al., 2001] Dayal, U., Hsu, M., and Ladin, R. (2001). Business
Process Coordination: State of the Art, Trends and Open Issues. In
Proceedings of the 27th Very Large Databases Conference (VLDB 2001).
[De Michelis et al., 1997] De Michelis, G., Dubois, E., Jarke, M., Matthes,
F., Mylopoulos, J., Papazoglou, M., Pohl, K., Schmidt, J., Woo, C., and Yu,
E. (1997). Cooperative Information Systems: A Manifesto. In Papazoglou,
M. and Schlageter, G., editors, Cooperative Information Systems: Trends
& Directions. Accademic-Press.
[Elmagarmid and McIver Jr, 2001] Elmagarmid, A. and McIver Jr, W.
(2001). The Ongoing March Towards Digital Government (Special Issue).
IEEE Computer, 34(2).
[Georgakopoulos, 1999] Georgakopoulos, D., editor (1999). Proceedings of
the 9th International Workshop on Research Issues on Data Engineering:
Information Technology for Virtual Enterprises (RIDE-VE’99).
[Henzinger et al., 1994] Henzinger, T., Manna, Z., and Pnueli, A. (1994).
Temporal Proof Methodologies for Timed Transition Systems. Information
and Computation, 112(2):273–337.
[HP, 2001] HP (2001). Web Services Concepts: a Technical Overview. HP
Document. Available on-line (link checked March, 1st 2003):
http://www.bluestone.com/downloads/pdf/web_
services_tech_overview.pdf.
[Kuno et al., 2001] Kuno, H., Lemon, M., Karp, A., and Beringer, D. (2001).
Conversations + Interfaces = Business Logic. In Proceedings of the 2nd
VLDB International Workshop on Technologies for e-Services (VLDB-TES
2001).
[Lenzerini, 2002] Lenzerini, M. (2002). Data Integration: A Theoretical
Perspective. In Proceedings of the 21st ACM SIGACT-SIGMOD-SIGART
Symposium on Principles of Database Systems (PODS 2002).
[Leymann, 2001] Leymann,
F.
(May
2001).
Web
Service Flow Language (WSFL 1.0).
IBM Document.
http://www-4.ibm.com/software/solutions/
webservices/pdf/WSFL.pdf.
[Mecella and Pernici, 2002] Mecella, M. and Pernici, B. (2002). Building
Flexible and Cooperative Applications Based on e-Services. Technical Report 21-2002, Dipartimento di Informatica e Sistemistica,
Università di Roma “La Sapienza”.
(available on line at:
http://www.dis.uniroma1.it/∼mecella/publications/
mp techreport 212002.pdf).
[Mecella et al., 2001] Mecella, M., Pernici, B., and Craca, P. (2001). Compatibility of e-Services in a Cooperative Multi-Platform Environment. In
Proceedings of the 2nd VLDB International Workshop on Technologies
for e-Services (VLDB-TES 2001).
[Meredith, 2002] Meredith, G. (2002). Contract and Types. In Invited Talk
at the 3rd VLDB International Workshop on Technologies for e-Services
(VLDB-TES 2002).
[Rahm and Bernstein, 2001] Rahm, E. and Bernstein, P. (2001). A Survey
of Approaches to Automatic Schema Matching. VLDB Journal, 10(4).
[Satish, 2001] Satish, T. (2001).
XLANG. Web Services
for
Business
Process
Design.
Microsoft
Document.
http://www.gotdotnet.com/team/xml_wsspecs/
xlang-c/default.hm.
[UDDI.org, 2001] UDDI.org (2001).
UDDI Technical White Paper.
http://www.uddi.org/pubs/Iru_UDDI_Technical_White_
Paper.pdf.
[W3C, 2002] W3C (2002). XML Protocol. XML Protocol Web Page (link
checked September, 1st 2002): http://www.w3.org/2000/xp/.
[Weikum, 1999] Weikum, G. (1999). Towards Guaranteed Quality and
Dependability of Information Services. In Invited Talk at the 8th
German Database Conference (Datenbanksysteme in Büro, Technik und
Wissenschaft).
[Yang et al., 2002] Yang, J., van den Heuvel, W., and Papazoglou, M.
(2002).
Tackling the Challenges of Service Composition in eMarketplaces. In Proceedings of the 12th International Workshop on Research Issues on Data Engineering: Engineering E-Commerce/E-Business
Systems (RIDE-2EC 2002).
Context-aware Composition of E-Services ?
L. Baresi1 , D. Bianchini2 , V. De Antonellis2 ,
M.G. Fugini1 , B. Pernici1 , and P. Plebani1
1
Politecnico di Milano – Department of Electronics and Information Science
baresi|fugini|pernici|[email protected]
2
Università di Brescia – Dipartimento di Elettronica per l’Automazione
bianchini|[email protected]
Abstract. Composition of e-Services in a multichannel environment requires
taking into account the constraints imposed by the context: user profiles, geographical locations, available channels, and usable devices.
In this paper, we propose an approach for context-aware composition of e-Services
based on an abstract description of both e-Services and context. E-Services are
described in terms of functionality and quality of service. The context describes
the channels that can be used to access e-Services. The paper proposes adaptation rules as the means to allow the composition and dynamically select eService channels according to the constraints posed by available architectures
and application-level requirements. Composition and adaptation rules are exemplified on a simple case for emergency management.
1
Introduction
Nowadays, users are greatly interested in easily accessing a wide variety of services
through different channels [10, 12]. This means that e-Services can be accessed using
different devices (e.g., PCs, laptops, palmtops, cell-phones, TV sets), but also different
network technologies and application protocols. For example, the same service could
be delivered via call centers, the Web, or message-based systems like SMS. In particular, nomadic users want to access services from their current locations and with the
best possible performance. As a consequence, the need emerges for the design of networks and services that are highly flexible and adaptive, capable of exploiting available
resources in an optimal way and with different levels of quality of service.
The Italian MAIS (Multichannel Adaptive Information Systems) project [6] aims to
create an enabling platform, a methodology, and design tools for the development of
distributed information systems based on e-Services and with significant adaptability
features.
Adaptive information systems span different research areas. For example, the simplest
way towards adaptation is through transcoding [2]. As to profiles and context information, we can mention the WWRF (Wireless World Research Forum) [16], the Cameleon
project [5], and the CC/PP (Composite Capabilities/Preferences Profile) initiative of
the W3C device independence working group [15]. Gu et al. [11] present a precise
?
This work has been partially supported by the Italian MIUR FIRB MAIS (Multichannel Adaptative Information Systems) project.
2
L. Baresi et al.
model for quality of service and also propose rules to support the negotiation phase.
But also, the UWA project studied and proposed customization rules [7] to describe and
constrain the adaptability of ubiquitous Web applications. Finally, composition is addressed in [13], where they use DAML-S and coloured Petri nets to reason on e-Service
composition.
The goal of this paper is to define a modeling framework for adaptive information systems based on e-Services. We aim at separating the aspects at application and technological levels and at providing a basis for formalizing contracts between e-Service
providers and the user.
In the proposed modeling approach, e-Services are defined by means of two complementary perspectives: the request perspective, which provides an abstract model of the
context where the e-Service is requested and executed, and the provisioning perspective, which models available e-Services in terms of their functional description and
composition. Both perspectives consider proper characteristics of quality of service to
allow e-Service negotiation in terms of user requests, channels used in the interaction,
and constraints from the e-Service provider. These negotiation policies are coded in
adaptation rules. The two perspectives and adaptation rules form the basis for contextaware composition of e-Services that is able to dynamically select e-Service channels
according to the constraints posed by available architectures and application-level requirements. In particular, adaptation rules allow us to dynamically adapt the execution
flow of our services – described as workflows – according to the characterization of the
selected channel.
The paper is organized as follows. Section 2 presents the reference example used to
illustrate the proposed approach. Section 3 shows the two modeling perspectives, while
Section 4 discusses the application of the approach to the reference example. Section
5 and Section 6 address the specification of quality of service and adaptation rules,
respectively. Finally, Section 7 introduces the MAIS platform and Section 8 concludes
the paper.
2
E-Service model
In this paper we present two different modeling perspectives related to the provisioning and request of e-Services. The provisioning perspective specifies who provides the
e-Service, what the e-Service does and how to invoke its functionality, according to
the available quality of service. The request perspective specifies who requires the eService, i.e., the actor, who wants to have a certain level of quality for the required
e-Service, has a particular user profile, and operates in a particular context.
In the MAIS project, we use UML (Unified Modeling Language) [14] as modeling
language because of its expressiveness.
2.1 e-Service provisioning
Figure 1 shows the components used to model an e-Service with respect to the e-Service
provisioning perspective.
Context-aware Composition of e-Services
3
An EService is described by means of a name that identifies it, a short textual description, a service category (such as, for example, commercial service or information service), and an aggregation of three types of elements:
– a Channel, on which the e-Service is provided. To pursue adaptativity, an e-Service
can be provided through one or more channels and an association class CQualityDimension represents the quality of the e-Service with respect to the channel used.
There can exist several parameters to express the quality of service, for instance:
response time, channel availability, usability, accessibility, integrity, bandwidth, reliability, and price;
Provisioning
Abstract
EService
1
1
has associated
Compatibility
Class
CQuality
Dimension
1..n
Channel
1
1..n
1..n
1..n
Composite
EService
EService
1..n
1..n
1..n
1
Service
Provider
PQuality
Dimension
1
1
Functional
Description
1..n
1
Precondition
1..n
1..n
1..n
1
1..n
PostCondition
Event
1..n
1..n
1
Operation
1
input
1..n
Input
1
1
output
1..n
Output
Fig. 1. Service provisioning perspective
– one or more ServiceProviders, each of them described by a name and standard address information. An association class PQualityDimension expresses the quality
parameters guaranteed by the service provider: for example, data reliability, provisioning time, service availability, price;
4
L. Baresi et al.
– a FunctionalDescription that describes the operational aspects of the e-Service.
The FunctionalDescription – inspired by WSDL [3] – is a set of Operations, with a
name and a short textual description about “what the operation does”:
– Each operation requires one or more Inputs and gives back one or more Outputs;
input and output parameters are described by a name and a value;
– Each operation is associated with a set of PreConditions and PostConditions that
predicate on the Inputs and Outputs of the operation. The former must be verified
before the execution of the operation, while the latter must be satisfied after the
execution. Pre- and post-conditions can also be defined on whole services;
– External Events are used to model actions that are asynchronous with respect to the
normal flow of the e-Service. Each event has a name that identifies it and a type
such as temporal event, data event and so on: for instance, a temporal event is a
timeout that occurs during the execution of an operation. Events must be managed
through appropriate rules.
E-Services can be composed in a recursive manner to create CompositeEServices (similarly to BPEL4WS [8]). Composite e-Services are described through workflows, where
component e-Services are connected by means of control constructs [4].
Moreover, e-Services are grouped into CompatibilityClasses for substitutability purposes. A compatibility class is associated with an AbstractEService, that is the e-Service
required in a process execution expressed in terms of the functionality it provides. A
compatibility class groups, on the basis of predefined “similarity” criteria performed
through comparison between functional descriptions [9], e-Services that are able to
substitute each other in satisfying the considered abstract service. When an e-Service
during the execution of some tasks is not available anymore, it can be automatically substituted by another e-Service that belongs to the same compatibility class and that offers
at least the same functionality. An e-Service can belong to more than one compatibility
class at the same time.
2.2 e-Service request
Figure 2 presents the elements that define our service request perspective. An Actor
issues requests for EServices, already defined in Section 2.1, with a given Quality Level.
In a simplified setting, Quality Level indicators could be: speed, availability, security,
conformity to standards, and price. More thorough descriptions should be used in real
cases. The actual quality of service with which the service is supplied comes from
the negotiation of this Quality Level with that supplied by the provider (i.e., PQuality
Dimension in Figure 1).
Each Actor has a Profile, defined as a set of User Preferences. Since User Preference
is abstract, the Profile can contain a Role, which identifies the role played by the actor
while using the application, its Expertise on the application, and a set of Generic Preferences to add application-specific characterizations to the profile. The hypothesis is
that Role or Expertise define the minimum profile, which can always be enriched with
further information: Generic Preference has a name and value to let the designer render and “quantify” any property. The additional requirement that a Profile must have at
Profile
User
Preference
1..n
1..n
Profile
1
Generic
Preference
Expertise
Role
Request
1
1..n
requests
1..n
EService
Actor
1..n
1..n
is in
Quality
Level
cu rre nt
1..n
is in
Channel
Context
1
1..n
1..n
1..n
Application
Protocol
1..n
1
Channel
1..n
1..n
1
Context
Time Zone
1..n
1
1
Network
1
1
1..n
Network
Interface
Device
1..n
Location
CPU
1..n
Input
Device
1
Memory
1..n
Operating
System
Property
1..n
1..n
1..n
1
1..n
Display
0..n
0..n
Geo
Position
Town
1..n
0..n
0..n
Application
District
Fig. 2. Service request perspective
Country
5
6
L. Baresi et al.
most one Role and one Expertise is not shown here, but can be easily added by means
of an OCL constraint1 .
We assume that an Actor is in some Contexts at the same time, but only one of these is
his current Context. The latter identifies the channels that can be used to supply required
services, while the former define the back-up options, that is, the set of available Contexts – and thus channels – in which the user can be moved to recover from problems
with his current channel.
A Context is characterized by a Location and a Time Zone. Location can be zero or
more Geo Positions, i.e., latitudes and longitudes, Districts, e.g., special-interest areas,
Towns, and Countries. Moreover, a Location can be associated with a set of Properties:
a general-purpose mechanism to add further information to the context description. For
instance, we could use a Property to specify weather conditions. Time Zone describes
the Context with respect to its time information, i.e., its offset from Greenwich mean
time, and the daylight saving time.
The user requests a Service on a given Channel. As soon as this Channel becomes
unavailable, the Actor can switch to a new Channel among those associated with his
current Context. The choice is even wider since the Actor can change Context and thus
the set of available channels.
A Channel is characterized by one Device, one Network, one or more Network Interfaces, and one or more Application Protocols. A Device comprises one CPU, one or
more Input Devices, one Display, and one or more Memories. These hardware components are described through the usual characteristics: for instance, a Display is defined
by means of its size and number of colors. Besides specifying the hardware on board,
we also define the software with which it is equipped: one ore more Operating Systems
and one or more Applications. Network defines the network as a name and a bandwith,
Network Interfaces define how the Device can connect to the Network (e.g., Ethernet,
WI-FI), and Application Protocols specify the application protocols that can be used:
for instance, HTTP, SOAP, SMTP.
3
Reference example
The MAIS project defines sample domains to test multichannel adaptive applications.
In this section, we present an example in the emergency management domain, where
we have to deal with interventions for territorial emergencies due to hydro-geological
events or sanitary emergencies (e.g., due to car accidents). In particular, we consider
the collection and diffusion of information at fixed stations to deliver on-line traffic information to travelers, policemen, firemen, highway operators, and tele-control centers.
This activity implies rapidity of service provisioning and urgency. We assume that provisioning sites are fixed stations spread on wide areas and endowed with small-sized
computing facilities (e.g., PCs). Data collection is managed by operators and users on
the territory via mobile stations, smart phones, GSM, and radio systems. The fixed
stations coordinate the information flow from and to mobile stations, operate data processing, such as check and cross analysis of received data, and distribute information
back to reachable mobile users, and also to the other fixed stations.
1
OCL (Object Constraint Language) is the constraint language supplied with UML [14].
7
Given the distributed nature of the domain, GSM/SMS and mobile channels play a key
role. The strategy, in this context, is to maximize the availability of information on these
channels and minimize the delay in redistributing collected critical information.
The scenario considers that fixed stations act as coordinators and mobile stations (e.g.,
travelers as well as police cars) collect data on local traffic and forward them to the
closest, and reachable, fixed station. Fixed stations receive these data, check them for
accuracy and timeliness, and process them with weather information and statistical data
available on site.
Considering composed e-Services modeled as workflows, whose steps are operations
or e-Services, the composed service Collection and diffusion of information at fixed
stations can be modeled as the cooperation of two services (Figure 3): an e-Service
Remote
Data
Collection
If channel not available
and priority HIGH
Send data to
the closest
fixed station
CHANGE
SERVICE
CHANNEL
If close stations
not available
SUSPEND
SERVICE
AND WAIT
e-service executed on
mobile stations
Send to fixed
stations
Receive from fixed
stations
If mobile channel
not available
CHANGE
SERVICE
eCHANNEL
Receive data
from mobile
Check
data
GSM/SMS
transmission
Not valid
Discard
data
Valid
Contact mobile
and ask to retransmit
data
Load data on
Server/PC and
compute
SUSPEND
SERVICE
AND WAIT
GSM/SMS
transmission
If mobile channel
not available
If channel not
available
Distribute updated
data to fixed
stations
Re-distribute
to mobile
stations
CHANGE
SERVICE
CHANNEL
GSM/SMS
transmission
If mobile channel
not available
GSM/SMS
transmission
CHANGE
SERVICE
CHANNEL
e-service
executed on fixed
stations
Fig. 3. Collection and diffusion of information
8
L. Baresi et al.
to collect data, which is executed on mobile stations, and an e-Service to process and
re-transmit data, which is executed on fixed stations.
Both services are modeled as workflows and include channel switches. The cooperation between the two services is modeled through message exchange with conditions.
Each service starts executing as soon as it receives a start event. Service requests are
processed within the given context, but if a message is urgent and the current channel is
not available, the workflow schema specifies a channel switch. Urgency (i.e., priority)
is modeled through a condition in the workflow.
We specify explicitly those channel switches that are visible to the user and may involve
a change in the process composition logic. As shown in the example, service/channel
switches can occur basically because of:
1. e-Service characteristics: these are inherent to the workflow, hence statically identifiable in the design phase. An example is the condition of no close stations available for data transmission on Internet-based channels. In this case, the service can
be suspended; alternatively, if the message is urgent, it can be simplified and sent
on a different channel (e.g., SMS). It is a design choice to decide the conditions
that can lead to adaptation actions.
2. Channel status: these are parameters that depend on provisioning and can vary over
time. For instance, system workload, speed, bandwidth, and price – our PQualityDimensions in Figure 1 – can make the e-Service be deviated on a different channel
during its execution. At design time, we must foresee both important events, to
capture significant changes of the current channel, and the ways to react to these
changes.
Summarizing, besides conditions, the schema for a composed service must be augmented with adaptation rules to specify how to adjust the execution flow at run-time.
These rules, presented in Section 5, predicate in terms of parameters bound to the quality of service and available context. Adaptation actions include: suspend, alternatives in
the workflow, channel switch, and request for channel upgrade.
4
QoS specification
The reference example highlights situations in which channel availability influences
process execution. In this paper, we focus on adaptivity related to quality of service
parameters. As described above, we take in account two perspectives: e-Service request
and e-Service provisioning. In the same way we define the quality of service following
such two standpoints. We define a set of basic quality dimensions that characterize the
service being provided on a given channel and requests for quality levels in service
requests. Quality of service dimensions are grouped in quality of service parameters
related to the provider (PQualityDimension) and quality of service parameters related
to the provisioning on a given channel by a given provider (CQualityDimension) as
shown in Figure 1.
Consistently to the models presented in Section 2, we can represent such characteristics
using XML:
9
<Service name="sendData">
<Provider name="provider1">
...
<PQualityDimensions>
<ProvisioningTime unit="s">10</ProvisioningTime>
<ServiceAvailability hoursperday=24 daysperweek=7>90%</ServiceAvailability>
<Price currency="USD">100</Price>
</PQualityDimensions>
</Provider>
<Channels>
<Channel name="PDA/HTTP/GPRS">
<Device>PDA</Device>
<ApplicationProtocol>HTTP</ApplicationProtocol>
<Network>GPRS</Network>
<NetworkInterface>ModemGPRS</NetworkInterface>
<CQualityDimensions>
<Bandwidth unit="Kbps" min=56.6 max=113.2/>
<ChannelAvailability hoursperday=24 daysperweek=7>99%</ChannelAvailability>
<Price model="flatrate" currency="USD">100</Price>
</CQualityDimensions>
</Channel>
<Channel name="Phone/HTTP/UMTS">
<Device>Phone</Device>
<ApplicationProtocol>HTTP</ApplicationProtocol>
<Network>UMTS</Network>
<NetworkInterface>UMTSModem</NetworkInterface>
<Bandwidth unit="Kbps" min=50 max=1024/>
<Price model="per minutes" currency="USD">0.30</Price>
</Channel>
<Channel name="PDA/WAP/GPRS">
<Device>PDA</Device>
<ApplicationProtocol>WAP</ApplicationProtocol>
<Network>GPRS</Network>
<NetworkInterface>ModemGPRS</NetworkInterface>
<Bandwidth unit="Kbps" min=28.3 max=56.6/>
<Price model="per minutes" currency="USD">0.30</Price>
</Channel>
</Channels>
</Service>
In this case, we consider service sendData, which sends data to the fixed stations. The
provider assures its provisioning with a ProvisioningTime equal to at most 10
seconds, ServiceAvailability equal to 90% 24 hours 7 days a week, and a price
of 100 USD. We also suppose that it can be used through three wireless channels: a
PDA which uses (i) HTTP or (ii) WAP over GPRS and (ii) a SmartPhone which communicates via HTTP over UMTS. These three channels provide different performances
and availability degrees described by Bandwidth and Availability.
From a user perspective, the quality of service can be defined as a set of quality levels
that depend on either the basic quality dimensions presented above or dimensions that
capture the status of the system. In the first case, the actor that uses the service knows the
quality features and is able to negotiate the more appropriate quality level. In the second
case the system informs the actor that some aspects of the system can be observed. For
example, let us consider the following dimensions:
10
L. Baresi et al.
<QualityLevels>
<Dimension name="Speed">
<Level name="very high">
<Bandwidth>
<Condition type="greaterThan" unit="Kbps">512</Condition>
</Bandwidth>
<ProvisioningTime>
<Condition type="lessThan" unit="s">2</Condition>
</ProvisioningTime>
</Level>
<Level name="high">
<Bandwidth>
<Condition type="between" unit="Kbps">
<min>60</min><max>512</max>
</Condition>
</Bandwidth>
<ProvisioningTime>
<Condition type="between" unit="s">
<min>2</min><max>4</max>
</Condition>
</ProvisioningTime>
</Level>
...
</Dimension>
<Dimension name="Availability">
<ChannelAvailability>
<Condition type="greaterThan" dimension="hourperday">10</Condition>
<Condition type="greaterThan" dimension="dayperweek">6</Condition>
<Condition type="greaterThan" dimension="percent">99</Condition>
</ChannelAvailability>
</Level>
</Dimension>
</QualityLevels>
The actor can negotiate the Speed and Availability of the service. Thus, after
the negotiation phase, the actor selects, for each offered quality dimension, the required
level. During the execution of the process which involves e-Service sendData, the execution system has to ensure that the quality does not assume a rate lower than the
negotiated level.
5
Adaptation rules
In an adaptive context, e-Service composition has to handle critical situations. Due to
e-Service failures or insufficient quality of service, the execution could consider service
changes or reconfigurations. The first case has already been studied in [9]: We analyze
the functional aspects of the e-Service to discover a similar one that can substitute the
former. E-Service substitutability and similarity are tackled by considering the compatibility classes introduced above.
The second case is analyzed in this paper. Service provisioning still occurs, but using a
different channel, that is, by changing one of its components: device, network, application protocol, or network interface. Additional e-Services might be invoked to handle
aspects related to the reconfiguration.
To disclose those critical situations that require service reconfiguration, we suppose that
a system can monitor the execution and reveal any modification about the quality dimensions considered during the negotiation phase. Thus, following the event-condition-
11
action paradigm [1], we define adaptation rules to specify how the service reconfiguration has to occur. Such rules are associated with the workflow schema.
In our reference example, we consider a critical situation that refers to a communication
breakdown due to a service or channel unavailability while the service is sending data
to a fixed station using a SmartPhone over UMTS. In particular, since priority is high, if
the service becomes unavailable, the service itself will must be changed. For instance,
we could select a different service provider: After a negotiation phase, we would decide
a new quality level. On the contrary, if the channel fails, the system can decide to change
the communication channel by selecting a new transmission protocol like GPRS. In our
approach, we define events to notify significant changes on quality dimensions. For
instance:
<Events>
<Event type="ChangeSpeedEvent">
<Conditions>
<Predicate dimension="Speed" condition="lessthan">
<value>high</value>
</Predicate>
</Conditions>
<Actions>
<Action type="changeDevice"/>
<Action type="eventActivation">ChangeDeviceEvent</action>
</Actions>
</Event>
<Event type="ServiceNotAccessibleEvent">
<Conditions>
<Predicate dimension="Availability" condition="true">
</Predicate>
</Conditions>
<Actions>
<Action type="changeChannel"/>
<Action type="eventActivation">ChangeChannelEvent</action>
</Actions>
</Event>
<Event type="ChangeChannelEvent">
<Action type="notification">The channel is changed</action>
</Event>
<Events>
Event ServiceNotAccessible occurs when the communication breakdowns. In
such a situation, if Availability is true, we impose a channel switch, because we
need to find another means to deliver the service. If Availability is false, we must
switch to another service (this is not shown in the rule). The two rules are applied
to an excerpt of our running example in Figure 4 (the e-Service on mobile stations).
ChangeSpeed can be triggered when sending data to the closest fixed station (because the speed drops down drastically), while ServiceNotAccessible is triggered when we discover that the channel is not available, but we want to send our data
with high priority. To maintain a consistent environment, every service reconfiguration
generates an event to inform all active services and the user about the new status.
6
MAIS Architecture
The e-service composition and selection approach presented in the previous sections
is based on the adaptive architecture that we are developing in the MAIS project. This
12
L. Baresi et al.
ServiceNotAccessible
ChangeSpeed
Remote
Data
Collection
Send data to
the closest
fixed station
If channel not available
and priority HIGH
CHANGE
SERVICE
CHANNEL
If close stations
not available
e-service executed on
mobile stations
SUSPEND
SERVICE
AND WAIT
GSM/SMS
transmission
Fig. 4. Adaptation rules in our example
architecture assumes adaptivity at various levels, as shown in Figure 6. As we discussed
E-service
directory
Context
description
iMac
Fig. 5. MAIS architecture
in Section 2, services may be accessed by different types of devices, provided using different technological channels, and networks may present different levels of quality of
service. All information about networks, devices, and service providers is supplied as
Context description used by the Context manager. The architecture is reflective to provide functionality to access context information, and to control channel configurations,
according to suitable parameters.
The Interaction enabling platform uses the Definitions of Quality levels illustrated in
Section 4 to transform quality of service requests at the E-Service composition platform
13
into requests in technological terms to the Adaptive channels used by the application.
Initially, such transformations are to be obtained by mapping application level rules into
technological constraints; negotiation of parameters at different levels in the Interaction
enabling platform will be considered at later phases in the project.
E-Services are stored in an E-Service directory, representing the characteristics of eservices in terms of provided functionality and possible channels for their provisioning.
The e-Service directory provides functionality for retrieving e-Services to enable a dynamic composition of processes according to the characteristics of the user requests and
context information. The directory being realized extends the e-Service registry developed in the VISPO project [4]. This registry stores e-Service information in terms of
descriptors derived from WSDL abstract specifications and allows retrieval and adaptation of e-services to a given composition schema on the basis of a domain ontology.
7
Conclusions and future work
The paper analyzes context-aware composition of e-Services and discusses the MAIS
approach for a flexible and channel-dependent composition of services. We propose to
separate the characteristics of e-Service provisioning and user contexts, for e-Service
requests, and we propose two separate models to describe them.
We also discuss adaptation rules for mapping user level requirements into technological
constraints. These rules allow for the composition of e-Service specifications based on
context information. In this way, we define flexible processes that are able to provide
and access services which are adequate to the context available to the user.
The MAIS project is developing an adaptive approach that addresses both technology
(e.g., networks, devices, micro-databases) and composition and enabling platforms to
manage and control context information and to allow context-aware dynamic composition.
References
1. F. Casati, S. Ceri, S. Paraboschi, and G. Pozzi. Database Support for Workflow Management:
the WIDE Project, chapter Active Rule Support. Kluwer Academics Publishers, 1999.
2. Y. Chen, W.Y Ma, and H.J. Zhang. Detecting web page structure for adaptive viewing on
small form factor devices. In ACM press, editor, Proceedings of WWW 2003, 2003.
3. E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description
Language (WSDL) 1.1. www.w3.org/TR/2001/NOTE-wsdl-2001 0315, March
2001.
4. E. Colombo, V. De Antonellis, C. Francalanci, M. Mecella, M. Melchiori, B. Pernici, and
P. Plebani. Cooperative information systems in virtual districts:the vispo approach. IEEE
Bulletin on Data Engineering, 2002.
5. Cameleon Consortium. Cameleon web site. giove.cnuce.cnr.it/cameleon.
html.
6. MAIS Consortium. Mais: Multichannel adaptative information systems. black.elet.
polimi.it/mais/.
7. UWA Consortium. UWA web site. www.uwaproject.org.
14
L. Baresi et al.
8. F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana.
Business Process Execution Language for Web Services, version 1.0. www.ibm.com/
developerworks/library/ws-bpel/, July 2002.
9. V. De Antonellis, M. Melchiori, and P. Plebani. An Approach to Web Service compatibility in
cooperative processes. In Proc. IEEE SAINT2003 of Int. Workshop SOC, Orlando, Florida,
USA, 2003.
10. A. Maurino et al. Studio delle caratteristiche dei canali. Technical report, Politecnico di
Milano, 2003. In Italian.
11. X. Gu, K. Nahrstedt, W. Yuan, D. Wichadakul, and D. Xu”. An xml-based quality of service
enabling language for the web. Technical Report UIUCDCS-R-2001-2212, University of
Illinois at Urbana-Champaign – Computer Science Department, 2001.
12. J. Krogstie, K. Lyytinen, A. Opdahl, B. Pernici, K. Siau, and K. Smolander. Mobile information system–research challengers on the conceptual and logical level. International
Journal of Mobile Communication, special issue on Modeling Mobile Information Systems:
Conceptual and Methodological issues., 2003.
13. S. Narayanan and S.A. McIlraith:. Simulation, verification and automated composition of
web services. In Proceedings of WWW 2002, pages 77–88, 2002.
14. Object Modeling Language (OMG). UML Unified Modeling Language - Version 1.5. www.
omg.org/technology/documents/formal/uml.html, 2003.
15. W3C. Composite capabilities/preferences profile. www.w3.org/Mobile/CCPP/.
16. WWRF. Book of visions 2001. www.wireless-world-research.org/.
A quality model for e-Service based multi-channel adaptive information systems ∗
Carlo Marchetti
Università di Roma “La Sapienza” – Dipartimento di Informatica e Sistemistica
via Salaria 113, I-00198 Roma, Italy
[email protected]
Barbara Pernici, Pierluigi Plebani
Politecnico di Milano – Dipartimento di Elettronica e Informazione
piazza L. da Vinci 32, I-20133 Milano, Italy
[pernici,plebani]@elet.polimi.it
Abstract
provider information system. Current implementation of eServices are mainly based on Web-service, i.e. e-Services
communicating through the network layers and protocols
common to the Web community (TCP/IP, HTTP etc).
In a multichannel information system users can access the
same service through different channels. At a high level
of abstraction, “channel” examples are: a simple PC connected to the service provider through the Internet, a PDA
connected through a wireless LAN, a SmartPhone exploiting UMTS and a private backbone.
Depending on the channel used to access a given service,
the latter can be exported with different quality levels, i.e.,
a channel can be associated to some level of Quality of Service (by now QoS) perceived by users exploiting it. As
an example, a channel consisting of a WebTV connected
by a private Intranet to a provider allows watching a video
stream at a quality higher than the one achievable by a PDA
connected through a wireless network.
Within an adaptive multichannel information system, the
system is also capable of tuning itself according to the (i)
user needs, (ii) underlying network and computing infrastructure. Concerning adaptation with respect to user needs,
adaptation should be intended as the capability of reacting
to asynchronous changes of user preferences, e.g. with respect to the channel used to access a given service. As example, a user could start watching a movie using a SmartPhone while travelling on a train, and then, once at home, he
could continue watching the movie on her WebTV. In this
case the system should adapt itself to continue the service
provisioning despite the user-triggered channel switch. Furthermore, the service level agreement (SLA) mechanisms
should allow to deal with such a class of scenarios.
For what it concerns adaptation with respect to the network
and computing infrastructure, the system should be able to
handle events that could determine a change in the QoS per-
In a multichannel information system users can access the
same service through different channels. At a high level
of abstraction, “channel” examples are: a simple PC connected to the service provider through the Internet, a PDA
connected through a wireless LAN, a SmartPhone exploiting UMTS and a private backbone. Within an adaptive multichannel information system, the system is also capable of
tuning itself according to the user needs, underlying network and computing infrastructure.
We present a novel quality model for multi-channel eServices and we propose adaptation strategies that allow
describing and enforcing QoS aspects, respectively. In particular the quality model, which can be viewed as an extension of existing proposals for single-channel system, allows classifying resources of a multichannel information
systems, their properties related to non-functional quality
related aspects, and defines the role of the service provider
as a proposer of service levels, and of the user as a selector
of the adequate service levels.
1
Introduction
e-Services are self-describing components that are open
and enable fast development and deployment of distributed
applications. Services are exported by service providers,
i.e. organizations that offer (i) the service implementations,
(ii) service descriptions, and (iii) the technical and business support deemed necessary to provide the service. eServices implementations and descriptions lays within the
∗ This work is partially supported by the Italian MAIS (Multichannel
Adaptive Information Systems) project. http://black.elet.polimi.it/mais
1
Profile
Request
Profile
1
2
Provisioning
1..n
1..n
User
Preference
1..n
User
requests 1..n
1..n
1..n
e-Service
is in
Expertise
current
1..n
Generic
Preference
Role
is in
Context
Channel
Application 1..n
Protocol
1..n
1
1..n
1..n
1..n
Channel
1
1..n
Context
1
Composite
EService
1..n
EService
1..n
1..n
Service
Provider
1..n
Time Zone
1
1..n
1
Channel
1..n
1
Network
1
1
Location
Device
1..n
1..n
Property
1..n
1..n
1..n
1
CPU
1..n
Input
Device
Memory
1..n
Operating
System
0..n
1
Display
1..n
Application
1
0..n
Geo
Position
Town
0..n
0..n
District
Country
1..n
Functional
Description
1
1
2
MAIS Overview
The Italian MAIS (Multi-channel Adaptive Information
System) project aims at studying a set of models and
methodologies which allows service provisioning through
different channels. According to the scenarios described in
the introduction, this work concentrates on the quality modelling and adaptivity at application level which depends on
both user preferences and provider resources.
1..n
PostCondition
1..n
1..n
1
Operation
ceived by users, by reacting to such events striving to enforce the maximum QoS and to avoid violations of SLAs.
As an example, in the video-on-demand scenario the system
could monitor channel behavior and then discover that the
jitter of a channel exceeds a given threshold, necessary to
fulfill the SLA holding with some users accessing from that
channel. It could then react to such an event by increasing
the compression of a stream or invite the user to switch onto
another channel. Similar examples can be made considering
on-line banking: a user equipped with a cellular phone with
limited processing capabilities could impose the choice of a
cryptography algorithm less expensive than the one implementable using a full-fledged PC.
This work aims at presenting a quality model suitable for
adaptive multi-channel information systems able to satisfy
the scenarios presented above. In Section 2, after a brief introduction of the MAIS project, we introduce the e-Service
and channel specifications with respect to the provider, the
user and the desired adaptivity. In Section 3, a discussion
about related work and research needs motivated by the
multi-channel environment is presented. Section 4 introduces our quality model and Section 5 the adaptation strategies which aim at resolving the scenarios discussed above
on the basis of the quality model presented.
Precondition
1..n
1..n
Event
Figure 1. User perspective
1..n
1
1
Figure 2. Provider perspective
In MAIS, user is characterized by a context and by a profile
[6] (Figure 1). The context describes, among the others, the
set of channels available and the channel currently in use,
in a given location and at a given time. The profile captures
user preferences which depends on a role held by the user,
its expertise on the service, and a set of generic preferences
that enable further service-specific user profiling. Referring
to the video-on-demand example, a user could be able to
watch a video on both a PC and a SmartPhone, which is
described in the context. Furthermore, the user could classify channels according to her preferences by stating, for instance, that when all the channels are available she prefers
to use the PC when she stays at home (using the profile).
The provider is described in terms of the provided eServices and available channels as shown in Figure 2. According to this description, an e-Service is defined as an
abstraction of a functionality, or a set of functionalities, exported by a system through a standard interface. Unlike the
Web Service, with the e-Service we suppose that the functionalities it performs could be invoked by different channels not only Web based. However, even if we consider the
generic e-Services, for their specification we reuse the vast
amount of work done in the Web-Service community.
Therefore, WSDL [10] can be used to specify what are the
operations the e-Service is able to perform, and in which
way the user can invoke them. Such operations constitute
the application logic of the e-Service and in the video-ondemand example could be operation as select video, start
video, and pause video.
Proposal such as BPEL4WS [12] or WSCL [5] allow to
define, at different detail levels, the e-Service behavior.
In particular we are interested on the observable behavior
[3] (named also conversation), i.e. the order in which the
e-Service operations can be invoked. DAML-S [11] can
also be used to specify behavior in terms of pre and postconditions. In the video-on-demand example, the behavior
description can state that a video can be played only after it
has been selected.
Using a simplified version of [22], as shown
in Figure 1 a channel is defined as a triple
hdevice, network, applicationprotocoli,
where device characterizes the user’s equipment (e.g. PDA, PC,
SmartPhone, ...), network identifies the data-link protocol
exploited by the user’s device to connect to the provider
(e.g. UMTS, GPRS, ...), and application protocol represents the protocol used for message exchange (e.g. HTTP,
SMTP, WAP, ...). Self-explaining examples of channels
are: h PC, Ethernet, HTTP i, h PC, ISDN-TA, HTTP
i, h SmartPhone, UMTS, HTTP i, h PC, 802.11b,
FTP i. Using channels, the service provider characterizes
services (Figure 2) with the list of channels users can
exploit to access the service. As different channels usually
perform differently, service providers can offer services
at different quality levels (the so-called service levels).
Actually, service levels depend on both the service quality
parameters (e.g. video frame rate, video resolution) and
channel quality parameters (e.g. bandwidth, latency).
Given a description of available resources, the provider is
able to quantify service levels and to export related information to users through a Service Level Specification
(SLS). Then, when a user wishes to access a service, a
Service Level Agreement (SLA) describing the QoS obligations of the provider (and the possible penalties) is negotiated among the user and the provider. Once a user and
a provider agree on an SLA, the service provisioning phase
starts. During this phase SLA must be honored as long as (i)
the necessary resources stays available and (ii) the user continues to access the service from the initial channel. To attain this, the service provider system strives to monitor and
control the usage of its internal resources in order to maintain the service levels agreed with users. However, channels are assumed out of the control of the service provider,
and thus their service levels could abruptly reduce hindering the maintenance of a set of SLAs. Furthermore, users
can decide to switch onto different channels due, for example, to a change of the device used to access a service or
network failure. Therefore, we want our system to dynamically adapt SLA upon upon facing these events. The main
issue to be addressed in this context is to continue providing
the service at a service quality which is adequate to the user
needs.
Addressing this issue requires to tackle a number of problems to be addressed, e.g.:
– to define how service levels can be expressed;
3
– to define how to monitor and control resources, especially channels, and in particular which attributes can
be observed and which can be controlled;
– to define means to translate requirements expressed at
high abstraction level (e.g., frame rate) more useful
for the user, into requirements on resource usage (e.g.
bandwidth, latency) and vice-versa.
To solve the above mentioned problems, we start from the
definition of a quality model for e-Services in a multichannel information system. This model enables to reason
about both QoS as to be expressed in Service Level Specifications (high level) and QoS of resources needed to enforce
service levels (low level), especially of channels, that are
explicitly represented in the model. Furthermore, the model
makes it possible to reason about attributes of services and
resource, and to devise how mapping among them can be
addressed. Finally, we devise means to feed the low level
of the model in order to define and implement adaptation
strategies, that enable the system to react to asynchronous
events as user-driven channel switches and resource shortages.
3
Related work
Definition of the QoS in a web-service based system is
a topic largely discussed in the literature. An interesting
framework which considers the main aspects interesting the
QoS definition and management for the Web-Service is provided in [19]. In this proposal, the QoS is defined at two
different levels shown in Figure 3.
At the bottom level the provider, using specific metrics, can
measure the QoS of the resources that he uses to provide the
service. On the basis of such measurements, an e-Service
quality can be defined by a set of suitable QoS parameters.
At the higher level, through the definition of a set of Service
Levels, the provider advertises which is the possible QoS
configuration he is able to guarantee for the e-Service he
provides. In such a way, the user analyzes and selects a
set of Service Levels creating the Service Level Agreement
(SLA).
During provisioning, first of all the satisfaction of SLA by
the provider is monitored by the user or by a trusted thirdparty. Secondly, the provider performs a set of strategies in
order to enforce the promised QoS.
About the QoS definition for the e-Service, current work
take into account only the service provisioning through the
Web. [21] identifies the QoS parameters which are considered useful for the service provider to characterized its own
Web-Service with respect to the user. [28] proposes a set of
Service Level
Agreement
Provider
User
Service Levels
e-Service
QoS service
parameters
Resources
QoS resources
parameters
Figure 3. General framework
metrics which allow not only measuring the QoS parameters for a single e-Service, but also calculating measures for
derived parameters for a composition of e-Services. About
the quality of the data exported by the e-Service, [9] lists the
main parameters (e.g., accuracy, completeness, consistency,
reliability) and the related metrics. At higher level, [24] and
[16] identify how to define an SLA and which are the most
important parameters which have to be considered.
According to this framework, QoS definition and monitoring at resource level and service level are required.
For what it concerns QoS management with respect to the
resources, both the middleware and agent communities offer significant contributions enabling the enforcement of
several distinct QoS aspects. As examples, in the middleware for distributed objects community, the Common Object Request Broker Architecture (CORBA, [14]) specification details standard interfaces enabling the implementation
of applications with QoS guarantees. Examples are: RealTime CORBA (implemented by the TAO object request broker [26]) provides standard interfaces to enforce timeliness
properties, e.g. scheduling policies and bounded message
transfer delays; Fault-Tolerant CORBA (implemented in the
Eternal [23] and IRL [4] systems) allows the enforcement of
availability properties, e.g. increasing the mean time to failure, to repair and thus between failures of CORBA objects
through software replication techniques; CORBA Security
[15] allows the enforcement security properties such as authentication and confidentiality of object requests. Other
relevant proposals, e.g., BBN’s Quality Objects, [29], entail
timeliness, availability, and security properties by providing a uniform (unfortunately non-standard) framework enabling the rapid design of mission critical applications. In
the agent community, significant standardization efforts are
those from the Foundation for Intelligent Physical Agents
[27] (FIPA), guiding implementation efforts, e.g. JADE [7]
and FIPA-OS [2]. In particular [1] defines a Monitor Agent
and a Control Agent that implements QoS properties related4
to performance and security exploiting resource adaptation,
which should be achieved through the standard pattern of
reflective computing, i.e. observing and controlling system behavior. Finally, commercial solutions are currently
targeted to enterprise QoS and system management architectures for web-service provisioning by focusing on load
balancing, access control and network management, e.g.
[25, 18, 17, 20].
Even if several of the above mentioned contributions deals
with communication channels by taking into account common QoS properties (latency, bandwidth, jitter, cryptography etc), none of them is based on a framework for
multi-channel information systems1 . As a consequence,
objects/agents/web-services are usually not designed taking
into account users that possibly access a service from several channels, and thus QoS enforcement strategies usually
assume users to statically connect to a provider via a single
channel, which is the same for all users.
Starting from the existing proposals, our model aims at considering a more extended environment in which the channel
influences the QoS definition and management.
4
Quality model
The existing proposals highlight the different role held by
the service user and the service provider in the QoS definition. Taking into account such distinction between these
two perspectives, our quality model is defined by the Service Level Specification (SLS) as the definition of QoS offered by the service provider and the Service Level Agreement (SLA) as the agreement between the user and the
provider.
From the service provider perspective, it is possible to define the QoS of his services by analyzing the resources that
he allocates in order to provide the service. In our model,
represented in Figure 4, we consider three main categories
of resources: (i) the physical resources, (ii) data resources,
and (iii) channel resources. With the physical resources, we
consider the quality aspects of devices like CPU, disks, and
memories which are used to perform the service functionalities. For data resources, we are interested in quality dimensions like currency, timeliness, and availability of data as
expressed in [9]. Finally, the channel resources capture dimensions like bandwidth, latency, and jitter. Based on some
of the resource quality dimensions, the service provider is
able to define the parameters which define the QoS strictly
related to the service functionalities. Nearby such resource
related dimensions, even the QoS related to service provider
is used to define the overall QoS. In this case, typical dimensions are related to the economical issues defining, for
1 Let us remark that in MAIS a channel embeds both the communication
channel and the user device.
SLS
Resources
Device
Data
Provider
Channel
Figure 4. Service Level Specification
instance, the pricing policy for the service and the payment
forms.
It is important to note that several quality dimensions, in
particular the channel quality parameters, represent elements the provider can only monitor and cannot control and
especially can be “guaranteed” only by best-effort strategies.
For this matter, we make a distinction between the QoS parameters which are both observable and controllable against
the QoS parameters which are only observable. In fact,
the first kind of parameters, can be used to effectively propose an SLS in order to expose quality dimensions that the
provider is able to really guarantee modifying their values.
On the contrary, the second kind of parameters is used only
to inform the user about the possibility of monitoring a particular dimension.
On the basis of the quality dimensions introduced, the
provider builds the Service Level Specification (SLS) as
represented in Figure 4, expressed using high-level, useroriented values.
Since the QoS mainly depends on the channel, we can associate an XML representation of the QoS to the WSDL
specification of the e-Service, according to the distinction
made in [8]. In this way two WSDL specifications exist:
(i) the WSDL interface document, in which only the types,
messages and portType are expressed, and (ii) the WSDL
implementation document in which the portType is specialized with respect to a particular binding (channel) and in
which our SLS representation can be associated.
An hypothetical example for the video-on-demand service
is shown in Figure 5 where, using the RTSP (a video streaming protocol) two different channels are available and, for
each of them three different service levels (high, medium,
low) are introduced. In particular, the service level depends
on parameters related to the device (framerate and resolution) and the provider (price and availability).
Once the SLS is defined, the user given a set of e-Services
with equivalent functionalities, is able to decide which is the
better e-Service with respect to its quality. Before the actual
<levels channel="PC-Eth-RSTP">
5
<level id="high">
<framerate>40fps</framerate>
<resolution>1024x768</resolution>
<price currency="EUR">100</price>
<availability unit="percentage">95</availability>
</level>
<level id="medium">
</level>
<level id="low">
</level>
</levels>
<levels channel="SPhone-UMTS-RSTP">
<level id="high">
</level>
<level id="medium">
</level>
<level id="low">
</level>
</levels>
Figure 5. A Service Level Specification for the
Video-on-Demand example.
e-Service invocation, the user has to negotiate with the service provider in order to define in which way the service
will be used. The result of such phase is a contract specified
by the Service Level Agreement (SLA).
According to [19], the SLA has to take into account several
aspects related to the service provisioning in order to describe all the situations in which the provider and the user
can be. About the definition of the value of QoS parameters,
it is important to notice that the SLS could be used only as
a reference point by the provider and the user during the negotiation. In fact the real value of the QoS parameter that
the provider promises to the user can be different from the
value presented in the SLS due, for instance, to the different
bargaining power of the potential users. For this matter, before issuing an SLA between a user and a provider, an SLS
can be dynamically adapted to user preferences and system
resource, thus building an SLS that takes into account the
user’s context and profile, as well as the available resources.
As a consequence, the SLA will probably be satisfactory for
users and implementable by the system.
An important issue not considered in this paper and that will
be developed in future work, is the definition of penalty
clauses, i.e. the behavior of the user and the provider in
case of contract unfulfillment. This aspect of the SLA has
to define who and how the system (divided into several subsystems) has to be monitored in order to discover QoS violations.
5
Multi-channel Adaptation Strategies
As pointed out in Section 3, current proposals for service
provisioning with QoS guarantees mainly focus on singlechannel systems in which users can access a service exploiting a device and an underlying infrastructure known
since the system design time. This enable designers to deploy architectures enforcing SLAs through mechanisms as
resource monitoring, request/traffic admission control, priorization, load balancing, and so on, essentially devoted to
avoid performance degradation due, for example, to platform congestion and faults [13]. Analogous techniques are
put in place to enforce other non-functional properties such
as availability, and security (see Section 3). Even if these
mechanisms are still necessary to implement a given SLA
on each channel of a multi-channel service provider, the latter could miss opportunities if omitting to consider multichannel adaptation strategies. Broadly speaking, these
strategies are additional features enabling the system to dynamically react to asynchronous events notifying the modification of the conditions under which an SLA was issued,
i.e. changes of user needs and of the underlying network
and computing infrastructure states. The basic idea underlying these strategies is to react to these events by exploiting
the availability of (i) several channels to provide the service
and (ii) of the information on users available within the context and profile (see Section 2), in order to continue service
provisioning without violating SLA.
Once an SLA has been established between a user and a
provider, the service provisioning phase takes place. During
this phase, however, according to the examples of Section
1, the user is allowed changing the channel for accessing
the service, and channels can even modify their behavior2
possibly causing SLA violations. An adaptive system reacts by proposing to the user to switch onto another channel
compatible with the user profile and the context.
To achieve such adaptiveness, it is first necessary to bridge6
the gap between low-level QoS properties and high-level
QoS guarantees as expressed in SLA and SLS. This issue
is clearly application dependent (e.g. translating frame rate,
dimension and color depth in channel requirements as minimum bandwidth, maximum latency, and maximum jitter in
the video-on-demand example). However, means to monitor low-level QoS parameters and to set thresholds to signal
possible violations of SLAs must be put in place in order
to enable applications to reason about service levels. The
quality model presented in the previous section represents a
useful framework (see Figure 4), as the physical, data and
channel resource model can be fed of values coming from
a monitoring infrastructure (e.g. a JMX-based system [20],
and the quality factory presented in [9]). Once the system
is fed with values coming from resource monitoring tools,
multi-channel adaptation strategies can be built on top of
this knowledge base3 .
Such strategies can be implemented by enabling applications to handle two events, namely the user-triggered
channel-switch, and the provider-triggered channel-switch,
that model the condition under which a channel switch can
occur.
In particular, a user-triggered channel-switch event is
thrown by the user device to the provider upon detecting
(i) a change of user preferences in terms of channels or
devices to access a service or (ii) that the SLA has been
violated. In the first case, in order to allow the user to
switch among the available channels, a set of suitable operations which acts on the channel properties should be included in the service specification. For this matter, each
service will have to provide operations as changeChannel(aChannel)which, given in input the channel definition, states the availability of the required channel with respect to the user context and eventually operates the channel switching. Moreover, in order to create a user-friendly
system more expressive operations could be used as, for instance in video-on-demand example, playOnTV(), playOnPDA(). On the contrary, in order to discover SLA violations, the user can use its own devices able to fairly monitor
service level, or indifferently can refer to trusted third party
[19] .
Provider-triggered channel-switch events are thrown to the
application when the usage of some resource exceeds a
given threshold, e.g. upon a channel exceeding a maximum
jitter value. To account for this, the quality model allows
setting thresholds on the metrics defined for low level resources according to [19].
Upon the receipt of both user-triggered and providertriggered channel-switching events, the provider generates
2 We remark the assumption that channel behavior is out of the provider
control: even if service providers can require SLAs to channel providers,
upon a violation of such an SLA they would necessarily incur in violations
of SLAs with users in the absence of on-line adaptation strategies.
3 Resource monitoring is also one of the building block to enforce SLAs
on each channel, which is out of the scope of this paper being deeply discussed in the literature (see Section 3).
a novel customized SLS taking by into account context, profile, and available resources; then it suspends service provisioning, sends the SLS to the user, and the system eventually come up with a new SLA, possibly after a negotiation
phase.
6
Conclusion and Future Work
In this paper we present a first proposal for novel quality model for multi-channel e-Services and proposing
adaptation strategies that allow describing and enforcing
QoS aspects, respectively, developed in the context of
the MAIS project. In particular the quality model, which
can be viewed as an extension of existing proposals for
single-channel system [19], allows classifying resources
of a multichannel information systems, their properties
related to non-functional aspects, and defines the role of
the service provider as a proposer of service levels, and
of the user as a selector of the accepted service level.
Adaptation strategies allow providing users with service
levels that are compliant with the user equipment and
preferences, other than being implementable by service
providers. Furthermore, adaptation strategies enable the
system to dynamically react to asynchronous events as a
change of user preferences about channel exploitation or a
shortage of resources due to some unpredicted failure event.
As future work, first we plan to refine and to detail the quality model with the attributes related to the resources, especially those of channels4 . Describing channels in terms
of QoS passes through the analysis of several attributes related to (i) physical devices (ii) data-link protocols, and (iii)
application protocols, and of their dependencies. The description of these attributes would allow feeding the model
with current values fetched from observable components
and thus to implement adaptation strategies involving controllable components. Another issue requiring further investigation is the mapping between high-level QoS properties as expressed in an application dependent manner within
service levels and the low-level QoS properties, in order to
provide applications with possibly standard tools to easily
translate their service levels in resource-level requirements,
at least for a restricted set of applications, i.e. service levels.
Further investigations will be in the definition of the characteristics of user profiles which translate to QoS requirements, such as for instance in the case for user with special
needs.
4 A deep investigation on the quality of data attributes has already been carried out in the context of the DaQuinCIS project, see
http://www.dis.uniroma1.it/∼dq.
References
7
[1] Fipa 2000 specification. http://www.fipa.org.
[2] Fipa-os web site. http://www.fipa-os.sourceforge.net.
[3] V. De Antonellis, M. Melchiori, B. Pernici, and P. Plebani. A methodology for e-service substitutability
in a virtual district environment. In Conference on
Advanced Information System Engineering (CAISE
2003), Klagenfurt-Velden, Austria, June 16-20, 2003.
[4] R. Baldoni and C. Marchetti. Three-tier Replication
for FT-CORBA Infrastructures. Software: Practice &
Experience - Wiley InterScience, 8(33):767–797, July
2003.
[5] A. Banerji, C. Bartolini, D. Beringer, V. Chopella,
K. Govindarajan, A. Karp, H. Kuno, M. Lemon,
G. Pogossiants, S. Sharma, and S. Williams. Web Service Conversation Language (WSCL) 1.0. W3C Web
Site: http://www.w3.org/TR/wscl10, March
2002.
[6] L. Baresi, D. Bianchini, V. De Antonellis, M. G. Fugini, B. Pernici, and P. Plebani. Context-aware Composition of e-Service. In Technologies for E-Services :
Third International Workshop, TES 2003, Berlin, German, September 7-8, 2003.
[7] F. Bellifemine, A. Poggi, and G. Rimassa. Jade - a fipa
compliant agent framework. In Proc. of the practical
applications of intellingent agents and multi-agents
(PAAM99), pages 97–108, 1999.
[8] P. Brittenham, F. Cubera, D. Ehnebuske, and
S. Graham.
Understanding WSDL in a UDDI
Registry.
IBM Web Site:
http://www106.ibm.com/developerworks/
webservices/library/ws-wsdl/, 2001.
[9] C. Cappiello, C. Francalanci, B. Pernici, P. Plebani,
and M. Scannapieco. Data Quality Assurance in Cooperative Information Systems: a Multi-dimension
Quality Certificate. In International Workshop on
Data Quality in Cooperative Information Systems in
conjunction with ICDT 2003, Siena, Italy, January 1011, 2003.
[10] E. Christensen,
F. Curbera,
G. Meredith,
and S. Weerawarana.
Web Services Description Language (WSDL) 1.1.
http://www.w3.org/TR/2001/NOTEwsdl-20010315, March 2001.
[11] DAML
Service
Coalition.
DAML-S:
Semantic
Markup
For
Web
Services.
http://www.daml.org/services/damls/0.7/daml-s.html, October 2002.
[12] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller,
S. Thatte, and S. Weerawarana. Business Process
Execution Language for Web Services, version 1.0.
http://www.ibm.com/developerworks/
library/ws-bpel/, July 2002.
[13] A. Dan, H. Ludwig, and G. Pacifici. Web service differentiation with service level agreements. White Paper, IBM Corporation, March 2003.
[14] Object Management Group. Common object request
broker architecture (corba/iiop) v3.0.2, 2003.
[23] L.E. Moser, P.M. Melliar-Smith, P. Narasimhan, L.A.8
Tewksbury, and V. Kalogeraki. The Eternal System: an Architecture for Enterprise Applications. In
Proceedings of the 3rd International Enterprise Distributed Object Computing Conference (EDOC’99),
pages 214–222, Mannheim, Germany, July 1999.
[24] J. M. Myerson. Guarantee your Web Service with an
SLA. IBM Developer Works, April 2002. Available at:
http://www.ibm.com/developerworks/library/ws-sla.
[25] J. V. Nguyen. Estabishing an architectural model.
blueprint 816-4597-11, Sun Microsystems, 4150 Network Circle, Santa Clara (CA) 95045 USA, February
2003. http://www.sun.com/blueprints.
[15] Object Management Group. Common secure interoperability (csiv2), 2003.
[26] D. C. Schmidt, A. Gokhale, T. Harrison, D. Levine,
and C. Cleeland. Tao: A high performance endsystem
architecture for real-time corba. IEEE Communications Magazine, 14(2), 1997.
[16] L. Jin, V. Machiraju, and A. Sahai. Analysis on service level agreement of web services. Technical Report HPL-2002-180, HP Labs, June 2002.
[27] M. Wooldridge. Multiagent systems - A modern approach to artificial intelligence. MIT Press, 1999.
[17] D. Kakadia. Enterprise quality of service (qos) part ii:
Enterprise solution using solaris bandwidth manager
1.6. software. blueprint 816-4459-10, Sun Microsystems, 4150 Network Circle, Santa Clara (CA) 95045
USA, March 2002. http://www.sun.com/blueprints.
[28] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam,
and Q. Z. Sheng. Quality driven web services composition. In Proceedings of the twelfth international
conference on World Wide Web, pages 411–421. ACM
Press, 2003.
[18] D. Kakadia, T.G. Thomas, and S. Vembu J. Ramasamy.
Enterprise management systems part
i: Architectures and standards.
blueprint 8164525-10, Sun Microsystems, 4150 Network Circle, Santa Clara (CA) 95045 USA, April 2002.
http://www.sun.com/blueprints.
[29] J. A. Zinky, D. E. Bakken, and R. E. Schantz. Architectural support for quality of service for corba objects. Theory and Practice of Object Systems, 3(1),
1997.
[19] A. Keller and H. Ludwig. The WSLA Framework: Specifying and Monitoring Service Level
Agreements for Web Services. Technical Report
RC22456(W0205-171), IBM Research Division, T.J.
Watson Research Center, May 2002.
[20] H. Kreger, W. Harold, and L. Williamson. Java and
JMX: Building Manageable Systems. Addison Wesley
Professional, 2003.
[21] A. Mani and A. Magarajan.
Understanding
quality of service of your Web services.
IBM
Developer Works, January 2002.
Available at:
http://www.ibm.com/developerworks/library/wsquality.html.
[22] A. Maurino, B. Pernici, and F. A. Schreiber. Adaptive
channel behaviour in financial information system. In
UMICS Workshop in conjunction with CAISE 2003,
Klagenfurt-Velden, Austria, June 16-17, 2003.
Automatic Composition of e-Services that
Export their Behavior?
Daniela Berardi, Diego Calvanese, Giuseppe De Giacomo
Maurizio Lenzerini, and Massimo Mecella
Dipartimento di Informatica e Sistemistica
Università di Roma “La Sapienza”
Via Salaria 113, 00198 Roma, Italy
lastname @dis.uniroma1.it
Abstract. The main focus of this paper is on automatic e-Service composition. We start by developing a framework in which the exported
behavior of an e-Service is described in terms of its possible executions
(execution trees). Then we specialize the framework to the case in which
such exported behavior (i.e., the execution tree of the e-Service) is represented by a finite state machine. In this specific setting, we analyze the
complexity of synthesizing a composition, and develop sound and complete algorithms to check the existence of a composition and to return
one such a composition if one exists. To the best of our knowledge, our
work is the first attempt to provide an algorithm for the automatic synthesis of e-Service composition, that is both proved to be correct, and
has an associated computational complexity characterization.
1
Introduction
Service Oriented Computing (SOC [16]) aims at building agile networks of collaborating business applications, distributed within and across organizational
boundaries.1 e-Services, which are the basic building blocks of SOC, represent
a new model in the utilization of the network, in which self-contained, modular
applications can be described, published, located and dynamically invoked, in a
programming language independent way.
The commonly accepted and minimal framework for e-Services, referred
to as Service Oriented Architecture (SOA [17]), consists of the following basic roles: (i) the service provider, which is the subject (e.g., an organization)
providing services; (ii) the service directory, which is the subject providing a
repository/registry of service descriptions, where providers publish their services
and requestors find services; and, (iii) the service requestor, also referred to as
?
1
This work has been partially supported by MIUR through the “Fondo Strategico
2000” Project VISPO and the “FIRB 2001” Project MAIS. The work of Massimo
Mecella has been also partially supported by the European Commission under Contract No. IST-2001-35217, Project EU-PUBLI.com.
cf., Service Oriented Computing Net: http://www.eusoc.net/
client, which is the subject looking for and invoking the service in order to fulfill
some goals. A requestor discovers a suitable service in the directory, and then it
connects to the specific service provider and uses the service.
Research on e-Services spans over many interesting issues regarding, in particular, composability, synchronization, coordination, and verification [21]. In
this paper, we are particularly interested in automatic e-Service composition.
e-Service composition addresses the situation when a client request cannot be
satisfied by an available e-Service, but a composite e-Service, obtained by combining “parts of” available component e-Services, might be used. Each composite
e-Service can be regarded as a kind of client wrt its components, since it (indirectly) looks for and invokes them. e-Service composition leads to enhancements
of the SOA, by adding new elements and roles, such as brokers and integration
systems, which are able to satisfy client needs by combining available e-Services.
Composition involves two different issues. The first, sometimes called composition synthesis, or simply composition, is concerned with synthesizing a new
composite e-Service, thus producing a specification of how to coordinate the component e-Services to obtain the composite e-Service. Such a specification can be
obtained either automatically, i.e., using a tool that implements a composition
algorithm , or manually by a human. The second issue, often referred to as
orchestration, is concerned with coordinating the various component e-Services
according to some given specification, and also monitoring control and data flow
among the involved e-Services, in order to guarantee the correct execution of the
composite e-Service, synthesized in the previous phase.
Our main focus in this paper is on automatic composition synthesis. In order
to address this issue in an effective and well-founded way, our first contribution is
a general formal framework for representing e-Services. Note that several works
published in the literature address service oriented computing from different
points of views (see [11] for a survey), but an agreed comprehension of what an
e-Service is, in an abstract and general fashion, is still lacking. Our framework,
although simplified in several aspects, provides not only a clear definition of
e-Services, but also a formal setting for a precise characterization of automatic
composition of e-Services.
The second contribution of the paper is an effective technique for automatic
e-Service composition. In particular, we specialize the general framework to the
case where e-Services are specified by means of finite state machines, and we
present an algorithm that, given a specification of a target e-Service, i.e., specified
by a client, and a set of available e-Services, synthesizes a composite e-Service
that uses only the available e-Services and fully captures the target one. We also
study the computational complexity of our algorithm, and we show that it runs
in exponential time with respect to the size of the input state machines.
Although several papers have been already published that discuss either a
formal model of e-Services (even more expressive than ours, see e.g., [7]), or
propose algorithms for computing composition (e.g., [15]), to the best of our
knowledge, the work presented in this paper is the first one tackling simultaneously the following issues: (i) presenting a formal model where the problem
2
of e-Service composition is precisely characterized, (ii) providing techniques for
computing e-Service composition in the case of e-Services represented by finite
state machines, and (iii) providing a computational complexity characterization
of the algorithm for automatic composition.
The rest of this paper is organized as follows. In Section 2 and 3 we define our
general formal framework, and in Section 4 we define the problem of composition
synthesis in such a framework. In Section 5 we specialize the general framework
to the case where e-Services are specified by means of finite state machines, and
in Section 6 we present an EXPTIME algorithm for automatic e-Service composition in the specialized framework. Finally, in Section 7 we consider related
research work and in Section 8 we draw conclusions by discussing future work.
2
General Framework
Generally speaking, an e-Service is a software artifact (delivered over the Internet) that interacts with its clients in order to perform a specified task. A client
can be either a human user, or another e-Service. When executed, an e-Service
performs its task by directly executing certain actions, and interacting with other
e-Services to delegate to them the execution of other actions. In order to address
SOC from an abstract and conceptual point of view, several facets may be identified [5], each one reflecting a particular aspect of an e-Service during its life
time. Here, we focus on two of them, namely, (i) the e-Service schema, specifying
functional requirements2 , i.e., what an e-Service does; (ii) an e-Service instance,
that is an occurrence of an e-Service effectively running and interacting with a
client. In general, several running instances corresponding to the same e-Service
schema may exist, each one executing independently from the others.
In order to execute an e-Service, the client needs to activate an instance from
a deployed e-Service. In our abstract model, the client can then interact with
the e-Service instance by repeatedly choosing an action and waiting for either
the fulfillment of the specific task, or the return of some information. On the
basis of the information returned, the client chooses the next action to invoke. In
turn, the activated e-Service instance executes (the computation associated to)
the invoked action; after that, it is ready to execute new actions. Under certain
circumstances, i.e., when the client has reached his goal, he may explicitly end
(i.e., terminate) the e-Service instance. However, in principle, a given e-Service
instance may need to interact with a client for an unbounded, or even infinite,
number of steps, thus providing the client with a continuous service. In this case,
no operation for ending the e-Service instance is ever executed.
When a client invokes an e-Service instance e, it may happen that e does not
execute all of its actions on its own, but instead it delegates some or all of them
to other e-Service instances. All this is transparent to the client. To precisely
capture the situations when the execution of certain actions can be delegated to
2
An e-Service schema may also specify non-functional requirements, such as those
concerning quality or performance. However, non-functional requirements go beyond
the scope of this paper.
3
other e-Service instances, we introduce the notion of community of e-Services,
which is formally characterized by:
– a finite common set of actions Σ, called the action alphabet, or simply the
alphabet of the community,
– a set of e-Services specified in terms of the common set of actions.
Hence, to join a community, an e-Service needs to export its service(s) in terms
of the alphabet of the community. The added value of a community is the fact
that an e-Service of the community may delegate the execution of some or all
of its actions to other instances of e-Services in the community. We call such an
e-Service composite. If this is not the case, an e-Service is called simple. Simple
e-Services realize offered actions directly in the software artifacts implementing
them, whereas composite e-Services, when receiving requests from clients, can
invoke other e-Service instances in order to fulfill the client’s needs.
Notably, the community can be used to generate (virtual) e-Services whose
execution completely delegates actions to other members of the community. In
other words, the community can be used to realize a target e-Service requested by
the client, not simply by selecting a member of the community to which delegate
the target e-Service actions, but more generally by suitably “composing” parts
of e-Service instances in the community in order to obtain a virtual e-Service
which “is coherent” with the target one. This function of composing existing
e-Services on the basis of a target e-Service is known as e-Service composition,
and is the main subject of the research reported in this paper.
3
e-Service Schema
From the external point of view, i.e., that of a client, an e-Service E, belonging to
a community C, is seen as a black box that exhibits a certain exported behavior
represented as sequences of atomic actions of C with constraints on their invocation order. From the internal point of view, i.e., that of an application deploying
E and activating and running an instance of it, it is also of interest how the
actions that are part of the behavior of E are effectively executed. Specifically,
it is relevant to specify whether each action is executed by E itself or whether
its execution is delegated to another e-Service belonging to the community C
with which E interacts, transparently to the client of E. To capture these two
points of view we introduce the notion of e-Service schema, as constituted by
two different parts, called external schema and internal schema, respectively.
Also e-Service instances can be characterized by an external and an internal
view: further details can be found in [5].
3.1
External Schema
The aim of the external schema is to specify the exported behavior of the eService. For now we are not concerned with any particular specification formalism, rather we only assume that, whatever formalism is used, the external schema
4
specifies the behavior in terms of a tree of actions, called external execution tree.
The external execution tree abstractly represents all possible executions of all
possible instances of an e-Service. Therefore, any instance of an e-Service executes a path of such a tree. In this sense, each node x of an external execution
tree represents the history of the sequence of actions of all e-Service instances3 ,
that have executed the path to x. For every action a belonging to the alphabet
Σ of the community, and that can be executed at the point represented by x,
there is a (single) successor node x·a. The node x·a represents the fact that,
after performing the sequence of actions leading to x, the client chooses to execute action a, among those possible, thus getting to x·a. Therefore, each node
represents a choice point at which the client makes a decision on the next action
the e-Service should perform. We call the pair (x, x·a) edge of the tree and we
say that such an edge is labeled with action a. The root ε of the tree represents
the fact that the e-Service has not yet executed any action. Some nodes of the
execution tree are final : when a node is final, and only then, the client can stop
the execution of the e-Service. In other words, the execution of an e-Service can
correctly terminate only at these points4 .
Notably, an execution tree does not represent the information returned to the
client by the e-Service instance execution, since the purpose of such information
is to let the client choose the next action, and the rationale behind this choice
depends entirely on the client.
Given the external schema E ext of an e-Service E, we denote with T (E ext )
the external execution tree specified by E ext .
3.2
Internal Schema
The internal schema specifies, besides the external behavior of the e-Service,
the information on which e-Service instances in the community execute each
given action. As before, for now, we abstract from the specific formalism chosen
for giving such a specification, instead we concentrate on the notion of internal
execution tree. An internal execution tree is analogous to an external execution
tree, except that each edge is labeled by (a, I), where a is the executed action and
I is a nonempty set denoting the e-Service instances executing a. Every element
of I is a pair (E 0 , e0 ), where E 0 is an e-Service and e0 is the identifier of an
instance of E 0 . The identifier e0 uniquely identifies the instance of E 0 within the
internal execution tree. In general, in the internal execution tree of an e-Service
E, some actions may be executed also by the running instance of E itself. In this
case we use the special instance identifier this. Note that, since I is in general
not a singleton, the execution of each action can be delegated to more than one
other e-Service instance.
An internal execution tree induces an external execution tree: given an internal execution tree Tint we call offered external execution tree the external
3
4
In what follows, we omit the terms “schema” and “instance” when clear from the
context.
Typically, in an e-Service, the root is final, to model that the computation of the
e-Service may not be started at all by the client.
5
execution tree Text obtained from Tint by dropping the part of the labeling denoting the e-Service instances, and therefore keeping only the information on
the actions. An internal execution tree Tint conforms to an external execution
tree Text if Text is equal to the offered external execution tree of Tint .
Given an e-Service E, the internal schema E int of E is a specification that
uniquely represents an internal execution tree. We denote such an internal execution tree by T (E int ).
We now formally define when an e-Service of a community correctly delegates
actions to other e-Services of the community. We need a preliminary definition:
given the internal execution tree Tint of an e-Service E, and a path p in Tint
starting from the root, we call the projection of p on an instance e0 of an e-Service
E 0 the path obtained from p by removing each edge whose label (a, I) is such
that I does not contain e0 , and collapsing start and end node of each removed
edge.
We say that the internal execution tree Tint of an e-Service E is coherent
with a community C if:
– for each edge labeled with (a, I), the action a is in the alphabet of C, and
for each pair (E 0 , e0 ) in I, E 0 is a member of the community C;
– for each path p in Tint from the root of Tint to a node x, and for each pair
(E 0 , e0 ) appearing in p, with e0 different from this, the projection of p on e0
0
0
is a path in the external execution tree Text
of E 0 from the root of Text
to a
0
node y, and moreover, if x is final in Tint , then y is final in Text .
Observe that, if an e-Service of a community C is simple, i.e., it does not
delegate actions to other e-Service instances, then it is trivially coherent with
C. Otherwise, it is composite and hence delegates actions to other e-Service
instances. In the latter case, the behavior of each one of such e-Service instances
must be correct according to its external schema.
Example 1. Figure 1(a) shows (a portion of) an (infinite) external execution tree
representing an e-Service that allows for searching and listening to mp3 files5 .
In particular, the client may choose to search for a song by specifying either its
author(s) or its title (action search by author and search by title, respectively). Then the client selects and listens to a song (action listen). Finally,
the client chooses whether to perform those actions again.
Figure 1(b)6 shows (a portion of) an (infinite) internal execution tree,
conforming to the previous external execution tree, where all the actions
are delegated to e-Services of the community. In particular, the execution of
search by title action and its subsequent listen action are delegated to instance e2 of e-Service E2 , and search by author action and its subsequent
listen action to instance e1 of e-Service E1 .
¤
5
6
Final nodes are represented by two concentric circles.
In the figure, each action is delegated to exactly one instance of an e-Service schema.
Hence, for simplicity, we have denoted a label (a, {(Ei , ei )}) simply by (a, Ei , ei ), for
i = 1, 2.
6
a = search by author
t = search by title
l = listen
a
t
l
a
l
t
l
l
.
.
.
(a, E1 , e1 )
a
.
.
.
(t, E2 , e2 )
(l, E1 , e1 )
t
.
.
.
(a, E1 , e1 )
(t, E2 , e2 )
(a, E1 , e1 )
.
.
.
(l, E2 , e2 )
(l, E1 , e1 )
.
.
.
.
.
.
(a) External tree
(l, E2 , e2 )
(t, E2 , e2 )
.
.
.
.
.
.
(b) Internal tree
Fig. 1. e-Service execution trees
4
Composition Synthesis
When a user requests a certain service from an e-Service community, there may
be no e-Service in the community that can deliver it directly. However, it may
still be possible to synthesize a new composite e-Service, which suitably delegates action execution to the e-Services of the community, and when suitably
orchestrated, provides the user with the service he requested. Formally, given an
e-Service community C and the external schema E ext of a target e-Service E expressed in terms of the alphabet Σ of C, a composition of E wrt C is an internal
schema E int such that (i) T (E int ) conforms to T (E ext ), (ii) T (E int ) delegates
all actions to the e-Services of C (i.e., this does not appear in T (E int )), and
(iii) T (E int ) is coherent with C.
The problem of composition existence is the problem of checking whether
there exists some internal schema E int that is a composition of E wrt C. Observe
that, since for now we are not placing any restriction of the form of E int , this
corresponds to checking if there exists an internal execution tree Tint such that
(i) Tint conforms to T (E ext ), (ii) Tint delegates all actions to the e-Services of
C, and (iii) Tint is coherent with C.
The problem of composition synthesis is the problem of synthesizing an internal schema E int for E that is a composition of E wrt C.
An e-Service Integration System delivers possibly composite e-Services on
the basis of user requests, exploiting the available e-Services of a community C.
When a client requests a new e-Service E, he presents his request in the form of
an external e-Service schema E ext for E, and expects the e-Service Integration
System to execute an instance of E. To do so, first a composer module makes the
composite e-Service E available for execution, by synthesizing an internal schema
E int of E that is a composition of E wrt the community C. Then, following
7
the internal execution tree T (E int ) specified by E int , an orchestration engine
activates an (internal) instance of E, and orchestrates the different available eServices, by activating and interacting with their external view, so as to fulfill
the client’s needs.
The orchestration engine is also in charge of terminating the execution of
component e-Service instances, offering the correct set of actions to the client,
as defined by the external execution tree, and invoking the action chosen by the
client on the e-Service that offers it.
All this happens in a transparent manner for the client, who interacts only
with the e-Service Integration System and is not aware that a composite eService is being executed instead of a simple one.
5
e-Services as Finite State Machines
Till now, we have not referred to any specific form of e-Service schemas. In what
follows, we consider e-Services whose schema (both internal and external) can
be represented using only a finite number of states, i.e., using (deterministic)
Finite State Machines (FSMs).
The class of e-Services that can be captured by FSMs are of particular interest. This class allows us to address an interesting set of e-Services, that are
able to carry on rather complex interactions with their clients, performing useful
tasks. Indeed, several papers in the e-Service literature adopt FSMs as the basic
model of exported behavior of e-Services [7, 6]. Also, FSMs constitute the core
of statecharts, which are one of the main components of UML and are becoming
a widely used formalism for specifying the dynamic behavior of entities.
In the study we report here, we make the simplifying assumption that the
number of instances of an e-Service in the community that can be involved in
the internal execution tree of another e-Service is bounded and fixed a priori.
In fact, wlog we assume that it is equal to one. If more instances correspond
to the same external schema, we simply duplicate the external schema for each
instance. Since the number of e-Services in a community is finite, the overall
number of instances orchestrated by the orchestrator in executing an e-Service
is finite and bounded by the number of e-Services belonging to the community.
Within this setting, in the next section, we show how to solve the composition
problem, and how to synthesize a composition that is a FSM. Instead, how to
deal with an unbounded number of instances remains open for future work.
We consider here e-Services whose external schemas can be represented with a
finite number of states. Intuitively, this means that we can factorize the sequence
of actions executed at a certain point into a finite number of states, which are
sufficient to determine the future behavior of the e-Service. Formally, for an
e-Service E, the external schema of E is a FSM Aext
= (Σ, SE , s0E , δE , FE ),
E
where:
– Σ is the alphabet of the FSM, which is the alphabet of the community;
– SE is the set of states of the FSM, representing the finite set of states of the
e-Service E;
8
(l, 2)
a = search by author
a
t = search by title
l = listen
t
(t, 2)
(a, 1)
(l, 1)
l
(a) External FSM
(b) Internal MFSM
Fig. 2. e-Service specification as FSM
– s0E is the initial state of the FSM, representing the initial state of the eService;
– δE : SE × Σ → SE is the (partial) transition function of the FSM, which
is a partial function that given a state s and an action a returns the state
resulting from executing a in s;
– FE ⊆ SE is the set of final states of the FSM, representing the set of states
that are final for the e-Service E, i.e., the states where the interactions with
E can be terminated.
The FSM Aext
E is an external schema in the sense that it specifies an external
ext
ext
execution tree T (Aext
E ). Specifically, given AE we define T (AE ) inductively on
the level of nodes in the tree, by making use of an auxiliary function σ(·) that
associates to each node of the tree a state in the FSM. We proceed as follows:
0
– ε, as usual, is the root of T (Aext
E ) and σ(ε) = sE ;
ext
– if x is a node of T (AE ), and σ(x) = s, for some s ∈ SE , then for each a
0
such that s0 = δE (s, a) is defined, x · a is a node of T (Aext
E ) and σ(x · a) = s ;
– x is final iff σ(x) ∈ FE .
Figure 2(a) shows a FSM that is a specification for the external execution
tree of Figure 1(a). Note that in general there may be several FSMs that may
serve as such a specification.
Since we have assumed that each e-Service in the community can contribute
to the internal execution tree of another e-Service with at most one instance,
in specifying internal execution trees we do not need to distinguish between eServices and e-Service instances. Hence, when the community C is formed by
n e-Services E1 , . . . , En , it suffices to label the internal execution tree of an eService E by the action that caused the transition and a subset of [n] = {1, . . . , n}
that identifies which e-Services in the community have contributed in executing
the action. The empty set ∅ is used to (implicitly) denote this.
We are interested in internal schemas, for an e-Service E, that have a finite
number of states, i.e., that can be represented as a Mealy FSM (MFSM) Aint
E =
[n]
int 0 int int
int
int
(Σ, 2 , SE , sE , δE , ωE , FE ), where:
int 0
– Σ, SE
, sE
int
int
, δE
, FEint , have the same meaning as for Aext
E ;
9
– 2[n] is the output alphabet of the MFSM, which is used to denote which
e-Service instances execute each action;
int
int
– ωE
: SE
× Σ → 2[n] is the output function of the MFSM, that, given a
state s and an action a, returns the subset of e-Services that executes action
a when the e-Service E is in the state s; if such a set is empty then this
int
is implied; we assume that the output function ωE
is defined exactly when
int
δE is so.
The MFSM Aint
E is an internal schema in the sense that it specifies an internal
int
execution tree T (Aint
E ). Given AE we, again, define the internal execution tree
int
T (AE ) by induction on the level of the nodes, by making use of an auxiliary
function σ int (·) that associates each node of the tree with a state in the MFSM,
as follows:
int
int
– ε is, as usual, the root of T (Aint
(ε) = s0E ;
E ) and σ
int
int
int
– if x is a node of T (AE ), and σ (x) = s, for some s ∈ SE
, then for
0
int
each a such that s = δE (s, a) is defined, x · a is a node of T (Aint
E ) and
σ int (x · a) = s0 ;
int
int
– if x is a node of T (Aint
(x) = s, for some s ∈ SE
, then for each
E ), and σ
int
int
a such that ωE (s, a) is defined (i.e., δE (s, a) is defined), the edge (x, x · a)
int
of the tree is labeled by ωE
(s, a);
int
int
– x is final iff σ (x) ∈ FE .
As an example, Figure 2(b) shows a MFSM that is a specification of an
internal execution tree that conforms to the external execution tree specified by
the FSM of Figure 2(a). Indeed the MFSM in the figure compactly represents the
e-Service whose internal execution tree is shown in Figure 1(b). In general, an
external schema specified as FSM and its corresponding internal schema specified
as MFSM may have different structures, as the example shows.
Given an e-Service E whose external schema is an FSM and whose internal
schema is an MFSM, checking whether E is well formed, i.e., whether the internal execution tree conforms to the external execution tree, can be done using
standard finite state machine techniques. Similarly for coherency of E with a
community of e-Services whose external schemas are FSMs. In this paper, we
do not go into the details of these problems, and instead we concentrate on
composition.
6
Automatic e-Service Composition
We address the problem of actually checking the existence of a composite eService in the FSM-based framework introduced above. We show that if a composition exists then there is one where the internal schema is constituted by a
MFSM, and we show how to actually synthesize such a MFSM. The basic tool
we use to show such results is reducing the problem of composition existence
into satisfiability of a suitable formula of Deterministic Propositional Dynamic
10
Logic (DPDL), a well-known logic of programs developed to verify properties of
program schemas [12].
We start from a set P of atomic propositions and a set A of deterministic
atomic actions and we define DPDL formulas as follows:
φ −→ P | ¬φ | φ1 ∧ φ2 | hriφ | [r]φ
where P is an atomic proposition in P and r is a regular expression over the set of
actions in A. That is, DPDL formulas are composed from atomic propositions by
applying arbitrary propositional connectives, and modal operators hriφ and [r]φ.
The meaning of the latter two is, respectively, that there exists an execution of r
reaching a state where φ holds, and that all terminating executions of r reach a
state where φ holds. Let u be an abbreviation for (∪a∈A a)∗ . Then [u] represents
the master modality, which can be used to state universal assertions.
A DPDL interpretation is a (deterministic) Kripke structure of the form
I = (∆I , {aI }a∈A , {P I }P ∈P ), where aI ⊆ ∆I × ∆I is a partial function from
elements of ∆I to elements of ∆I , and P I ⊆ ∆I are all the elements of ∆I
where P is true. Such interpretation is then extended to formulas and complex
actions in a standard way, see [12] for details.
DPDL enjoys two properties that are of particular interest for our aims. The
first is the tree model property, which says that every model of a formula can be
unwound to a (possibly infinite) tree-shaped model (considering domain elements
as nodes and partial functions interpreting actions as edges). The second is the
small model property, which says that every satisfiable formula admits a finite
model whose size (in particular the number of domain elements) is at most
exponential in the size of the formula itself.
Given the target e-Service E0 whose external schema is a FSM A0 and a
community of e-Services formed by n component e-Services E1 , . . . , En whose
external schemas are FSMs A1 , . . . , An respectively, we build a DPDL formula
Φ as follows. As set of atomic propositions P in Φ we have (i) one proposition
sj for each state sj of Aj , j = 0, . . . , n, that is true if Aj is in state sj ; (ii)
propositions Fj , j = 0, . . . , n, denoting whether Aj is in a final state; and (iii)
propositions moved j , j = 1, . . . , n, denoting whether (component) automaton Aj
performed a transition. As set of atomic actions A in Φ we have the actions in Σ
(i.e, A = Σ). The formula Φ is built as a conjunction of the following formulas.
– The formulas representing A0 = (Σ, S0 , s00 , δ0 , F0 ):
• [u](s → ¬s0 ) for all pairs of states s ∈ S0 and s0 ∈ S0 , with s 6= s0 ; these
say that propositions representing different states are disjoint (cannot
be true simultaneously).
• [u](s → haitrue ∧ [a]s0 ) for each a such that s0 = δ0 (s, a); these encode
the transitions of A0 .
• [u](s → [a]false) for each a such that δ(s, a) is not defined; these say
when a transition
is not defined.
W
• [u](F0 ↔ s∈F0 s); this highlights final states of A0 .
– For each component FSM Ai = (Σ, Si , s0i , δi , Fi ), the following formulas:
11
• [u](s → ¬s0 ) for all pairs of states s ∈ Si and s0 ∈ Si , with s 6= s0 ; these
again say that propositions representing different states are disjoint.
• [u](s → [a](moved i ∧ s0 ∨ ¬moved i ∧ s)) for each a such that s0 = δi (s, a);
these encode the transitions of Ai , conditioned to the fact that the component Ai is actually required to make a transition a in the composition.
• [u](s → [a]¬moved i ) for each a such that δi (s, a) is not defined; these
say that when a transition is not defined, Ai cannot be asked to execute
in the composition.
W
• [u](Fi ↔ s∈Fi s); this highlights final states of Ai .
– Finally, the
V following formulas:
• s00 ∧ i=1,...,n s0i ; this says that initially all e-Services are in their initial
state; note that this
W formula is not prefixed by [u]·.
• [u](haitrue → [a] i=1,...,n moved i ), for each a ∈ Σ; these say that at
each step V
at least one of the component FSM has moved.
• [u](F0 → i=1,...,n Fi ); this says that when the target e-Service is in a
final state also all component e-Services must be in a final state.
Theorem 1. The DPDL formula Φ, constructed as above, is satisfiable if and
only if there exists a composition of E0 wrt E1 , . . . , En .
Proof (sketch). “⇐” Suppose that there exists some internal schema (without restriction on its form) E0 int which is a composition of E0 wrt E1 , . . . , En .
Let Tint = T (E0 int ) be the internal execution tree defined by E0 int .
Then for the target e-Service E0 and each component e-Service Ei , i =
1, . . . n, we can define mappings σ and σi from nodes in Tint to states of A0 and
Ai , respectively, by induction on the level of the nodes in Tint as follows.
– base case: σ(ε) = s00 and σi (ε) = s0i .
– inductive case: let σ(x) = s and σi (x) = si , and let the node x · a be in Tint
with the edge (x, x · a) labeled by (a, I), where I ⊆ [n] and I 6= ∅ (notice
that this may not occur since Tint is specified by a composition). Then we
define
σ(x · a) = s0 = δ0 (s, a)
and
(
σi (x · a) =
si 0 = δi (si , a)
si
if i ∈ I
if i ∈
6 I
Once we have σ and σi in place we can define a model I
(∆I , {aI }a∈Σ , {P I }P ∈P ) of Φ as follows:
=
– ∆I = {x | x ∈ Tint };
– aI = {(x, x · a) | x, x · a ∈ Tint }, for each a ∈ Σ;
– sI = {x ∈ Tint | σ(x) = s}, for all propositions s corresponding to states of
A0 ;
– sIi = {x ∈ Tint | σi (x) = si }, for all propositions si corresponding to states
of Ai ;
– moved Ii = {x · a | (x, x · a) is labeled by I with i ∈ I}, for i = 1, . . . , n;
12
– F0I = {x ∈ Tint | σ(x) = s with s ∈ F0 };
– FiI = {x ∈ Tint | σi (x) = si with si ∈ Fi }, for i = 1, . . . , n.
It is easy to check that, being Tint specified by a composition Eint , the above
model indeed satisfies Φ.
“⇒” Let Φ be satisfiable and I = (∆I , {aI }a∈Σ , {P I }P ∈P ) be a tree-like
model. From I we can build an internal execution tree Tint for E0 as follows.
– the nodes of the tree are the elements of ∆I ; actually, since I is tree-like we
can denote the elements in ∆I as nodes of a tree, using the same notation
that we used for internal/external execution tree;
– nodes x such that x ∈ F0I are the final nodes;
– if (x, x · a) ∈ aI and for all i ∈ I, x · a ∈ movedIi and for all j 6∈ I,
x · a 6∈ movedIj , then (x, x · a) is labeled by (a, I).
It is possible to show that: (i) Tint conforms to T (A0 ), (ii) Tint delegates all
actions to the e-Services of E1 , . . . , En , and (iii) Tint is coherent with E1 , . . . , En .
Since we are not placing any restriction on the kind of specification allowed for
internal schemas, it follows that there exists an internal schema Eint that is a
composition of E0 wrt E1 , . . . , En .
Observe that the size of Φ is polynomially related to the size of A0 ,
A1 , . . . , An . Hence, from the EXPTIME-completeness of satisfiability in DPDL
and from Theorem 1 we get the following complexity result.
Theorem 2. Checking the existence of an e-Service composition can be done in
EXPTIME.
Observe that, because of the small model property, from Φ one can always obtain a model which is at most exponential in the size of Φ. From
such a model one can extract an internal schema for E0 that is a composition of E0 wrt E1 , . . . , En , and has the form of a MFSM. Specifically,
given a finite model I = (∆I , {aI }a∈Σ , {P I }P ∈P ), we define such an MFSM
Ac = (Σ, 2[n] , Sc , s0c , δc , ωc , Fc , ) as follows:
S c = ∆I ;
V
s0c = d0 where d0 ∈ (s00 ∧ i=1,...,n s0i )I ;
s0 = δc (s, a) iff (s, s0 ) ∈ aI ;
I = ωc (s, a) iff (s, s0 ) ∈ aI and for all i ∈ I, s0 ∈ movedIi and for all j 6∈ I,
s0 6∈ movedIj ;
– Fc = F0I .
–
–
–
–
As a consequence of this, we get the following result.
Theorem 3. If there exists a composition of E0 wrt E1 , . . . , E0 , then there exists
one which is a MFSM of at most exponential size in the size of the external
schemas A0 , A1 , . . . , An of E0 , E1 , . . . , En respectively.
13
Proof (sketch). By Theorem 1, if A0 can be obtained by composing
A1 , . . . , An , then the DPDL formula Φ constructed as above is satisfiable. In
turn, if Φ is satisfiable, for the small-model property of DPDL there exists a
model I of size at most exponential in Φ, and hence in A0 and A1 , . . . , An . From
I we can construct a MFSM Ac as above. It is possible to show that the internal execution tree T (Ac ) defined by Ac satisfies all the conditions required
for Ac to be a composition, namely: (i) T (Ac ) conforms to T (A0 ), (ii) T (Ac )
delegates all actions to the e-Services of E1 , . . . , En , and (iii) T (Ac ) is coherent
with E1 , . . . , En .
In [4] a detailed example is provided, that explains the composition synthesis
algorithm step by step.
From a practical point of view, because of the correspondence between
Propositional Dynamic Logics (which DPDL belongs to) and Description Logics (DLs [8]), one can use current highly optimized DL-based systems [3]7 to
check the existence of e-Service compositions. Indeed, these systems are based
on tableaux techniques that construct a model when checking for satisfiability,
and from such a model one can construct a MFSM that is the composition.
7
Related Work
Up to now, research on e-Services has mainly concentrated on the issues of
(i) service description and modeling, and (ii) service composition, including
synthesis and orchestration.
Current research in description and modeling of e-Services is mainly founded
on the work on workflows, which model business processes as sequences of (possibly partially) automated activities, in terms of data and control flow among
them (e.g., [18, 19]). In [14] e-Services are represented as statecharts, and in [7],
an e-Service is modeled as a Mealy machine, with input and output messages,
and a queue is used to buffer messages that were received but not yet processed.
In our paper, we model e-Services as finite state machines, even if we do not
consider communication delays and therefore any concept of message queuing
is not taken into account. Indeed, from the survey of [11], it stems that the
most practical approaches for modeling and describing e-Services are the ones
based on specific forms of state machines. Additionally, our model of e-Service is
oriented towards representing the interactions between a client and an e-Service.
Therefore, our focus is on action sequences, rather than on message sequences
as in [7], or on actions with input/output parameters as in [15].
Orchestration requires that the composite e-Service is specified in a precise
way, considering both the specification of how various component e-Services are
linked and the internal process flow of the component one. In [11], different
technologies, standards and approaches for specification of composite e-Services
7
In fact, current DL-based systems cannot handle Kleene star. However, since in Φ,
∗ is only used to mimic universal assertions, and such systems have the ability of
handling universal assertions, they can indeed check satisfiability of Φ.
14
are considered, including BPEL4WS, BPML, AZTEC, etc. In [11] three different kinds of composition are identified: (i) peer-to-peer, in which the individual
e-Services are equals, (ii) the mediated approach, based on a hub-and-spoke
topology, in which one service is given the role of process mediator, and (iii) the
brokered approach, where process control is centralized but data can pass between component e-Services. With respect to such a classification, the approach
proposed in this paper belongs to the mediated one. Analogously, research works
reported in [9, 19, 13] can be classified into the mediated approach to composition. Conversely in [10] the enactment of a composite e-Service is carried out
in a decentralized way, through peer-to-peer interactions. In [7], a peer-to-peer
approach is considered, and the interplay between a composite e-Service and
component ones is analyzed, also in presence of unexpected behavior.
The DAML-S Coalition [2] is defining a specific ontology and a related language for e-Services, with the aim of composing them in automatic way. In [20]
the issue of service composition is addressed, in order to create composite services by re-using, specializing and extending existing ones; in [15] composition of
e-Services is addressed by using Golog and providing a semantics of the composition based on Petri Nets. In [1] a way of composing e-Services is presented,
based on planning under uncertainty and constraint satisfaction techniques, and
a request language, to be used for specifying client goals, is proposed. e-Service
composition is indeed a form of program synthesis as is planning. The main
conceptual difference is that, while in planning we are typically interested in
synthesizing a new sequence of actions (or more generally a program, i.e., an
execution tree) that achieves the client goal, in e-Service composition, we try to
obtain (the execution tree of) the target e-Service by reusing in a suitable way
fragments of the executions of the component e-Services.
8
Conclusions
The main contribution of this paper wrt research on service oriented computing
is in tackling simultaneously the following issues: (i) presenting a formal model
where the problem of e-Service composition is precisely characterized, (ii) providing techniques for computing e-Service composition in the case of e-Services
represented by finite state machines, and (iii) providing a computational complexity characterization of the algorithm for automatic composition.
In the future we plan to extend our work both in practical and theoretical
directions. On one side, we are developing a DL-based prototype system that
implements the composition technique presented in the paper. Such system will
enable us to test how the complexity of composition in our framework impacts
real world applications. On the theoretical side, we will address open issues such
as the characterization of a lower bound for the complexity of the composition
problem. Additionally, we plan to extend our setting, by taking into account the
possibility that the target e-Service is underspecified, as well as the presence of
communication delays and of an unbounded number of active instances.
15
References
1. M. Aiello, M.P. Papazoglou, J. Yang, M. Carman, M. Pistore, L. Serafini, and
P. Traverso. A Request Language for Web-Services Based on Planning and Constraint Satisfaction. In Proc. of VLDB-TES 2002.
2. A. Ankolekar, M. Burstein, J. Hobbs, O. Lassila, D. Martin, D. McDermott,
S. McIlraith, S. Narayanan, M. Paolucci, T. Payne, and K. Sycara. DAML-S:
Web Service Description for the Semantic Web. In Proc. of ISWC 2002.
3. F. Baader, D. Calvanese, D. McGuinness, D. Nardi, and P. Patel-Schneider. The
Description Logic Handbook: Theory, Implementation and Applications. CUP,
2003.
4. D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella. Automatic Composition of e-Services. Technical Report DIS 22-03 (http://www.dis.
uniroma1.it/~berardi/publications/techRep/TR-22-03.pdf).
5. D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella. A Foundational Vision of e-Services. In Proc. of WES 2003.
6. D. Berardi, F. De Rosa, L. De Santis, and M. Mecella. Finite State Automata as
Conceptual Model for e-Services. In Proc. of IDPT 2003, to appear.
7. T. Bultan, X. Fu, R. Hull, and J. Su. Conversation Specification: A New Approach
to Design and Analysis of E-Service Composition. In Proc. of WWW 2003.
8. D. Calvanese, G. De Giacomo, M. Lenzerini, and D. Nardi. Reasoning in Expressive
Description Logics. Handbook of Automated Reasoning, ESP, 2001.
9. F. Casati and M.C. Shan. Dynamic and Adaptive Composition of e-Services.
Information Systems, 6(3), 2001.
10. M.C. Fauvet, M. Dumas, B. Benatallah, and H.Y. Paik. Peer-to-Peer Traced Execution of Composite Services. In Proc. of VLDB-TES 2001.
11. R. Hull, M. Benedikt, V. Christophides, and J. Su. E-Services: A Look Behind the
Curtain. In Proc. of PODS 2003.
12. D. Kozen and J. Tiuryn. Logics of programs. Handbook of Theoretical Computer
Science — Formal Models and Semantics, ESP, 1990.
13. M. Mecella and B. Pernici. Building Flexible and Cooperative Applications Based
on e-Services. Technical Report DIS 21-2002 (http://www.dis.uniroma1.it/
~mecella/publications/mp_techreport_212002.pdf).
14. M. Mecella, B. Pernici, and P. Craca. Compatibility of e-Services in a Cooperative
Multi-Platform Environment. In Proc. of VLDB-TES 2001.
15. S. Narayanan and S. McIlraith. Simulation, Verification and Automated Composition of Web Services. In Proc. of WWW 2002.
16. M. Papazoglou. Agent-Oriented Technology in Support of e-Business. Communications of the ACM, 44(4):71–77, 2001.
17. T. Pilioura and A. Tsalgatidou. e-Services: Current Technologies and Open Issues.
In Proc. of VLDB-TES 2001.
18. H. Schuster, D. Georgakopoulos, A. Cichocki, and D. Baker. Modeling and Composing Service-based and Reference Process-based Multi-enterprise Processes. In
Proc. of CAiSE 2000.
19. G. Shegalov, M. Gillmann, and G. Weikum. XML-enabled Workflow Management
for e-Services across Heterogeneous Platforms. VLDB Journal, 10(1), 2001.
20. J. Yang and M.P. Papazoglou. Web Components: A Substrate for Web Service
Reuse and Composition. In Proc. of CAiSE 2002.
21. J. Yang, W.J. van den Heuvel, and M.P. Papazoglou. Tackling the Challenges of
Service Composition in e-Marketplaces. In Proc. of RIDE-2EC 2002.
16
Reflective architectures for adaptive information
systems
Andrea Maurino, Stefano Modafferi, and Barbara Pernici
Politecnico di Milano,
Dipartimento di Elettronica e Informazione,
Piazza Leonardo da Vinci, 20133 Milano, Italy
{maurino, modafferi, pernici}@elet.polimi.it
Abstract. Nowadays the anytime/anywhere/anyone paradigm is becoming very important and new applications are being developed in
many contexts. The possibility of using applications along a wide range
of devices, networks, and protocols raises new problems related to delivery of services. Current academic and industrial solutions try to adapt
services to the specific distribution channel, mainly by changing the presentation of the service. In this paper, we reverse this perspective by
using adaptive strategies to try to adapt the delivery channel to services
as well. We present a possible architecture and focus our attention on
the use of reflective components in the adaptive process. Using the reflection principle, we are able to evaluate the channel constraints and
the conditions in which the distribution channel is working at a specific
time. This information, built with service, user, and context constraints,
is used as input to adaptive strategies to change the current channel
characteristics, to new ones satisfying all the requirements. If this kind
of adaptation is not possible, we consider the different QoS levels offered
by the service and the user’s readiness to accept a downgraded service
provisioning.
Keywords: Adaptive information system, reflective architecture
1
Introduction
In the last years, the design and development of information systems have significantly changed due to new network architectures and devices, which increase
the number of distribution channels available for delivering of information or
services. In the anytime/anywhere/anyone paradigm [18], a novel generation of
applications [9] modify themselves according to the change of context, or to specific application constraints; for example, adaptive hypermedia applications [5, 1,
20] modify data presentation according to the specific client browser capability.
The goal of this paper is to present an architecture of a reflective adaptive system
and adaptation strategies at different levels. First, we consider the possibility of
modifying the distribution channel by means of adaptive information systems
based on reflective architectures. The principle of reflection [10] is mainly studied in the programming language community and it consists in the possibility of
2
Andrea Maurino et al.
system inspecting and adapting itself by using appropriate metadata. In [6, 12],
the use of reflective architectures has been proposed as a new design principle
of middleware, but the adaptivity is in charge of applications only; other papers
[16, 7] have considered the use of non-reflective adaptive channels, but they consider only the network as channel. Clearly adaptive distribution channels may
be also used with adaptive applications to create a novel generation of multichannel adaptive information systems. The middleware architecture we present
allows overcoming existing limitations of information systems by means of modification of controllable components of distribution channels, identified through
their description, and according to the specific context and level of Quality of
Service (QoS) requested by users. The distribution channel delivers e-Services
in order to satisfy a given QoS. If the user-specified quality level cannot be satisfied then our strategies try to adapt the distribution channel to a reduced QoS
level still acceptable for the user. If the downgrading of QoS levels is still not
sufficient, then other alternatives to provide the service are considered according
to the users and service constraints.
The paper is organized as follows: in Section 2, we present the requirements of
a reference example used to show, throughout the paper, how our architecture is
able to adapt the distribution channel to deliver e-Services; Section 3 shows the
distribution channel model representing metadata used by the reflective architecture. In Section 4, we present the general architecture and then we describe
adaptive strategies in Section 5. Section 6 explains the adaptations functions
used in our strategies. Finally, Section 7 discusses the state of art of adaptive
information systems.
2
Reference example
The reference example taken from the banking information system domain is
based on a service that “allow users, through Internet, to see in real time interviews with financial analysts”. This activity requires the delivery of real time
videos along Internet, with some mandatory minimum requirements: the user
device must be audio enabled and due to the real time nature of the service
the channel bandwidth is also relevant. The information system has to negotiate
with the user a reasonable minimum channel bandwidth that s/he accepts to see
the video in an acceptable mode from her/his point of view.
3
Distribution channel model
The distribution channel model adopted in this paper defines the metadata
needed for adaptation functionalities. Developing our first proposal in [13], we
specify this information at three different levels of abstraction. The conceptual
level specifies the general characteristics of service distribution; at logical level,
we characterize such general characteristics; at technological level, technical tuning parameters are specified.
Reflective architectures for adaptive information systems
3
At each level, characteristics may be either observable or controllable, or
both, yielding different levels of possible adaptation. In the following, we illustrate the three levels in detail.
3.1
Conceptual model
We consider a conceptual distribution channel as an access point to a specific set
of information or execution services. This level corresponds to channel definitions
as they are viewed from the commercial point of view. For instance, a service
can be provided via web, via a call center, or using short messages. In the
description of distribution channels at conceptual level, a service can be viewed
as a functionality with a set of constraints. If requirements for invoking the
service on each channel on which it is provided, and for providing the results
of the service itself, are given, the service is well described for the distribution
channel.
At this level a distribution channel is defined as:
– Set of services: each distribution channel supplies a specific set of services
– Technological features: each distribution channel has specific technological features characterizing the definition of channel.
Reference example. Within a banking information system, we consider the
Internet banking channel as the one requiring that customers interact with the
Bank information system by means of an Internet connection. Customers access
the Bank application (typically a web site) through a login/password mechanism. After the authentication phase, they may carry out services according to
their personal profile. The technological constraints in this case require that the
provider provides the service through a web server, a http connection, and a
video-player plugged in the browser on the client side.
3.2
Logical model
From the logical point of view, we characterize a distribution channel as composed of (see Fig.1):
–
–
–
–
The user device of application users,
The network interface through which the device is connected to the network,
The network used to transfer information,
The application protocols used by e-Services.
Each element composing the distribution channel is characterized by a number of attributes (e.g., device screen resolution or network topology). Each attribute is associated with a value, which can be numeric, as for example in the
case of the device weight, or a set of numbers, or a mathematical function, e.g.,
the graph function describing the network topology. The service delivery is affected by user requirements. To specify them, we introduce the concept of rating
4
Channel
1..N
*
Device
*
Network Interface
*
Network
*
Application Protocol
Fig. 1. UML specification of logical distribution channel components
class, which associates qualitative values (e.g., “fast” or “slow”) to attributes in
a given application domain. Rating classes are defined thanks to a measurement
scale applied on measurable attributes. The scale has to be at least ordinal,
but it can be also interval, ratio or absolute [15]. The rating classes are used
to describe QoS levels offered by a given e-Service. An example of QoS levels
is shown in Fig.2, where the quality dimension “speed” is associated with three
different quality level: “very high”, “high”, and “medium”. For each quality level
a minimum value is defined.
<QualityLevels ServiceID="S1">
<Dimension name="speed">
<LogicalAttribute name="Bandwidth">
</LogicalAttribute>
</Level>
</Dimension>
<Level name="high">
</LogicalAttribute>
</Level>
</Dimension>
<Level name="medium">
</LogicalAttribute>
</Level>
</Dimension>
...
</QualityLevels>
Fig. 2. Example of QoS levels
Reference example. According to the business requirements of the banking
information system, we define the domain specific relevant attributes for all the
four components previously defined.
5
Table 1. The 5 tuples of Internet banking channel used in the examples
The first element describing a distribution channel is the device on which
the end-user interacts. Within the financial application domain, we consider as
relevant attributes for this component: the screen resolution and the number
of colors, which are relevant when the information system wants to send users
graphical information. Other key attributes are the audio support describing the
presence or absence of audio cards inside the device and the input device used by
customers; this attribute is relevant in the definition of the best interaction methods. The second component is the network interface representing the connection
between devices and transmission media. It is worth noting that a device can
access different networks by means of different interfaces; for example, a PC can
access the Internet via LAN through a network card or via PSTN by means of
an analogical modem. In the financial context, we consider that the only relevant
attribute is the Transfer rate achievable by the specific interface.
The next component describing a distribution channel is the network. It
includes all physical structures, hardware components and protocols defining a
network infrastructure. In this component, we include all protocols covering the
first four levels of the ISO/OSI protocol stack. Within the bank information
system, we identify as relevant attributes for the network the transfer rate and
the security level that it offers.
We also consider as a distribution channel component the set of application
protocols allowing users to interact with the information system. We identify two
interesting attributes: the security support and the standardization of the application protocol, which is an important feature for reusing existing application
parts.
3.3
Technological model
From a technological point of view a distribution channel is defined by a tuple of
specific instances of device, network interface, networks and application protocols. If a value does not exist we assume that it is null. At technological level, it
6
is possible to define attributes as observable (e.g. device position), if a software
layer allows only showing their values to the information system; or controllable
(e.g. bandwidth or screen resolution), if it is also possible to modify them. It is
worth noting that a logical model can be instantiated with several tuples having
at least one common attribute value. For example the logical distribution channel Internet (described in Section 3.2) is composed of a set of tuples each one
characterized by the use of the HTTP as application protocol.
Reference example. An example of the technological model applied to Internet banking channel is shown in Table.1, where for each attribute and for each
tuple, we indicate if it is observable (O) or controllable (C ).
4
General architecture
Fig.3 shows the general architecture and its relationships with clients and services. Three are the layers composing our architecture; they are:
SERVICE
LOCAL
SERVICE
PROFILE
CLIENT
(1)
(3)
COMPOSITION
E-Service
description (2)
(4)
LOCAL
CLIENT
PROFILE
INVOCATION
(12)
Interaction enabling platform(5)
(7)
Rating
class
(7)
QoS
NEGOTIATOR
(7)
(6)
(8)
(8)
TRANSLATOR
(8)
(8)
(8)
TECHNOLOGICAL
MERGER
MERGING
RULES
LOGICAL
CHANNEL
MANAGER
TRANSLATOR
(8)
(8)
(11)
(8)
(9)
(8)
Reflective platform
CHANNEL
DESCR.
CONTEXT MANAGER
(GLOBAL PROFILE)
CHANNEL ADAPTER
(10)
HARMONIZE
REDUCE_
LEVEL
VALIDATE
ADAPT
CHANNEL
MONITOR
CHANNEL
MANAGER
SERVICE
CONTEXT
MGR.
USER
CONTEXT
MGR.
N-UPLES
Fig. 3. General architecture
– e-Service composition platform, which is in charge of receiving the client
request, selecting e-Service(s) satisfying it, and invoking the selected eService(s).
– Interaction enabling platform, which is the core of our architecture, because
it is in charge of collecting constraints from e-Services, clients and context,
7
determining the QoS for each e-Service according to the client profile and
selecting the best channel where the e-Service can be delivered.
– Reflective platform, which is in charge of adapting the selected distribution
channel according to the constraints obtained from the Interaction enabling
platform and monitoring if the distribution channel along which an e-Service
is delivering respects the QoS level chosen by user.
Our architecture interacts with the client, which can be a user or a software
agent, and with the e-Service. It is worth noting that the general architecture is
decentralized so it is possible that all components of each layer are distributed
over a number of hosts.
4.1
Constraints
In this paragraph we introduce the concept of technological constraints. They
are given by service and user, through local and global profiles, and by context,
and they are collected by Technological merger (see Fig.3), which sends them,
opportunely integrated, to the Reflective platform.
Let Tc be the set of Technological Constraints associated with a tuple.
Because there exist different QoS levels that user might accept, there will
exist a set of Tc for each tuple. We indicate with ∆T this set of Tc .
Each element Tcji is defined as
Tcji = hvmini , vmaxi , attribute, componenti
where:
– the index i represents the tuple and the index j the instance of ∆T we are
considering;
– vmin and vmax are the minimum and the maximum of a mathematic function
(i.e. the media or the peak or simply the identity function) calculated for
each distribution channel attribute value;
– attribute and component are respectively the attribute and the component
where the constraint is defined.
4.2
The first layer of our architecture is in charge of receiving the client requests,
defining the appropriate (set of) e-Service(s) satisfying them. The goal is obtained by analyzing the static description of the requested e-Services and the
functional and non-functional requirements of the client as described in [3]. The
e-Service composition platform selects the best e-Service, and requests the Interaction enabling platform to find the best distribution channel. When the
distribution channel is selected, the e-Service composition platform invokes the
execution of the e-Service.
8
Reference example Let us assume that a user requests the video streaming
service about an interview of financial analysts. He sends his request (through arc
(1) of Fig.3) to the Composition module, which queries the e-Service description
repository and gets the description of e-Service S1 only (arcs (2) and (3) of
Fig.3). The Composition module calls the Invocation module which passes to
the Logical channel manager, in the Interaction Enabling Platform, the request
of enabling the delivery of e-Service S1 (arc (5)).
4.3
Interaction enabling platform
The Interaction enabling platform collects all requirements from the client, the
e-Service and the distribution channel in order to manage service delivery on a
given distribution channel. The Logical channel manager module, according to
the description of the e-Service received from the Invocation module, selects a
technological distribution channel (that is, a given tuple). The QoS negotiator,
invoked by the Logical channel manager (arc (6)), requests the sub-set of the
local client profile involved in the definition of QoS levels related to the given
e-Service. This information can be stored directly in the user device or in other
hosts if the device has a very small amount of memory. The QoS levels acceptable
for the end users are chosen among the ones available for the e-Service stored in
the Rating class repository of Fig.3 (arc (7)). These different levels allow a flexible QoS managing policy, by modeling different satisfaction degrees for the client.
The Technological merger module receives inputs (arc (8) of Fig.3) from the QoS
negotiator, and non negotiable constraints from both client and service profiles.
We identify two kinds of constraints: logical and technological. The former are
related to logical features which do not refer to measurable attributes and they
have to be translated into constraints on technological attributes. An example
of logical attribute is the device graphical capability, which is the result of both
screen resolution and number of colors of a given device at technological level.
Technological constraints are related to technological attributes as described in
Section 4.1. Logical constraints, coming from both user and service profile, are
first translated into technological ones (by using appropriate Translator modules, which are different for both client and service). The Technological merger
integrates all constraints by using the Merging rules repository and passes down
to the Reflective platform the result of its elaboration and QoS levels expressed
as sets of technological constraints, requesting to satisfy them.
Reference example Continuing the example, the Logical channel manager
invokes the QoS negotiator by passing the description of e-Service S1. This
component finds in the Rating class repository the QoS levels shown in Fig.2.
In the example of Fig.2 the e-Service S1 is offered at several different QoS
levels about the channel speed (“Very high”, “high”, “medium”, etc.). The client
(through his local profile) selects his best and worst acceptable level by defining
a sorted sub set of QoS. They are then translated into technological constraints
before passing them to the Technological merger. The translation considers that
9
channel bandwidth depends on both the transfer rate of the Network interface
and the Network. The Technological merger receives also another technological
constraint specified by the e-Service S1 requiring that the client device must
have the audio card turned on to allow user to listen to the interview. This
requirement is mandatory in order to deliver the e-Service; consequently it has
not been included in the definition of the QoS level.
Let n3, described in Table 1, be the tuple chosen by the Logical channel
manager. Let be

 h0, 128kb/si for Transfer rate of Interface
h0, 10M b/si for Transfer rate of Network

hOf f, Oni for Audio of Device
the range of values in which the distribution channel we are considering can
work.
The Technological merger module generates the following constraints:

h150kb/s, ∗, T ransf er rate, Interf acei


level 0 h150kb/s, ∗, T ransf er rate, N etworki


hOn, On, Audio, Devicei

h128kb/s, ∗, T ransf er rate, Interf acei


 level 1 h128kb/s, ∗, T ransf er rate, N etworki
hOn, On, Audio, Devicei
where ∗ means that a maximum value is not given.
This output represents the two acceptable technological QoS levels for the
user. The chosen tuple and the set of technological QoS levels, that is the set of
technological constraints, are sent to the Reflective platform.
4.4
Reflective platform
The central element of the Reflective platform is constituted by metadata, that
is, the description of distribution channels built by using the model shown in Section 3 and stored in the Channel description repository. The availability of this
characterization allows the platform to evaluate if constraints can be satisfied.
The Channel monitor module is in charge of measuring the current values
of the attributes describing the selected distribution channel. Its information is
used by the Channel adapter module, which first evaluates if all constraints can
be satisfied for the tuple chosen by the upper layer from a hypothetical point
of view; that happens if the current working point of tuple satisfies constraints
or if it is possible to modify the distribution channel attributes values according to constraints. If there is the theoretical possibility of adaptation, then the
Channel manager module realizes the modification of the distribution channel
by invoking the appropriate software components. If one or more attributes cannot be modified, for example because the network manager does not accept the
request of additional bandwidth, the Reflective platform reduces QoS levels and
tries to modify the current tuple according to the new values. The reduction of
QoS levels is executed also if there are no acceptable hypothetical solutions. If
10
the Reflective platform does not satisfy the client request at least at the lower
level of the QoS assigned, then it advises the Logical channel manager module (arc 11 in Fig.3), which will select another tuple according to the e-Service
description. The Reflective platform has also the goal of monitoring and, if necessary, adapting tuples along which e-Services are delivering services. Finally
the Service context manager and the User context manager modules measure
the behavior of e-Services and users to build their global profiles (realized by
the Context manager module).
5
Adaptive strategies
We consider that the adaptation of distribution channels to services means to
find and, in case, modify, if it exits, a tuple satisfying all constraints.
Let a working point (W p) be the set of all attribute values carried out by
Channel Monitor in a given instant for the given tuple.
Wp=Get_current_n-uple_values
Consider another n-uple
(Logical adaptivity)
Service
Channel
YES
Supply service
is possible
NO
Dev
1
Net
Int
1
Net
1
App
Prot
1
Dev
1
Net
Int
2
Net
1
App
Prot
1
Dev
2
Net
Int
2
Net
1
App
Prot
1
Dev
3
Net
Int
3
Net
2
App
Prot
1
Dev
4
Net
Int
3
Net
2
App
Prot
1
Fig. 4. Channel adaptivity
YES
Logical
Adaptivity
Technological
Adaptivity
Validate(Wp)
Exist
another
n-uple
NO
Service cannot
be supplied
YES
Wp* = Adapt(Wp)
Validate(Wp*)
NO
YES
Move Wp
to Wp*
NO
Exist another
level in
NO
YES
Reduce_Level()
Fig. 5. Adaptive flow-chart
Fig.4 shows the two strategies of adaptivity we consider; logical and technological, which are developed in sequence, in particular:
– The “Technological Adaptivity” represents the tuning phase on the single
tuple, i.e. the attempt to change some attributes of the given tuple to satisfy
constraints, and it is realized by the Reflective platform
– The “Logical Adaptivity” represents the possibility of using a different tuple
of the same logical distribution channel, it is realized by the Interactive
enabling platform.
Fig.5 shows the flow-chart of adaptive strategies mainly realized by the Channel
adapter module, while the concrete movement of working point is realized by the
11
Channel manager and the selection of alternative tuples is in charge of the Interaction enabling platform. Hereafter we consider the “Technological Adaptivity”
only.
The V alidate() function evaluates if the current tuple working point satisfies
the conditions required by constraints. In this case the service is supplied along
the current tuple, otherwise the Adapt() function (see Section 6.2) proposes
an acceptable working point available for such tuple (W p∗ ). The new point is,
then, evaluated again by the V alidate() function. If it satisfies constraints then
the Channel manager module tries to change the current working point of the
selected tuple. If it is impossible to move the current tuple working point, due to
technical limitations or because W p∗ does not satisfy the constraints, then the
Channel adapter, by means of the Reduce level() function, tries to progressively
reduce QoS levels, according to the service and user requests, looking for an
existing QoS level satisfying them. After each invocation of the Reduce level()
function, the Adapt() function is invoked.
If technological adaptation fails, the information system, within the Interaction enabling platform, selects another tuple, QoS levels and constraints, and
the technological adaptive strategy starts again.
This iterative process ends when a tuple satisfying all constraints is found or
when no tuple can deliver the service. In this case the Logical channel manager
tries to use multichannel delivery strategies selecting an alternative delivery
channel, if possible, for the given e-Service.
6
Adaptive functions
As shown before, adaptive strategies are executed in two phases: theoretical and
practical. For the theoretical study the Channel adapter module has to know
the channel structure. It obtains this information from the Channel description
repository. It is worth noting that the designer has to write some functions
defining the relationship between two or more technological constraints of a
specific tuple to express them in a compatible way. These functions are named
Harmonize Functions as shown in Fig.3.
Following the direction of most recent literature [2], to adapt means looking
for an admissible solution minimizing the distance between service directive and
channel availability to maximizing the QoS. It is clear that this concept of QoS
is dynamic [17, 14, 19], because channel conditions vary both in time and space.
The Adapt() function realizes such algorithm, while the V alidate() function detects if the working point, current or proposed by the Adapt() function,
satisfies the constraints. In the next sections we explain more in depth these
functions.
6.1
Validate function
The V alidate() function evaluates if current attribute values, that is, the current
working point, (W p), satisfy all constraints. Formally
12
V alidate() : {A} → {[0, 1] ∈ N }
where A = hAo ∪ Ac i is the set of attributes composed by the union of
observable (Ao ) and controllable attributes (Ac ) of a given tuple. The result of
V alidate function is 1 if W p satisfies all constraints, it is 0 otherwise.
Let CA the hypercube formed by the union of theoretical available working points included between all vmin and all vmax carried out from Interaction
enabling platform and let CC the hypercube formed by all theoretical working
points of a given tuple; it results that acceptable solutions are those included in
the intersection of CA and CC .
Each edge hypercube CCi (resp. CAi ) of CC (resp. CA ) associated with the
generic attribute (i) is defined as follows:

if constraints are like hvimin , ∗, i, componenti
[vi ; ∞[


 min
[vimin ; vimax ] if constraints are like hvimin , vimax , i, componenti
if constraints are like h∗, vimax , i, componenti
[0; vimax ]



[0; ∞]
if there are no associated constraints
It is worth noting that an attribute domain can be discrete rather than continuous and all W p are included in CC .
The V alidate() function is defined as follows:
1 if W p ∈ (CC ∩ CA )
V alidate(W p) |CA ,CC =
0 otherwise
A hypercube can have an infinite extension along variables associated with constraints where vimax is not defined. Moreover if an attribute allows only a value,
the hypercube loses one dimension.
According to the flow-chart of Fig.5 the V alidate() function is also invoked
each time a new W p is proposed by the Adapt() function as shown in next
Section.
6.2
Adapt function
The Adapt() function is used to move the current channel working point to CA
hypercube, that is, to a new one respecting the constraints requested from eService and user. Thus it receives as input a working point (W p) and return as
output another working point (W p∗ ).
Notice that Adapt() function does not change the working point, it only
detects if there exists a hypothetical point in the solution space where all constraints are satisfied. The result of function is:
W p∗ = Adapt(W p) |(CA ,CC ) = argmin(k W p; CA k)
The Adapt() function looks for a point in CC having the minimum distance from
CA .
Fig.6 shows a graphical representation of the Adapt() function by considering
only two continuous attributes. There exists an overlapping area between the two
Fig. 6.
Adapt() function behavior when
there exists a no-empty intersection
13
Fig. 7.
Adapt() function behavior when
there exists an empty intersection
areas CA and CC ; consequently the Adapt() function will define a W p∗ as shown.
Conversely, Fig.7 shows the case in which there exists an empty intersection
between the two constraint sets. In this case the Adapt() function returns a
new W p∗ point, that is the best working point available for the current tuple,
however, using V alidate() functions the Channel adapter module will notice
that W p∗ does not satisfy constraints and thus it will try to relax one or more
constraints (that is to widen CA ) by using the Reduce Level() function described
in Section 6.3.
Reference example Considering that the current tuples is n3, let CA be:
CA =
(
h150kb/s, ∞i for Network
h150kb/s, ∞i for Interface Network
hOn, Oni
for Audio
where values are related to the best QoS level chosen by user.
Let CC be the following:
(
CCn3 =
h0kb/s, 128kb/si for Network
h0kb/s, 128kb/si for Interface Network
hOf f, Oni
for Audio
Let we suppose that the current working point is:
(
Wp =
64 kb/s for Network
64 kb/s for Interface Network
On
for Audio
14
Calculating the V alidate() function on these values we obtain
V alidate(W p) |CA ,CC = 0
Then the Channel adapter module tries to adapt distribution channel by calculating the Adapt() function:
(
W p∗ = Adapt(W p) =
128 kb/s for Network
On
for Audio
but the output of V alidate() is still the same
V alidate(W p∗ ) |CA ,CC = 0
6.3
Reduce level function
Let ∆T be the ordered set of QoS levels acceptable for a given tuple by service
and user, generated by the Interaction enabling platform. Each QoS level is
composed by a set of constraints Tc (Section 4.1), that is different levels may
have different Tc . The Reduce level() function tries to downgrade the CA of
one level. This operation is strongly related to the tuple the Channel adapter
module is considering; so the function tries to relax attribute constraints that
are still not respected looking for closest downgrading level allowed for the tuple.
Formally:
Reduce level() : {CA } → {CA }
In particular
new
CA
= Reduce level(CA ) |∆T
It is hopefully that this new CA is formed by satisfable constraints for the
channel characteristic. The reduction process is progressive and it ends if no
other level is available or if an acceptable one exists.
Reference example By continuing the reference example the Channel adapter
module controls if it is possible to provide a downgraded service. For this goal
it uses the Reduce level() function.
(
new
CA
= Reduce level(CA ) |∆T =
Consequently, by remembering that
(
W p∗ =
h128Kb/s, ∞i
h128Kb/s, ∞i
hOn, Oni
128 kb/s for Network
On
for Audio
we obtain
because
15
V alidate(W p∗ ) |CA ,CC = 1
(CC ∩ CA 6= ø) ∧ (W p∗ ∈ CC ∩ CA )
That is, the current working point is now acceptable and it is the same of
the lower bound asked after relaxation. We suppose that all the modification of
attribute values are executed without failures; the e-Service provisioning can now
start (arc (12) in Fig.3) and it will be monitored by Channel monitor module in
order to respect the requested constraints during all the provisioning period.
7
Related work
The field of adaptive information systems is new and relatively unexplored. The
use of reflective architecture for mobile middleware is discussed in [12, 4]; other
work [6] use the reflection principle to support the dynamic adaptation of applications. However, none of these papers mention the possibility to assign the task
of adaptation to the distribution channel instead of application; in our opinion,
our approach simplifies the design and implementation of e-Services because
they do not have to realize adaptive behaviors.
The concept of dynamic service provisioning and dynamic QoS [19, 14] involves
both channel and application issues; moreover the new wireless networks and
devices increase the complexity of solutions. Different approaches are being developed; in [7, 16] the possibility of adapting the network by maximizing the
network efficiency looking at its intrinsic parameters is investigated. In the same
direction other systems [2] try to consider features regarding users, but their
channel idea is simply the network and their adaptation process consider a simple user-profile containing information about user preferences and past behavior.
Other approaches [1, 20] try to adapt applications to the distribution channel;
they consider the channel as an only-observable system and try to adapt the
application to it; some systems put their attention above all on the presentation
of the information delivering on a channel; important examples of this approach
are defined in the field of adaptive hypermedia [8, 5].
The enriched definition of distribution channel [13] distinguishes our approach from others, because we consider a distribution channel as a tuple of
four different components and the network is only one of them, thus our approach is at a higher level of abstraction. Moreover our strategies try to adapt
the distribution channel before trying adaptive application strategy to supply at
least a downgraded service.
8
Conclusion
In this paper we presented adaptive information systems to deliver e-Services
by means of reflective architectures. The use of reflection principle, obtained by
using a high level description of distribution channels, allow us to define adaptive strategies to modify the distribution channel itself (viewed as a tuple of
16
four different components) to e-Services. Two levels of adaptability are considered: logical and technological. The former, realized in the Interaction enabling
platform, selects the tuple where the e-Service has to be delivered. The latter
strategy tries to modify the controllable attributes of current tuple to satisfy
constraints. If it is impossible to adapt the selected tuple, then the Interaction
enabling platform selects an alternative tuple. This is the first proposal to design a new generation of multichannel adaptive information systems. We are now
studying more efficient logical adaptive strategies in the selection of the tuple
where to deliver the service, and how to assign each architectural components
in a distributed information system; we are also evaluating how a service can
select another logical distribution channel. Another problem we are studying is
channel monitoring in mobile systems and adaptive networks.
Acknowledgments. This work has been developed within the Italian MURSTFIRB Project MAIS (Multi-channel Adaptive Information Systems) [11].
References
1. G. Ammendola, A. Andreadis, and G. Giambene, A software architecture for the
provision of mobile information services, Softcom, International Conference on
Software, Telecommunications and Computer Networks (Dubrovnik (Croatia) and
Ancona, Venice (Italy)), October 2002.
2. G. Araniti, P. De Meo, A. Iera, and D. Ursino, Adaptively control the QoS of
multimedia wireless applications through “user profiling” techniques, IEEE Journal
On Selected Areas in Communications (JSAC) (2003), Forthcoming.
3. L. Baresi, D. Bianchini, V. De Antonellis, M.G. Fugini, B. Pernici, and P. Plebani, Context-aware composition of e-services, In Proc. of VLDB Workshop on
Technologies for E-Services (TES’03) (Berlin, Germany), 2003.
4. G. Blair, A. Andersen, L. Blair, G. Coulson, and D. Gancedo, Supporting dynamic
QoS management functions in a reflective middleware platform, IEEE Proceedings
– Software, 2000.
5. P. Brusilovky, Adaptive hypermedia, User Modeling and User Adapted Interaction
11 (2001), no. 1-2, 87–100.
6. L. Capra, W. Emmerich, and C. Mascolo, Reflective middleware solutions for
context-aware applications, Lecture Notes in Computer Science 2192 (2001).
7. A. Hac and A. Armstrong, Resource allocation scheme for QoS provisioning in microcellular networks carrying multimedia traffic, International Journal of Network
Management 11 (2001), no. 5, 277–307.
8. A. Kobsa, J. Koenemann, and W. Pohl, Personalized hypermedia presentation techniques for improving online customer relationships, The Knowledge Engineering
Review 16 (2001), no. 2, 111–155.
9. J. Krogstie, Requirement engineering for mobile information systems, Proc. of
International Workshop on Requirements Engineering: Foundation for Software
Quality (Interlaken, Switzerland), 2001.
10. P. Maes, Concepts and experiments in computational reflection, In Proc. of ObjectOriented Programming Systems, Languages, and Applications (OOPSLA) (Orlando, Florida, USA), vol. 7, ACM Press, 1987, pp. 147–155.
17
11. MAIS Consortium, MAIS: Multichannel Adaptive Information Systems,
http://black.elet.polimi.it/mais/.
12. V. Marangozova and F. Boyer, Using reflective features to support mobile users, In
Walter Cazzola, Shigeru Chiba, and Thomas Ledoux, editors, On-Line Proceedings
of ECOOP’2000 Workshop on Reflection and Metalevel Architectures, June, 2000.
13. A. Maurino, B. Pernici, and F.A. Schreiber, Adaptive behaviour in financial information system, Workshop on Ubiquitous Mobile Information and Collaboration
Systems (Klagenfurt/Velden, Austria), June, 2003.
14. K. Nahrstedt, D. Xu, D. Wichadakul, and B. Li, QoS-aware middleware for ubiquitous and heterogeneous environments, IEEE Communications Magazine 39 (2001),
no. (11), 140–148.
15. N.Fenton, Software metrics, a rigorous approach, Chapmann & Hall, 1991.
16. R. Raymond, F. Liao, and A. T. Campbell, A utility-based approach for quantitative
adaptation in wireless packet networks, Wireless Networks 7 (2001), no. 5, 541–557.
17. D. Reiniger, R. Izmalov, B. Rajagopalan, M. Ott, and D. Raychaudhuri, Soft Qos
control in the watmnet broadband wireless system, IEEE Personal Communications
Magazine Feb (1999), 34–43.
18. K. Siau, E.P. Lim, and Z. Shen, Mobile commerce: Promises, challenges, and research agenda, Journal of Database Management 12 (2001).
19. R. Steinmetz and L. Wolf, Quality of service: Where are we?, Proc. of IFIP International Workshop on Quality of Service (IWQOS’97) (New York City, New York,
USA), IEEE Press, 1997, pp. 211–222.
20. V. Zariskas, G. Papatzanis, and C. Stephanidis, An architecture for a self-adapting
information system for tourists, Proc. of the Workshop on Multiple User Interfaces
over the Internet: Engineering and Applications Trends (in conjunction with HCIIHM’2001) (Lille, France), 2001.

Definizione del modello di rappresentazione degli e

Transcript

Documenti analoghi

CHANNEL ONE RUSSIA

Modulo FAST CLAIM - Deutsche Bank Easy

Channel Bonding per il Cluster Arcosu

5DSC_INGLESE_PELOSIN

versione pdf

Thesis full text PDF - Politecnico di Milano

lista completa della serie di fragranze edition-line per l

Guida alla configurazione Outlook POP

Programma ING Corporate Card Transazione contestata

JharonSX - SourceForge