Gli e-service come tecnologie di supporto automatico per le diverse

classi di transazioni

Chiara Francalanci

27 maggio 2004

2

Sommario

Innovatività applicativa degli e-service Potenzialità degli e-service come tecnologie di

supporto automatico per le diverse classi di transazioni

Alcune considerazioni di fattibilità

3

E-service e transazioni: binomio scontato?

Manca supporto flessibile all’esecuzione delle transazioni Gli e-service permettono (dalle prime 10 ore di corso):

Il wrapping del SI aziendale L’esportazione e la condivisione di servizi fra soggetti diversi, in relazioni molti a molti, purché definiscano un’ontologia comune La definizione di contratti che definiscono le regole per lo scambio dei servizi In sintesi, modellano naturalmente il rapporto cliente-fornitore

4

Sintesi dei problemi aperti complessità del prodotto il cliente non dispone di informazioni integrate multi-fornitore per pianificazione e controllo specificità del prodotto (necessità di personalizzazione) manca supporto a negoziazione cooperativa incertezza ambientale (asimmetria informativa) manca supporto a controllo cooperativo in fase di esecuzione, workflow evoluto/cooperativo elevato potere contrattuale cliente/fornitore il fornitore non dispone di informazioni integrate multi-cliente per pianificazione e controllo elevata frequenza della transazione manca supporto a integrazione di SI per pianificazione e controllo condivisi

5

Sintesi dei problemi aperti

Dunque manca supporto a:

negoziazione cooperativa (v. prossima lezione) pianificazione cooperativa (EbXML) controllo di processo cooperativo (WSLA)

6

WSLA

Attraverso WSLA si definiscono i contratti stipulati tra consumatore e fornitore in termini di obblighi e corrispondenti provvedimenti in caso di fallimento

Le obbligazioni si basano su parametri di servizio denomina SLA e possono riguardare tempi di risposta, disponibilità, capacità produttiva (throughput),…

I SLA sono definiti sulla base di metriche base e/o composte (aggregazione di metriche base)

E’ possibile il coinvolgimento di terze parti addette al controllo delle obbligazioni, alla misurazione delle metriche relative alle garanzie, al rispetto delle garanzie violate

7

Caratteristiche di WSLA

Ideato per definire in maniera formale un contratto in modo da permettere di gestire in maniera automatica il servizio (parti in causa, interazioni,…) e il controllo di qualità concordato

Un documento WSLA comprende La descrizione delle “parti”, dei loro ruoli, delle interfacce delle azioni

possibili a fronte di anomalie La descrizione dettagliata dei parametri di servizio, delle metriche e

delle parti che hanno il compito di valutare la metrica La presentazione delle obbligazioni delle parti, “Service Level

Objective”, e la possibilità di eseguire certe attività nel caso in cui si verifichino anomalie, “Action Guarantee”.

8

WSLA: infrastruttura (1)

La definizione di un contratto WSLA è complementare alla definizione del servizio

WSDL identifica l’interfaccia del servizio, WSLA le caratteristiche di prestazione concordate

9

WSLA: infrastruttura (2)

Sia il fornitore che il cliente possono essere dotati di una propria infrastruttura di misurazione, gestione e di una propria strumentazione

Entrambi le parti hanno la possibilità di reperire le metriche da fonti differenti

10

WSLA: gestione run-time

Misurazione: identifica le metriche semplici e le computa in metriche di alto livello (es. tempo medio di risposta di un’insieme di server dato un certo intervallo)

Valutazione delle condizioni: valuta le condizioni sulla base della definizione nel documento WSLA. Le condizioni sono dei semplici predicati sui parametri SLA

Gestione: attua le azioni che vengono invocate in caso di violazione delle garanzie

L’interazione tra i servizi può avvenire a diversi livelli

11

WSLA: stipula di un contratto (1)

Nel contratto sono coinvolti fornitore e consumatore, “Signatory Parties” e terze parti, “Supporting parties”.

Le terze parti sono finanziate da uno o entrambi gli attori primari Le terze parti possono fornire una combinazione di servizi tra la

misurazione, la valutazione e la gestione

Nell’esempio sono coinvolte due terze parti, la prima fornisce un servizio di misurazione sia al fornitore che al consumatore mentre la seconda opera solo a vantaggio del consumatore

12

WSLA: stipula di un contratto (2)

13

WSLA: stipula di un contratto (3)

Le informazioni relative alle terze parti (es. azioni e ruolo) vengono specificate dai finanziatori

Le terze parti non partecipano alla creazione del contratto WSLA e non ne hanno completa visibilità

