Evoluzione dei Web Services per l'nteroperabilità: approcci a supporto della dinamicità e flessibilità nell'integrazione di infrastrutture IT

Evoluzione dei Web Services per l’interoperabilità: approcci a supporto della dinamicità e flessibilità nell’integrazione EAI di infrastrutture IT Emanuele Della Valle Area Middleware - CEFRIEL email:dellavalle@cefriel.it Web:www.cefriel.it/~dellavalle -1- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Sommario C’era una volta … Service Oriented Architecture basata su Web Services discovery  UDDI  Casi d’uso e limiti Composizione  Una nesessità  BPEL4WS, WSCI, BPML, … … e fu così che si affermarono le SOA basate su WS Limiti degli approcci attuali in contesti caratterizzati da alta dinamicità  mancanza di di semantica elaborabile dalle macchine  Semantic-based service discovery Semantic Web Services  Le iniziative in corso  WSMO all’opera Conlusioni -2- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

C’era una volta … … ma l’organizzazione non era certo …, in un’organizzazione felice, l’unica. Altre organizzazioni avevano un’applicazione con tanti utenti applicazione con utenti soddisfati e … soddisfatti, ma … […] […] […] applicazione applicazione applicazione Confine tra le due organizzazioni … e, per esigenze di business, le due Pensando alla contingenza organizzazioni sentirono l’esigenza di l’organizzazione felice decise di integrare le due applicazioni. addossarsi lo sforzo di integrazione, … ! […] […] […] […] ? adapter applicazione applicazione applicazione applicazione Confine tra le due Confine tra le due organizzazioni organizzazioni -3- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

… ma gestire la contingenza … … quando il problema di integrazione coinvolge molte organizzazioni autonome ma interdipendenti non paga sul lungo periodo […] […] Legenda ! OK ! […] !! Bene ! ! ! ! ! !!! Ottimo !?! Ottimo, ma … !?! […] ?? ? !? ! ?!? Avrò fatto la cosa giusta? !! ! ??? Che senso ha? ?#@ Perché lo ! !?! stiamo facendo? !! ##! … ?? ! […] […] […] ! ! ! -4- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

