Global Weather Web Service - A.A. 2007-2008
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
Corso di Laurea Specialistica in Informatica
Global Weather
Web Service
Giuseppe Specchio Matr.0120444 A.A. 2007-2008
1/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
Premessa
La presente documentazione viene redatta come progetto conclusivo del corso di Laboratorio di
Sistemi Distribuiti del corso di Laurea Specialistica in Informatica dell'Università di Roma – Tor
Vergata, svolto nell'a.a.2007-2008.
Sulla base di tali premesse è stata sviluppata una Web Application basata su tecnologie Web Service
denominata Global Weather , la quale, come si può intuire dal nominativo scelto, fornisce le
previsioni meteorologiche di una data città, previa selezione della nazione di appartenenza, i cui
valori delle misure rilevate vengono appositamente convertite da MP/H a KM/H.
Al fine di meglio strutturare la documentazione di tale applicazione, si è deciso di strutturare
l'argomentazione nei seguenti capitoli:
● Capitolo 1 : introduzione al concetto di architettura orientata ai servizi (SOA);
● Capitolo 2 : presentazione del modello Web Service, quale implementazione di un modello
SOA su rete Internet;
● Capitolo 3 : presentazione delle tecnologie utilizzate per l'implementazione del Web Service
Global Weather;
● Capitolo 4 : documentazione UML dell'applicazione Global Weather.
2/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
Indice generale
Premessa............................................................................................................................................... 2
Introduzione..........................................................................................................................................5
1SOA: Service-Oriented Architecture.................................................................................................. 8
1.1Introduzione................................................................................................................................ 8
1.2Caratteristiche di una SOA......................................................................................................... 8
1.3Come funziona una SOA............................................................................................................ 9
2I Web Service....................................................................................................................................11
2.1Introduzione.............................................................................................................................. 11
2.2Scenari Complessi.....................................................................................................................12
2.3Tecnologie.................................................................................................................................13
2.4XML..........................................................................................................................................14
2.4.1Struttura di un documento XML....................................................................................... 14
2.4.2DTD: Document Type Definition......................................................................................16
2.4.3XML Schema.................................................................................................................... 16
2.4.4Namespece XML.............................................................................................................. 16
2.4.5Lavorare con i documenti XML........................................................................................17
2.4.5.1Elaborazione tramite SAX.........................................................................................17
2.4.5.2Elaborazione tramite DOM....................................................................................... 18
2.5Il protocollo SOAP................................................................................................................... 20
2.5.1Il messaggio SOAP e modelli di scambio.........................................................................21
2.5.2Utilizzo dell’intestazione.................................................................................................. 23
2.5.3Gestione degli Errori......................................................................................................... 23
2.5.4SOAP su HTTP................................................................................................................. 24
2.5.5SOAP e RPC..................................................................................................................... 25
2.5.6SOAP Encoding................................................................................................................ 26
2.5.7SOAP con Allegati............................................................................................................ 27
2.5.8SOAP e Java......................................................................................................................29
2.6Il linguaggio WSDL..................................................................................................................29
2.6.1L'elemento Type................................................................................................................ 32
2.6.2L'elemento Message.......................................................................................................... 33
2.6.3L'elemento PortType......................................................................................................... 34
2.6.4L'elemento Binding........................................................................................................... 35
2.6.5L'elemento Service............................................................................................................ 37
2.7Il protocollo UDDI....................................................................................................................43
2.7.1Il contesto architetturale di UDDI.....................................................................................44
2.7.1.1I ruoli in UDDI.......................................................................................................... 44
2.7.1.2Il registro UDDI........................................................................................................ 44
2.7.2Rappresentazione delle informazioni in UDDI.................................................................44
2.7.2.1Struttura di UDDI...................................................................................................... 45
2.7.2.2Interazioni con UDDI................................................................................................ 47
2.7.2.3Esempio..................................................................................................................... 48
2.8Tecnologie per Web Services di seconda generazione..............................................................51
3Web Services : tecnologie.................................................................................................................53
3.1Introduzione.............................................................................................................................. 53
3.2Java........................................................................................................................................... 53
3.3TomCat......................................................................................................................................53
3.4Axis........................................................................................................................................... 53
3.4.1L'architettura di Axis......................................................................................................... 54
3.4.2Installazione di AXIS........................................................................................................ 56
3.4.3Deployment di Web Service su Axis.................................................................................57
3.4.4Strumenti per il monitoraggio delle comunicazioni..........................................................62
3.5MySQL..................................................................................................................................... 65
3/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
3.6jUDDI....................................................................................................................................... 65
3.6.1Installazione di jUDDI...................................................................................................... 65
3.7UDDI4J..................................................................................................................................... 71
3.7.1Installazione di UDDI4J....................................................................................................72
3.8Tecniche di invocazione di Web Service.................................................................................. 72
3.8.1Stub creato da WSDL........................................................................................................72
3.8.2Dynamic Proxy................................................................................................................. 73
3.8.3Dynamic Invocation Interface (DII)................................................................................. 74
3.8.4Dynamic Discovery and Invocation (DDI)....................................................................... 76
4Global Weather Web Service............................................................................................................ 79
4.1Introduzione.............................................................................................................................. 79
4.2Il Workflow............................................................................................................................... 80
4.3 Class Diagram..........................................................................................................................87
4.3.1Class Diagram del presentation layer................................................................................87
4.3.2Class Diagram della business logic...................................................................................90
4.3.3Class Diagram del meteo fornito dal Web Service fittizio................................................ 93
4.3.4Class Diagram del Web Service di conversione................................................................95
4.4Use Cases.................................................................................................................................. 98
4.4.1Use Case Scelta Nazione...................................................................................................98
4.4.2Use Case Scelta Città........................................................................................................ 98
4.4.3Use Case Previsioni Meteorologiche................................................................................ 99
4.5Sequence Diagram.................................................................................................................. 100
4.5.1Sequence Diagram per la richiesta dell'elenco città........................................................100
4.5.2Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in MPH. .101
4.5.3Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in KMH. 102
5Bigliogragia.................................................................................................................................... 103
4/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
Introduzione
Spiegare cosa sia il “Web 2.0”, ovvero cosa si nasconda dietro tale termine, è cosa veramente
ardua,. Questo perché oggi siamo di fronte più ad un cambiamento culturale che ad un'innovazione
tecnologica vera e propria come era stata Internet anni fa, possiamo dire oramai nella versione 1.0,
ovvero nell'oramai ex epoca della new economy, e sopratutto perché in linea di massima noi
informatici diventiamo matti quando una cosa è eterna e soprattutto siamo caratterizzati dal naturale
istinto di incatenare una definizione ad espressioni logiche (1.0, 1.03, 2.0beta, e così via).
Ad onor del merito, la paternità del termine è da attribuire a Tim O'Reilly, il quale coniò il termine,
verso la metà del 2004, durante una sessione di brainstorming volta a definire il tema di una nuova
conferenza sul Web.
In un primo momento l'idea di Tim O'Reilly fu oggetto di un aspro dibattito, sui primi WebLog del
tempo, tanto da far nascere una querelle tra lui e Tim Bray, inventore dell'XML, il quale in un suo
post intitolato “NOT 2.0”, ha dichiarato che l'espressione Web 2.0 era riconducibile a una vuota
operazione di marketing che richiamava i fantasmi della bolla.
Da quel momento, il termine new economy venne definitivamente sepolto e sostituito dal nuovo
slogan “Web 2.0”, il cui significato possiamo trovarlo anche su Wikipedia1, quale massimo
rappresentante della tecnologia proposta:
“Web 2.0 è un termine coniato da Tim O'Reilly e Dale Dougherty (della O'relly Media, casa editrice
americana specializzata in pubblicazioni riguardanti le nuove tecnologie ed Internet in particolare)
nel 2004 e fa riferimento ai cosiddetti servizi Internet di seconda generazione quali siti di social
networking, wiki2, strumenti di comunicazione e folksonomy3 che enfatizzano la collaborazione e la
condivisione tra utenti”
Tale definizione, ovviamente non è da considerarsi di carattere esaustivo, soprattuto poiché
Wikipedia, come tutti i servizi basati sui contenuti liberamente generati dagli utenti nel Web 2.0, ha
il problema della fondamentale, ovvero “l'anarchia dei contributi”, potenzialmente a scapito di
1 http://en.wikipedia.org/wiki/Web_2.0
2 Un wiki è un sito Web gestito da un sistema che permette a ciascuno dei suoi utilizzatori di aggiungere contenuti,
ma anche di modificare i contenuti esistenti inseriti da altri utilizzatori.
3 È un neologismo che descrive una categorizzazione collaborativa di informazioni mediante l'utilizzo di parole
chiave, dette tag, scelte liberamente.
5/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
qualità, etica e consapevolezza. Il Web 2.0 non è solo una nuova tecnologia o un nuovo insieme di
tecnologie e non è solo un cambiamento culturale di approccio alla Rete.
Tecnologia e società sono le vere basi del Web 2.0 che, con pieno titolo, può essere definito “un
movimento”. La componente tecnologica ha in sé anche la componente sociale in quanto nel Web
2.0 non ci si trova di fronte a nuove scoperte o nuove tecnologie ma piuttosto si assiste
all'affermazione e alla diffusione significativa nell'ambito delle comunità tecnologiche, di
sviluppatori e di architetti applicativi, di tecnologie che consentono di abilitare un utilizzo della
Rete incentrato sulla persona e sugli aspetti sociali (networking effect).
Sicuramente i tecnici più “conservatori” storceranno il naso nei confronti di tali affermazioni,
sicuramente affermeranno che:
● non siamo di fronte ad un'evoluzione tecnologica dei protocolli TCP/IP e ne tanto meno
protocolli come l'IPv64 sono ancora lontani dall'adozione di massa;
● il termine Web 2.0, può ritenersi limitativo in quanto, tecnologicamente parlando,
l'evoluzione va oltre i confini della Rete intesa come World Wide Web. L'affermazione di
servizi “oltre il Web” come per esempio VoIP5, il cui esempio più eclatante è il fenomeno
Skype, il podcasting, il Web Mobile e video e il fenomeno del peer to peer per file sharing,
suggeriscono che sarebbe più corretto definirlo “Internet 2.0”.
Le potenziali contestazioni che possono essere sollevate, vengono meno quando questi singoli
componenti tecnologici vengono gestiti dalla componente sociale, intesa come aspetto di
interazione sociale e il cambiamento di approccio il quale varia dalla consultazione, intesa come
ricerca clic, lettura di informazione su siti e portali, al contributo ed alla partecipazione sul Web
sono possibili solo grazie alla diffusione e adozione della tecnologia informatica su larga scala, vero
fattore abilitante della collaborazione tra utenti della condivisione di informazioni, dati e processi di
lavoro, sia a livello culturale che professionale.
Pertanto, volendo classificare e schematizzare le caratteristiche del Web 2.0 si può far riferimento a
quattro elementi principali, il cui sviluppo può essere considerato causa degli altri:
1. Technology. Ampia diffusione e utilizzo avanzato di tecnologie quali AJAX 6, API, Peer-to-
Peer, RSS7, XML e Web Service a supporto dell'utente che utilizza, plasma, modifica un
servizio bidirezionale, un'applicazione e non naviga semplicemente in un sito.
2. User Experience. L'utilizzo di tecnologie come AJAX consente di realizzare un'esperienza
utente nell'utilizzo delle applicazioni Web su Internet e di siti paragonabile a quella
dell'utilizzo di un'applicazione che gira sulla macchina locale.
4 Internet Protocol version 6, è un'evoluzione-rivoluzione dell'attuale protocollo IP alla base dello stack TCP/IP
comunemente usato. Esso introduce alcuni nuovi servizi e semplifica molto la configurazione e la gestione delle reti
IP. La sua caratteristica più appariscente è il più ampio spazio di indirizzamento: IPv6 gestisce fino a circa 3,4 × 10 38
indirizzi, mentre IPv4 gestisce soltanto fino a circa 4 miliardi (4 × 109) di indirizzi.
5 Voice over Internet Protocol, è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando
una connessione Internet o un'altra rete dedicata che utilizza il protocollo IP, anziché passare attraverso la rete
telefonica tradizionale (PSTN). Ciò consente di eliminare le relative centrali di commutazione e di economizzare
sulla larghezza di banda occupata. Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali,
codificati in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti collegati sta
parlando.
6 AJAX, acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo web per creare applicazioni web
interattive. L'intento di tale tecnica è quello di ottenere pagine web che rispondono in maniera più rapida, grazie allo
scambio in background di piccoli pacchetti di dati con il server, così che l'intera pagina web non debba essere
ricaricata ogni volta che l'utente effettua una modifica. Questa tecnica riesce, quindi, a migliorare l'interattività, la
velocità e l'usabilità di una pagina web.
7 RSS , acronimo di RDF Site Summary ed anche di Really Simple Syndication, è uno dei più popolari formati per la
distribuzione di contenuti Web; è basato su XML, da cui ha ereditato la semplicità, l'estensibilità e la flessibilità.
RSS definisce una struttura adatta a contenere un insieme di notizie, ciascuna delle quali sarà composta da vari campi
(nome autore, titolo, testo, riassunto, ...). Quando si pubblicano delle notizie in formato RSS, la struttura viene
aggiornata con i nuovi dati; visto che il formato è predefinito, un qualunque lettore RSS potrà presentare in una
maniera omogenea notizie provenienti dalle fonti più diverse.
6/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
3. Open (culture): Source, Application, Data, Content. Il fenomeno della condivisione,
supportato dalla tecnologia libera e gratuita, contagia tutto: dal codice al software, dai dati
alle applicazioni ai contenuti. Si affermano nuovi comportamenti di condivisione e
distribuzione libera attraverso la rete di ogni cosa sia dato, informazione, immagine, video o
software.
4. Social Network. Partecipazione e relazioni sociali. La tecnologia, la condivisione e
l'esperienza applicativa favoriscono lo sviluppo della partecipazione a una nuova vita di
community che crea sulla Rete nuove forme di intelligenza collettiva.
Il comun denominatore di questi quattro elementi, è rappresentato dalle persone, che ogni giorno
contribuiscono a diffondere tali tecnologie e comportamenti di massa, scrivendo codice, contenuti,
blog, creando e distribuendo foto, filmati, opinioni, commenti, inviti, ma soprattutto mixando questi
elementi in modi nuovi ed originali, creando innovazione tecnologica e sociale seguendo i propri
istinti e passioni.
Nei capitoli a seguire, concentreremo la nostra attenzione sul contesto tecnology, in particolar modo
sui web service, quale implementazione fisica di un Architettura Orientata ai Servizi (SOA) ,
fornendo in primis una loro descrizione di carattere teorico nel primo capitolo ed una loro
implementazione nel successivo capitolo 2, mediante la realizzazione del servizio anzi anticipato in
sede di premessa.
7/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
1 SOA: Service-Oriented Architecture
1.1 Introduzione
Una Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) è un modello
architetturale per la creazione di sistemi residenti su una rete che focalizza l’attenzione sul concetto
di servizio. Un sistema costruito seguendo la filosofia SOA è costituito da applicazioni, chiamate
servizi, ben definite ed indipendenti l’una dall’altra, che risiedono su più computer all’interno di
una rete (ad esempio la rete interna di una azienda o una rete di connessione fra più aziende che
collaborano: intracompany o intercompany network). Ogni servizio mette a disposizione una certa
funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando, in questo
modo, applicazioni di maggiore complessità.
SOA è una forma particolare di Distributed System, la cui definizione è la seguente:
Un Distributed System (Sistema distribuito) consiste di vari agenti software distinti che devono
lavorare insieme per svolgere alcuni compiti. Inoltre, gli agenti in un sistema distribuito non
operano nello stesso ambiente di calcolo, quindi devono comunicare per mezzo di stack di
protocolli hardware/software su una rete.
Questo significa che le comunicazioni in un sistema distribuito sono intrinsecamente meno veloci e
affidabili rispetto a quelle che utilizzano invocazione diretta del codice e memoria condivisa. Ciò ha
importanti implicazioni architetturali perché i sistemi distribuiti richiedono che gli sviluppatori (di
infrastruttura e applicazioni) considerino la latenza, fattore imprevedibile dell’accesso remoto, e
tengano presente questioni relative alla concorrenza e la possibilità di fallimenti parziali.
1.2 Caratteristiche di una SOA
L’astrazione delle SOA non è legata ad alcuna specifica tecnologia, ma semplicemente definisce
alcune proprietà, orientate al riutilizzo e all’integrazione in un ambiente eterogeneo, che devono
essere rispettate dai servizi che compongono il sistema. In particolare un servizio dovrà:
● essere ricercabile e recuperabile dinamicamente. Un servizio deve poter essere ricercato in
base alla sua interfaccia e richiamato a tempo di esecuzione. La definizione del servizio in
base alla sua interfaccia rende quest’ultima (e quindi l’interazione con altri servizi)
indipendente dal modo in cui è stato realizzato il componente che lo implementa.
● essere autocontenuto e modulare. Ogni servizio deve essere ben definito, completo ed
indipendente dal contesto o dallo stato di altri servizi.
● essere definito da un’interfaccia ed indipendente dall’implementazione. Deve cioè essere
definito in termini di ciò che fa, astraendo dai metodi e dalle tecnologie utilizzate per
implementarlo. Questo determina l’indipendenza del servizio non solo dal linguaggio di
programmazione utilizzato per realizzare il componente che lo implementa ma anche dalla
piattaforma e dal sistema operativo su cui è in esecuzione: non è necessario conoscere come
un servizio è realizzato ma solo quali funzionalità rende disponibili.
● essere debolmente accoppiato con altri servizi (loosely coupled). Un’architettura è
debolmente accoppiata se le dipendenze fra le sue componenti sono in numero limitato.
Questo rende il sistema flessibile e facilmente modificabile.
● essere reso disponibile sulla rete attraverso la pubblicazione della sua interfaccia (in un
Service Directory o Service Registry) ed accessibile in modo trasparente rispetto alla sua
allocazione. Essere disponibile sulla rete lo rende accessibile da quei componenti che ne
richiedono l’utilizzo e l’accesso deve avvenire in maniera indipendente rispetto
all’allocazione del servizio. La pubblicazione dell’interfaccia deve rendere noto anche le
modalità di accesso al servizio.
● fornire un’interfaccia possibilmente a “grana grossa” (coarse-grained). Deve mettere a
8/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
disposizione un basso numero di operazioni, cioè poche funzionalità, in modo tale da non
dover avere un programma di controllo complesso. Deve essere invece orientato ad un
elevato livello di interazione con gli altri servizi attraverso lo scambio di messaggi. Per
questo motivo e per il fatto che i servizi possono trovarsi su sistemi operativi e piattaforme
diverse è necessario che i messaggi siano composti utilizzando un formato standard
largamente riconosciuto (Platform Neutral). I dati che vengono trasmessi attraverso i
messaggi possono essere costituiti sia dal risultato dell’elaborazione di un certo servizio sia
da informazioni che più servizi si scambiano per coordinarsi fra loro.
● essere realizzato in modo tale da permetterne la composizione con altri. Nell’architettura
SOA le applicazioni sono il risultato della composizione di più servizi. È per questo motivo
che ogni servizio deve essere indipendente da qualsiasi altro, in modo tale da ottenere il
massimo della riusabilità. La creazione di applicazioni o di servizi più complessi attraverso
la composizione dei servizi di base viene definita Service Orchestration.
Queste dunque le caratteristiche di un sistema di tipo SOA, di cui adesso passiamo a descrivere il
funzionamento.
1.3 Come funziona una SOA
Gli attori di un sistema SOA sono tre:
● Service Provider
● Service Consumer
● Service Registry.
Il Service Provider è un’entità che mette a disposizione un qualche servizio. Tale servizio, per poter
essere trovato da altre entità che vogliono utilizzarlo, deve essere reso visibile sulla rete, in termine
tecnico Pubblicato. A tal fine il Service Provider comunica al Service Registry le informazioni
relative al servizio, perché vengano memorizzate. Il Service Registry possiede quindi le
informazioni, come URL e modalità di accesso, di tutti i servizi disponibili.
Nel momento in cui un Service Consumer dovrà utilizzare un servizio farà richiesta delle
informazioni ad esso relative al Service Registry. Con queste informazioni il Service Consumer
potrà comunicare direttamente con il Service Provider ed utilizzare il servizio.
In figura sono riportate le interazioni fra le entità appena descritte.
Illustrazione 1.1: Esempio di Architettura SOA.
Tutte queste interazioni passano attraverso quella che in figura viene genericamente definita Rete di
Comunicazione, la quale in un’implementazione reale di una SOA può essere costituita sia da
Internet sia da una intranet.
9/99
Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
SOA definisce, dunque, le caratteristiche che i componenti facenti parte di un sistema devono avere
al fine di poter definire quest’ultimo un’architettura orientata ai servizi.
Dopo aver descritto cos’è l’architettura SOA ed il funzionamento di un sistema di questo tipo,
vediamo adesso cosa sono i Web Services, quali tecnologie utilizzano ed il loro legame con SOA.
10/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
2 I Web Service
2.1 Introduzione
Promossi da società del calibro di Microsoft ed IBM, i servizi Web promettono di far integrare
sistemi software in modo standard sulla rete, mediante l'impiego di protocolli e tecnologie concrete
come SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) ed
UDDI (Universal Description, Discovery and Integration).
I Web Service sono soluzioni adottabili in contesti:
● Enterprise Application Integration8 (EAI)
● Business-to-Business9 (B2B)
● Business-to-Customer10 (B2C)
Tale tecnologia è stata adottata in maniera ufficiale W3C 11 intorno al Dicembre del 2001, il quale ha
formalizzato l'architettura con la seguente definizione:
“Un Web Service (o servizio web) è un sistema software progettato per supportare l’interoperabilità
tra diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è
quella di offrire un’interfaccia software attraverso la quale altri sistemi possono interagire con il
Web Service stesso tramite appositi messaggi: tali messaggi sono inviati tramite i protocolli di
livello applicativo (HTTP, FTP, SMTP ...) e formattati secondo lo standard XML.”
Illustrazione 2.1: Servizi Web: XML e
protocolli Internet
Sulla base di tali premesse, possiamo quindi affermare che la disponibilità di questi elementi sulla
rete, consente potenzialmente a chiunque di interagire con componenti software offerti dalle singole
aziende.
Uno scenario possibile potrebbe essere quello trattato nel capitolo successivo, nel quale si
costruisce una Web Application sfruttando Web Service forniti da altre società delle quali alcune
comunicano l'elenco delle città di una data nazione, altre invece forniscono le previsioni meteo di
una città della nazione prescelta ed infine altre società forniscono un servizio di conversione di unità
di misura, come quello da MPH a KMH. Tutte queste informazioni vengono gestite in backend dal
nostro sistema al fine di completare l’accettazione e l’evasione della richiesta di previsioni meteo,
ovviamente, se uno dei servizi non fosse disponibile, la logica di back-end potrebbe ritentare
l’operazione chiamando il medesimo servizio implementato da un altro fornitore, garantendo così
un buon livello di fault-tolerance.
8 Enterprice Application Integration : a differenza dei normali middleware che integrano i server che si trovano nello
strato delle risorse, l’ EAI è una generalizzazione di questo funzionamento, in quanto, integra le logiche applicative
di sistemi middleware.
9 Business-to-Business : insiemi di transazioni che avvengono tra ditte o società per il raggiungimento di un
determinato obiettivo di business. Generalmente in questo contesto vengono realizzate applicazioni le quali spesso
non hanno necessità di una vera e propria interfaccia, la quale se esiste risulta essere prevalentemente di tipo
testuale. Tali tipi di applicazioni sono orientate all'utilizzo da parte di sistemi automatizzati.
10 Business-to-Customer : insiemi di transazioni che avvengono tra ditte o società ed il loro clienti. Generalmente in
questo contesto vengono realizzate applicazioni ad interfaccia grafica, orientate all'utilizzo da parte di essere umani.
11 http://www.w3.org/
11/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
2.2 Scenari Complessi
I possibili scenari possono avere complessità diverse, a partire da quelli più banali, anche oggi
realizzabili, fino ad arrivare alle ipotesi più fantasiose, dove i flussi di lavoro non sono altro che
aggregazioni di singole componenti realizzate da servizi Web.
Nelle ipotesi più elaborate, i singoli sistemi software dovrebbero essere in grado di ricercare i
servizi all’interno di appositi registri mondiali, che si dovrebbero occupare di realizzare il punto di
incontro tra cliente e fornitore.
Riprendendo l’esempio precedente, l’applicazione potrebbe utilizzare i registri di servizi Web per
individuare tutti i potenziali fornitori di un tipo di servizio. Ad esempio, l’applicazione potrebbe
aver bisogno di ottenere l'elenco delle città di una data nazione, ma non sapere chi fornisce questa
tipologia di servizio. A questo punto l’applicazione può:
1. accedere ad uno o più registri;
2. localizzare il servizio richiesto;
3. scaricare le informazioni tecniche che consentono la sua chiamata;
4. ingaggiare il servizio.
S e r v ic e R e g is tr y
S c o p re W S D L U D D I R e g is t r y R e g is t r a W S D L
S e r v ic e C o n s u m e r S e r v ic e P r o v id e r
SO AP
C o d ic e Im p l
A p p lic a t P ro x y
S e r v ic e C o n tr a c t
Illustrazione 2.2: Workflow operativo che coinvolge registridi servizi Web
Inoltre, le componenti ingaggiate potrebbero essere molteplici, in modo da costituire un workflow
complesso di singoli elementi dallo scopo limitato e ben definito. Come un algoritmo svolge il suo
lavoro chiamando le singole routine e gestendo opportunamente i valori di ritorno per implementare
la logica richiesta, un workflow di servizi Web compone, anche in modo dinamico, singoli Web
Services in modo da ottenere la funzionalità richiesta.
Essendo per loro natura distribuiti, nelle tecnologie orientate ai servizi Web assumono una grande
importanza le problematiche classiche presenti nella programmazione distribuita classica, dove
giocano un ruolo determinante tecnologie come CORBA (Common Object Request Broker
Architecture) e RMI (Remote Method Invocation), ma anche RPC (Remote Procedure Call) e
DCOM (Distributed Component Object Model). I servizi web hanno però una serie di sostanziali
differenze rispetto alle altre tecnologie distribuite: utilizzano un protocollo testuale (XML) al posto
di quello binario costruito ad hoc, sfruttano le infrastrutture applicative già presenti di Internet
(HTTP, FTP, SMTP), non hanno ancora però prodotti e tecnologie così definiti come i loro
concorrenti di più lunga data.
Particolare rilevanza ha in quest’ambito la gestione delle transazioni: si ipotizzi che la richiesta
dell'elenco delle città di una data nazione non vada a buon fine, il sistema deve evitare lo stallo dei
flussi informativi, gestendo eventualmente anche un roll-back distribuito delle varie richieste
effettuate ai diversi fornitori di servizi.
12/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
2.3 Tecnologie
La visione dei Web Service è supportata da una serie di tecnologie sviluppate in fase iniziale dalle
maggiori aziende del settore, talvolta come membri di un consorzio.
Alcune tecnologie sono comunemente accettate, altre sono più conosciute, mentre altre ancora sono
proposte di singole aziende che non è chiaro se avranno successo in futuro.
Uno stack di tecnologie consolidato è presente nell'illustrazione 3.
Illustrazione 2.3: Pila concettuale dei Web Service
Di queste:
● Protocolli di Livello Applicativo. Il protocollo di trasporto preferito per lo scambio di
messaggi applicativi, ed il più utilizzato, è HTTP/HTTPS anche se sarebbe possibile
utilizzarne altri, come FTP e SMTP;
● XML. È un meta linguaggio utilizzato per creare nuovi linguaggi, atti a descrivere
documenti strutturati.
● SOAP. È il protocollo XML di scambio dei messaggi che consente la programmazione
distribuita dei servizi Web;
● WSDL. Consente di descrivere il servizio tramite un documento XML, in modo similare la
linguaggio IDL (Interface Description Language) di CORBA;
● UDDI. È un servizio di directory che consente agli utenti di localizzare i servizi Web.
2.4 XML
XML eXtensible Markup Language, è un linguaggio, indipendente dai sistemi e dall'hardware, che
permette di descrivere dei dati e la loro struttura all'interno di un documento XML, ovvero di un file
di testo UNICODE che contiene i dati e gli elementi di markup che definiscono la struttura dei dati
stessi.
Il markup XML assomiglia a quello del linguaggio HTML, in quanto consiste in un tag e attributi
aggiunti ai dati all'interno del file di testo. La somiglianza apparente tra XML e HTML si limita
comunque al loro aspetto superficiale: infatti XML e HTML sono profondamente differenti, sia per
il loro scopo sia che per la loro capacità.
Prima di tutto, sebbene un documento XML possa essere creato, letto e compreso da una persona, il
suo scopo primario consiste nella comunicazione di dati da un computer all'altro. Di conseguenza,
accade frequentemente che i documenti XML vengano generati ed elaborati da un programma e non
da un utente umano, anche se quest'ultimi sia in grado di farlo. Un documento XML definisce la
struttura dei dati contenuti al suo interno in modo che un programma che lo riceve sia in grado di
interpretarlo. È quindi possibile affermare che XML è uno strumento per trasferire informazioni e la
13/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
loro organizzazione da un programma all'altro. Lo scopo di HTML, dall'altra parte, consiste
essenzialmente nel fornire la descrizione di come i dati dovranno apparire quando vengono
visualizzati o stampati. Infatti le uniche informazioni strutturali che solitamente appaiono nei
documenti HTML sono relative all'aspetto dei dati dal punto di vista visivo.
In secondo luogo, HTML fornisce un insieme di tag essenzialmente prefissato e dedicato
principalmente alla presentazione dei dati, invece, XML è un linguaggio tramite il quale è possibile
definire nuovi insiemi di tag e attributi adatti a svariate tipologie di dati, anche di tipo
personalizzato.
Naturalmente, una volta inventato un insieme di elementi di markup XML adatti a descrivere un
tipo particolare di dato, sarà necessario rendere disponibile le regole per interpretare documenti
XML di quel tipo, in modo tale da poterli creare, leggere o modificare. La definizione di tali
elementi di markup utilizzati all'interno di un documento XML può essere inclusa direttamente
all'interno del documento, oppure sotto forma di un'entità separata come, ad esempio, un file
identificato da un URI, che possa essere referenziato all'interno di ogni documento di quel
particolare tipo.
Da un punto di vista implementativo, il linguaggio di programmazione Java, mette a disposizione
la libreria JAXP (Java API for XML Processing) la quale fornisce strumenti necessari per leggere,
creare e modificare documenti XML dall'interno dei nostri programmi. Per comprendere ed
utilizzare queste API, l'utente dovrebbe però acquisire una ragionevole familiarità oltre che con i
concetti fino ad ora esposti, anche il concetto di namespece XML, il quale verrà illustrato nel
paragrafo a seguire.
2.4.1 Struttura di un documento XML
Un documento XML può essere suddiviso in due porzioni, il prologo ed il corpo del documento
detto anche body.
Illustrazione
2.4: Struttura
logica di un file
XML
● il prologo fornisce le informazioni necessarie per interpretare il contenuto del corpo del
documento. Esso contiene due componenti opzionali: dato che entrambi possono essere
omessi, ne consegue che anche il prologo stesso è opzionale. Le due componenti del
prologo, nella sequenza in cui devono apparire sono:
○ una XML declaration che definisce la versione XML, applicabile al documento, e che
può inoltre specificare quale sia la particolare codifica UNICODE per i caratteri
utilizzata nel documento e se il documento stesso è di tipo standalone oppure no.
○ Una document type declaration che specifica quale sia la DTD 12 esterna che fornisce le
12 Document Type Definition : è un documento nel quale vengono definite le regole mediante le quali si assicura che i
vari dati vengano rappresentati in maniera consistente e corretta all'interno di documenti differenti.
14/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
dichiarazioni degli elementi di markup utilizzati nel corpo del documento, oppure
fornisce esplicitamente tali dichiarazioni, o infine che svolge entrambe le funzioni.
● Il body contiene i dati del documento stesso, costituito da uno o più elementi, ognuno dei
quali è definito da un tag d'inizio ed un tag di fine. Esiste sempre un singolo elemento root
che contiene tutti gli elementi.
Roma / Urbe, Italy (LIRU) 41-57N 012-30E 24M
Jun 20, 2008 - 08:50 AM EDT / 2008.06.20 1250 UTC
from the WSW (240 degrees) at 10 MPH (9 KT):0
greater than 7 mile(s):0
mostly clear
69 F (21 C)
60 F (16 C)
73%
29.97 in. Hg (1015 hPa)
Success
Listato 2.1 - Un semplice esempio di messaggio XML
Un documento XML viene detto ben formattato quando rispetta le regole di scrittura dei documenti
XML, definite dalle relative specifiche. Essenzialmente un documento XML risulta ben formattato
se il suo prologo ed il suo corpo sono compatibili con le regole di base alle quali essi devono essere
scritti.
Un XML processor è un modulo software utilizzato da un'applicazione per leggere un documento
XML, oltre che ottenere accesso ai dati contenuti al suo interno e allo loro struttura. Un XML
processor determina inoltre se un documento XML sia o meno ben formattato.
2.4.2 DTD: Document Type Definition
Una Document Type Definition è un file in cui è riportata la definizione di tutti gli elementi, e dei
loro attributi, usati nel documento XML, specificando inoltre la correlazione tra di essi. Tale file
permette ad un’applicazione di sapere se il documento XML che sta analizzando è corretto o no,
dato che gli elementi, essendo stati creati dallo sviluppatore, risulterebbero privi di significato senza
una loro definizione.
Una DTD definisce quindi la struttura di un particolare tipo di documento XML, rispetto al quale si
può valutare la conformità di una data istanza XML.
Le DTD, primo strumento di questo genere, presentano però delle limitazioni: possiedono una
sintassi complessa (non sono scritte in XML), non permettono di specificare tipi di dato e sono
difficilmente estendibili.
2.4.3 XML Schema
Uno strumento, creato allo stesso scopo delle DTD, che supera le limitazioni di queste ultime è
XML-Schema.
Un documento XML-schema definisce:
● gli elementi e gli attributi che possono comparire in un documento;
15/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
● quali elementi sono elementi figlio;
● l’ordine ed il numero degli elementi figlio;
● se un elemento è vuoto o può includere testo;
● i tipi di dato per gli elementi e gli attributi;
● i valori di default ed i valori costanti per gli elementi e gli attributi.
Rispetto alle DTD, gli XML-Schema sono estensibili e scritti in XML, rendono possibile la
definizione di tipi di dato e di vincoli, ammettono l’ereditarietà e supportano i namespace.
2.4.4 Namespece XML
In precedenza è stato affermato che un documento XML permette di identificare una DTD esterna
tramite un URI, di includere dichiarazioni di marckup esplicite o di fare entrambe le cose
contemporaneamente. Cosa succede però nel caso in cui si vogliano combinare due o più documenti
XML, ognuno de quali ha una propria DTD per ottenere un singolo documento? La risposta breve è
che non è sempre possibile. Infatti, ammettendo che i documenti siano due, dato che la DTD di ogni
documento molto probabilmente non è stata definita tenendo presenti le caratteristiche degli
elementi della seconda DTD, esistono probabilità concrete che si verifichino delle collisioni tra i
nomi delle due tipologie di documenti. In tal caso, sarebbe impossibile riuscire a differenziare gli
elementi il cui nome è comune ad entrambe le DTD.
I namespace XML sono stati ideati per aiutarci ad affrontare questo tipo di problemi. Un namespace
XML non è altro che una collezione di nomi di elementi ed attributi identificata da un URI. Ogni
nome di un determinato namespace XML viene quindi qualificato tramite l'URI che identifica il
namespace stesso. In questo modo namespace XML differenti possono contenere nomi in comune
senza che questo causi confusione, in quanto ogni singolo nome viene qualificato, tramite l'URI
univoco del namespace che lo contiene.
Un esempio di notazione a cui si è appena fatto cenno è la seguente:
In questo modo viene effettuata una dichiarazione di namespace utilizzando un nome di attributo
speciale e riservato, xmlns, all'interno della dichiarazione di un elemento; in questo esempio il
namespace viene applicato all'elemento . Il nome xsi separato da xmlns tramite un
carattere : rappresenta il prefisso di namespace mentre il suo valore,
http://www.w3.org/2001/XMLSchema-instance, specifica l'URI associato al namespace. Il solo
scopo dell'URI che identifica il namespace consiste nell'assicurare che i nomi all'interno del
namespace siano unici, indipendentemente dal fatto che l'URI esista oppure no. Come si nota
dall'esempio proposto, è possibile aggiungere un numero qualsiasi di dichiarazioni di namespace
all'interno di un elemento.
2.4.5 Lavorare con i documenti XML
Nei paragrafi precedenti è stato introdotta la nozione di XML processor come modulo utilizzato da
un'applicazione per leggere documenti XML. Un XML processor si occupa di effettuare il parsing
del contenuto di un documento e di mettere a disposizione dell'applicazione gli elementi ed i relativi
attributi: per questa ragione, l'XML processor viene spesso chiamato parser XML. Questi è quindi
un modulo di programma che si occupa di suddividere il testo scritto in un determinato linguaggio
nei suo componenti base, quindi da un punto di vista meramente implementativo un'applicazione
accede al contenuto di un documento sfruttando le API messe a disposizione da un parser XML, ed
il parser si occupa di svolgere tutte le operazioni necessarie per individuare ed interpretare le
informazioni che compongono il documento stesso.
Il linguaggio di programmazione Java supporta due API complementari per l'elaborazione di un
16/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
documento XML:
● SAX, acronimo di Simple API for XML;
● DOM, acronimo di Document Object Model for XML.
2.4.5.1 Elaborazione tramite SAX
Per la lettura di un documento XML, SAX utilizza un procedimento basato sugli eventi che
implementato tramite il meccanismo del callback, ovvero man mano che il parser legge un
documento, ogni evento di parsing come, per esempio, il riconoscimento del tag di inizio o di fine
di un elemento determina un richiamo ad un particolare metodo associato a tale evento. Questo
metodo viene spesso chiamato handler, oppure gestore dell'evento. Il compito del programmatore
consiste nell'implementare gli handler in modo da rispondere in maniera appropriata a ogni evento,
e quindi reagire al contenuto del documento in base alle esigenze dell'applicazione.
Il modo in cui lavora SAX si traduce necessariamente nel fatto che l'applicazione viene a
conoscenza del contenuto del documento un pezzo per volta, senza poter lavorare su una sua
rappresentazione totale. Ciò significa che, nel caso in cui il programma abbia la necessità di avere a
disposizione l'intero documento all'interno di una struttura che ne riproduca il contenuto, bisogna
costruire e riempire personalmente tale struttura con le informazioni invocate dai metodi di
callback.
----------> Inizio documento
--------------------------------------------> Inizio elemento : CurrentWeather
-----------------------------------------------> Inizio elemento : Visibility
greater than 7 mile(s):0 -----------------------> Carattere : greater than 7 mile(s) : 0
----------------------------------------------> Fine elemento : Visibility
-------------------------------------------> Inizio elemento : SkyConditions
mostly clear ------------------------------------------> Carattere : mostly clear
------------------------------------------> Fine elemento : SkyConditions
----------------------------------------------> Inizio elemento : Temperature
69 F (21 C)---------------------------------------------> Carattere : 69 F (21 C)
---------------------------------------------> Fine elemento : Temperature
--------------------------------------------> Fine elemento : CurrentWeather
Illustrazione 2.5: Elaborazione SAX di un documento XML
Naturalmente, il lato positivo di questo approccio a eventi consiste nel fatto che non è obbligatorio
mantenere l'intero documento in memoria.
Bisogna evidenziare il fatto che SAX, di per se stesso, non è un vero e proprio parser di documenti
XML, ma rappresenta solo una definizione di pubblico dominio di un'interfaccia verso un parser
XML, e tale perser è rappresentato da un programma esterno. Dal punto fi vista della
programmazione in Java le interfacce coinvolte nel procedimento sono molteplici. L'interfaccia
XMLReader definita nel package org.xml.sax specifica i metodi che il parser SAX richiama man
mano che riconosce elementi, attributi e altri componenti del documento XML. Di conseguenza, per
intercettare e interpretare il contenuto di un documento XML è necessario creare una classe che
implementi tali metodi e risponda in maniera appropriata alle chiamate di callback.
2.4.5.2 Elaborazione tramite DOM
DOM lavora in maniera del tutto differente rispetto a SAX. Infatti, a fronte del parsing di un
17/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
documento XML, il DOM assembla in memoria l'intero albero gerarchico degli elementi del
documento stesso e lo restituisce all'applicazione sotto forma di un oggetto di tipo Document che lo
incapsula completamente.
Illustrazione 2.6: Elaborazione DOM di un documento XML
Non appena l'oggetto Document viene messo a disposizione dell'applicazione, è possibile richiamare
i metodi dell'oggetto per navigare attraverso gli elementi dell'albero gerarchico del documento,
partendo dall'elemento root del documento stesso. Con DOM, l'intero documento è totalmente
disponibile per essere consultato ed elaborato un numero imprecisato di volte, ed in qualsiasi modo
risulti adeguato agli scopi dell'applicazione. Questo è sicuramente il vantaggio sostanziale rispetto
all'approccio seguito da SAX. Il lato negativo della metodologia seguita dal DOM consiste nella
quantità di memoria occupata dalla rappresentazione del documento (non c'è scelta), il documento
viene letto e memorizzato completamente in memoria, indipendentemente dalle sue dimensioni, e
per alcuni particolari documenti la quantità di memoria necessaria può risultare proibitiva.
Dal punto di vista implementativo del progetto proposto è sono state utilizzate le API open source
di JDOM, sviluppate da Brett McLaughlin e Jason Hunter. In tale tecnologia, un documento XML
viene rappresentato come un'istanza della classe org.jdom.Document la quale fornisce anche
l'analogo delle interfacce DOM come classi Java ma si osservi che la gerarchia di classi JDOM non
ha alcuna relazione diretta con DOM, ad esempio la classe Node di JDOM non implementa
l'interfaccia Node di DOM.
La prima caratteristica Java-oriented di JDOM che lo sviluppatore incontra è il poter creare gli
oggetti direttamente col proprio costruttore, senza la necessità di utilizzare metodi factory. Per
creare ad esempio un oggetto org.jdom.Element che rappresenta un tag è quindi
sufficiente scrivere
Element e = new Element("Document");
Per quanto riguarda il parsing di documenti XML JDOM fornisce i builder, oggetti che costruiscono
un documento a partire da diverse sorgenti dati come file, InputStream e InputSource. Sono
definiti due tipi di builder, DOMBuilder e SAXBuilder. Come è evidente dal nome DOMBuilder
carica un documento a partire da un oggetto org.w3c.dom.Document mentre SAXBuilder sfrutta
un parser SAX ed è quindi più performante.
Le seguenti righe di codice mostra come usare un SAXBuilder per eseguire il parsing di un file
istanziando un documento JDOM:
SAXBuilder builder = new SAXBuilder(true);
Document doc = builder.build(new File(args[0]));
// ...
Le classi SAXBuilder e DOMBuilder hanno vari costruttori in overloading che permettono di
specificare quale parser usare (il default è Xerces) e se eseguire o meno la validazione del
documento (il default è false).
18/99Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio
2.5 Il protocollo SOAP
SOAP è l’acronimo di Simple Object Access Protocol e nell’intenzione dei suoi sviluppatori
dovrebbe costituire un protocollo d’accesso ad oggetti remoti, basato su XML e semplice da
utilizzare.
Tale protocollo è in effetti semplice, ed in certi sensi “user friendly” ovvero, lo sviluppatore può
curiosare all’interno dei messaggi scambiati tra i vari nodi, visto che la comunicazione è in XML e
questo ne ha decretato un successo tale da promuovere SOAP a standard affermato.
Come vedremo, la semplicità del protocollo lascia però aperte numerose questioni che invece sono
risolte in tecnologie distribuite più mature, come CORBA ed RMI.
SOAP definisce la struttura dei singoli messaggi che vengono scambiati tra i nodi, definendo una
serie di tag XML specifici.
Utilizzando come riferimento questi elementi, chi riceve il messaggio è in grado di conoscere
informazioni importanti sul messaggio stesso; nella forma più semplice, la struttura di un messaggio
SOAP consente di mettere ordine e trasmettere le informazioni in modo strutturato.
Un esempio di messaggio SOAP è presente nel seguente listato:
Roma
Italy
Listato 2.2 - Un semplice esempio di messaggio SOAP
Il messaggio presentato appartiene ad una ipotetica applicazione che fornisce le previsioni
meteorologiche online. Come si nota, vengono inviati sia il nome della Città che la rispettiva
nazione di appartenenza.
Le specifiche di SOAP contengono in realtà quattro diversi aspetti:
1. la definizione del messaggio vero e proprio ed i modelli di scambio;
2. la “codifica SOAP”, uno standard per strutturare le informazioni in XML, per certi versi
un antesignano di XML-Schema (è stato mutuato da una sua versione beta);
3. regole per utilizzare SOAP su mediante un opportuno protocollo di trasporto
(generalmente HTTP);
4. regole per utilizzare SOAP per eseguire chiamate remote a procedure (RPC).
2.5.1 Il messaggio SOAP e modelli di scambio
Un messaggio SOAP è contenuto da un elemento XML più esterno chiamato envelope (busta) che
funge da raccoglitore di tutti gli altri elementi. Al suo interno può essere presente l’elemento header
(intestazione) che può contenere metainformazioni sul messaggio, come dati sull’autenticazione,
criteri di sicurezza o sulla transazione distribuita in corso. Si noti però che questi aspetti non sono
19/99Puoi anche leggere