Durante il “deployment” le informazioni necessarie vengono inviate dai finanziatori alle terze parti

Ci sono diversi scenari che permettono di arrivare alla definizione di un contratto WSLA (supplier-driven, customer-driven…)

14

WSLA: deployment (1)

Un WSLA può essere utilizzato sia dal fornitore che dal consumatore per configurare i loro sistemi (DEPLOYMENT)

Con deployment si intende quindi la creazione e la parametrizzazione di sistemi che attuano il servizio e supervisionano il WSLA

Ogni Signatory Party è responsabile per il deployment delle sue funzionalità e delle terze parti che finanzia

15

WSLA: deployment (2)

16

ebXML

Consorzio OASIS e UN/CEFACT Nato per supportare in maniera specifica la

definizione di processi intra e inter-organizzativi Fornisce un’infrastruttura dove gli investimenti

EDI possono essere preservati avendo i vantaggi di un’architettura XML-based

17

ebXML: contesto di applicazione

Una comunità di imprese descrive secondo standard precisi un processo, ossia un gruppo di attività coordinate orientato al raggiungimento di un obiettivo. La descrizione del processo è memorizzata in un Registry.

Un’impresa A, esaminando il Registry, può decidere di partecipare al processo realizzando una o più attività. Tale intenzione viene notificata inserendo nel Registry una serie di informazioni.

Un’impresa B, se interessata a partecipare al processo segue la stessa procedura di A. Dal Registry viene a sapere che l’attività che intende realizzare prevede la cooperazione con l’attività realizzata da A.

Per ottenere tale coordinamento le due aziende stilano un documento comune che specifica come e quando devono avvenire le interazioni, quali sono i messaggi scambiati, etc…

In fase di esecuzione, le due aziende cooperano tra loro grazie ad all’accordo definito in precedenza.

18

ebXML: schema di riferimento Design:Design: definizione del definizione del

processo e processo e inquadramento dei vari inquadramento dei vari sistemi cooperanti sistemi cooperanti all’interno del processo all’interno del processo stessostesso

Negotiation:Negotiation: comprende comprende la definizione dell’accordo la definizione dell’accordo tra due imprese che tra due imprese che decidono di cooperaredecidono di cooperare

Execution:Execution: esecuzione esecuzione vera e propria del vera e propria del processoprocesso

19

SOA vs ebXML

EbXML La specifica del processo di

business viene fatta a priori (dati, tempi, modalità di interazione, requisiti imposti dalle parti,…)

Esistenza di una fase di negoziazione in cui le aziende devono accordarsi riguardo alla suddivisione dei compiti

SOA La SOA fornisce la sola

infrastruttura di pubblicazione, reperimento ed invocazione del servizio

I linguaggi mettono a disposizione tutta l’informazione sulla cooperazione

Le caratteristiche del processo cooperativo possono essere modificate durante l’esecuzione

In entrambi i casi ogni organizzazione coinvolta viene In entrambi i casi ogni organizzazione coinvolta viene rappresentata come una black box di cui sono visibili rappresentata come una black box di cui sono visibili solo i processi pubblicisolo i processi pubblici

20

ebXML: architettura

BSI (Business Service BSI (Business Service Interface): Interface): interpreta interpreta documenti ebXMLdocumenti ebXML

CPP (Collaborative Partner CPP (Collaborative Partner Profile) :Profile) : specifica del ruolo, specifica del ruolo, caratteristiche minime di caratteristiche minime di comunicazione, QoScomunicazione, QoS

CPA (Collaborative Partner CPA (Collaborative Partner Agreement):Agreement): contiene contiene l’accordo che le parti l’accordo che le parti sottoscrivono prima di sottoscrivono prima di iniziare la collaborazioneiniziare la collaborazione

ebXML registry/repository:ebXML registry/repository: compatibile con UDDI, compatibile con UDDI, contiene tutte le contiene tutte le informazioni necessarie per informazioni necessarie per la costruzione dell’ambiente la costruzione dell’ambiente di cooperazionedi cooperazione

Messaging serviceMessaging service: elemento : elemento infrastrutturale in grado di infrastrutturale in grado di supportare lo scambio di supportare lo scambio di messaggi durante messaggi durante l’esecuzionel’esecuzione

21

ebXML: progettazione (1)

Per la definizione di un processo ebXML si appoggia ad uno standard consolidato denominato UMM (UN/CEFACT Modeling Metodology)

UMM utilizza diversi strumenti tra cui UML

