Università degli Studi di Roma "Tor Vergata" Facoltà di Scienze MFN

Transcript

1 Università degli Studi di Roma "Tor Vergata" Facoltà di Scienze MFN Corso di Laurea in Informatica Tesi di Laurea Analisi, progettazione e implementazione di un Infrastruttura di Comunicazione basata su Web services Relatore Chiar.mo Prof. Giorgio Gambosi Correlatore Dott. Marco Bianchi Candidato Antonio Mazza Matricola Anno accademico 2003/04

2 Alla famiglia e agli amici che mi danno la forza per non mollare 1

3 Indice Contesto formativo...13 Introduzione...13 Struttura della tesi...16 I - Scenario tecnologico e metodologico Web services Cosa sono i Web services Caratteristiche dei Web services Perché usare i Web services L architettura dei Web services I ruoli in un Web service Stack dei protocolli di un Web service Tecnologie dei Web services SOAP: il fulcro dell interoperabilità Cosa definisce SOAP La struttura di un messaggio SOAP SOAP con allegati Descrivere i Web services: WSDL Ricerca e pubblicazione dei Web services Sviluppo di Web services usando Java Apache Axis Caratteristiche principali di Axis Funzionalità e vantaggi di Axis L architettura di Axis Web service Deployment Descriptor (WSDD) Gestione degli allegati: Javabean Activation Framework

4 3. Modelli e processi di sviluppo Unified Process for EDUcational Caratteristiche e aspetti Ciclo di vita Catturare le informazioni del progetto: gli artefatti Extreme Programming I valori di XP Caratteristiche di XP Java e XP La filosofia dei tools in XP Automazione...48 Apache Ant Esecuzione di tests...50 JUnit...50 JMeter...51 TestMaker Localizzazione dei bugs...53 Log4J...53 II - Case study: un Infrastruttura di Comunicazione Analisi del contesto dell Infrastruttura di Comunicazione: scelte tecnologiche e metodologiche Introduzione al problema Il contesto: il sistema di catalogazione e condivisione Descrizione funzionale Assunzioni e attributi del sistema Architettura generale del sistema

5 4.2.4 Proiezione delle funzionalità sull architettura: realizzazione dei casi d uso Analisi tecnologica Java e i Web services Implementazione delle tecnologie e ambienti open source Analisi metodologica e processo di produzione del software: UP affiancato da XP Analisi dei requisiti, definizione dell architettura e pianificazione Introduzione alle iterazioni Definizione dei requisiti a partire dal contesto I casi d uso: l input per l analisi Requisiti non Funzionali e specifiche supplementari Business Rules Dal modello di analisi alla definizione dell architettura Definizione dei sottosistemi Definizione dell architettura Pattern Overview La gestione delle eccezioni Pianificazione dei tests Tests funzionali Test di performance e di scalabilità Piano di sviluppo del software Il sottosistema VirtualRepository dell Infrastruttura di Comunicazione Funzionalità e obbiettivi del sottosistema VirtualRepository Modello di analisi Definizione delle classi a partire dall architettura generale

6 6.4 Le dinamiche del sottosistema VirtualRepository: realizzazione dei casi d uso Rimuovi Metadata(LOM) da Catalogo DeleteLO Registra Metadata(LOM) su Catalogo InsertLO Modifica Metadata(LOM) su Catalogo Pianificazione ed esecuzione dei tests per il sottosistema VirtualRepository Tests funzionali Tests di performance e scalabilità Il sottosistema Repository dell Infrastruttura di Comunicazione Introduzione alle funzionalità del sottosistema Repository Il modello di analisi L architettura delle classi del sottosistema Repository Realizzazione dei casi d uso sulla base delle classi definite Richiedi lista LO su repository Predisponi Download LO su Repository Pianificazione, esecuzione e reports dei tests del sottosistema Repository Tests funzionali Tests di performance e scalabilità Il sottosistema Catalogue dell Infrastruttura di Comunicazione Analisi delle funzionalità Il modello di analisi Identificazione delle classi che definiscono l architettura Realizzazione dei casi d uso: collaborazioni tra gli oggetti Esegui query su Catalogo GetLO Scaricamento di un LO

7 8.5 Progettazione, esecuzione e reports dei tests Tests funzionali Tests di performance e scalabilità Integrazione, deployment e testing dell Infrastruttura di Comunicazione Integrazione e deployment Testing distribuito dell Infrastruttura di Comunicazione Tests funzionali del VirtualRepository Tests di performance e scalabilità del VRepository Tests funzionali del Repository Tests di performance e scalabilità del servizio Repository Testing delle funzionalità fornite alle Interfacce Tests di performance e scalabilità del servizio Catalogue Conclusioni Bibliografia

8 Indice delle figure Figura 1 - Un Web service permette l'accesso ad applicazioni usando tecnologie standard Figura 2 - Un semplice Web service Figura 3 - Messaggistica XML per i Web services Figura 4 - Modello operazionale dei Web services, visualizza ruoli e relazioni Figura 5 - Pila concettuale dei Web services Figura 6 - Struttura del messaggio SOAP Figura 7 - Rappresentazione concettuale del documento WSDL Figura 8 - Il cammino del Message sul Server. I cilindri piccoli rappresentano le handlers, quelli grandi, invece, rappresentano le chains Figura 9- Il cammino del Message sul Client. I cilindri piccoli rappresentano le handlers, quelli grandi, invece, rappresentano le chains Figura 10 - modello del ciclo di vita Figura 11 - ciclo di sviluppo Figura 12 - Casi d'uso relativi al sistema di condivisione e catalogazione di LO Figura 13 Componenti generali del sistema Figura 14 - Il sottosistema Catalogo Figura 15 - Architettura generale del sistema e collocazione dell'infrastruttura di Comunicazione Figura 16 - Sequence diagram relativo al caso d'uso DeployLO Figura 17 - Sequence diagram relativo al caso d'uso DeleteLO Figura 18 - Sequence diagram relativo al caso d'uso ModifyLO Figura 19 - Sequence diagram relativo al caso d'uso UpdateLOM Figura 20 - Sequence diagram relativo al caso d'uso QueryMetadata Figura 21 - Sequence diagram relativo al caso d'uso GetLO Figura 22 Architettura generale del sistema di catalogazione e condivisione Figura 23 - Diagramma dei casi d'uso dell'infrastruttura di Comunicazione... 75