… fu così che … … nacquero le soluzioni di Enterprise Application Integration e iniziò il processo di maturazione delle tecnologie per l’integrazione […] […] 2010 SOA over WS […] 2005 WS-* 1.x (SOAP1.1, WSDL1.2, UDDI, BPEL4WS…) […] CORBA 2.4 2000 WS-* 0.x XML-RPC EAI CORBA2.0 1995 CORBA1.0 1990 EDIFACT RPCs […] 1985 […] Sockets ANSI X12 1980 […] TDCC 1970 Tecnologie per EAI -5- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Service Oriented Architecture basata su Web Services Il concept di Service Oriented Architecture (SOA) abilita flessibilità e dinamismo tramite una descrizione ricca del servizio e un meccanismo di pubblicazione/scoperta di tali descrizioni che permette a richiedenti occasionali di interagire con il servizio senza (o con limitate) conoscenze a priori. Una discovery agency può essere realizzata in diversi Service Descriptio modi n Registro  i service provider Discovery richiedono al registro di Agencies essere rendere disponibili sul mercato i proprio servizi Discover  Accordo esplicito tra service Publish provider e registro Indice  i service provider rendono disponibile la descrizione Service per una indicizzazione Descriptio esterna (es. Google) n  Nessun accordo esplicito tra Service Service provider e indice P2P requester provider Interact  Service provider e service requester hanno anche il ruolo di discovery agency source: http://www.w3.org/TR/2002/WD-ws-arch-20021114/ -6- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Tecnologie che abilitano la discovery Lo standard UDDI Un registro UDDI (v 3.0) contiene: Business Entity Pagine Bianche Pagine Bianche Nome, Indirizzo, Contatti  Nome del service provider, identificativo, Pagine Gialle Identificativo indirizzo e altre informazioni per contattare la società ABN, CAN, DUNS, … Pagine Verdi Pagine Gialle Classificazione Standard  Sistemi di classificazione di service Geografica, tipo di industria, … provider e servizi su base geografica, tipo di industri, etc. Business Service Pagine Verdi Nome, descrizione  Descrizione tecnica delle interfacce del servizio (es. Acquisto libri) e del punto di Classificazione accesso (URL, e-mail, ecc.) utilizzando Tipo di processo, ruolo, … opportuni “tModel” tModel Binding Template  Definizione tecnica di un tipo di servizio Descrizione, URL, … tipicamente emessa da enti di standardizzazione di specifici domini (es. tModel EAN/UCC*) per essere utilizzata dai Descrizione dell’interfaccia, service provider. trasport, protocollo, sintassi, … Oggetti nel repository  Tutti gli oggetti descritti sopra sono tModel immagazzinati come metadati nel registro UDDI prevede API per scrivere e cercare nel Nome, descrizione, URL, … repository XML Classificazione * EAN.UCC System standardizza bar codes, insiemi di transazioni EDI Tipo, namespace, processo, ruolo, tipo objects transactions sets, schemi XML, e altre soluzioni per rendere più efficiente di industria, geografia, riferimenti ad l’e-business altri tModels repository -7- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Tecnologie che abilitano la discovery Casi d’uso e limiti di UDDI Si iniziano a registrare casi d’uso reali In ambienti caratterizzati da alto interessanti di UDDI dinamismo in cui numerose BizDex Registry organizzazione autonome gestiscono un  L’Australian National B2B Registry fa insieme di servizi eterogenei, ma leva su UDDI per ridurre il costo di fortemente interdipendenti, UDDI setup di infrastrutture B2B anche per mostra limiti di flessibilità. piccoli business e con piccoli volumi In particolare, il meccanismo di ricerca di transazioni. effettua un matching sintattico (senza 30 Gennaio 2004 considerare il significato delle Picture Services Network descrizioni) con conseguente:  Il Common Picture Exchange basso recall: Environment dell’International  a causa di termini semanticamente Imaging Industry Association's utilizza simili ma sintatticamente diversi UDDI per ridurre i costi di (sinonimi) integrazione di differenti prodotti esempio: “sagra” e “manifestazione per la fotografia digitale. folkloristica” 10 Giugno 2003 bassa precisione:  a causa di termini con uguale sintassi Altri casi d’uso ma differente semantica (omonimi)  http://www.uddi.org/casestudies.html esempio: “grana”, si intende il formaggio o il tipo di pasta? -8- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Composizione: una necessità In un mercato dinamico e Esempio di composizione del contesto del aggressivo, l’estrema turismo specializzazione è una necessità, ma le esigenze dei consumatori restano trasversali e per soddisfarle occorre la collaborazione di molti attori. Nel caso del turismo, ad esempio, è normale che chi offre viaggi aerei, non offra pacchetti vacanza completi (cosa che, invece, fanno le agenzie di viaggio). La composizione di servizi cross-organizzazione è una delle possibili vie per offrire servizi ad alto valore aggiunto per l’utente finale integrando i servizi di molte realtà settoriali. Fonte: W3C Note: WSCI http://www.w3.org/TR/wsci/ -9- Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Tecnologie che abilitano la composizione BPEL4WS, WSCI, BPML, … La composizione abilita la creazione Standard in competizione BPEL4WS di nuovi servizi a partire da servizi  è un linguaggio per la specifica formale di esistenti. processi di business e protocolli per Molti dei convenzionali middleware di l’interazione tra business. composizione (es. WfMS) non sono stati Web Service Choreography Interface (WSCI) in grado di garantire un sufficiente  è un linguaggio per la descrizione del flusso di grado di interoperabilità e i relativi messaggi scambiati da Web Services che processi di standardizzazione si sono in collaborano per esibire un servizio composto. Business Process Modeling Language parte “arenati” (es. gli standard (BPML) proposti dalla WfMC sono scarsamente  è un modello di esecuzione astratto per supportati) processi di business collaborativi e Le opportunità per i Web Services transazionali Gli standard disponibili (SOAP e WSDL) sono largamente impiegati e garantiscono coerenza nei meccanismi di invocazione e nella descrizione dell’interfaccia dei servizi Molti tools (per discovery e invocazione) sono già disponibili e, pertanto, sviluppare un ambiente di composizione di Web Services è “poco” costoso - 10 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