Niente ci impedisce di utilizzare una metodologia di progettazione diversa

22

ebXML: progettazione (2)

23

E-service e transazioni: binomio scontato? Gli standard emergenti non sono legati necessariamente al concetto di transazione economica L’ “e-service” non coincide necessariamente con il concetto di servizio business Gli standard emergenti sono orientati ad una maggior flessibilità rispetto al supporto delle transazioni (in particolare la SOA) Una transazione può essere supportata orchestrando più e-service o tramite meccanismi di coordinamento P2P

24

Conseguenze

Ci dobbiamo attendere una “discontinuità” nel percorso evolutivo dei sistemi informativi aziendali?

Gli e-service renderanno possibile il supporto alle esistenti transazioni gerarchiche, oppure modificheranno le relazioni fra clienti e fornitori spostandone gli equilibri?

25

Esempi di “discontinuità”

Cambieranno le coalizioni fra fornitori nella composizione del servizio business? Cambieranno le modalità di acquisizione, meno vincolate al fornitore? Si disaccoppierà il SW dal suo contesto, cioè gli e-service permetteranno di evolvere da software standardizzato a processi

standardizzati e condivisibili fra più imprese in relazioni cliente-fornitore analoghe ma che coinvolgono attori distinti?

26

Lavoro su coalition formation in MAIS

Multicanalità Multifornitura

Nella formazione della rete del valore interviene una molteplicità di fornitori interconnessi in una rete di relazioni

Nella composizione del servizio finale intervengono due categorie di problemi:

• La formazione di coalizioni tra fornitori (cooperazione)

• La competizione tra fornitori e/o tra coalizioni di fornitori

27

Framework

Framework teorico: Cooperative Game Theory Cost Allocation Coalition formation

Formazione della coalizione: partizione dei giocatori in coalizioni disgiunte

Massimizzazione del valore di ciascuna coalizione: massimizzazione dei payoff

Ripartizione dei payoff tra i singoli componenti di ciascuna coalizione

28

Framework

Tipicamente nella letteratura esistente (coopetitive game theory, cost allocation, coalition formation) il valore della coalizione è indipendente dalle azioni dei giocatori esterni alla coalizione: assenza di interazione strategica (un’eccezione Klusch e Gerber 2002)

Nella maggior parte dei casi la letteratura esistente considera contesti superadditivi: in questi casi il problema della coalition formation è risolto banalmente in quanto la coalizione avente massimo valore è quella costituita da tutti i giocatori (eccezioni Dang e Jannings 2004, Sandholm et. alii 1999).

29

Il modello Il valore della coalizione dipende da:

Interazione strategica La superadditività non è data per assunto

Modello basato sulle Combinatorial Auctions Rothkopf M.H., A. Pekeč and M.H. Harstad 1998 Kutanoglu E. and D.S. Wu 1999 Ausubel L. and P. Milgrom 2002 Conitzer V. and T. Sandholm 2004

Le preferenze dei giocatori sono definite da: Ogni giocatore “i” associa un valore VK ad un insieme “K” di “entità”

(risorse scarse, attività, obiettivi) Regole d’asta:

Chiunque può fare offerte “per bundle” di entità Alcune offerte sono incompatibili: non tutte le offerte possono essere

selezionate come vincenti simultaneamente

30

Il modello

Estendendo la teoria di base sulle aste combinatorie determiniamo il minimo “sforzo” P(S) (pagamento) che un’intera coalizioni S deve sostenere per vincere, date le offerte degli altri

Individuiamo la partizione di giocatori in coalizioni tale che la somma degli sforzi sia massima:

maxS

P S

31

Problemi computazionali

Il problema combinatorio è NP-hard Approccio naive: enumerazione esaustiva Affrontiamo i problemi computazionali

dimostrando che la partizione ottimale e i relativi sforzi possono essere determinati risolvendo un opportuno Integer Linear Problem, con un numero polinominiale di vincoli e variabili

32

E-services

In questo caso il servizio elettronico viene progettato come una rete di fornitori (Reti di Progetto): le entità sono costituite da: infrastrutture di rete,

hardware, software di base e applicativo, attività. i giocatori sono rappresentati dai fornitori delle

risorse e delle attività stesse.

Attraverso il modello proposto è possibile determinare le coalizioni ottimali e il valore di ciascuna di esse.

33

Il ruolo delle ontologie

Fondamentali nella standardizzazione di processo

Da ontologie informative a ontologie di processo

Letteratura: progetto DAML-S, concetto di domain-independent ontologies istanziabili nella descrizione degli e-service