9 Figura 24 - Analysis Classes Diagram Figura 25 - I sottosistemi dell'infrastruttura di Comunicazione Figura 26 - Architettura di comunicazione tra una componente e un Web service Figura 27 - La connessione tra i Web services e i componenti che ne implementano le funzionalità: i Connectors Figura 28 - Pattern overview dell'infrastruttura di Comunicazione Figura 29 - Struttura di un'eccezione nell'infrastruttura di Comunicazione Figura 30 - Casi d'uso relativi al sottosistema VirtualRepository Figura 31 - Analysis classes Diagram del sottosistema VirtualRepository Figura 32 - Classes Diagram del sottosistema VirtualRepository dell'infrastruttura di Comunicazione Figura 33 - I transfer objects utilizzati nel sottosistema VirtualRepository Figura 34 - Classes Diagram delle eccezioni del sottosistema VirtualRepository Figura 35 - Collaboration Diagram dell'operazione di rimozione di un LO dal Catalogo Figura 36 - Collaboration Diagram dell'operazione di inserimento di un LO sul Catalogo Figura 37 - Collaboration Diagram dell'operazione di aggiornamento dei LOM sul Catalogo.101 Figura 38 - Reports del sottosistema VirtualRepository Figura 39 Test di performance dell operazione di rimozione di un LO dal Catalogo del Web service VRepository (in locale) Figura 40 - Test di performance dell operazione di inserimento di un LO sul Catalogo del Web service VRepository (in locale) Figura 41 - Test di performance dell operazione di aggiornamento dei metadata (LOM) sul Catalogo del Web service VRepository (in locale) Figura 42 - Dettagli delle operazioni testate sul Web service(numero di volte eseguite, media del tempo in ms, minimo tempo, max tempo, percentuale di errore, numero ipotizzato di operazioni per secondo). (in locale) Figura 43 - Rappresentazione grafica della media, mediana, deviazione standard dei tempi impiegati nell eseguire le operazioni(300) e il numero di richieste per minuto relative al Web service VRepository. (in locale) Figura 44 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni esposte dal Web service VRepository. (in locale)

10 Figura 45 - Diagramma dei casi d'uso che deve realizzare il sottosistema Repository dell'infrastruttura di Comunicazione Figura 46 - Analysis Classes Diagrams del sottosistema Repository Figura 47 - Classes Diagram del sottosistema Repository dell'infrastruttura di Comunicazione Figura 48 - Class Diagram che mette in risalto la gestione dello scaricamento di un LO Figura 49 - I TO del sottosistema Repository Figura 50 - Classes Diagram del RepositoryLocator Figura 51 - Classes Diagram delle eccezione del sottosistema Repository Figura 52 - Collaboration Diagram dell'operazione di restituzione della lista di LO presenti su un Repository Figura 53 - Collaboration Diagram dell'operazione di predispozizione dei parametri download sul Repository Figura 54 - Reports dell'esecuzione del test funzionale del sottosistema Repository Figura 55 - Test di performance dell operazione di restituzione della lista (10) di LO (id) del Web service Repository Figura 56 - Test di performance dell operazione di impostazione dei parametri per il download del Web service Repository Figura 57 - Test di performance dell operazione di scaricamento di un LO (dim: 11.2 MB) del Web service Repository Figura 58 - Dettagli delle operazioni testate sul Web service Repository (numero di volte eseguite, media del tempo in ms, minimo tempo, max tempo, percentuale di errore, numero ipotizzato di operazioni per secondo). (in locale) Figura 59 - Rappresentazione grafica della media, mediana, deviazione standard dei tempi impiegati nell eseguire le operazioni(150) e il numero di richieste per minuto relative al Web service Repository. (in locale) Figura 60 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni esposte dal Web service Repository. (in locale) Figura 61 - I casi d'uso del sottosistema Catalogue Figura 62 - Analysis Classes Diagram del sottosistema Catalogue Figura 63 - Classes Diagram del sottosistema Catalogue

11 Figura 64 - I Transfer Objects del sottosistema Catalogue Figura 65 - Le eccezioni del sottosistema Catalogue Figura 66 - Collaboratiion Diagram dell'operazione di esecuzione di una query sul Catalogo.132 Figura 67 - Sequence Diagram ad alto livello dell'operazone di scaricamento di un LO Figura 68 - Collaboration Diagram dell'operazione di scaricamento di un LO Figura 69 - Reports dell'esecuzione del test funzionale del sottosistema Catalogue Figura 70 - Test di performance dell operazione di restituzione dei parametri per il download di un LO del Web service Catalogue Figura 71 - Test di performance dell operazione di esecuzione di una query sul Catalogo del Web service Catalogue Figura 72 - Test di performance dell operazione di conferma di avvenuto download del Web service Catalogue Figura 73 - Dettagli delle operazioni testate sul Web service Catalogue (numero di volte eseguite, media del tempo in ms, minimo tempo, max tempo, percentuale di errore, numero ipotizzato di operazioni per secondo). (in locale) Figura 74 - Rappresentazione grafica della media, mediana, deviazione standard dei tempi impiegati nell eseguire le operazioni(300) e il numero di richieste per minuto relative al Web service Catalogue. (in locale) Figura 75 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni esposte dal Web service Catalogue. (in locale) Figura 76 - Deployment e organizzazione delle distribuzioni rilasciate dall'infrastruttura di Comunicazione Figura 77 - Reports di esecuzione dei tests funzionali del Repository Virtuale su rete Figura 78 - Dettagli delle operazioni testate del WS (numero di volte eseguite, media del tempo in ms, minimo tempo in ms, max tempo in ms, percentuale di errore, numero ipotizzato di operazioni per secondo). (sulla rete) Figura 79 - Rappresentazione grafica della media(ms), mediana (ms), deviazione standard(ms) e il numero di richieste per minuto dei tempi impiegati nell eseguire le operazioni(300). (sulla rete) Figura 80 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni (sulla rete) Figura 81 - Testing funzionale dell'operazione di richiesta della lista di LO