… e fu così che si affermarono le SOA basate su WS Il continuo processo di maturazione delle tecnologie ha portato negli ultimi anni all’affermazione dei Web Services come potenziale base tecnologica di soluzioni per EAI che ambiscono a supportare scenari ad alta dinamicità con il dovuto grado di flessibilità. 2010 […] […] SOA over WS 2005 WS-* 1.x […] (SOAP1.1, WSDL1.2, UDDI, BPEL4WS…) SOAP CORBA 2.4 2000 […] WS-* 0.x XSD WSDL XML-RPC CORBA2.0 EAI UDDI 1995 WSCI CORBA1.0 1990 WS-* EDIFACT BPEL RPCs 1985 Sockets […] ANSI X12 […] 1980 TDCC […] 1970 Tecnologie per EAI - 11 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Limiti degli approcci attuali in contesti caratterizzati da alta dinamicità È semplice gestire pochi servizi Gestirli diventa difficile quanto i servizi all’interno di un unica sono numerosi e occorre comporli in organizzazione da utilizzare in complessi business process cross- workflow poco complessi organizzazione Pochi servizi Numerosi servizi All’interno di un’organizzazione Tra molteplici organizzazioni A1 B3 A1 B3 B8 A1 A4 B3 B3 A1 A1 A1 A1 A1 A1 A4 A2 A1 A4 A2 A4 A1 A2 A4 A1 A2 B3 A2 A1 A2 A5 A4 A1 B3 A1 B3 A1 A1 B3 B3 A1 A1 A1 A1 A4 A6 A1 A4 A1 A1 A1 A1 A4 A1 A2 A1 B3 A4 A1 A1 B3 A4 A1 A2 A1 A1 A4 A1 A2 A1 A2 A4 B3 A4 A1 A1 A4 A1 A2 B3 A2 A1 A1 A1 A1 A1 A1A1 A2 A4 A1 A2 A4 A1 A1 1 A A1 A1 B3 A4 A1 A2 A1 A2 A1 A2 A1 A2 A1 A1 A4A4 1 A2 A1 A4 B3 A2 A4 A2 A4 A1 4 A1 A1 A A4 B3 A2 A4 A1 A A2 A4 A1 A1 A1 A1 A1 B3 A4 A1 A2 B3 A4A1 A1 A2 B3 A4 A1 B3 A2 A4 A2 A1 A4 A1 A2 A1 A1 A1 A1 A1 A1 A4 B3 B3 A1 A1 A1 A1 A1A4 A2 Workflow A1A1 A2 A1 A2 A1 A1 A4 A4 A1 A2 A4 A1 A1A4 A1 A2 A1 A4 A4 A1 B3 B3 A1 A1 A1 B3B3 A1A1 poco complessi B3 ? E A N1 N2 F C D Complessi Business Process Inspired by: J. Cardoso, C. Bussler, A. Sheth1, D. Fensel, Semantic Web Services and Processes, October 2002 - 12 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Il principale limite è la mancanza di di semantica elaborabile dalle macchine quot;Semantic differences remain the primary roadblock to smooth application integration, one which Web Services alone won't over-come. Until someone finds a way for applications to understand each other, the effect of Web services technology will be fairly limited. When I pass customer data across in a certain format using a Web Services interface, the receiving program has to know what that format is. You have to agree on what the business objects look like. And no one has come up with a feasible way to work that out yet ...“ “L’eterogeneità semantica rimane il principale intoppo alla integrazione di applicazioni, un intoppo che i Web Services da soli non risolveranno. Finchè qualcuno non troverà un modo di per far si che le applicazioni si capiscano, gli effetti dei Web Services resteranno limitate. Quando si passano i dati di un utente in un certo formato usango un Web Services come interfaccia, il programma che li riceve deve comunque sapere in che formato sono. Occorre comunque accordarsi sulla struttura di ciascun business object. Fino ad ora nessuno ha ancora trovato una soluzione attuabile …” Oracle Chairman and CEO Larry Ellison - 13 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Nell’implementazione di una SOA usando i WS, dove sta la semantica dell’informazione scambiata? In parte è codificata nella descrizione del servizio (WSD), ma quella che abilita l’interazione resta nella testa delle persone … Discovery Discover Publish Agencies WSD Provider Entity Requester Entity ? Sem AGREE Sem Provider Requester Human Human + Sem + WSD Service Service provider requester Interact - 14 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Il Semantic Web sta rendendo disponibili meccanismi per rendere la semantica elaborabile La semantica può essere resa elaborabile dalle macchine tramite le ontologie ( ) perchè abilitano la comprensione dei simboli da parte delle persone e allo stesso tempo la loro elaborabilità Discovery Discover Agencies + Sem Publish WSD Ontology Provider Entity Requester Entity ? Sem Sem Provider Requester Human Human AGREE + Sem + Sem WSD WSD Service Service provider requester Interact - 15 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Esempio di uso della semantica Semantic-based service discovery Un’ontologia permette di descrivere le relazioni tra Mentre nel keyword mathcing (es. in i simboli in modo formale. La più semplice relazione UDDI) il matching è basato solo sulla è quella di classificazione. sintassi della stringa, avendo a Ad esempio, nel contesto del turismo le “sagre” e le disposizione un’ontologia si possono “mostre” sono due tipi di “eventi culturali” che a utilizzare le relazioni tra i simboli per loro volta sono “attrattive culturali” come i “beni “inferire” altre forme di matching. culturali” I possibili mathcing abilitati dalla relazione di classificazione sono: Exact Mathcing ( ) Subsume  Tutti i servizi classificati utilizzando il simbolo richiesto AttrattivaCulturale Plug-in matching ( )  Tutti i servizi classificati utilizzando Exact uno dei simboli che sono classificati BeniCulturali EventiCulturali come tipi più specifici di quello richiesto Subsume matching ( ) Mostre Sagre  Tutti i servizi classificati utilizzando uno dei simboli di tipo più generico Plug-in di quello richiesto Qui a fianco è illustrato un esempio di Fotografica Pittura mathcing nel caso in cui venga richiesto “eventi culturali” - 16 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Quale approccio ai Semantic Web Services? In aggiunta ad un linguaggio per esprimere le ontologie, l’interoperabilità semantica richiede la definizione di un modello concettuale per i Web Services. OWL-S e WSMO sono le due principali iniziative attive nel contesto dei Semantic Web Services, OWL-S è un’ontologia dei servizi definita in OWL (Ontology Web Language)  Mette a disposizione dei service providers un insieme di costrutti per descrivere le proprietà e le funzionalità offerte dai loro Web Services in modo che tali descrizioni siano “comprensibili” alle macchine.  OWL-S è stato sottomesso al W3C nel Novembre del 2004. http://www.daml.org/services/owl-s/1.1/ . WSMO, Web Service Modeling Ontology,  Prende il problema da un punto di vista più ampio introducendo quattro elementi: Le ontologie che permettono di descrivere il significato dei simboli necessari a tutti gli altri elementi, I goal che descrivono le funzionalità richiesta da chi intendo utilizzare i Web Services disponibili, Le descrizioni dei servizi vere e proprie, e I mediatori per aggirare i problemi di interoperabilità  La preparazione di una sottomissione al W3C è in corso ed è attesa per il giugno 2005 http://www.wsmo.org/ . L’idea è “completare (gli standard esistenti), non competere” - 17 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Le iniziative relative ai Semantic Web Services in corso ha preparato le basi per DAML-S ha sviluppato Compatibile con Compatibile con Sta sviluppando Sta sviluppando Contribuisce a Contribuisce a OWL-S WSMO Prossim o Event Sottomette Drafts a o 6 - 10 J une 200 5 Innsbruc k, Austr ia - 18 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

