Gli e-service come tecnologie di supporto automatico per le diverse classi di transazioni Chiara Francalanci 27 maggio 2004.

Presentazione sul tema: "Gli e-service come tecnologie di supporto automatico per le diverse classi di transazioni Chiara Francalanci 27 maggio 2004."— Transcript della presentazione:

1 Gli e-service come tecnologie di supporto automatico per le diverse classi di transazioni Chiara Francalanci 27 maggio 2004

2 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 3 E-service e transazioni: binomio scontato? Manca supporto flessibile allesecuzione delle transazioni Gli e-service permettono (dalle prime 10 ore di corso): Il wrapping del SI aziendale Lesportazione e la condivisione di servizi fra soggetti diversi, in relazioni molti a molti, purché definiscano unontologia comune La definizione di contratti che definiscono le regole per lo scambio dei servizi In sintesi, modellano naturalmente il rapporto cliente-fornitore

4 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 5 Sintesi dei problemi aperti Dunque manca supporto a: negoziazione cooperativa (v. prossima lezione) pianificazione cooperativa (EbXML) controllo di processo cooperativo (WSLA)

6 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 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 8 WSLA: infrastruttura (1) La definizione di un contratto WSLA è complementare alla definizione del servizio WSDL identifica linterfaccia del servizio, WSLA le caratteristiche di prestazione concordate

9 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 10 WSLA: gestione run-time Misurazione: identifica le metriche semplici e le computa in metriche di alto livello (es. tempo medio di risposta di uninsieme 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 Linterazione tra i servizi può avvenire a diversi livelli

11 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 Nellesempio 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 12 WSLA: stipula di un contratto (2)

13 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 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 15 WSLA: deployment (2)

16 16 ebXML Consorzio OASIS e UN/CEFACT Nato per supportare in maniera specifica la definizione di processi intra e inter-organizzativi Fornisce uninfrastruttura dove gli investimenti EDI possono essere preservati avendo i vantaggi di unarchitettura XML-based

17 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. Unimpresa 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. Unimpresa B, se interessata a partecipare al processo segue la stessa procedura di A. Dal Registry viene a sapere che lattività che intende realizzare prevede la cooperazione con lattività 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 allaccordo definito in precedenza.

18 18 ebXML: schema di riferimento Design: definizione del processo e inquadramento dei vari sistemi cooperanti allinterno del processo stesso Design: definizione del processo e inquadramento dei vari sistemi cooperanti allinterno del processo stesso Negotiation: comprende la definizione dellaccordo tra due imprese che decidono di cooperare Negotiation: comprende la definizione dellaccordo tra due imprese che decidono di cooperare Execution: esecuzione vera e propria del processo Execution: esecuzione vera e propria del processo

19 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 linformazione sulla cooperazione Le caratteristiche del processo cooperativo possono essere modificate durante lesecuzione In entrambi i casi ogni organizzazione coinvolta viene rappresentata come una black box di cui sono visibili solo i processi pubblici In entrambi i casi ogni organizzazione coinvolta viene rappresentata come una black box di cui sono visibili solo i processi pubblici

20 20 ebXML: architettura BSI (Business Service Interface): interpreta documenti ebXML BSI (Business Service Interface): interpreta documenti ebXML CPP (Collaborative Partner Profile) : specifica del ruolo, caratteristiche minime di comunicazione, QoS CPP (Collaborative Partner Profile) : specifica del ruolo, caratteristiche minime di comunicazione, QoS CPA (Collaborative Partner Agreement): contiene laccordo che le parti sottoscrivono prima di iniziare la collaborazione CPA (Collaborative Partner Agreement): contiene laccordo che le parti sottoscrivono prima di iniziare la collaborazione ebXML registry/repository: compatibile con UDDI, contiene tutte le informazioni necessarie per la costruzione dellambiente di cooperazione ebXML registry/repository: compatibile con UDDI, contiene tutte le informazioni necessarie per la costruzione dellambiente di cooperazione Messaging service: elemento infrastrutturale in grado di supportare lo scambio di messaggi durante lesecuzione Messaging service: elemento infrastrutturale in grado di supportare lo scambio di messaggi durante lesecuzione

21 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 22 ebXML: progettazione (2)

23 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 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 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 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 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 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 (uneccezione 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 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 V K ad un insieme K di entità (risorse scarse, attività, obiettivi) Regole dasta: Chiunque può fare offerte per bundle di entità Alcune offerte sono incompatibili: non tutte le offerte possono essere selezionate come vincenti simultaneamente

30 30 Il modello Estendendo la teoria di base sulle aste combinatorie determiniamo il minimo sforzo P(S) (pagamento) che unintera 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:

31 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 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 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