12 Figura 82 - Dettagli delle operazioni testate del WS (numero di volte eseguite, media del tempo in ms, minimo tempo in ms, max tempo in ms, percentuale di errore, numero ipotizzato di operazioni per secondo). (sulla rete) Figura 83 - Rappresentazione grafica della media(ms), mediana (ms), deviazione standard(ms) e il numero di richieste per minuto dei tempi impiegati nell eseguire le operazioni(60). (sulla rete) Figura 84 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni (sulla rete) Figura 85 - Risultati dei tests funzionali eseguiti dall'interfaccia Figura 86 - Dettagli delle operazioni testate del WS (numero di volte eseguite, media del tempo in ms, minimo tempo in ms, max tempo in ms, percentuale di errore, numero ipotizzato di operazioni per secondo). (sulla rete) Figura 87 - Rappresentazione grafica della media(ms), mediana (ms), deviazione standard(ms) e il numero di richieste per minuto dei tempi impiegati nell eseguire le operazioni(300). (sulla rete) Figura 88 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni. (sulla rete)

13 Indice delle Tabelle Tabella 1 - Gli obbiettivi e le milestones di ogni iterazione...90

14 Contesto formativo La tesi è stata affiancata da un periodo di tirocinio svolto presso il NetLab 1, il Laboratorio di Ricerca e Sperimentazione su Reti e Multimedialità dell Istituto di Analisi dei Sistemi ed Informatica 2 Antonio Ruberti del Consiglio Nazionale delle Ricerche (IASI-CNR). L Infrastruttura di Comunicazione, oggetto di studio, è lo sviluppo di parte di un sistema finalizzato all interscambio ed alla condivisione di materiale didattico da parte dei dottorati di ricerca avviato nell ambito del progetto FIRB Web Minds 3. Va sottolineata, in modo particolare, la collaborazione con il Gruppo architettura layer di interazione 4 che ha definito l architettura generale [1] del sistema e l Infrastruttura di Comunicazione [2]. Introduzione L obbiettivo della tesi è la definizione di un Infrastruttura di Comunicazione per un sistema di catalogazione semantica e condivisione distribuita di Learning Objects, avente come scopo la condivisione e l interscambio di materiale didattico tra Dottorati di ricerca, a carattere informatico, tenuti in diversi Atenei italiani. Il sistema, caratterizzato da un significativo livello di distribuzione, prevede la seguente organizzazione in termini di componenti: uno o più Repositories, un Catalogo e una o più Interfacce. Un Repository è semplicemente un contenitore di LO, con funzioni di creazione, modifica e rimozione che ha l obbligo di registrarsi presso il registro centralizzato del sistema; il Catalogo è responsabile della gestione della banca dati centralizzata, costituita dai metadata (Learning Object Metadata) associati a tutti i LO registrati e del motore inferenziale utilizzato per eseguire le ricerche semantiche; l Interfaccia si occupa di gestire l'interazione con gli utenti interessati alla ricerca e allo scaricamento dei LO. Al fine di rendere Di cui fanno parte il Prof. Giorgio Gambosi e il Dott. Marco Bianchi

15 trasparente la natura distribuita del sistema e garantire l interconnessione tra le vari componenti appare necessaria e utile la progettazione di un Infrastruttura di Comunicazione, oggetto dello studio che seguirà. La progettazione di una simile Infrastruttura è conseguenza di un opportuna analisi di ricerca e di scelta dei differenti approcci tecnologici e metodologici. L Infrastruttura di Comunicazione si modellerà su un architettura di tipo Peer to Peer che prevede la presenza di un registro centralizzato dei Repositories. I Repositories rappresentano i peers che dispongono delle risorse (Learning Objects) necessarie agli altri peers (le interfacce). Le scelte architetturali dell Infrastruttura di Comunicazione sono legate alla libertà tecnologica che viene fornita ai singoli componenti distribuiti del sistema, in modo da non porre nessun vincolo sulle scelte implementative da adottare. L eterogeneità dei componenti che ne consegue, relativamente a Interfacce e Repositories, suggerisce di non fare nessuna ipotesi in merito alla relativa implementazione ma porta a considerare soluzioni di tipo aperto che incrementano l espandibilità. L espandibilità contribuisce ad aumentare le abilità delle componenti e del sistema nel cooperare con gli altri. L impronta di eterogeneità e l alto grado di distribuzione, uniti al requisito di espandibilità che l Infrastruttura di Comunicazione deve considerare, inducono ad adottare tecnologie aperte come i Web services. I concetti che sono alla base dei Web services costituiscono ottime soluzioni ai problemi ricorrenti nell ambito di integrazione e interazione di componenti e sistemi eterogeneamente distribuiti. L infrastruttura di Comunicazione, difatti, facendo uso dei Web services interagirà con tecnologie consolidate come standard de-facto. Tra queste, la più affermata, SOAP (Simple Objects Access Protocol), definito come il fulcro dell interoperabilità, è il protocollo di scambio basato su messaggi XML che sta alla base della comunicazione nei Web services. L Infrastruttura di Comunicazione implementerà un insieme di componenti software (i Web services) che possono essere richiamate utilizzando XML (SOAP) ed il protocollo internet HTTP. I Web services, SOAP, XML e HTTP consentono potenzialmente una interconnessione delle 14