WSMO all’opera Semantic Service Discovery - publishing time Requester Provider Provider entity entity entity WSD WSD WS WS Execution Enviroment Ontologies Mediators Web Services WSD + WSD + WSD +WSD + 2. 3. 1. 1. i provider e i requester si accor- dano sulle ontologie da usare WS WS 1. Quando non si riesce a trovare un Provider Provider accordo si possono introdurre dei entity entity mediatori (es. Conversione €/$) WSD WSD 1. Ciascun provider descrive i propri servizi usando i simboli delle ontologie prescelte e, se necessario i mediatori - 19 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

WSMO all’opera Semantic Service Discovery - discovery time 4. Requester Provider Invoke Provider entity entity entity WSD G WSD WS WS 3. 1. Execution Enviroment { ● ● } Discovery engine 2. Ontologies Mediators Web Services WSD + WSD + WSD + WSD + 1. I Requester descrivono i proprio goal usando i simboli delle ontologie prescelte e, se necessario i mediatori 1. Il meccanismo di discovery usa le ontologie e i mediatori per scoprire quali descrizioni hanno WS WS una corrispondenza semantica con il goal Provider 1. L’ execution environment returna una lista Provider entity entity di Web Services WSD WSD 1. Il requester seleziona il Web Services più appropriato e lo invoca - 20 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