16 componenti distribuite, considerando una eventuale eterogeneità tra i componenti del sistema. La loro potenzialità consiste, inoltre, nella loro indipendenza tanto dalla piattaforma quanto dai linguaggi di programmazione utilizzati per svilupparli. I Web services, pertanto, si propongono come la soluzione più idonea alla realizzazione dell Infrastruttura di Comunicazione. Sebbene, alla luce di quanto detto, non appare rilevante l utilizzo di uno specifico linguaggio di programmazione, per il lavoro svolto, la scelta è stata orientata verso il linguaggio Java. Il suo uso, in ambiente SOAP, oltre a rendere scalabile e portabile le applicazioni che si vogliono costruire, favorisce interoperabilità con applicazioni eterogenee residenti su piattaforme diverse risolvendo problemi di incompatibilità. Nel caso di Interfacce e Repositories realizzati utilizzando tecnologie diverse e quindi un linguaggio di programmazione diverso da Java, sarà possibile implementarne la corretta interazione con il resto del sistema operando direttamente a livello di invocazione ed implementazione dei Web services. A tal fine, i Web services implementati dall Infrastruttura di Comunicazione comprenderanno la descrizione delle interfacce dei Web services sotto forma di documenti WSDL (Web Service Description Language). L utilizzo di Java come linguaggio di programmazione per sviluppare applicazioni SOAP, richiede, inoltre, l implementazione Java per SOAP del binding specifico. Tra gli ambienti open source ha avuto un notevole successo l implementazione di SOAP per Java fornita dall'apache Group denominata Axis (Apache extensible Interaction System). La caratteristica interessante di Axis è che permette di integrare facilmente i Web services e in particolare la messaggistica SOAP nell Infrastruttura di Comunicazione senza la necessità di implementare SOAP o altri protocolli Internet a basso livello. Quanto detto permette di scegliere Axis come ambiente SOAP per l implementazione dei Web services dell Infrastruttura di Comunicazione. Per quanto concerne la metodologia applicata all organizzazione delle attività di progettazione e sviluppo, e delle fasi inerenti la realizzazione 15

17 dell Infrastruttura di Comunicazione, si è optato nell adottare un approccio misto tra metodologia UP (Unified Process) e metodologia XP (extreme Programming). L UP, con la separazione in iterazioni, si presta meglio ad una realizzazione incrementale dell Infrastruttura di Comunicazione distribuendo il lavoro in sottoproblemi. Un processo guidato da incrementi aggiuntivi e perfezionativi supporta una divisione in sottosistemi dell Infrastruttura consentendo di implementare, testare e rilasciare versioni ridotte della stessa (che implementino un sottoinsieme delle funzionalità). Utilizzando un approccio UP (nello specifico UP for EDUcational), nella fase di analisi e descrizione dei requisiti, di progettazione e di pianificazione, si catturano le informazioni chiave per la realizzazione del progetto. Le informazioni vengono schematizzate e organizzate negli artefatti che documentano le attività e le scelte, facilitando il mantenimento. Tuttavia, UP tralascia in qualche modo gli aspetti concreti e pragmatici della fase di implementazione e di testing, senza fornire gli strumenti concreti che la caratterizzano. L implementazione ed il testing sono però approfonditi nella metodologia XP. Progettare e implementare i tests, prima di codificare (implementare) una particolare funzionalità, è un aspetto molto interessante per un Infrastruttura di Comunicazione che si fa garante di una serie di chiamate a servizi remoti. L utilizzo di tools e frameworks open source, sono alla base della filosofia XP nonché le fondamenta stesse su cui si basa l implementazione e il testing dell Infrastruttura. L approccio misto che unisce le funzionalità analitiche dell UPEDU all agilità della metodologia XP, permette di ottenere un processo di produzione del software che garantisce un prodotto di qualità ed al tempo stesso scalabile, affidabile, mantenibile, efficiente e facile da usare. Struttura della tesi La tesi consta principalmente di due parti: nella prima parte, vengono trattati gli aspetti che non sono stati oggetto di studio del corso di Laurea in 16

18 Informatica (Scenario Tecnologico e Metodologico); nella seconda parte della tesi, invece, viene analizzato il caso di studio oggetto del tirocinio e della tesi: l Infrastruttura di Comunicazione. La prima parte della tesi, comprendente i primi tre capitoli, analizza: I Web services e le tecnologie correlate, come SOAP, WSDL, UDDI, mettendone in risalto i vantaggi e approfondendo gli aspetti che interessano l Infrastruttura di Comunicazione (Capitolo 1). L implementazione di SOAP per Java adottata per l implementazione dei Web services dell Infrastruttura di Comunicazione: Axis. Viene dettagliata l architettura, il modo in cui lavora il framework e le funzionalità che fornisce. (Capitolo 2) Le metodologie che definiscono il processo di produzione del software e che sono state adottate per definire il ciclo di vita dell Infrastruttura di Comunicazione. (Capitolo 3). La seconda parte della tesi, invece, analizza gli aspetti legati all Infrastruttura di Comunicazione: Partendo dal contesto, in cui è calata l Infrastruttura di Comunicazione, vengono motivate le scelte tecnologiche e metodologiche che sono state prese in considerazione per la realizzazione della stessa. (Capitolo 4) Vengono definiti e analizzati i requisiti che quantificano il lavoro e consentono la pianificazione dello stesso e la divisione dell Infrastruttura in sottosistemi. Viene definito lo scheletro dell architettura dell Infrastruttura di Comunicazione in base alle scelte progettuali e tecnologiche mettendone in rilievo i pattern utilizzati. (Capitolo 5). Partendo dallo scheletro dell architettura definita vengono definiti i sottosistemi (VirtualRepository, Repository, Catalogue) dell Infrastruttura: dopo aver selezionato i casi d uso, si fornisce il modello di analisi, il disegno architetturale (in termini di moduli e classi che compongono il sottosistema), la pianificazione dei tests e i 17

19 risultati prodotti dall esecuzione degli stessi. (Capitolo 6, Capitolo 7, Capitolo 8). L integrazione, il deployment e il testing dell Infrastruttura di Comunicazione vengono approfonditi. Gli aspetti relativi all organizzazione dei rilasci e delle distribuzioni sono delineati in modo da poter consentire ai clienti dell Infrastruttura l interazione con essa. Tests funzionali, di performance e di scalabilità sono eseguiti sull Infrastruttura: i loro risultati vengono documentati e commentati (Capitolo 9). Alla tesi sono, inoltre, allegati i documenti prodotti durante il processo di produzione del software. Questi documenti sono utili ai fini del mantenimento dell Infrastruttura di Comunicazione. I modelli dei documenti sono quelli forniti da UPEdu. 18

20 I Scenario tecnologico e metodologico

21 1. Web services Oggigiorno, l uso principale del World Wide Web è l accesso interattivo a documenti e applicazioni. Nella maggior parte dei casi, tale accesso è effettuato da utenti, tramite Web browser, audio players o altri sistemi di front end interattivi. Il Web può espandere ampiamente il proprio raggio di azione e la propria influenza solo se la sua azione venisse estesa a supporto della comunicazione tra diverse applicazioni nonché tra differenti programmi. - Dal W3C XML Protocol Working Group Charter [3] Una delle aree nello sviluppo di applicazioni e servizi informatici che presentano maggiore sviluppo è probabilmente quella che ruota attorno al concetto di comunicazione B2B (Business to Business). Le casse continue cooperano con le banche, i registratori di cassa comunicano con le aziende che offrono servizi di credito, i sistemi di gestione delle scorte procurano nuovi prodotti da vari fornitori. B2B, quindi, vuol dire anche flusso di informazioni di tipo A2A (Application to Application). I Web services [4] introducono un nuovo modo per lo scambio di informazioni tra aziende e una nuova concezione dello sviluppo del software. Le aziende possono pensare al software modularmene. Nelle organizzazioni con applicazioni eterogenee e architetture distribuite, l introduzione di Web services standardizza il meccanismo di comunicazione e permette interoperabilità tra le applicazioni, basate su differenti linguaggi di programmazione, localizzate su diverse piattaforme. 1.1 Cosa sono i Web services Dare una definizione di Web service è allo stesso tempo semplice e complesso; questo potrebbe essere dovuto alla dinamicità dei Web services stessi. 20

22 Un servizio Web è un sistema software identificato da una URI le cui interfacce pubbliche e i binding sono descritti da XML. La sua definizione può essere rintracciata da altri sistemi software. Questi sistemi software possono interagire secondo quanto scritto nella definizione, usando messaggi XML veicolati da protocolli internet. [5] In sostanza, un Web service è un interfaccia di rete accessibile alle funzionalità di un applicazione, costruito usando tecnologie standard di Internet. Questo è illustrato in Figura 1. Figura 1 - Un Web service permette l'accesso ad applicazioni usando tecnologie standard 1.2 Caratteristiche dei Web services Il successo dei Web services dipende dai seguenti fattori: Sono basati su XML: il ricorso a tale formalismo, per la rappresentazione dei dati per tutti i protocolli e le tecnologie dei Web services, permette di raggiungere la più completa indipendenza dal linguaggio di programmazione e dalla piattaforma utilizzata. Hanno basso accoppiamento (coupling): l utente non è legato in modo diretto ad un determinato Web service. L'interfaccia del servizio potrebbe cambiare leggermente senza che la capacità dell'utente di interagire con esso ne sia compromessa. Sono a grana fine: tecnologie object-oriented come java espongono questi servizi attraverso metodi individuali. I Web services permettono di definire un modo naturale per avere servizi a grana fine che accedono alla business logic. 21

23 Possono essere sincroni o asincroni: nei contesti sincroni quando un cliente invoca un servizio si sospende, nell attesa della risposta da parte del servizio invocato. Nei contesti asincroni una volta effettuata la chiamata il cliente può proseguire la sua esecuzione senza attendere il completamento del servizio remoto. I contesti asincroni sono particolarmente adeguati quando l'elaborazione da parte del Web service è particolarmente onerosa e richiede tempo. Supportano chiamate stile RPC: i Web services permettono ad un cliente di invocare metodi su oggetti remoti facendo uso di un protocollo basato su XML (SOAP) Supportano lo scambio di documenti: con i Web services si possono rappresentare e scambiare in maniera uniforme anche documenti. I Web services, inoltre, lavorano ad un livello di astrazione tale da rendere possibile connettere ogni sistema operativo, piattaforma hardware, o linguaggio di programmazione. Figura 2 - Un semplice Web service Ci sono diverse alternative [6] per lo scambio di messaggi XML. Per esempio, si potrebbe usare XML Remote Procedure Calls (XML-RPC) o SOAP. Alternativamente, si potrebbe semplicemente usare HTTP GET/POST e passare documenti XML arbitrari (vedi Figura 3). 22

24 Figura 3 - Messaggistica XML per i Web services Ad aumentare le potenzialità dei Web services sono altre due proprietà di fondamentale importanza: Un Web service è self-describing. Se si pubblica un Web service, si dovrebbe pubblicare anche la sua interfaccia pubblica. L interfaccia pubblica, scritta in XML, viene utilizzata per identificare tutti i metodi pubblici, gli argomenti dei metodi e i valori di ritorno. Un Web service è discoverable. Se si crea un Web service, esiste un meccanismo relativamente semplice che permette la sua pubblicazione. Similmente, esiste un meccanismo semplice che permette, alle parti interessate, di cercare un servizio e localizzare la sua interfaccia pubblica. 1.3 Perché usare i Web services Tradizionalmente, le Web applications permettono un interazione tra un utente finale e un sito web. I Web services, invece, sono orientati ai servizi e permettono una comunicazione A2A (Application to Application) su Internet e una semplice accessibilità ad applicazioni e dispositivi eterogenei. Elenchiamo qui di seguito le maggiori ragioni tecniche [7] affinché si adottino i Web services in una Web application: 23