C’era una volta e un’altra volta non c’era più, ma quella volta comunque c’era … Nelle soluzioni di application-to- […] […] application integration la semantica rimane nella testa di chi scrive adapter l’adapter Sem Sem Sem Nelle soluzioni di EAI che usano i Web […] […] Services come soluzione di integrazione la semantica è in parte codificata negli standard (XSD, SOAP, WSDL, BPEL4WS, BPML, etc.) usati per definire WS* i formati dei dati scambiati e le EAI modalità di scambio, ma buona parte rimane della testa di chi realizza la soluzione di integrazione. […] […] Sem Sem - 21 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

C’era una volta e un’altra volta non c’era più, ma quella volta comunque c’era … Le soluzioni di EAI del Sem futuro potrebbero essere Sem basate sui risultati dei working group che oggi […] […] stanno lavorando per aggiungere Semantica SOA over SWS 2010 (direttamente elaborabile dalle macchine) ai Web SOA over WS Services. WS-* 1.x 2005 In questo modo la (SOAP1.1, WSDL1.2, UDDI, BPEL4WS…) semantica risulta EAI ! SWS CORBA 2.4 condivisa tra gli utenti e 2000 WS-* 0.x le macchine XML-RPC (direttamente disponibile CORBA2.0 alla soluzione di EAI) 1995 CORBA1.0 permettendo 1990 un’integrazione flessibile EDIFACT […] RPCs in grado di seguire le […] 1985 Sockets esigenze di business di un ANSI X12 1980 mercato caratterizzato da TDCC forte specializzazione e 1970 Sem dinamismo. Sem - 22 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Opportunità, sfide e attività CEFRIEL Opportunità: studiare soluzioni di EAI con elevato grado di flessibilità per ambiti applicativi con elevato grado di dinamismo. Sfida: impiegare in scenari reali l’approccio innovativo dei Semantic Web Services attraverso un opportuno tuning che richiede la selezione delle tecnologie abilitanti, l’uso di standard esistenti, la scelta dell’architet- tura complessiva, la selezione degli ambiti applicativi più idonei, … Es. COCOON: WSMO per e-Health [http://cocoon.cefriel.it] - 23 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Grazie mille dell’attenzione Domande? EAI Evento Contatto ossimo Pr Emanuele Della Valle Area Middleware - CEFRIEL email:dellavalle@cefriel.it 2005 10 June ustria Web:www.cefriel.it/~dellavalle 6- ck, A Innsbru Tel: 02 23954-324 - 24 - Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

Evoluzione dei Web Services per l'nteroperabilità: approcci a supporto della dinamicità e flessibilità nell'integrazione di infrastrutture IT

by Emanuele Della Valle on Nov 13, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 15

Statistics

Evoluzione dei Web Services per l’nteroperabilità: approcci a supporto della dinamicità e flessibilità nell’integrazione di infrastrutture IT — Presentation Transcript

http://emanueledellavalle.org	8
http://www.slideshare.net	7