25 I Web services possono essere invocati attraverso meccanismi RPC basati su XML che possono attraversare i firewalls. Fornendo una soluzione basata su messaggi XML, i Web services sono cross-platform e cross-language. I Web services facilitano in modo notevole l integrazione di applicazioni, utilizzando un infrastruttura leggera che non influisce sulla scalabilità. I Web services permettono interoperabilità tra applicazioni eterogenee. 1.4 L architettura dei Web services Ci sono due modi per considerare l architettura di un Web service. Il primo è esaminare i ruoli individuali di ogni attore del Web service; il secondo è esaminare la pila dei protocolli di un Web service I ruoli in un Web service Ci sono tre ruoli principali all interno dell architettura di un Web service come è possibile evincere dalla Figura 4. Figura 4 - Modello operazionale dei Web services, visualizza ruoli e relazioni. Service provider: è il fornitore del servizio. Il service provider implementa il servizio e lo rende disponibile su Internet. Da una prospettiva business, questo 24

26 rappresenta il proprietario del servizio. Dal punto di vista architetturale, è la piattaforma che ospita l accesso al servizio. [50] Service requestor: è responsabile dell invocazione del servizio. Il service requestor localizza il Web service usando il service broker, invoca il servizio richiesto che viene eseguito dal service provider. Da una prospettiva business, è il cliente richiedente la soddisfazione di determinate funzioni. Da una prospettiva architetturale, questa è l applicazione che effettua la ricerca e invoca o inizializza un interazione con il servizio. [50] Service registry: è l elenco logicamente centralizzato dei servizi. Il registry fornisce un punto centrale dove gli sviluppatori possono pubblicare nuovi servizi e trovarne uno già esistente. Il registry, dunque, si comporta da intermediario (broker) per le società ed i loro servizi Stack dei protocolli di un Web service Un altro modo per considerare l architettura di un Web service è esaminare la pila di protocolli utilizzati dallo stesso. La pila, ancora in fase di evoluzione, possiede 5 strati principali ( Figura 5 - Pila concettuale dei Web services). Figura 5 - Pila concettuale dei Web services [7] 25

27 Network: i Web services devono essere accessibili tramite rete per essere invocati da un service requestor. I Web services che sono disponibili comunemente su Internet utilizzano a questo strato HTTP (standard de facto). Altri protocolli comunque sono supportati, inclusi SMTP e FTP. XML-Based Messaging: rappresenta l uso di XML come protocollo per lo scambio dei messaggi. Il protocollo scelto per lo scambio di messaggi XML è SOAP. SOAP è lo standard document-centric, utilizzato per avvolgere i messaggi e le chiamate di procedura remota usando XML. Il messaggio SOAP viene spedito come richiesta HTTP di tipo POST. Service Description: rappresenta lo strato responsabile della descrizione dell interfaccia pubblica di un Web service. Il Web Service Description Language (WSDL) è lo standard de facto, basato su XML, per la descrizione di un servizio. WSDL, oltre a garantire l interoperabilità, definisce l interfaccia e il modo in cui si interagisce con il servizio. Service Publication e Service Discovery: rappresenta lo strato responsabile della centralizzazione dei servizi fornendo le funzionalità di pubblicazione e ricerca di un servizio. Attualmente, lo standard utilizzato, basato su XML è Universal Description, Discovery e Integration (UDDI). Service Flow: descrive come comunicazioni service-to-service, collaborazioni e flussi sono eseguiti. Web service Flow Language (WSFL) è usato per descrivere queste interazioni. 1.5 Tecnologie dei Web services In questo paragrafo si analizzeranno nel dettaglio le tecnologie essenziali utilizzate dalle principali piattaforme di Web services. Le tecnologie che verranno descritte sono gli standard affermati e le fondamenta stessi dei Web services. 26

28 1.5.1 SOAP: il fulcro dell interoperabilità SOAP [8] (Simple Object Access Protocol) è un metodo di trasporto basato su XML e progettato per lo scambio di informazioni in ambiente distribuito. SOAP utilizza protocolli di trasporto di livello inferiore, come HTTP. I messaggi SOAP, in realtà possono essere trasmessi con tecniche differenti, tra cui il protocollo SMTP. Bisogna sottolineare il fatto che SOAP definisce un protocollo privo di stato (stateless): quindi non è necessario mantenere una sessione, dato che gli elementi di stato sono contenuti nel messaggio stesso Cosa definisce SOAP SOAP definisce il modo in cui il messaggio XML è strutturato, le convenzioni che rappresentano una RPC (Remote Procedure Call) nel messaggio XML, il binding al protocollo HTTP per assicurare che il messaggio XML venga trasportato in modo corretto e infine definisce le convenzioni per restituire un errore al mittente del messaggio. SOAP non definisce semantiche per i dati e le chiamate, ma fornisce agli sviluppatori i mezzi per farlo (attraverso i Namespaces XML ). Quello che definisce, invece, sono le regole fondamentali per processare un messaggio, rimanendo completamente indipendente dal protocollo di trasporto utilizzato La struttura di un messaggio SOAP La struttura dei messaggi definisce gli elementi XML di base che occorrono per costruire le richieste SOAP. 27

29 Figura 6 - Struttura del messaggio SOAP Un messaggio SOAP [9] è un documento XML ben formato che contiene un elemento Envelope, un elemento opzionale Header e un elemento body obbligatorio, come visualizzato in figura 6. L elemento envelope serve come contenitore per il body e l header e anche come indicatore ad evidenziare che si tratta di un messaggio SOAP. Il tag </Envelope> indica che l elaborazione può iniziare (o eventuali allegati) poiché tutte le informazioni sono state raccolte. L envelope, essenzialmente, è solo una struttura di impacchettamento. L elemento header è opzionale, ma se presente, dovrebbe essere il primo elemento da considerare. Questo contiene informazioni aggiuntive, per esempio relative all autenticazione, all instradamento o all identificativo di transazione. SOAP non definisce nessuna entry nel blocco header, quindi è possibile aggiungere altre funzionalità. L header potrebbe contenere meta-data che aiutano a descrivere il contenuto principale di un messaggio SOAP, 28

30 informazioni su come indirizzare il messaggio a indirizzi differenti, sicurezza e cosi via. Il body, obbligatorio, contiene le informazioni principali per il destinatario del messaggio. Le informazioni possono essere elementi XML che descrivono l invocazione di una procedura per esempio, descrivendo argomenti e parametri insieme al nome della procedura oppure altro contenuto XML, come un ordine di acquisto. Queste due tecniche sono genericamente chiamate messaggistica SOAP RPC-style e document-style, rispettivamente. Il body può, infine, contenere un blocco speciale fault che indica errori a livello di protocollo. Le regole che definiscono come un particolare messaggio SOAP è spedito su un particolare protocollo di trasporto prendono il nome di SOAP binding al particolare protocollo SOAP con allegati E possibile aggiungere ad un messaggio SOAP un allegato [10]. Questo è reso possibile grazie ad un binding speciale che si serve della codifica MIME multipart/related anziché di text/xml. La codifica multipart/related frammenta il contenuto della richiesta HTTP in parti differenti: per convenzione, la prima parte contiene l envelope SOAP ed è di tipo text/xml. Questa soluzione è interessante poiché lascia del tutto intatto il documento SOAP: in effetti, quest ultimo è del tutto ignaro del binding a parti multiple Descrivere i Web services: WSDL Il Web Service Description Language (WSDL) [11], basato su XML, fornisce il meccanismo attraverso il quale le definizioni dei Web services sono rese pubbliche. WSDL non si limita alla semplice descrizione delle procedure d impiego di un servizio, ma va oltre definendo anche il protocollo di trasporto. WSDL consente ai Service Providers di fornire il modo in cui le richieste, da inoltrare ai Web services, dovranno essere definite. In un documento WSDL si specificano la locazione fisica e le operazioni disponibili 29

31 per il servizio descritto. Si ha una descrizione astratta che comprende i tipi, i messaggi e le operazioni; si ha inoltre una descrizione concreta che dipende dal binding e dalla posizione in cui si trova il servizio (figura 7). Figura 7 - Rappresentazione concettuale del documento WSDL I principali tags XML che compongono una descrizione WSDL sono: <types>: all'interno di questo elemento vengono definiti i tipi di dato complessi utilizzati dal Web service, servendosi della stessa sintassi degli schemi XML. <message>: serve ad indicare quali sono le parti di cui è composto un messaggio. Le parti hanno lo stesso ruolo dei parametri delle funzioni. <porttype>: raggruppa le operations disponibili per il Web service, elencando per ognuna quali messages ne fanno parte. Il porttype può 30

32 essere visto come una libreria di funzioni (nei linguaggi imperativi) o come una classe (nei linguaggi ad oggetti). <binding>: raggruppa un insieme di operations e gli assegna un tipo di binding (che indica un porttype). <operation>: specifica quali sono i messages di input e di output per la funzione che rappresenta. <service>: raccoglie tutte le ports del Web service <port>: rappresenta una singola implementazione del Web service: contiene un binding e un indirizzo di rete (al quale le richieste verranno inviate) Ricerca e pubblicazione dei Web services Una volta creata la descrizione di un Web service, rimane il problema di come far giungere agli utenti questa descrizione. Tipicamente, si agisce in tre direzioni: Direct publication: il Service Provider invia direttamente al client il documento WSDL che descrive il Web service. Static discovery: il Client possiede la descrizione WSDL ottenuta per direct publication, e la rende disponibile ad un'applicazione a tempo di esecuzione. Dynamic discovery: Il Client può venire a conoscenza del Web service anche a tempo di esecuzione, tramite un registro UDDI. UDDI (Universal Description Discovery and Integration) [12] è un directory service, dove le aziende possono registrare i propri Web services e cercarne altri. Un registro UDDI contiene informazioni riguardanti un insieme di Web services, tra le quali anche la loro descrizione WSDL, e i dati in esso contenuti sono accessibili tramite SOAP. UDDI è stato proposto per fornire uno standard che mettesse in comunicazione le aziende con i clienti e i partners fornendo informazioni riguardanti i propri prodotti e servizi. 31

33 Esso è pensato per fornire tre tipi di servizi: le pagine bianche, comprendono le informazioni di base sui contatti dell'azienda (ragione sociale, indirizzo, codice DUNS (Data Universal Numbering System)); le pagine gialle, comprendono le informazioni sui servizi Web in base alle loro categorie, per consentire, a chi esegue ricerche, di localizzare un certo tipo di servizio (ad esempio produttori di automobili); le pagine verdi, infine, comprendono informazioni tecniche sulle funzioni supportate dal servizio Web ospitato dall'azienda (riferimento alle descrizioni dei Web services, localizzazione). 32

34 2. Sviluppo di Web services usando Java Come si è potuto constatare (vedi capitolo 1), invocare un Web service significa inviargli un messaggio SOAP contenente una richiesta di esecuzione di un'operazione e i dati di input necessari. Quello che il Web service ritornerà sarà un altro messaggio SOAP, contenente il risultato dell'operazione richiesta. SOAP non definisce un binding ad uno specifico linguaggio di programmazione: è compito del progettista scegliere un linguaggio e definirne l implementazione. In questo contesto [13], usare Java come linguaggio di programmazione per sviluppare applicazioni SOAP richiede l implementazione Java [14] per SOAP del binding specifico. Allo stato attuale, ci sono molti venditori di applicazioni SOAP che hanno dato vita ad implementazioni di SOAP basate su Java per sviluppare da applicazioni Web a Web services. In generale, l uso di Java per lo sviluppo di applicazioni SOAP rende scalabile e portabile le applicazioni che si vogliono costruire e possono, inoltre, interoperare con applicazioni eterogenee residenti su piattaforme diverse risolvendo problemi di incompatibilità. Inoltre, avere applicazioni basate su SOAP che adottano un infrastruttura basata su J2EE [15], permette di ereditare le caratteristiche dei containers come transazioni, sicurezza, connettività a back-end. Una lunga lista di comunità open source e fornitori di piattaforme basate su Web services hanno realizzato implementazioni SOAP adottando la piattaforma Java e le API che mette a disposizione. Tra queste ha avuto un notevole successo l implementazione di SOAP per Java fornita dall'apache Group denominata Axis (Apache extensible Interaction System). 2.1 Apache Axis Axis [16], un toolkit per il deploying e l uso di Web services, permette agli sviluppatori di integrare servizi Web all interno delle loro applicazioni senza la necessità di imparare SOAP o altri protocolli Internet a basso livello. Axis non è un semplice engine SOAP, ma un framework per realizzare sistemi di 33

35 integrazione (clients, servers, gateways, etc.) basati su SOAP [17]. Il progetto non è una revisione della precedente versione del toolkit, Apache SOAP 2.2, ma una completa riscrittura che nasce dalla necessità di migliorare le prestazioni e supportare un varietà più ampia di protocolli. Axis include [18]: Un semplice stand-alone server, Un server che si inserisce all interno di un servlet engines come Tomcat, Supporto esteso per il Web service Description Language (WSDL) Un tool per la generazione di classi Java a partire da un documento WSDL e viceversa, Un tool per i monitorare pacchetti TCP/IP Caratteristiche principali di Axis Uno dei tools più interessanti che mette a disposizione Axis [19] è WSDL2Java. WSDL2Java può generare sia il codice degli stubs per il client che per il server; inoltre genera anche i beans per modellare i dati del modello definito dagli XML-Schema. WSDL2Java popolerà poi automaticamente questi beans a partire dalle informazioni in formato XML. Questo processo in generale è chiamato data binding. Per la validazione dei documenti XML occorre un parser XML. Per interagire con un parser, Axis [20] si serve delle API JAXP [21]. Quindi si dà la possibilità di sceglierne uno qualsiasi tra quelli compatibili 5 con JAXP. Un altro strumento che mette a disposizione Axis è Java2WSDL: a partire da una classe java che rappresenta il Web service genera il documento WSDL di descrizione del servizio. 5 Nello sviluppo del lavoro, per coerenza con il progetto Apache XML, verrà scelto il parser Xerces2 [49]. 34

36 2.1.2 Funzionalità e vantaggi di Axis Vengono di seguito elencate le funzionalità e i vantaggi [18] nell utilizzo di Axis: Velocità: il meccanismo di parsing utilizzato nell implementazione di Apache SOAP era basato su DOM (Document Object Model), il quale impiega più tempo rispetto ad un parser basato su SAX (Simple API for XML). Infatti, Axis usa SAX, un parser basato sugli eventi che opera più a basso livello e permette di ottenere alte prestazioni. Flessibilità: Axis fornisce funzionalità per facilitare l inserimento di nuove estensioni nell engine che consentono di personalizzare l elaborazione dell header e la gestione del sistema. Axis fornisce un deployment descriptor per descrivere le vari componenti come i servizi, gli oggetti handler, i serializzatori e i deserializzatori e così via. Il deployment descriptor (WSDD) è usato per eseguire il deployment di un Web service. Deployment orientato alle componenti: Axis presenta il concetto di handlers per implementare patterns comuni di elaborazione per le applicazioni. Un handler, un oggetto capace di processare un messaggio, è il responsabile delle elaborazioni specifiche associate al flusso di input, output e fault. Stabilità: Axis definisce una serie di interfacce stabili, che facilitano la migrazione verso nuove versioni Axis. Framework di trasporto: Axis, come anticipato, offre un framework di trasporto fornendo senders e listeners per SOAP sopra vari protocolli come SMTP, FTP, etc L architettura di Axis Axis gioca un ruolo fondamentale sia sul lato client del Web service (colui che utilizza il servizio) che sul lato server (colui che fornisce il servizio). Verranno analizzati entrambi gli aspetti architetturali [22] mettendo in rilievo le componenti che formano il nucleo di Axis e della comunicazione. Molto semplicemente, Axis è tutto ciò che riguarda l elaborazione dei messaggi. 35

37 Durante l elaborazione dei messaggi vengono eseguiti una serie di Handlers invocate in un ordine che varia a secondo della configurazione del deployment e della posizione dell Engine (client o server). L elaborazione di un servizio SOAP è fatta passando un context message ad ogni componente. Un context message è una struttura che contiene un request message, un response message e una lista di proprietà (attributi dell header SOAP). Prima di analizzare il funzionamento dell architettura definiamo quelli che sono i concetti chiave di Axis: Le Handler [23] sono utili ai fini del processamento dei messaggi; un handler potrebbe spedire una richiesta e ricevere una risposta oppure processare una richiesta e produrre una risposta. Un Handler può appartenere a tre famiglie: transport-specific, service-specific o global. Le Handlers di ciascuna famiglia sono combinate in Chains. Quindi la sequenza complessiva di Handlers comprende tre tipi di Chains: transport, global e service. Si è detto che Axis interviene in due modi: quando viene invocato come server e quando viene invocato come client. Il cammino del Message sul server: come visualizzato in Figura 8 elenchiamo i passi principali. 36

38 Figura 8 - Il cammino del Message sul Server. I cilindri piccoli rappresentano le handlers, quelli grandi, invece, rappresentano le chains. Un request message è spedito al nodo di elaborazione del messaggio del transport listener. Il transport listener converte il messaggio in entrata in un oggetto Message e lo incapsula in un oggetto MessageContext. Successivamente il transport listener carica varie proprietà specificate come attributi di SOAP (Es: l action header di SOAP) e imposta il tipo di trasporto come proprietà sul MessageContext. Il tipo di trasporto, come evidenziato, può essere HTTP, SMTP o FTP. Una volta che il MessagceContext è inizzializzato viene passato all AxisEngine. Dopo che l AxisEngine ha individuato il tipo di trasporto, viene invocata la request Chain del Transport (vedi figura 8), se questa esiste, passandogli il MessageContext. L Engine, a questo punto, localizza una global request Chain e invoca gli Handlers specificati; dopodichè alcuni Handlers impostano il campo servicehandler del MessageContext Il campo servicehandler indicherà l handler da invocare per eseguire il servizio richiesto (Es: RPC). I Services oltre a contenere una request Chain e una response Chain, contengono anche un Provider, un Handler responsabile dell implementazione della logica del back end del servizio. Nel caso di richieste RPC il Provider invoca l oggetto della classe specificata nel file di deploy. 37