java webservices

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/103


PremessaLa 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/103


Indice generalePremessa............................................................................................................................................... 2Introduzione..........................................................................................................................................51SOA: Service-Oriented Architecture.................................................................................................. 8

1.1Introduzione................................................................................................................................ 81.2Caratteristiche di una SOA......................................................................................................... 81.3Come funziona una SOA............................................................................................................ 9

2I Web Service....................................................................................................................................112.1Introduzione.............................................................................................................................. 112.2Scenari Complessi.....................................................................................................................122.3Tecnologie.................................................................................................................................132.4XML..........................................................................................................................................14

2.4.1Struttura di un documento XML....................................................................................... 142.4.2DTD: Document Type Definition..................................................................................... 162.4.3XML Schema.................................................................................................................... 162.4.4Namespece XML.............................................................................................................. 162.4.5Lavorare con i documenti XML........................................................................................17

2.4.5.1Elaborazione tramite SAX.........................................................................................172.4.5.2Elaborazione tramite DOM....................................................................................... 18

2.5Il protocollo SOAP................................................................................................................... 202.5.1Il messaggio SOAP e modelli di scambio.........................................................................212.5.2Utilizzo dell’intestazione.................................................................................................. 232.5.3Gestione degli Errori......................................................................................................... 232.5.4SOAP su HTTP................................................................................................................. 242.5.5SOAP e RPC..................................................................................................................... 252.5.6SOAP Encoding................................................................................................................ 262.5.7SOAP con Allegati............................................................................................................ 272.5.8SOAP e Java......................................................................................................................29

2.6Il linguaggio WSDL..................................................................................................................292.6.1L'elemento Type................................................................................................................ 322.6.2L'elemento Message..........................................................................................................332.6.3L'elemento PortType......................................................................................................... 342.6.4L'elemento Binding........................................................................................................... 352.6.5L'elemento Service............................................................................................................37

2.7Il protocollo UDDI....................................................................................................................432.7.1Il contesto architetturale di UDDI.....................................................................................44

2.7.1.1I ruoli in UDDI.......................................................................................................... 442.7.1.2Il registro UDDI........................................................................................................ 44

2.7.2Rappresentazione delle informazioni in UDDI.................................................................442.7.2.1Struttura di UDDI......................................................................................................452.7.2.2Interazioni con UDDI................................................................................................472.7.2.3Esempio..................................................................................................................... 48

2.8Tecnologie per Web Services di seconda generazione..............................................................513Web Services : tecnologie.................................................................................................................53

3.1Introduzione.............................................................................................................................. 53

3/103


3.2Java........................................................................................................................................... 533.3TomCat......................................................................................................................................533.4Axis...........................................................................................................................................53

3.4.1L'architettura di Axis.........................................................................................................543.4.2Installazione di AXIS........................................................................................................ 563.4.3Deployment di Web Service su Axis.................................................................................573.4.4Strumenti per il monitoraggio delle comunicazioni..........................................................62

3.5MySQL..................................................................................................................................... 653.6jUDDI....................................................................................................................................... 65

3.6.1Installazione di jUDDI...................................................................................................... 653.7UDDI4J.....................................................................................................................................71

3.7.1Installazione di UDDI4J....................................................................................................723.8Tecniche di invocazione di Web Service.................................................................................. 72

3.8.1Stub creato da WSDL........................................................................................................723.8.2Dynamic Proxy................................................................................................................. 733.8.3Dynamic Invocation Interface (DII)................................................................................. 743.8.4Dynamic Discovery and Invocation (DDI)....................................................................... 76

4Global Weather Web Service............................................................................................................ 794.1Introduzione.............................................................................................................................. 794.2Il Workflow...............................................................................................................................804.3 Class Diagram..........................................................................................................................87

4.3.1Class Diagram del presentation layer................................................................................874.3.2Class Diagram della business logic...................................................................................904.3.3Class Diagram del meteo fornito dal Web Service fittizio................................................934.3.4Class Diagram del Web Service di conversione................................................................95

4.4Use Cases..................................................................................................................................984.4.1Use Case Scelta Nazione...................................................................................................984.4.2Use Case Scelta Città........................................................................................................ 984.4.3Use Case Previsioni Meteorologiche................................................................................ 99

4.5Sequence Diagram.................................................................................................................. 1004.5.1Sequence Diagram per la richiesta dell'elenco città........................................................1004.5.2Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in MPH. .1014.5.3Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in KMH. 102

5Bigliogragia.................................................................................................................................... 103

4/103


IntroduzioneSpiegare 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 natuale 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”

1 http://en.wikipedia.org/wiki/Web_2.02 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/103


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 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 AJAX6, API, Peer-to-Peer, RSS7, XML e Web Service a supporto dell'utente che utilizza, plasma, modifica un

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 × 1038

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à.

6/103


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.

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.

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.

7/103


1 SOA: Service-Oriented Architecture

1.1 IntroduzioneUna 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 SOAL’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

8/103


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 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 SOAGli 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.

9/103


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.

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/103


2 I Web Service

2.1 IntroduzionePromossi 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 W3C11 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

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/103

http://www.w3.org/


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.

2.2 Scenari ComplessiI 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.

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

12/103

Applicat

UDDI Registry

Service Consumer Service Provider

Service Registry

SOAP

Scopre WSDL Registra WSDL

ProxyCodice Impl

Service Contract


differenze rispetto alle altre tecnologie distribuite: utilizzano un protocollo testuale (XML) al posto di quello binario costruito ad hoc, sfruttano le infrastrutture di trasporto 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.

2.3 TecnologieLa 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.

13/103


2.4 XMLXML 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 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 XMLUn documento XML può essere suddiviso in due porzioni, il prologo ed il corpo del documento detto anche body.

14/103

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 DTD12 esterna che fornisce le 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.

<?xml version="1.0" encoding="utf-16"?><CurrentWeather>  <Location>Roma / Urbe, Italy (LIRU) 41-57N 012-30E 24M</Location> <Time>Jun 20, 2008 - 08:50 AM EDT / 2008.06.20 1250 UTC</Time> <Wind> from the WSW (240 degrees) at 10 MPH (9 KT):0</Wind> <Visibility> greater than 7 mile(s):0</Visibility> <SkyConditions> mostly clear</SkyConditions> <Temperature> 69 F (21 C)</Temperature> <DewPoint> 60 F (16 C)</DewPoint> <RelativeHumidity> 73%</RelativeHumidity> <Pressure> 29.97 in. Hg (1015 hPa)</Pressure> <Status>Success</Status></CurrentWeather>

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.

15/103


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 DefinitionUna 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 SchemaUno 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;

● 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 XMLIn 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

16/103


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:

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 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 <Envelope>. 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 XMLNei 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 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

17/103


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.

<?xml version="1.0" encoding="utf-16"?> ----------> Inizio documento <CurrentWeather> --------------------------------------------> Inizio elemento : CurrentWeather

<Visibility> -----------------------------------------------> Inizio elemento : Visibility greater than 7 mile(s):0 -----------------------> Carattere : greater than 7 mile(s) : 0

</Visibility> ----------------------------------------------> Fine elemento : Visibility <SkyConditions> -------------------------------------------> Inizio elemento : SkyConditions

mostly clear ------------------------------------------> Carattere : mostly clear

</SkyConditions> ------------------------------------------> Fine elemento : SkyConditions

<Temperature> ----------------------------------------------> Inizio elemento : Temperature

69 F (21 C)---------------------------------------------> Carattere : 69 F (21 C)

</Temperature> ---------------------------------------------> Fine elemento : Temperature

</CurrentWeather> --------------------------------------------> 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 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.

18/103


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 <Document> è 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

19/103


documento (il default è false).

2.5 Il protocollo SOAPSOAP è 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:

<?xml version="1.0" encoding="utf-8"?><soap:Envelope

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body> <GetWeather xmlns="http://www.webserviceX.NET"> <CityName>Roma</CityName> <CountryName>Italy</CountryName> </GetWeather> </soap:Body></soap:Envelope>

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).

20/103


2.5.1 Il messaggio SOAP e modelli di scambioUn 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 definiti dal protocollo SOAP ma devono essere implementati, seguendo altri standard interni od esterni all’azienda.

Oltre all’intestazione, la busta contiene l’elemento body che è il vero deputato a contenere le informazioni applicative che è necessario comunicare al ricevente.

Illustrazione 2.7: struttura di un messaggio SOAP

I messaggi SOAP vengono scambiati tra i nodi fondamentalmente in modalità one-way (a senso unico), dove cioè un nodo invia e l’altro riceve.

Illustrazione 2.8: Modello di scambio one-way

Con questa modalità è possibile costruire interazioni più complesse, come quella di tipo Request/Response, che prevede anche una risposta.

21/103

SOAPEnvelope

HeaderEntries

[Header Element]

Body Element

[FaultElement]

[Attachment]


Illustrazione 2.9: Modello di scambio Request/Response

Un singolo nodo è tenuto, alla ricezione di un messaggio SOAP, ad eseguire una serie di operazioni:

● identificare tutte le componenti di sua competenza;

● verificare che tutti gli elementi obbligatori tra quelli identificati al punto precedente siano supportati dall’applicazione, ed elaborarli di conseguenza;

● nel caso qualcosa vada male, il nodo deve ritornare un messaggio di errore (chiamato Fault);

● eventualmente analizzare le parti non di competenza del nodo (questa elaborazione è opzionale);

● se il nodo attuale non è il destinatario finale del messaggio, inoltrarlo al nodo successivo.

Come si nota, la sequenza di eventi prevede la possibilità di instaurare una catena di nodi all’ascolto di messaggi SOAP allo scopo di eseguire elaborazioni successive, ad esempio per implementare filtri o cache.

Illustrazione 2.10: Un esempio di catena di ascoltatori SOAP, con filtri e cache

La busta contiene due informazioni che ne consentono l’identificazione della versione e la specifica dell’encoding.

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

In particolare:

● il namespace di appartenenza. Gli elementi XML propri del messaggio SOAP appartengono ad un namespace, il cui URI definisce la versione di SOAP utilizzata. Per SOAP 1.1 il namespace è http://schemas.xmlsoap.org/soap/envelope/. In caso il server riceva un messaggio la cui versione è diversa da quella attesa, viene generato un errore (di tipo VersionMismatch);


● attributo encodingStyle. Indica quale standard è stato utilizzato per codificare il contenuto del messaggio (si veda il paragrafo SOAP Encoding).

22/103



Nel caso in cui volessimo applicare la codifica di SOAP 1.2 bisogna sostituire la precedente URI con http://www.w3.org/2001/09/soap-encoding.

2.5.2 Utilizzo dell’intestazioneIl blocco header ha uno scopo specifico nei messaggi SOAP: fornire metainformazioni sul messaggio principale, dati cioè, non strettamente legati alle informazioni applicative, ma relativi a questioni architetturali, quali l’autenticazione o le transazioni distribuite.

<SOAP-ENV:Header><t:Authentication xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">

<t:user>Max</t:user></t:token>163gd63gd3</7:token>

</t:Transaction></SOAP-ENV:Header>

Listato 2.3 - un esempio di header

All’interno dell’intestazione è possibile utilizzare due attributi:

● actor. Identifica il destinatario di questo elemento di intestazione. Per indicare che l'elemento è destinato al primo nodo a ricevere il messaggio, è possibile specificare la costante: http://schemas.xmlsoap.org/soap/actor/next;

● mustUnderstand. Se questo attributo vale 1, la relativa sezione deve per forza essere elaborata dal nodo (se questa è indirizzata al nodo attuale). Se il nodo non è in grado di elaborarla, è necessario sollevare un fault;

<t:Authentication xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">

2.5.3 Gestione degli ErroriAbbiamo visto che il contenuto di un messaggio SOAP deve prevedere un elemento di tipo body che contiene il messaggio applicativo. Nel caso però l’elaborazione produca degli errori, il corpo del messaggio dovrà essere costituito da un (solo) elemento Fault. Questo contiene tutte le informazioni in merito all’anomalia che si è presentata.

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body>

<SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>Server Error</faultstring><detail>

<e:myfaultdetails xmlns:e="Some-URI"><message>My application didn't work </message><errorcode>1001</errorcode>

</e:myfaultdetails></detail>

</SOAP-ENV:Fault></SOAP-ENV:Body>

23/103

http://schemas.xmlsoap.org/soap/actor/next


</SOAP-ENV:Envelope>Listato 2.4 - un esempio di Fault SOAP

Le componenti di un messaggio Fault sono molteplici:

● faultcode. Definisce il codice di errore che è avvenuto, identificato da una stringa che lo individua univocamente. Le specifiche SOAP definiscono alcuni errori che si possono verificare perché legati ai funzionamenti intrinseci del protocollo, ed altri prefissi standard, come Client e Server, che consentono di individuare se il problema è relativo alla richiesta del client od alla elaborazione del server;

<faultcode>SOAP-ENV:Server</faultcode>● faultstring. Contiene sostanzialmente una descrizione dell’errore leggibile dall’essere

umano;

<faultstring>Server Error</faultstring>● faultactor. Definisce quale nodo del percorso intrapreso dal messaggio, ha generato questo

errore;

● detail. Questo elemento può contenere un messaggio applicativo variabile, che può descrivere nel dettaglio il problema occorso. Nel listato sottostante è mostrato un blocco applicativo specifico, mentre spesso si inserisce uno stack trace della chiamata Java, all’interno di un elemento CDATA.

<detail><e:myfaultdetails xmlns:e="Some-URI">

<message>My application didn't work </message><errorcode> 1001</errorcode>

</e:myfaultdetails></detail>

2.5.4 SOAP su HTTPCome accennato, HTTP è un protocollo privilegiato per il trasporto di messaggio SOAP, forse anche perché le specifiche SOAP definiscono i meccanismi di veicolazione dei propri messaggi con questo protocollo che sono tra le altre cose anche abbastanza semplici.

Per l’invio di un messaggio, è necessario utilizzare il verbo HTTP POST, unitamente ad una nuova variabile di intestazione, SOAPAction, che definisce l’intento della richiesta. Anche in virtù della libertà di utilizzo di questo elemento, spesso non viene utilizzato (infatti è definito come opzionale nelle specifiche), ed anzi, nella versione 1.2 di SOAP non è più presente.

POST /globalweather.asmx HTTP/1.1Host: www.webservicex.netContent-Type: text/xml; charset=utf-8Content-Length: lengthSOAPAction: "http://www.webserviceX.NET/GetWeather"<?xml version="1.0" encoding="utf-8"?><soap:Envelope ...

Listato 2.5 - Una richiesta SOAP su HTTP

24/103


Come si nota dal listato sottostante, SOAP su HTTP richiede che il content-type del messaggio sia “text/xml”.

Content-Type: text/xml; charset=utf-8La risposta segue poi le semantiche definite nei valori di stato di HTTP. Possiamo quindi avere:

● 200 se è andato tutto bene;

● 404 se il destinatario non è stato trovato;

● 500 se è avvenuto un errore interno (in questo caso il messaggio conterrà un elemento Fault).

HTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-Length: length<?xml version="1.0" encoding="utf-8"?><soap:Envelope ...

Listato 2.6 - una risposta SOAP su HTTP

2.5.5 SOAP e RPCÈ giunto il momento, infine, di vedere come SOAP può essere utilizzato per rappresentare chiamate a procedure remote.

Fino ad ora i singoli messaggi potevano sia ingaggiare procedure remote o semplicemente servire alla comunicazione di informazioni. La sezione delle specifiche di SOAP che ne definiscono il funzionamento come meccanismo di RPC, forniscono alcune regole uniformi per fare in modo che una chiamata RPC sia riconosciuta come tale.

In particolare, la richiesta e la risposta sono modellate come strutture (struct) e codificate, preferibilmente, con l’encoding SOAP. Il nome della struttura riprende quello del metodo da invocare, mentre la risposta ha lo stesso nome della richiesta, ma per convenzione contiene anche la parola “Reponse”.

HTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-Length: length<?xml version="1.0" encoding="utf-8"?><soap:Envelope

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body> <GetWeatherResponse xmlns="http://www.webserviceX.NET">

<GetWeatherResult><CurrentWeather>

<Location>Roma / Urbe, Italy (LIRU) 41-57N 012-30E 24M

</Location> <Time>Jun 23, 2008 - 08:50 AM EDT / 2008.06.23 1250 UTC</Time>

25/103


<Wind> from the WSW (250 degrees) at 7 MPH (6 KT):0</Wind><Visibility>greater than 7 mile(s):0</Visibility><SkyConditions> mostly clear</SkyConditions> <Temperature> 91 F (33 C)</Temperature> <DewPoint> 62 F (17 C)</DewPoint> <RelativeHumidity> 38%</RelativeHumidity> <Pressure> 30.03 in. Hg (1017 hPa)</Pressure><Status>Success</Status>

</CurrentWeather></GetWeatherResult>

</GetWeatherResponse> </soap:Body></soap:Envelope>

Listato 2.7 - Un esempio di RPC con SOAPIl metodo da invocare è identificato da un URI, che è specificato dal protocollo di trasporto utilizzato. Non esistono limitazioni alla forma dell’URI utilizzato, tranne che questo sia valido.

Altri elementi informativi non direttamente correlati alla chiamata del metodo, devono essere specificati come sottoelemento dell’intestazione. Un esempio può essere l’ID dell’oggetto da chiamare, o quello della transazione: queste informazioni di contorno non sono pertinenti al corpo del messaggio ma all’intestazione.

Eventuali errori nell’elaborazione della richiesta dovranno essere ritornati al chiamante come elementi Fault. Questa eventualità può succedere, oltre che per errori interni dell’applicazione, anche per il fatto che alcuni parametri del metodo non risultano specificati nella richiesta.

2.5.6 SOAP EncodingIl corpo di un messaggio SOAP può definire un attributo chiamato encodingStyle che indica lo standard di codifica che è stato seguito nel popolare di informazioni il corpo del messaggio. Le specifiche SOAP 1.1 definiscono l’encoding SOAP, una sorta di XML Schema in versione 0. La costante associata a questo encoding è:

http://schemas.xmlsoap.org/soap/encoding/.Non è però indispensabile utilizzare questo standard, è sufficiente utilizzarne uno che possa essere intellegibile sia da parte del client che del server.

D’altra parte, Microsoft stessa non ritiene che l’encoding SOAP faccia parte del futuro dei servizi Web, ed anche il W3C ne ha reso opzionale la sua implementazione in SOAP 1.2 e ne ha eliminato il supporto da WSDL 1.2.

Inoltre, e questo è un aspetto molto importante, la WS-I (Web Services Interoperability Organization), un consorzio di aziende che lavora per assicurare che le diverse implementazioni dei servizi Web possano comunicare tra di loro correttamente, non ne consente l’utilizzo.

Alla luce di queste notizie, non appare utile investire su un aspetto della tecnologia che in futuro non sarà più presente.

Per completezza, riportiamo comunque un esempio di blocco dati codificato in SOAP encoding .

<element name="age" type="int"/><element name="height" type="float"/>

26/103


<element name="displacement" type="negativeInteger"/><element name="color">

<simpleType base="xsd:string"><enumeration value="Green"/><enumeration value="Blue"/>

</simpleType></element>

<age>45</age><height>5.9</height><displacement>-450</displacement><color>Blue</color>

Listato 2.8 - Un esempio di encoding SOAP

2.5.7 SOAP con AllegatiOltre alle specifiche SOAP 1.1, esiste anche un altro documento del W3C che definisce delle estensioni per poter veicolare assieme ad messaggio SOAP anche dei contenuti binari, come immagini o programmi eseguibili.

Le specifiche in questione, definiscono l’utilizzo di elementi MIME per poter specificare in un unico blocco testuale, più informazioni.

MIME-Version: 1.0Content-Type: Multipart/Related; boundary=MIME_boundary;type=text/xml;

start="<[email protected]>"Content-Description: Questa è una descrizione opzionale del messaggio.--MIME_boundaryContent-Type: text/xml; charset=UTF-8Content-Transfer-Encoding: 8bitContent-ID: <[email protected]><?xml version='1.0' ?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body>..<theSignedForm href="cid:[email protected]"/>..</SOAP-ENV:Body></SOAP-ENV:Envelope>--MIME_boundary

27/103


Content-Type: image/tiffContent-Transfer-Encoding: binaryContent-ID: <[email protected]>...binary TIFF image...--MIME_boundary--

Listato 2.9 - Un esempio di SOAP con allegatiL’esempio sopra riportato mostra un messaggio SOAP inviato insieme ad una immagine TIFF. Il formato ricalca la struttura del presente schema :

Illustrazione 2.11: La struttura di un messaggio SOAP con allegati

Questa possibilità consente di associare ad un messaggio SOAP un elemento binario, come ad esempio un certificato di sicurezza o un blocco dati che risulta poco pratico o efficiente da codificare in XML.

Una caratteristica interessante è la possibilità, da parte del messaggio SOAP, di puntare a URI assoluti (quindi all’esterno del messaggio), ma anche interni, collegandosi dunque ad un altro allegato al messaggio.

Si noti che il contenuto dell'allegato non deve per forza essere di tipo binario: è anche possibile allegare ulteriori documenti XML, quando le informazioni in esse contenute non risultino

28/103


facilmente inseribili nel messaggio principale, o quando sia, dal punto di vista applicativo, preferibile mantenerle come documenti separati.

2.5.8 SOAP e JavaFino ad ora non si è parlato molto di Java, anche perché è giusto che l’argomento relativo all’implementazione di SOAP con Java sia affrontato con il dovuto spazio a disposizione.

Come introduzione, è però possibile fare una carrellata sulle diverse strategie di approccio al problema. Queste possono essere:

● utilizzo a basso livello di XML. La piattaforma Java2 Standard Edition possiede il supporto nativo ai dati XML grazie alla tecnologia JAXP (Java API for XML Processing), che consente di accedere a dati XML tramite parser di tipo DOM e di tipo SAX. Inoltre, dispone della possibilità di eseguire trasformazioni XSLT. Grazie a questo supporto è possibile pensare di costruire messaggi SOAP (o di analizzarli). Questo approccio ha il vantaggio di non richiedere lo studio di una nuova API, ma dall’altra espone direttamente a contatto con i dettagli a basso livello del protocollo SOAP;

● utilizzo di API standard a basso livello (JAXM). JAXM è l’implementazione Java del protocollo SOAP e consente di implementare codice server e client che utilizza questo standard. Anche JAXM è una tecnologia abbastanza a basso livello: alcune sue classi, come Envelope, Body, Header sono la diretta mappatura degli elementi presenti nei messaggi SOAP. Anche i singoli attributi che questi devono supportare, sono demandati allo sviluppatore che ne deve curare singolarmente ogni aspetto. Se da una parte questa soluzione presenta vantaggi rispetto al primo approccio, comunque è necessario molto codice per implementare complesse applicazioni distribuite basate su SOAP;

● utilizzo di API standard ad alto livello (JAXRPC). Fortunatamente, la piattaforma Java dispone anche di una tecnologia che consente di operare con SOAP ad un livello più alto. JAX-RPC (Java API for XML Remote Procedure Call) è una tecnologia che consente di generare, a fronte di una classe Java o di un file WSDL di definizione del servizio, tutta l’infrastruttura necessaria ad implementare un client od un server. Ovviamente, il codice generato sarà compatibile con tutte le implementazioni di terze parti che saranno disponibili. JAX-RPC è stato inserito nella versione 1.4 di Java2 Enterprise Edition e dunque i container presenti negli application server si occuperanno di fornire l’infrastruttura necessaria alle applicazioni JAX-RPC ad operare. Il vantaggio, con JAX-RPC, è che il codice SOAP viene generato dagli strumenti di sviluppo e non prodotto dal programmatore che però ha così meno controllo sui dettagli a basso livello, ma che vede ridursi i tempi di sviluppo;

● utilizzo di strumenti di terze parti. In ultima analisi, è possibile anche rivolgersi a strumenti ed API di terze parti, sia open-source, che commerciali. Un progetto interessante è ad esempio Apache Axis. Completa implementazione del protocollo SOAP, consente di realizzare servizi in modo molto semplice: è sufficiente creare una classe Java che implementi il servizio che si vuole erogare, cambiargli estensione da java a jws e posizionarla in una directory specifica sotto il web container. Si occuperà Axis di tramutare l’interfaccia del servizio in un Web Service SOAP.

2.6 Il linguaggio WSDLWSDL è l’acronimo di Web Services Description Language e può essere inteso come un linguaggio

29/103


formale in formato XML utilizzato per la creazione di “documenti” per la descrizione di Web Service.

Mediante WSDL può essere, infatti, descritta l'interfaccia pubblica di un Web Service ovvero creata una descrizione, basata su XML, di come interagire con un determinato servizio: un “documento” WSDL contiene infatti, relativamente al Web Service descritto, informazioni su:

● cosa può essere utilizzato (le “operazioni” messe a disposizione dal servizio);

● come utilizzarlo (il protocollo di comunicazione da utilizzare per accedere al servizio, il formato dei messaggi accettati in input e restituiti in output dal servizio ed i dati correlati) ovvero i “vincoli” (bindings in inglese) del servizio;

● dove utilizzare il servizio (cosiddetto endpoint del servizio che solitamente corrisponde all'indirizzo - in formato URI - che rende disponibile il Web Service)

Le operazioni supportate dal Web Service ed i messaggi che è possibile scambiare con lo stesso sono descritti in maniera astratta e quindi collegati ad uno specifico protocollo di rete e ad uno specifico formato.

Il WSDL è solitamente utilizzato in combinazione con SOAP e XML Schema per rendere disponibili Web Service su reti aziendali o su Internet: un programma client può, infatti, “leggere” da un registro UDDI il documento WSDL relativo ad un Web Service per determinare quali siano le funzioni messe a disposizione sul server e quindi utilizzare il protocollo SOAP per utilizzare una o più delle funzioni elencate dal WSDL.

La versione 1.1 di WSDL non è stata adottata come standard dal World Wide Web Consortium (W3C).

Il 26 giugno 2007 la versione 2.0 è stata promossa a standard ufficiale (in forma di “raccomandazione”) dal W3C.

All'interno del documento esistono quattro elementi principali:

● <types>

● <message>

● <portType>

● <binding>

● <service>

30/103

Illustrazione 2.12: Struttura di un documento WSDL1.1

Questi elementi vengono organizzati nel modo seguente (vedremo più avanti il loro contenuto):

<definitions> <types>

 </types> <message>



</message> <portType>  </portType> <binding>  </binding> <service>



</service>

31/103

WSDLDocument

[Types]

{Messages}

{Port Types}

{Bindings}

{Services}

[Operations]

[Ports]


</definitions>Listato 2.10 - Struttura di un documento WSDL1.1

Nei paragrafi che seguiranno prenderemo in analisi il file WSDL del Web Service Global Weather fornito da WebserviceX.net13, utilizzato all'interno di questo progetto.

2.6.1 L'elemento TypeAbbiamo detto che all'interno del tag <types> bisogna definire i tipi che utilizzeremo nel documento, tale operazione risulta particolarmente facile per chi ha un minimo di conoscenza di XML Schema. Tutto quello che dobbiamo fare è inserire uno schema adatto ai nostri propositi. Supponendo di voler creare un operazione in grado di ricevere in input due stringhe, rappresentanti ad esempio la nazione e la città e di restituire le corrispettive previsioni meteo espresse ovviamente anch'esse in stringhe, possiamo fare come segue:

All'interno di definitions impostiamo i namespace che ci servono, definendo inoltre wsdl come namespace base per gli elementi di questo documento.

<wsdl:definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns="http://schemas.xmlsoap.org/wsdl/"targetNamespace="urn:com.dominio.service.TemperatureConverter">

<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://www.webserviceX.NET" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://www.webserviceX.NET" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

Listato 2.11 - Definizione del tag definitionsDato il nostro Web Service Global Weather utilizza solo strutturati, per il metodo GetWeather e la relativa risposta sono stati definiti i seguenti tipi:

<wsdl:types><s:schema

elementFormDefault="qualified" targetNamespace="http://www.webserviceX.NET"><s:element name="GetWeather">

<s:complexType><s:sequence>

<s:element minOccurs="0" maxOccurs="1" name="CityName" type="s:string" />

<s:element minOccurs="0" maxOccurs="1"name="CountryName" type="s:string" />

</s:sequence>13 http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=48

32/103

</s:complexType> </s:element>

<s:element name="GetWeatherResponse"><s:complexType>

<s:sequence> <s:element minOccurs="0" maxOccurs="1"

name="GetWeatherResult" type="s:string" /> </s:sequence> </s:complexType> </s:element>

::::: 

::::: </s:schema> </wsdl:types>

Listato 2.12 - Stralcio del tag Type del file WDSL del Web Service Global Weather

2.6.2 L'elemento MessageContinuando sempre la nostra analisi sul metodo il metodo GetWeather, per inviare la coppia (CountryName, CityName) e ricevere le corrispettive previsioni meteorologiche, implica invocare due messaggi. Nella fattispecie, attraverso il primo dei due (la richiesta dell'applicazione) sarà inviata al Web Service la Città e la Nazione mentre con l'altro messaggio il Web Service invierà la risposta.

Vediamo allora con un esempio questi due messaggi implementati:

...<wsdl:message name="GetWeatherSoapIn"> <wsdl:part name="parameters" element="tns:GetWeather" /> </wsdl:message>...<wsdl:message name="GetWeatherSoapOut"> <wsdl:part name="parameters" element="tns:GetWeatherResponse" /> </wsdl:message>...

Listato 2.13 - Definizione dei blocchi MessageCosì facendo sono stati definiti due messaggi ad ognuno dei quali è stato dato un nome che utilizzeremo più avanti. Invece ogni parte (<part>) all'interno di un messaggio descrive da che cosa è composto ed ha a sua volta un nome che l'applicazione client userà per indicare i parametri che passa o riceve.

33/103


2.6.3 L'elemento PortTypeQuesto elemento è senza dubbio il più importante all'interno di un documento WSDL infatti ha il compito di definire un Web Service, le operazioni che può effettuare ed i messaggi che sono coinvolti in questo processo.

È importante anche sottolineare il valore astratto del <portType>. Possiamo infatti compararlo con una libreria di funzioni del tutto simile a quella che troviamo nei principali linguaggi di programmazione. Questo risulta ulteriormente chiaro se ripetiamo ancora una volta che lo scopo di questo elemento è descrivere le operazioni (metodi) ed i messaggi che utilizzano (quindi il tipo degli argomenti passati e dei dati che ritornano).

Ogni operazione definita all'interno del <portType> può essere di quattro tipi:

● One-way (monodirezionale): un messaggio dal client al servizio;

Illustrazione 2.13: Operazione One-Way

● Notification (notifica): il contrario dell'operazione one-way, ossia un messaggio dal servizio al client;

Illustrazione 2.14: Operazione Notification

● Request-Response (richiesta-risposta): un messaggio da parte del client ed una risposta proveniente dal servizio;

Illustrazione 2.15: Operazione Request-

Response

● Solicit-Response (sollecito-risposta): il contrario dell'operazione di request-response. In questo caso, il messaggio originale è trasmesso dal servizio ed è il client che risponde.

34/103


Illustrazione 2.16: Operazione Solicit-

Response

Proseguendo con l'esempio del metodo GetWeather è giunto il momento di analizzare anche l'elemento portType.

<wsdl:portType name="GlobalWeatherSoap"><wsdl:operation name="GetWeather">

<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get weather report for all major cities around the world.

</documentation> <wsdl:input message="tns:GetWeatherSoapIn" /> <wsdl:output message="tns:GetWeatherSoapOut" /> </wsdl:operation>:::</wsdl:portType>

Listato 2.14 - Definizione di un nuovo blocco PortTypeCome potete notare definire il <portType> è piuttosto semplice. È sufficiente infatti darli un nome ed inserire delle operazioni. Ogni operazione può essere composta da un messaggio di input, output oppure entrambi. Operazioni di solicit-response e request-response possono includere anche un terzo elemento (opzionale) chiamato fault che specifichi un messaggio con un formato valido per descrivere tutti gli errori che possono avvenire durante l'operazione.

<fault message=”faultMessage”/>

2.6.4 L'elemento BindingUna volta definito il il portType bisogna che questi sia collegato con il protocollo SOAP tramite l'elemento <binding>. All'interno di questo paragrafo vedremo solamente un binding SOAP di tipo HTTP document.

<wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap"><soap:binding transport="http://schemas.xmlsoap.org/soap/http"

style="document" /> <wsdl:operation name="GetWeather">

<soap:operation soapAction="http://www.webserviceX.NET/GetWeather"style="document" />

<wsdl:input><soap:body use="literal" />

35/103


</wsdl:input><wsdl:output>

<soap:body use="literal" /> </wsdl:output>

</wsdl:operation>:::

</wsdl:binding>Listato 2.15 - Definizione di un blocco Binding relativo al metodo GlobalWeatherSoap

Come vediamo nell'esempio esistono due elementi binding, il primo appartenente al namespace di WSDL

<wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap">ed il secondo appartenente a SOAP.

<soap:binding transport="http://schemas.xmlsoap.org/soap/http"style="document" />

Ovviamente sono due elementi diversi.

Il primo ha due attributi, uno indica il nome dell'elemento (inserito a piacere)

<wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap">e l'altro il tipo del binding cioè il nome del nostro <portType>.

<wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap">Una volta collegato il portType al binding possiamo proseguire con il secondo elemento di questo tipo, quello appartenente a SOAP. Anche questo elemento ha due attributi: uno stile che può essere inpostato a rpc o document

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

ed un attributo transport.

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

In questo caso abbiamo usato document come style poiché riceveremo una risposta sotto forma di documento. L'attributo transport indica il protocollo da utilizzare con SOAP per comunicare e come possiamo leggere nell'URI abbiamo scelto HTTP.

Giunti a questo punto, dopo aver definito i due elementi “binding” possiamo passare alla parte più interessante: definire i dettagli per le operazioni.

Con il primo tag operation, quello più esterno, richiamiamo le operazioni che abbiamo già definito nell'elemento <portType>

<wsdl:operation name="GetWeather">::::

</wsdl:operation>e per ognuna di queste definiamo il valore soapAction e confermiamo lo stile attraverso

36/103


soap:operation.

<soap:operation soapAction="http://www.webserviceX.NET/GetWeather"style="document" />

Come valore di soapAction abbiamo inserito un URI che nel mezzo ha una servlet. Questo serve per sottolineare che l'attributo soapAction è molto importante (oltre che indispensabile) poiché ci servirà come descrizione dell'azione richiesta per il Web Service.

All'interno del tag operation, dopo aver impostato l'elemento <soap:operation> bisogna elencare come saranno comunicati messaggi. Per farlo, ad ogni messaggio previsto dall'operazione che stiamo descrivendo dopo aver specificato il tipo con gli appositi tag (input, output o fault).

<wsdl:input><soap:body use="literal" />


<soap:body use="literal" /> </wsdl:output><wsdlsoap:body> specifica come le parti del messaggio appariranno all'interno dell'elemento body di SOAP ed imposta la codifica da utilizzare se si è deciso di utilizzarla. Se non si desidera la codifica si può impostare l'attributo use con valore literal.

2.6.5 L'elemento Serviceservice è il primo elemento che i vostri utenti vedono quando ricevono il documento WSDL. È stato progettato per riunire tutte le porte in relazione tra loro; in altri termini, l'elemento service consente ad un utente di determinare se un servizio specifico supporta tutte le operazioni che gli vengono richieste.

Esiste, comunque, una regola in merito alla combinazione delle porte nei servizi: queste ultime non possono comunicare tra loro ossia non si possono concatenare in modo che l'output di una porta costituisca l'input di un'altra.

<wsdl:service name="GlobalWeather"><wsdl:port name="GlobalWeatherSoap" binding="tns:GlobalWeatherSoap">

<soap:address location="http://www.webservicex.net/globalweather.asmx" />

</wsdl:port>:::</wsdl:service>

Listato 2.16 - Definizione di un nuovo blocco ServiceScegliamo il nome per il servizio

<wsdl:service name="GlobalWeather">e colleghiamo una porta al al binding;

<wsdl:port name="GlobalWeatherSoap" binding="tns:GlobalWeatherSoap">per questa porta definiamo un punto di comunicazione con l'attributo location.

37/103


<soap:address location="http://www.webservicex.net/globalweather.asmx" />

Finalmente abbiamo incontrato e realizzato tutte le parti di un documento WSDL. Possiamo quindi vedere la versione integrale del nostro WSDL.

<?xml version="1.0" encoding="utf-8" ?> <wsdl:definitions

xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://www.webserviceX.NET" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://www.webserviceX.NET" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"><wsdl:types>

<s:schema elementFormDefault="qualified" targetNamespace="http://www.webserviceX.NET"><s:element name="GetWeather">


<s:element minOccurs="0" maxOccurs="1" name="CityName" type="s:string" />

<s:element minOccurs="0" maxOccurs="1" name="CountryName" type="s:string" />

</s:sequence> </s:complexType> </s:element> <s:element name="GetWeatherResponse">


<s:element minOccurs="0" maxOccurs="1" name="GetWeatherResult" type="s:string" />

</s:sequence> </s:complexType> </s:element>

<s:element name="GetCitiesByCountry"><s:complexType>

<s:sequence> <s:element minOccurs="0" maxOccurs="1"

name="CountryName" type="s:string" /> </s:sequence> </s:complexType>

38/103


</s:element><s:element name="GetCitiesByCountryResponse">


<s:element minOccurs="0" maxOccurs="1" name="GetCitiesByCountryResult" type="s:string" />

</s:sequence> </s:complexType> </s:element> <s:element name="string" nillable="true" type="s:string" /> </s:schema> </wsdl:types>

<wsdl:message name="GetWeatherSoapIn"> <wsdl:part name="parameters" element="tns:GetWeather" /> </wsdl:message>

<wsdl:message name="GetWeatherSoapOut"> <wsdl:part name="parameters" element="tns:GetWeatherResponse" /> </wsdl:message>

<wsdl:message name="GetCitiesByCountrySoapIn"> <wsdl:part name="parameters" element="tns:GetCitiesByCountry" /> </wsdl:message>

<wsdl:message name="GetCitiesByCountrySoapOut"> <wsdl:part name="parameters"

element="tns:GetCitiesByCountryResponse" /> </wsdl:message>

<wsdl:message name="GetWeatherHttpGetIn"> <wsdl:part name="CityName" type="s:string" /> <wsdl:part name="CountryName" type="s:string" /> </wsdl:message>

<wsdl:message name="GetWeatherHttpGetOut"> <wsdl:part name="Body" element="tns:string" /> </wsdl:message>

<wsdl:message name="GetCitiesByCountryHttpGetIn"> <wsdl:part name="CountryName" type="s:string" /> </wsdl:message>

<wsdl:message name="GetCitiesByCountryHttpGetOut"> <wsdl:part name="Body" element="tns:string" />

</wsdl:message><wsdl:message name="GetWeatherHttpPostIn">

39/103


<wsdl:part name="CityName" type="s:string" /> <wsdl:part name="CountryName" type="s:string" />

</wsdl:message><wsdl:message name="GetWeatherHttpPostOut">

<wsdl:part name="Body" element="tns:string" /> </wsdl:message>

<wsdl:message name="GetCitiesByCountryHttpPostIn"> <wsdl:part name="CountryName" type="s:string" /> </wsdl:message>

<wsdl:message name="GetCitiesByCountryHttpPostOut"> <wsdl:part name="Body" element="tns:string" /> </wsdl:message>

<wsdl:portType name="GlobalWeatherSoap"><wsdl:operation name="GetWeather">


</documentation> <wsdl:input message="tns:GetWeatherSoapIn" /> <wsdl:output message="tns:GetWeatherSoapOut" /> </wsdl:operation>

<wsdl:operation name="GetCitiesByCountry"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/">

Get all major cities by country name(full / part).

</documentation> <wsdl:input message="tns:GetCitiesByCountrySoapIn" /> <wsdl:output message="tns:GetCitiesByCountrySoapOut" /> </wsdl:operation> </wsdl:portType>

<wsdl:portType name="GlobalWeatherHttpGet"><wsdl:operation name="GetWeather">


</documentation> <wsdl:input message="tns:GetWeatherHttpGetIn" /> <wsdl:output message="tns:GetWeatherHttpGetOut" /> </wsdl:operation>


Get all major cities by country name

40/103


(full / part).</documentation>

<wsdl:input message="tns:GetCitiesByCountryHttpGetIn" /> <wsdl:output message="tns:GetCitiesByCountryHttpGetOut" /> </wsdl:operation> </wsdl:portType>

<wsdl:portType name="GlobalWeatherHttpPost"><wsdl:operation name="GetWeather">


</documentation> <wsdl:input message="tns:GetWeatherHttpPostIn" /> <wsdl:output message="tns:GetWeatherHttpPostOut" /> </wsdl:operation>


Get all major cities by country name(full / part).

</documentation> <wsdl:input message="tns:GetCitiesByCountryHttpPostIn" /> <wsdl:output message="tns:GetCitiesByCountryHttpPostOut" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"

style="document" /> <wsdl:operation name="GetWeather">

<soap:operation soapAction="http://www.webserviceX.NET/GetWeather" style="document" />

<wsdl:input> <soap:body use="literal" /> </wsdl:input>

<wsdl:output><soap:body use="literal" />

</wsdl:output> </wsdl:operation>

<wsdl:operation name="GetCitiesByCountry"> <soap:operation

soapAction="http://www.webserviceX.NET/GetCitiesByCountry" style="document" />

<wsdl:input>

41/103


<soap:body use="literal" /> </wsdl:input>

<wsdl:output><soap:body use="literal" />

</wsdl:output></wsdl:operation>

</wsdl:binding><wsdl:binding name="GlobalWeatherHttpGet" type="tns:GlobalWeatherHttpGet">

<http:binding verb="GET" /> <wsdl:operation name="GetWeather">

<http:operation location="/GetWeather" /> <wsdl:input>

<http:urlEncoded /> </wsdl:input>

<wsdl:output> <mime:mimeXml part="Body" />


<wsdl:operation name="GetCitiesByCountry"> <http:operation location="/GetCitiesByCountry" />

<wsdl:input> <http:urlEncoded /> </wsdl:input>

<wsdl:output> <mime:mimeXml part="Body" /> </wsdl:output> </wsdl:operation> </wsdl:binding>

<wsdl:binding name="GlobalWeatherHttpPost" type="tns:GlobalWeatherHttpPost">

<http:binding verb="POST" /> <wsdl:operation name="GetWeather">

<http:operation location="/GetWeather" /> <wsdl:input>

<mime:content type="application/x-www-form-urlencoded" />


<mime:mimeXml part="Body" />

42/103



<wsdl:operation name="GetCitiesByCountry"> <http:operation location="/GetCitiesByCountry" />

<wsdl:input> <mime:content

type="application/x-www-form-urlencoded" /> </wsdl:input>

<wsdl:output> <mime:mimeXml part="Body" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="GlobalWeather">

<wsdl:port name="GlobalWeatherSoap" binding="tns:GlobalWeatherSoap"> <soap:address

location="http://www.webservicex.net/globalweather.asmx" /> </wsdl:port>

<wsdl:port name="GlobalWeatherHttpGet" binding="tns:GlobalWeatherHttpGet"> <http:address

location="http://www.webservicex.net/globalweather.asmx" /> </wsdl:port>

<wsdl:port name="GlobalWeatherHttpPost" binding="tns:GlobalWeatherHttpPost">

<http:address location="http://www.webservicex.net/globalweather.asmx" />

</wsdl:port> </wsdl:service></wsdl:definitions>

Listato 2.17 - Listato completo del WSDL del Web Service Global Weather

2.7 Il protocollo UDDIUDDI è l'acronimo di Universal Description, Discovery and Integration ed è un servizio di directory che consente agli utenti di localizzare i servizi Web. In sostanza, UDDI è un registry (ovvero una base dati ordinata ed indicizzata), basato su XML ed indipendente dalla piattaforma hardware, che permette alle aziende la pubblicazione dei propri dati e dei servizi Web offerti su Internet.

UDDI, è un'iniziativa “open” sviluppata tra il 1999 ed il 2000 e sponsorizzata dall'Organization for the Advancement of Structured Information Standards (consorzio internazionale per lo sviluppo e l'adozione di standard nel campo dell'e-business e dei Web Services spesso indicato anche come OASIS), permette quindi la scoperta e l'interrogazione dei servizi offerti sul web, delle aziende che li offrono e della maniera per usufruirne.

43/103


2.7.1 Il contesto architetturale di UDDICi sono due modi per considerare il contesto architetturale di un Web Service. Il primo è esaminare i ruoli individuali; il secondo è esaminare la pila dei protocolli in cui si inserisce UDDI.

2.7.1.1 I ruoli in UDDI

Ci sono due ruoli principali all’interno dell’architettura UDDI come è possibile evincere dall'illustrazione.

Illustrazione 2.17: I ruoli in UDDI

● Publisher: è il fornitore del servizio. Il Publisher implementa il servizio e lo rende disponibile pubblicandolo sul registro UDDI.

● Utente: è il fruitore del servizio. L’utente consulta l’elenco, localizza il Web Service e invoca il servizio richiesto che viene eseguito dal Publisher.

2.7.1.2 Il registro UDDI

Il registro UDDI è supportato da una rete mondiale di nodi, collegati tra di loro in una sorta di federazione, in modo similare alla tecnologia DNS. Quando un client sottopone una informazione al registro, questo la propaga agli altri nodi. In questo modo si attua la ridondanza dei dati, fornendo una certa affidabilità. Il ruolo del singolo nodo rimane comunque fondamentale, poiché, nel momento in cui un client gli sottopone dei dati, questo ne diviene il proprietario, e sarà in futuro solo questo nodo a poter operare importanti operazioni sui dati, quali la loro eliminazione.

2.7.2 Rappresentazione delle informazioni in UDDIRicapitolando UDDI tratta un insieme di funzioni che permettono di:

● Registrare aziende, servizi e informazioni per raggiungere i servizi stessi.

● Modificare o cancellare le registrazioni.

● Ricercare il database delle registrazioni.

Operativamente un’azienda che vuole rendere disponibile un Web Service dovrà:

● Registrarsi come azienda in quanto tale.

● Registrare il servizio offerto da un punto di vista descrittivo.

● Registrare le informazioni necessarie ad invocare il servizio, come per esempio la URL presso cui è esposto.

44/103

RegistroUDDI

Publisher Utente

RegistroUDDI

PublisherPublisher UtenteUtente


Concettualmente, queste informazioni che devono essere fornite, coerentemente con le specifiche previste da UDDI, possono essere divise in tre blocchi fondamentali: White Pages, Yellow Pages e Green Pages.

Illustrazione 2.18: Informazioni presenti in UDDI

Con le White Pages (pagine bianche) possiamo trovare informazioni come gli indirizzi di una azienda o contatti ad essa relativi. Nelle Yellow Pages (pagine gialle) le aziende ed i loro servizi vengono catalogati sotto differenti categorie e classificazioni. Infine vi sono le Green Pages (pagine verdi), dove sono contenute informazioni tecniche relative ai servizi, grazie alle quali questi ultimi possono essere invocati.

Questa è la suddivisione dell’informazione dentro UDDI a livello concettuale ma vediamo come è realmente strutturato un UDDI Registry.

2.7.2.1 Struttura di UDDI

Illustrazione 2.19: Struttura principale di un registro UDDI.

Le parti principali di un registro UDDI, sono quattro, in ognuna delle quali è memorizzato un certo tipo di informazione:

● businessEntity: informazioni relative alle compagnie o aziende che hanno pubblicato uno o più Web Service (White Pages).

● businessService: informazioni descrittive relative ad un particolare servizio (Yellow Pages).

● bindingTemplate: informazioni tecniche relative ad un Web Service, come ad esempio l’entry point (Green Pages).

45/103


● tModel: informazioni tecniche che descrivono una particolare tipologia di servizio, riportandone la specifica dell’interfaccia (Green Pages).

Una businessEntity possiede informazioni come nome, indirizzo e contatti di una azienda che ha pubblicato dei Web Service.

<element name = “businessEntity”> <complexType> <sequence> <element ref = “discoveryURLs” minOccurs = “0”/> <element ref = “name” maxOccurs = “unbounded”/> <element ref = “description” minOccurs = “0” maxOccurs = “unbounded”/> <element ref = “contacts” minOccurs = “0”/> <element ref = “businessServices” minOccurs = “0”/> <element ref = “identifierBag” minOccurs = “0”/> <element ref = “categoryBag” minOccurs = “0”/> </sequence> <attribute ref = “businessKey” use = “required”/> <attribute ref = “operator”/> <attribute ref = “authorizedName”/> </complexType></element>

Listato 2.18 - Definizione della struttura businessEntityAd ogni businessEntity fanno riferimento uno o più businessService, ognuno dei quali memorizza dati di tipo descrittivo, come nome e categoria di appartenenza, circa uno dei Web Service di tale azienda.

<element name = “businessService”> <complexType> <sequence> <element ref = “name” maxOccurs = “unbounded”/> <element ref = “description” minOccurs = “0” maxOccurs = “unbounded”/> <element ref = “bindingTemplates” minOccurs = “0”/> <element ref = “categoryBag” minOccurs = “0”/> </sequence> <attribute ref = “serviceKey” use = “required”/> <attribute ref = “businessKey”/> </complexType></element>

Listato 2.19 - Definizione della struttura businessServiceI dettagli tecnici relativi alla locazione del servizio ed alle modalità di accesso si trovano in una o più strutture, a cui questo businessService si riferisce, che si chiamano bindingTemplate; un binding (cioè un legame) mette in relazione un businessService, cioè le informazioni generiche descrittive di un servizio, con una sua reale implementazione.

<element name = “bindingTemplate”> <complexType> <sequence> <element ref = “description” minOccurs = “0” maxOccurs = “unbounded”/> <choiche> <element ref = “accessPoint” minOccurs = “0”/> <element ref = “hostingRedirector” minOccurs = “0”/>

46/103


</choice> <element ref = “tModelInstanceDetails”/> </sequence> <attribute ref = “bindingKey” use = “required”/> <attribute ref = “serviceKey”/> </complexType></element>

Listato 2.20 - Definizione della struttura bindingTemplateInfine completano l’architettura di UDDI i tModels. Un tModel definisce la specifica di un certo tipo di servizio, precisando ad esempio l’interfaccia che esso deve o dovrà avere; il termine “dovrà” sta appunto a chiarire il fatto che un servizio, specificato da un tModel, non deve necessariamente essere stato implementato ma può anche essere solamente stato ideato in termini di specifiche che una sua implementazione è tenuta a rispettare. Per fare ciò un tModel memorizza l’URL di un documento WSDL che riporta appunto le caratteristiche del servizio. Nel momento in cui viene realizzato un servizio, i bindingTemplate (uno o più) ad esso relativi faranno riferimento ad uno o più tModel, a precisare che esso rispetta un certo tipo di specifiche.

2.7.2.2 Interazioni con UDDI

Le interazioni con un registro UDDI sono suddivisibili in due categorie: quelle finalizzate alla ricerca di dati e quelle il cui scopo è l’inserimento o la modifica degli stessi. Questa suddivisione è rappresentata da due API (Application Programming Interface) tramite le quali si accede ai contenuti di UDDI: Inquiry API e Publish API.

Inquiry API è utilizzata per la ricerca di informazioni tramite i metodi seguenti:

● find binding: bindings relativi a un businessService.

● find business: informazioni su uno o più business.

● find relatedBusinesses: informazioni relative a businessEntity collegate ad una specifica di cui viene fornito l’identificativo.

● find service: trova i servizi di una data businessEntity.

● find tModel: trova uno o più tModel.

● get bindingDetail: informazioni di un bindingTemplate, utilizzabili per effettuare invocazioni ad un servizio.

● get businessDetail: informazioni di un businessEntity.

● get businessDetailExt: informazioni, in forma completa, di un businessEntity.

● get serviceDetail: dettagli di un businessService.

● get tModelDetail: dettagli di un tModel.

Publish API, utilizzata invece per l’inserimento, l’aggiornamento e la cancellazione, richiede un’autorizzazione per accedere ai dati e mette a disposizione i seguenti metodi, di ognuno dei quali viene specificata la funzionalità realizzata; il termine “publisher”, di cui si fa uso, identifica un soggetto, i cui dati sono memorizzati nel sistema UDDI, che possiede l’autorizzazione per accedere al registro, tramite la Publish API, e manipolare le informazioni relative ai servizi da lui pubblicati. Per ottenere l’accesso ai dati vengono utilizzati degli “authToken” (Authorization Token, cioè gettoni di autorizzazione), i quali altro non sono che stringhe di caratteri il cui utilizzo equivale a quello della classica funzione di login.

47/103


● add publisherAssertions: Aggiunge una publisherAssertion all’insieme di Assertions esistenti; una “assertion” definisce una relazione tra due registrazioni di servizi, che esprime un certo tipo di legame esistente fra loro: una relazione possibile può essere quella di sottoservizio, cioè un servizio si occupa di implementare una parte di un servizio più generale.

● delete binding: cancella un bindingTemplate dall’insieme dei bindingTemplate che fanno parte della struttura di un dato businessService.

● delete business: cancella le informazioni relative ad un dato businessEntity.

● delete publisherAssertions: cancella specifiche publisherAssertions dall’insieme di publisherAssertions relative ad un publisher.

● delete service: cancella un dato businessService.

● delete tModel: nasconde un tModel; in questo modo, tale tModel non può più essere restituito da una ricerca find tModel ma ad esso è ancora possibile fare riferimento ed accedervi tramite la funzionalità get tModelDetail. Non esiste una funzionalità che cancelli un tModel definitivamente.

● discard authToken: informa l’Operator Node (cioè il sistema che gestisce il nodo UDDI) che un dato token di autenticazione non è più valido ed una richiesta di accesso tramite tale token dovrà essere rifiutata fintantoché esso non sarà riattivato dall’operatore.

● get assertionStatusReport: restituisce un resoconto, status report, relativo alle publisherAssertions gi`a stabilite (visibili) ed allo stato di quelle non ancora corrisposte.

● get authToken: richiede un token di autenticazione ad un Operator Node. I token di autenticazione vengono utilizzati dai metodi di Publish per accedere ai dati e rappresentano il login al registro UDDI.

● get publisherAssertions: restituisce la lista delle publisherAssertion (visibili) di un dato publisher.

● get registeredInfo: restituisce un sommario di tutte le informazioni inserite da un publisher.

● save binding: registra nuovi bindingTemplate o aggiorna i dati di quelli esistenti.

● save business: registra nuovi businessEntity o aggiorna i dati relativi a quelli già presenti.

● save service: registra o aggiorna le informazioni relative ad un businessService.

● save tModel: registra o aggiorna le informazioni relative ad un tModel.

● set publisherAssertions: salva l’insieme completo delle publisherAssertions relative ad un publisher sostituendo quelle esistenti, che vengono così cancellate.

Come abbiamo già accennato, un servizio UDDI è basato su XML e comunica con gli altri Web Service attraverso messaggi SOAP. Per avere un’idea di quali sono e come vengono strutturate le informazioni restituite ad un Web Service da parte di un UDDI Registry, in seguito ad un’operazione di inquiry, vediamo i due seguenti messaggi SOAP, rispettivamente di richiesta e di risposta.

2.7.2.3 Esempio

Richiesta:

48/103


<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>

<get_businessDetailExt generic="2.0" xmlns="urn:uddi-org:api_v2"><businessKey>

6738A270-8718-11D9-BE19-E3A8EDD29D26</businessKey>

</get_businessDetailExt></soapenv:Body>

</soapenv:Envelope>Listato 2.21 - Richiesta interrogazione UDDI

Nel messaggio di richiesta si trova il costrutto “get businessDetailExt”, usato per ottenere tutte le informazioni riguardanti un servizio, ed al suo interno l’elemento “businessKey” che specifica l’identificativo di tale servizio.

Risposta:

<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>

<businessDetailExt generic="2.0" operator="eurodyn.com"xmlns="urn:uddi-org:api_v2"><businessEntityExt>

<businessEntity authorizedName="ROOT"businessKey="6738A270-8718-11D9-BE19-E3A8EDD29D26"operator="eurodyn.com"><discoveryURLs>

<discoveryURL useType="businessEntity">http://localhost:8080/juddi//uddiget.jsp?

businesskey=6738A270-8718-11D9-BE19-E3A8EDD29D26</discoveryURL>

</discoveryURLs><name>ISTI Web Services</name><contacts>

49/103


<contact useType="publisher"><personName>ROOT</personName>

</contact></contacts><businessServices><businessServicebusinessKey="6738A270-8718-11D9-BE19-E3A8EDD29D26"serviceKey="7CD2E0A0-8718-11D9-BE19-CCA88D805CB7">

<name>MergeService</name><bindingTemplates><bindingTemplate

bindingKey="D38E48A0-87E8-11D9-B722-A26BE7DE4B86"serviceKey="7CD2E0A0-8718-11D9-BE19-CCA88D805CB7"><accessPoint URLType="http">http://localhost:8080/axis/services/MergeService</accessPoint><tModelInstanceDetails><tModelInstanceInfo

tModelKey="uuid:B5CA6C80-8717-11D9-BE19-FAE3FA307183"><instanceDetails>

<overviewDoc>< overviewURL>

http://localhost:8080/axis/services/MergeService?wsdl</overviewURL>

</overviewDoc></instanceDetails>

</tModelInstanceInfo></tModelInstanceDetails>

<categoryBag/></bindingTemplate>

</bindingTemplates><categoryBag/></businessService></businessServices>

<identifierBag/><categoryBag/></businessEntity></businessEntityExt></businessDetailExt>

50/103


</soapenv:Body></soapenv:Envelope>

Listato 2.22 - Esempio di risposta UDDIIl messaggio di risposta contiene tutte le informazioni di una registrazione UDDI relativa ad un’entità come un’azienda o una compagnia. Si può notare come nella struttura ad albero delle informazioni siano implicitamente riportate le relazioni di inclusione e appartenenza dei quattro elementi principali, businessEntity, businessService, bindingTemplate e tModel.

2.8 Tecnologie per Web Services di seconda generazioneNelle sezioni precedenti abbiamo descritto le tecnologie standard dei Web Services e come, grazie ad esse, sia possibile descrivere, ricercare ed invocare un servizio. Ogni servizio mette a disposizione alcune funzionalità, le quali però sono, in relazione alla complessità del compito che svolgono, di basso livello. Ciò che queste tecnologie non forniscono è un punto di vista più elevato, al di sopra dei Web Service, che permetta di vedere ogni servizio come parte di un processo più grande e complesso ottenuto dalla collaborazione di molti servizi web. Una tale collaborazione, che può coinvolgere più organizzazioni mosse da un obiettivo comune, viene definita “business process”.

I termini “Orchestration” e “Choreography” identificano due attività che si occupano di descrivere un business process da punti di vista differenti.

● Orchestration: orchestrazione o coordinamento, descrive il business process ed in particolare la sua logica in termini del flusso di esecuzione controllato da una singola parte. Definisce le interazioni, costituite da scambi di messaggi, che vi possono essere fra i servizi web e stabilisce il loro ordine di esecuzione.

● Choreography: coreografia, definisce la sequenza dei messaggi che può coinvolgere i vari web service. In tale sequenza viene identificato il ruolo che ogni parte svolge all’interno del processo. Il processo è quindi descritto a livello collaborativo, rappresentando la cooperazione fra i servizi che ne fanno parte.

La differenza importante fra queste due attività risiede, come possiamo già aver intuito, nel punto di vista da cui si osserva il processo. Per “Orchestration” il punto di vista è quello relativo ad una delle parti che costituiscono il processo, in particolare quella che ne detiene il controllo mentre per “Choreography” è quello generale di una visione della cooperazione fra i vari servizi.

Illustrazione 2.20: Orchestration e Choreography.

51/103


Quando si progettano e sviluppano business process che coinvolgono molti web service e la cui esecuzione può avere un tempo di durata elevato bisogna tenere presenti alcuni requisiti tecnici molto importanti. Per prima cosa è necessario che i servizi possano essere invocati in modo asincrono; in questo modo un business process può invocare concorrente più Web Service per migliorare le prestazioni. Devono poi essere gestite le eccezioni e l’integrità delle transazioni, definendo il comportamento del sistema in caso di errore o di mancata risposta di un servizio invocato entro un certo limite di tempo. Infine caratteristiche importanti nell’attività di coordinamento dei Web Service sono dinamicità, flessibilità, adattabilità e riutilizzabilità; tenendo separata la logica del processo dai Web Service che lo realizzano si ottiene un alto livello di flessibilità che permette al business process di essere dinamicamente adattato per vari scopi, semplicemente richiamando i servizi necessari; inoltre un business process può essere visto come un qualsiasi servizio ed essere invocato da altri, riutilizzandolo all’interno di vari processi costituiti cosa da una composizione ricorsiva di Web Service.

Vi sono molte tecnologie, sviluppate autonomamente o in collaborazione da grandi organizzazioni come IBM, Microsoft, BEA, SUN o altre, il cui scopo è quello di gestire le due attività di Orchestration e Choreography.

All’interno di queste tecnologie la distinzione fra Orchestration e Choreography spesso si perde, perciò nel seguito considereremo semplicemente la Web Services Orchestration come l’attività che le comprende entrambe.

Le tecnologie più promettenti in ambito di Web Services Orchestration sono BPEL4WS, WSCI e BPML.

52/103


3 Web Services : tecnologie

3.1 IntroduzioneL’implementazione e l’esecuzione di Web Service richiedono l’adozione di alcune tecnologie necessarie al loro funzionamento. Di tali tecnologie fanno parte ad esempio il supporto al linguaggio di programmazione e il Web Server.

Grande parte del tempo impiegato per la realizzazione di questo progetto è stato dedicato allo studio di queste tecnologie, per comprendere la loro struttura ed il loro funzionamento e per effettuare correttamente la loro installazione e configurazione. Le tecnologie utilizzate sono state scelte in base a semplici criteri di valutazione del prodotto come il fatto di essere software Open Source o meno, la libertà di utilizzo, di modifica e di personalizzazione, chiarezza e semplicità d’uso, costo ridotto o nullo ed infine inesistenza di alternative valide.

Vediamo adesso una per una le tecnologie utilizzate spiegando quale compito assolvono, come funzionano.

3.2 JavaIl linguaggio di programmazione scelto per l’implementazione dei Web Service che compongono il progetto è JAVA. Linguaggio molto diffuso, Java è utilizzabile pressoché su qualsiasi macchina semplicemente installando l’opportuna JVM (Java Virtual Machine), disponibile per i principali sistemi operativi, quali Windows, Linux, Mac o Solaris.

Il supporto Java utilizzato per questo progetto `e il J2SDK 1.4.2 05 (Java 2 Starndard Development Kit, versione 1.4.2 05).

È stato scelto Java come linguaggio di programmazione perché, oltre al fatto che è semplice trovare una grande quantità di informazioni che lo descrivono, è su di esso che sono basati molti dei software che abbiamo adottato e che vedremo più avanti.

3.3 TomCatTomcat è un Application Server basato sulla tecnologia Java, un Web Server ed un contenitore di servlet e JSP. Tomcat è necessario per fare del nostro pc o del computer che vogliamo connettere alla rete un server che possa ospitarele nostre applicazioni che desideriamo siano utilizzate da altri utenti via web. Su Tomcat possono essere caricate semplici pagine HTML come anche servlet e JSP. Relativamente semplice da configurare ed utilizzare, Tomcat è Open Source, cioè con codice liberamente visibile e modificabile, al contrario di prodotti analoghi, come ad esempio IIS (Internet Infomation Service) di Microsoft ed inoltre è liberamente scaricabile ed utilizzabile. La versione di Tomcat scelta `e la 5.0.27.

3.4 AxisAxis è l'acronimo di Apache eXtendable Interction System, si tratta di un'API di programmazione e deployment di Web Service che permette di lavorare ad un livello di astrazione elevato, evitando così di dover maneggiare direttamente l’envelope SOAP.

Axis è una piattaforma Java per la creazione e l’utilizzo di applicazioni che si basano sui Web

53/103


Services, cioè il motore per l’esecuzione di Web Service.

Axis è una servlet che, per la sua esecuzione, necessita di un contenitore di servlet che nel nostro caso è Tomcat. Axis rappresenta il supporto ai Web Services, cioè la base su cui essi poggiano. Una possibile alternativa ad Axis è costituita da JWSDP, Java Web Service Developer Pack (SUN). Nella fasedi studio e confronto di questi due software ho riscontrato una maggiore semplicità di utilizzo ed una maggiore flessibilità di Axis rispetto a JWSDP ed è per questo motivo che la scelta è ricaduta sul primo dei due.

Il framework di Axis include:

● un server stand-alone;

● un server utilizzabile all’interno di un servlet engine come Jakarta Tomcat;

● implementazione di SOAP 1.1/1.2,

● supporto JWS (Java Web Services),

● supporto per WSDL (Web Service Description Language);

● meccanismi per il deployment dei Web Service;

● supporto a differenti metodi per l’invocazione di Web Service come:

○ Stub creato da WSDL;

○ Dynamic Proxy;

○ Dynamic Invocation Interface (DII);

ai quali, nel caso in cui si faccia uso di un servizio UDDI come jUDDI (di cui parleremo in seguito), si aggiunge anche il metodo:

○ Dynamic Discovery and Invocation (DDI).

● tool di monitoraggio delle trasmissioni di messaggi: SOAP Monitor e TCP Monitor;

● utility WSDL2Java e Java2WSDL;

3.4.1 L'architettura di AxisL’ architettura di Axis è divisa in componenti lato client e lato server. Concentrando l’attenzione sull’architettura lato server, si intuisce il comportamento del SOAP Engine:

54/103


Illustrazione 3.1: Architettura Axis lato server

Si supponga che arrivi un messaggio. Esso viene gestito dall’oggetto TransportListener, il quale ha il compito di consegnare la richiesta all'Axis Engine, convertendola in un oggetto chiamato MessageContext. L'Axis Engine ha il compito di verificare la configurazione del Transport Chain e del campo opzionale Global Chain, passando loro il MessageContext .

Una Chain (rappresentata in figura dai cilindri più grandi) è una collezione ordinata di elementi che vengono invocati in sequenza. Questi elementi sono chiamati Handlers, (rappresentati dai cilindri più piccoli) e sono la parte fondamentale dell'Axis Engine. La loro presenza è necessaria per esaminare e/o modificare, secondo i relativi scopi e funzionalità, il messaggio SOAP contenuto nel MessageContext, destinato ad un determinato servizio o di ritorno da un determinato servizio invocato.

Come detto in precedenza, Axis viene anche usato sul lato client, ovvero, viene utilizzato per generare le richieste per Web Service.

In questo caso, il tragitto del messaggio è simile a quello sul lato server, con gli stessi componenti, ma con la differenza che il Service Chains, il Global Chains e il Transport Chains vengono invocati in ordine inverso.

55/103

Illustrazione 3.2: Architettura Axis lato client


Si noti come ora nel Transport è presente l'Handler Sender che è responsabile di mandare la richiesta SAOP all'Axis Server ed ottenere da quest’ultimo una risposta.

3.4.2 Installazione di AXISDal sito ufficiale14 è possibile scaricare il file di installazione. All’interno di questo, oltre alla documentazione, esempi, etc., è presente la cartella axis (sotto la cartella webapps) che contiene tutte le risorse necessarie al funzionamento di Axis. Essa va inserita nel Servlet Engine di cui si dispone; in questo progetto si è scelto il classico e diffusissimo Apache Tomcat15.

Illustrazione 3.3: Installazione AXIS

In questo caso, dunque, la cartella va brutalmente copiata sotto la webapps di Tomcat. In questo modo avremo dotato il nostro server di un Web Service engine (di fatto una struttura Servlet) in grado di esaudire richieste provenienti da qualsiasi client WS.

A questo punto, dopo aver riavviato Tomcat, apriamo il browser ed inseriamo l’indirizzo “http://localhost:8080/axis” al quale si trova la prima pagina di Axis. Se la pagina viene visualizzata significa che Axis è presente ma dobbiamo controllare che siano presenti tutti i pacchetti necessari al suo corretto funzionamento.

Sulla prima pagina di Axis possiamo notare alcuni link il primo dei quali è Validation. Facendo click su di esso ci viene restituita una pagina chiamata “Axis Happiness Page” che riporta i risultati dell’analisi della configurazione di Axis. Vengono riportati i componenti necessari ed opzionali al funzionamento di Axis ed il path ai relativi pacchetti nel caso in cui siano stati trovati.

14 Apache Axis: http://ws.apache.org/axis/15 Apache Tomcat: http://jakarta.apache.org/tomcat/

56/103

Direcotry Structure:

axis-1_2

docslibwebapps samples

axis

WEB-INFlibclassesweb.xml……


Illustrazione 3.4: Axis - Home Page su TomCat Illustrazione 3.5: Axis Happiness Page

I componenti necessari devono ovviamente essere tutti presenti, poiché senza di essi Axis non funzionerà correttamente. I componenti opzionali devono essere presenti solo nei casi in cui le applicazioni da noi sviluppate ne facciano uso.

I pacchetti mancanti, nel caso ve ne siano, devono essere inseriti nella directory “$CATALINA HOME/common/lib/”16; riavviando Tomcat tali pacchetti vengono rilevati automaticamente e ciò può essere verificato semplicemente ricaricando la pagina di validazione di Axis (“Axis Happiness Page”, raggiungibile dall’indirizzo http://localhost:8080/axis).

3.4.3 Deployment di Web Service su AxisIl deployment è un’operazione che deve essere effettuata su un Web Service affinché questo possa essere utilizzato. Attraverso l’operazione di deployment si notifica ad Axis la presenza di un nuovo servizio specificando il suo nome e la sua locazione.

In Axis, come già accennato in precedenza, vi sono due modi per effettuare il deployment di un servizio:

● deployment dinamico attraverso l’uso di file .jws;

● deployment statico attraverso l’uso di deployment descriptor.

Nel caso di un Web Service semplice si può utilizzare il primo tipo di deployment. Dopo aver creato il file java che implementa il Web Service è sufficiente sostituire l’estensione .java di tale file con l’estensione .jws e copiarlo nella directory $CATALINA HOME/webapps/axis/ o in una sua subdirectory. A questo punto il Web Service è immediatamente disponibile all’indirizzo http://localhost:8080/axis/nomeFile.jws?method=nomeMetodo poiché Axis tratta i file .jws in modo simile a quello in cui Tomcat tratta una JSP (Java Server Page). Ciò che Axis fa è localizzare il file, compilarlo e posizionare attorno ad esso un wrapper, cioè una sorta di filtro, che converte le chiamate SOAP dirette verso il servizio in invocazioni di metodi java.

È anche possibile vedere il WSDL del servizio all’indirizzo

http://localhost:8080/axis/nomeFile.jws?wsdl

16 CATALINA è il nome della variabile di ambiente che identifica la cartella di TomCat

57/103

http://localhost:8080/axis/nomeFile.jws?wsdl

http://localhost:8080/axis/nomeFile.jws?method=nomeMetodo

http://localhost:8080/axis

Illustrazione 3.6: http://localhost:8080/axis/MPHtoKMH.jws?wsdl

Via browser apparirà una pagina bianca della quale è necessario visualizzare il sorgente per vedere il WSDL.

Questa soluzione rappresenta un meccanismo di deployment facile ed immediato, ma che può essere utilizzata solo nei casi di Web Service molto semplici.

Inoltre tale soluzione presenta alcuni inconvenienti come ad esempio il fatto di non poter specificare quali metodi devono essere esposti e quali invece non devono esserlo. Altro svantaggio è quello di non poter definire un mapping dei tipi SOAP/Java personalizzato.

Nel caso invece di Web Service più complessi o nel caso in cui le caratteristiche della soluzione appena vista non siano adeguate per la nostra applicazione, vi è il metodo di deployment standard di Axis.

Questo metodo utilizza dei particolari file chiamati Web Services Deployment Descriptor (WSDD) all’interno dei quali sono inserite le informazioni relative al servizio di cui vogliamo fare il deployment. I file .wsdd permettono di specificare molte più cose riguardo all’esposizione in rete del servizio. Vediamo nel seguente codice un esempio di file deploy.wsdd della nostra applicazione Global Weather:

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

 <handler name="track" type="java:com.service.specchio.LogHandler">

<parameter name="filename" value="MyService.log"/> </handler> 




<service name="Dispatcher" provider="java:RPC" style="rpc" use="encoded">

<requestFlow> <handler type="track"/>

58/103

</requestFlow> 

<parameter name="wsdlTargetNamespace" value="urn:com.service.specchio"/> <parameter name="wsdlServiceElement" value="DispatcherService"/> <parameter name="wsdlServicePort" value="Dispatcher"/> <parameter name="className"

value="com.service.specchio.DispatcherSoapBindingImpl"/> <parameter name="wsdlPortType" value="Dispatcher"/> <parameter name="typeMappingVersion" value="1.2"/>

<operation name="getMeteoS" qname="operNS:getMeteoS" xmlns:operNS="urn:com.service.specchio" returnQName="getMeteoSReturn" returnType="rtns:string" xmlns:rtns="http://www.w3.org/2001/XMLSchema" soapAction="" >

<parameter qname="in0" type="tns:string" xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>


</operation>

<operation name="getCittas" qname="operNS:getCittas" xmlns:operNS="urn:com.service.specchio" returnQName="getCittasReturn" returnType="rtns:string" xmlns:rtns="http://www.w3.org/2001/XMLSchema" soapAction="" >


</operation>

<operation name="getMPHtoKMHs" qname="operNS:getMPHtoKMHs" xmlns:operNS="urn:com.service.specchio" returnQName="getMPHtoKMHsReturn" returnType="rtns:double" xmlns:rtns="http://www.w3.org/2001/XMLSchema" soapAction="" >

<parameter qname="in0" type="tns:double" xmlns:tns="http://www.w3.org/2001/XMLSchema"/>

</operation>

<parameter name="allowedMethods" value="getCittas getMPHtoKMHs getMeteoS"/>

<parameter name="scope" value="Session"/>

</service></deployment>

Listato 3.1 - deployment descriptor dell'applicazione Global Weather – deploy.wsddAll’interno dell’elemento deployment, che riporta i namespace a cui si fa riferimento, si trova l’elemento service che specifica le informazioni relative al servizio di cui vogliamo fare il deployment.

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">... <service name="Dispatcher" provider="java:RPC" style="rpc" use="encoded"> ... </service></deployment>Nel tag service possiamo vedere due attributi con i quali vengono specificati il nome del servizio e

59/103

lo stile dell’applicazione, in questo esempio RPC.

All’interno dell’elemento service vi sono gli elementi parameter:

<parameter name="wsdlTargetNamespace" value="urn:com.service.specchio"/><parameter name="wsdlServiceElement" value="DispatcherService"/><parameter name="wsdlServicePort" value="Dispatcher"/><parameter name="className"

value="com.service.specchio.DispatcherSoapBindingImpl"/><parameter name="wsdlPortType" value="Dispatcher"/><parameter name="typeMappingVersion" value="1.2"/>...<parameter name="allowedMethods" value="getCittas getMPHtoKMHs getMeteoS"/><parameter name="scope" value="Session"/>tra i quali evidenziamo, quello che specifica il nome della classe che implementa il servizio ed il package in cui si trova mentre il secondo riporta i metodi che possono essere esposti (“allowedMethods”: metodi concessi) ad un utilizzo diretto da altri servizi (in questo esempio avremmo potuto inserire il carattere asterisco “*” al posto dei valori, in modo tale che tutti i metodi della classe siano utilizzabili dall’esterno).

Tra i vari elementi che compongono il file deploy.wsdd sono presenti anche i tag operation il quali, specificano le caratteristiche di un metodo ed i suoi parametri. Ad esempio il metodo getMeteoS viene così definito:

...<operation name="getMeteoS" qname="operNS:getMeteoS"

xmlns:operNS="urn:com.service.specchio" returnQName="getMeteoSReturn" returnType="rtns:string" xmlns:rtns="http://www.w3.org/2001/XMLSchema" soapAction="" >



</operation>...dall'analisi del suo è facile evincere che questi restituisce un parametro di tipo string ed accetta due parametri di input di ugual tipologia.

Infine evidenziamo la presenza del tag handler definito immediatamente dopo il tag deployment:

<handler name="track" type="java:com.service.specchio.LogHandler"><parameter name="filename" value="MyService.log"/>

</handler>...<requestFlow> <handler type="track"/></requestFlow>anche tale elemento è caratterizzato da un proprio nome univoco, il nome della classe che implementa l'handler, ed il file in cui salverà le sue elaborazioni; infatti, tale hadler effettua un log dell'utilizzo del Web Service.

Una volta creato il file deploy.wsdd, dobbiamo per prima cosa copiare il package contenente le classi che realizzano il Web Service nella directory “$CATALINA HOME/webapps-/axis/WEB-INF/classes” e, successivamente, da tale posizione eseguire l’operazione di deployment utilizzando un

60/103


apposito tool di Axis da linea di comando:

java org.apache.axis.client.AdminClient ‘‘PackagePath’’/deploy.wsddA questo punto il servizio è disponibile.

Nel caso in cui si voglia rendere tale servizio non disponibile dobbiamo utilizzare lo stesso tool con un file di undeployment, ad esempio undeploy.wsdd, come quello che segue:

<undeployment xmlns="http://xml.apache.org/axis/wsdd/">


<service name="Dispatcher"/></undeployment>

Listato 3.2 - undeployment descriptor dell'applicazione Global Weather – undeploy.wsddjava org.apache.axis.client.AdminClient ‘‘PackagePath’’/undeploy.wsddLa lista di tutti i servizi disponibili può essere ottenuta dalla prima pagina di Axis “http://localhost:8080/axis/” , cliccando sul link View.

Illustrazione 3.7: Axis - Servizi Disponibil

61/103

http://localhost:8080/axis/


3.4.4 Strumenti per il monitoraggio delle comunicazioniAxis mette a disposizione dello sviluppatore due utili strumenti per il monitoraggio di connessioni e comunicazioni, quali TCPMonitor e SOAPMonitor.

TCPMonitor è utilizzato per monitorare il flusso di dati su una connessione TCP. Viene posizionato fra un client ed un server, dove acquisisce i dati, inviati in una connessione stabilita con esso dal client, li visualizza nella sua interfaccia grafica ed infine li inoltra al server. Allo stesso modo, i dati inviati come risposta dal server verranno visualizzati nell’interfaccia di TCPMonitor prima di essere inoltrati al client.

Per utilizzare TCPMonitor è necessario digitare da linea di comando la seguente istruzione:

java org.apache.axis.utils.tcpmon

Illustrazione 3.8: TCPMonitor - Admin

Viene caricata l’interfaccia grafica di TCPMonitor, visualizzando la pagina principale, dalla quale può essere creato un nuovo TCP/IP Monitor, specificando alcuni dati, come ad esempio la porta sulla quale attendere connessioni in entrata (Listen Port) e l’Hostname (Target Hostname) e la porta (Target Port) sui quali inoltrare tali connessioni.

La creazione di un nuovo TCP/IP Monitor farà apparire una nuova finestra nell’interfaccia grafica.

62/103


Illustrazione 3.9: TCPMonitor

In essa, ogni volta che verrà effettuata una connessione alla “ListenPort”, saranno visualizzati i messaggi di richiesta verso il server e quelli di risposta da esso, nei riquadri ad essi relativi .

Nella parte alta del pannello sono riportate tutte le connessioni effettuate, che possono essere selezionate per visualizzare i relativi messaggi di richiesta e risposta.

SOAPMonitor è uno strumento molto utile per gli sviluppatori di Web Service poiché consente di vedere i messaggi SOAP utilizzati per invocare i Web Service.

Per poter utilizzare questa utility, al fine di monitorare i messaggi SOAP ricevuti e restituiti da un Web Service, bisogna prima seguire alcuni passi di preparazione.

Per prima cosa è necessario compilare l’applet che implementa SOAP Monitor eseguendo da linea di comando, dalla directory “webapps/axis” di Tomcat, la seguente istruzione:

javac -classpath WEB-INF/lib/axis.jar SOAPMonitorApplet.javaSi osservi che se axis.jar è nel classpath non è necessario specificare l’opzione -classpath ma è sufficiente eseguire “javac SOAPMonitorApplet.java”.

Dopo aver compilato l’applet, dobbiamo effettuare il deployment, esattamente come visto in precedenza, creando un file di deployment per SOAPMonitor come il seguente:

<deployment xmlns="http://xml.apache.org/axis/wsdd/"xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"><handler name="soapmonitor"

type="java:org.apache.axis.handlers.SOAPMonitorHandler"><parameter name="wsdlURL"

value="/axis/SOAPMonitorService-impl.wsdl"/>

63/103


<parameter name="namespace"value="http://tempuri.org/wsdl/2001/12/SOAPMonitorService-impl.wsdl"/>

<parameter name="serviceName" value="SOAPMonitorService"/><parameter name="portName" value="Demo"/>

</handler><service name="SOAPMonitorService" provider="java:RPC">

<parameter name="allowedMethods" value="publishMessage"/><parameter name="className"

value="org.apache.axis.monitor.SOAPMonitorService"/><parameter name="scope" value="Application"/>

</service></deployment>

Listato 3.3 - deploy-SOAPMonitor.wsddchiamato ad esempio deploy-SOAPMonitor.wsdd, ed eseguendo il comando

java org.apache.axis.client.AdminClient deploy-monitor.wsddDopo aver effettuato tali operazioni, il servizio SOAPMonitor è abilitato ed infatti viene inserito tra i servizi disponibili alla pagina “http://localhost:8080/axis/servlet/AxisServlet”, raggiungibile dalla prima pagina di Axis tramite il link “List”.

A questo punto dobbiamo specificare i Web Service dei quali vogliamo monitorare i messaggi in arrivo ed in partenza. Per fare questo dobbiamo effettuare una modifica al file di deployment di tali Web Service, inserendo, immediatamente dopo al tag di apertura dell’elemento <service>, le definizioni dei due elementi requestFlow e responseFlow, come riportato nel seguente codice:

...<service name="MergeService" provider="java:RPC">

<requestFlow><handler type="soapmonitor"/>

</requestFlow><responseFlow>

<handler type="soapmonitor"/></responseFlow>

...Con questi due elementi viene specificato soapmonitor come gestore del flusso dei messaggi di richiesta e del flusso dei messaggi di risposta. Affinché queste modifiche abbiano effetto dobbiamo effettuare il deployment del servizio, come visto in precedenza, ma non prima di averne eseguito l’undeployment nel caso in cui tale servizio fosse già attivo su Axis.

A questo punto possiamo lanciare SOAPMonitor, caricando da browser l’URL “http://localhost:8080/axis/SOAPMonitor”, ed ogni messaggio ricevuto ed inviato dai Web Service che vengono monitorati apparirà nei relativi box dell’interfaccia di SOAPMonitor, come si può vedere in figura

64/103

http://localhost:8080/axis/SOAPMonitor

http://localhost:8080/axis/servlet/AxisServlet


Illustrazione 3.10: SOAPMonitor

3.5 MySQLIl progetto ha richiesto l’utilizzo di un database che permettesse di immagazzinare informazioni relative al registro UDDI e la scelta è ricaduta su MySQL. MySQL è un Database Management System (DBMS) relazionale, cioè un sistema per la gestione di database relazionali, potente e facile da usare. Le alternative a MySQL sono molte; vi sono ad esempio DB2, Oracle, PostgreSql. Fra tutti è stato però scelto MySQL per il fatto di essere Open Source e, soprattutto, gratuito.

3.6 jUDDIjUDDI è l’implementazione Java delle specifiche di UDDI, di cui abbiamo parlato in precedenza. Progetto Open Source sviluppato anch’esso da Apache, jUDDI mette a disposizione il servizio UDDI attraverso l’uso di un database, che nel nostro caso è fornito da MySQL, e delle API già descritte in passato, implementate in Java.

L’utilizzo diMySQL, come già accennato nel paragrafo ad esso relativo, è stato necessario esclusivamente come supporto per jUDDI.

Vediamo adesso la procedura da seguire per ottenere un servizio UDDI implementato utilizzando jUDDI e MySQL.

3.6.1 Installazione di jUDDIRequisito essenziale per l’installazione di jUDDI è la presenza ed il corretto funzionamento di Tomcat all’interno del sistema. La procedura di installazione di jUDDI prevede come prima cosa la preparazione del database MySQL, specificando una configurazione che ci permetta, attraverso l’uso di userid e password, di accedere ai dati per leggerli e modificarli.

Connettiamoci quindi a MySQL digitando da shell il seguente comando

mysql --host=localhost --port=3306 --user=root --password=123456

65/103


Listato 3.4 - Connessione al DBMS MySQLIl comando precedente effettua una connessione con il servizio MySQL, specificando l’host e la porta alle quali deve essere effettuata tale connessione e username e password per ottenere l’accesso; se l’accesso è ottenuto, viene presentato il prompt di MySQL, dal quale possono essere eseguite le query sui database.

mysql>Dal prompt di MySQL dobbiamo inserire le seguenti istruzioni, per configurare il database e prepararlo all’utilizzo di jUDDI.

Creazione del database jUDDI:

DROP DATABASE IF EXISTS juddi;CREATE DATABASE juddi;

Listato 3.5 - Creazione del database jUDDISettaggio dei privilegi generali per l’utente jUDDI:

REPLACE INTO mysql.user SETHost = ’%’, # tutti gli host (incluso localhost)User = ’juddi’,Password = PASSWORD(’123456’),Select_priv = ’Y’,Insert_priv = ’Y’,Update_priv = ’Y’,Delete_priv = ’Y’,Create_priv = ’Y’,Drop_priv = ’Y’,Reload_priv = ’Y’,Shutdown_priv = ’Y’,Process_priv = ’Y’,File_priv = ’Y’,Grant_priv = ’Y’,References_priv = ’Y’,Index_priv = ’Y’,Alter_priv = ’Y’

;FLUSH PRIVILEGES;

Listato 3.6 - Settaggio dei privilegi generali per l’utente jUDDICancellazione degli utenti con campo “User” vuoto:

DELETE FROM mysql.user WHERE User=’’;UPDATE mysql.user SET Password=PASSWORD(’123456’)

WHERE user=’root’;

66/103


FLUSH PRIVILEGES; # requiredListato 3.7 - Cancellazione degli utenti con campo “User” vuoto

Settaggio dei privilegi db e host per l’utente jUDDI:

INSERT INTO mysql.db SETHost = ’%’,Db = ’juddi%’,User = ’juddi’,Select_priv = ’Y’, Insert_priv = ’Y’,Update_priv = ’Y’, Delete_priv = ’Y’,Create_priv = ’Y’, Drop_priv = ’Y’,Grant_priv = ’N’, References_priv = ’Y’,Index_priv = ’Y’, Alter_priv = ’Y’,

;INSERT INTO mysql.host SET

Host = ’%’,Db = ’juddi%’,Select_priv = ’Y’, Insert_priv = ’Y’,Update_priv = ’Y’, Delete_priv = ’Y’,Create_priv = ’N’, Drop_priv = ’N’,Grant_priv = ’N’, References_priv = ’N’,Index_priv = ’N’, Alter_priv = ’N’,

;Listato 3.8 - Settaggio dei privilegi db e host per l’utente jUDDI

A questo punto dobbiamo creare le tabelle di jUDDI. Per fare questo dobbiamo prima di tutto scaricare da Internet il pacchetto relativo a jUDDI; per questo progetto è stata utilizzata la versione 0.9rc3. Scompattando questo pacchetto troviamo al suo interno, nella subdirectory “juddi-0.9rc3-src/sql/mysql” il file create database.sql.

Prendiamo il codice che si trova in questo file ed eseguiamolo in MySQL semplicemente digitando al prompt di MySQL la seguente istruzione:

SOURCE /.../juddi-0.9rc3/sql/mysql/create_database.sqlListato 3.9 - esecuzione del file database.sql da riga di comando MySQL

I puntini /.../ stanno ad indicare che è necessario trovare il path alla posizione in cui abbiamo estratto i file del pacchetto juddi-0.9rc3 e con questo sostituirli.

Adesso il database di jUDDI è pronto. Dobbiamo solo aggiungere un jUDDI Publisher, cioè l’entità preposta a pubblicare informazioni sul database jUDDI. L’istruzione da eseguire, che può essere personalizzata cambiando ad esempio identificativo o nome del Publisher, è la seguente. Vengono specificati l’identificativo con cui avviene l’autenticazione del Publisher, il nome del Publisher, l’abilitazione ed il possesso di privilegi amministrativi.

INSERT INTO PUBLISHER (PUBLISHER_ID,PUBLISHER_NAME,ENABLED,ADMIN)

67/103

VALUES (’juddi’,’juddi user’,’true’,’true’);Listato 3.10 - Inserimento del Pubblischer

La preparazione di MySQL per jUDDI è terminata. Possiamo quindi uscire dalla sessione di MySQL digitando il comando

quitPassiamo adesso alla configurazione della servlet jUDDI.

All’interno di “juddi-0.9rc3-src/webapps/” si trova la directory “juddi”; dobbiamo copiarla nella directory “$CATALINA HOME/webapps/”.

Accediamo adesso al file juddi.properties contenuto nella directory “$CATALINA HOME/webapps/juddi/WEB-INF/” e modifichiamo come segue.

Alla riga

# jUDDI DataSource to usejuddi.dataSource=java:comp/env/jdbc/juddiDB

Listato 3.11 - modifiche al file juddi.propertiesdobbiamo sostituire “juddiDB” con “juddi”; questo specifica il nome della sorgente dei dati, cioè il database.

Dobbiamo adesso, come abbiamo fatto anche nel caso di Axis, informare Tomcat della presenza di jUDDI, specificando alcuni parametri.

Accediamo quindi al file server.xml contenuto in “$CATALINA HOME/conf/” ed aggiungiamo le linee riportate di seguito all’interno dell’elemento <HOST>.

<Context path="/juddi" docBase="juddi" debug="5" reloadable="true"crossContext="true"><Logger className="org.apache.catalina.logger.FileLogger"

prefix="localhost_juddiDB_log" suffix=".txt"timestamp="true"/>

<Resource name="jdbc/juddi" auth="Container" type="javax.sql.DataSource"/><ResourceParams name="jdbc/juddi">

<parameter><name>factory</name><value>org.apache.commons.dbcp.BasicDataSourceFactory</value>

</parameter><parameter><name>maxActive</name><value>100</value></parameter>

68/103

<parameter><name>maxIdle</name><value>30</value>

</parameter><parameter>

<name>maxWait</name><value>10000</value>

</parameter><parameter>

<name>username</name><value>juddi</value>


<name>password</name><value>123456</value>

</parameter><parameter>

<name>driverClassName</name><value>org.gjt.mm.mysql.Driver</value>

</parameter><parameter>

<name>url</name><value>jdbc:mysql://host.domain.com:3306/juddiautoReconnect=true</value>


<name>validationQuery</name><value>select count(*) from PUBLISHER</value>

</parameter></ResourceParams>

</Context>

69/103


Listato 3.12 - modifiche al file server.xmlEffettuata questa aggiunta al file server.xml, dobbiamo eseguire una modifica in due file: “happyjuddi.jsp”, contenuto in “$CATALINA HOME/webapps/juddi/”, e “web.xml”, contenuto in “$CATALINA HOME/webapps/juddi/WEB-INF/”.

È necessario sostituire “jdbc/juddiDB” con “jdbc/juddi” in happyjuddi.jsp alla seguente linea

dsname = ‘‘java:comp/env/jdbc/juddi’’;Listato 3.13 - modifiche al file happyjuddi.jsp

ed in web.xml alle successive

<resource-ref><description>jUDDI DataSource</description><res-ref-name>jdbc/juddiDB</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth>

</resource-ref>Listato 3.14 - modifiche al file web.xml

Infine abbiamo bisogno del pacchetto contenente la classe del Driver per la connessione al database, che può essere scaricato da internet. Il pacchetto utilizzato è mysql-connector-java-3.0.16XX.jar contenente la classe org.gjt.mm.mysql.Driver. La locazione in cui va inserito `e “$CATALINA HOME/common/lib/”.

A questo punto tutto è pronto e possiamo quindi testare l’installazione. Dopo aver riavviato Tomcat inseriamo nel browser l’indirizzo “http://localhost:8080/juddi” ed otteniamo la prima pagina di jUDDI. Per il test dell’installazione facciamo click sul link “Validate”. Questo chiama la pagina happyjuddi.jsp che effettua la verifica della configurazione e presenta una pagina di report, riportata in figura sottostante.

70/103

http://localhost:8080/juddi


Illustrazione 3.11: Happy jUDDI Page

Se la nostra installazione è corretta vengono specificati tutti i path alle locazioni in cui sono state trovate le classi e le librerie necessarie al funzionamento di jUDDI ed inoltre, più in basso nella pagina, sono riportate le informazioni relative al DataSource, cioè al database jUDDI, ed alla connessione ad esso.

Illustrazione 3.12: Happy jUDDI Page - DataSource

3.7 UDDI4JUDDI4J è una libreria di classi Java che fornisce un’API per interagire con un registro UDDI. Questa libreria genera i messaggi da spedire ad un server UDDI ed effettua il parsing di quelli ricevuti da un server UDDI.

La classe principale in quest’insieme di API è org.uddi4j.client.UDDIProxy.

Attraverso di essa viene creato un proxy per l’accesso al server UDDI, mettendo a disposizione dei metodi che rispettano le specifiche delle API di UDDI (UDDI Programmer’s API Specification).

71/103


Le classi all’interno di org.uddi4j.datatype rappresentano gli oggetti utilizzati per spedire o ricevere informazioni da UDDI; datatype è suddiviso in sottopacchetti relativi ai vari argomenti trattati da UDDI, come business, service, tmodel, binding e assertion.

Vi sono poi i due sottopacchetti org.uddi4j.request e org.uddi4j.response che contengono rispettivamente i possibili messaggi di richiesta di informazioni al server UDDI e quelli che quest’ultimo può inviare come risposta.

Infine in org.uddi4j.transport si trovano i supporti ai protocolli di trasmissione che possono essere utilizzati per l’invio dei messaggi.

3.7.1 Installazione di UDDI4JPer utilizzare UDDI4J è necessario il pacchetto uddi4j.jar, scaricabile da Internet. In questo progetto è stato utilizzata la versione 2.0.2, ottenuta scaricando il file uddi4j-bin-2 0 2.zip.

Dopo aver acquisito il pacchetto, esso è stato copiato nella directory $CATALINA HOME/webapps/axis/WEB-INF/lib/ e tale percorso a uddi4j.jar è stato inserito al CLASSPATH nel file /etc/profile.

UDDI4J non necessita di alcuna installazione e, dopo aver riavviato il sistema in modo che venga aggiornato il CLASSPATH, UDDI4J può essere utilizzato.

3.8 Tecniche di invocazione di Web ServiceLa tecnologia utilizzata per l’invocazione dei Web Service realizzati in questo progetto è JAX-RPC (Java API for XML-Based Remote Procedure Call). JAX-RPC permette di invocare Web Service, impostando in modo semplice e veloce i parametri di tale invocazione. Questa tecnologia fornisce inoltre il supporto per il mapping dei tipi da XML a Java e viceversa.

JAX-RPC, che necessita di SOAP (sopra HTTP), mette a disposizione il supporto per il modello di scambio di messaggi SOAP.

Come già accennato nel paragrafo dedito alla presentazione di Axis, le possibili metodologie di invocazione di un Web Service sono:

● Stub creato da WSDL;

● Dynamic Proxy;

● Dynamic Invocation Interface (DII);

● Dynamic Discovery and Invocation (DDI), nel caso in cui si faccia uso di un servizio UDDI come jUDDI.

3.8.1 Stub creato da WSDLIl metodo Stub, dove lo stub rappresenta il lato client di un servizio, utilizza il file WSDL per ottenere informazioni riguardanti quel servizio. Prima della fase di esecuzione viene creato uno stub, specifico per la piattaforma che stiamo utilizzando, durante la fase di mapping delle informazioni da WSDL a Java. Dato che tale stub è creato prima della fase di esecuzione esso viene a volte chiamato static stub.

Lo stub è costituito da una classe Java che implementa una SEI (Service Endpoint Interface). La Service Endpoint Interface è la rappresentazione Java delle operazioni del Web Service che sono descritte dall’elemento PortType all’interno del documento WSDL, cioè un’interfaccia Java che

72/103


definisce i metodi utilizzati dal client per interagire con il Web Service. Come abbiamo già detto la SEI è generata prima della fase di esecuzione; la sua creazione avviene attraverso l’uso di appositi tool per il mapping da WSDL a Java, come ad esempio WSDL2Java di Apache Axis.

Lo stub è quindi una classe che agisce da proxy per un servizio remoto.

Il vantaggio del metodo stub è la semplicità; servono infatti poche linee di codice, come si può vedere dal seguente frammento, per invocare un Web Service.

// StubName: nome di esempio della classe che costituisce lo stub.StubName stub = (StubName) service.getStubName();// Invocazione del metodo di esempio StubMethod del web servicestub.getStubMethod("...");

Listato 3.15 - Esempio di StubNecessaria è la conoscenza in fase di sviluppo dell’URL del file WSDL, che deve essere passato al tool di mapping WSDL-to-Java per la generazione dello stub ed inoltre lo stub non è portabile perché dipendente, abbiamo già detto, dalla specifica piattaforma su cui è stato creato.

Se riprendiamo la classe http://localhost:8080/axis/MPHtoKMH.jws?wsdl , la quale ricordiamo effettua la conversione da MPH a KMH, precedentemente presentata nel paragrafo dedicato al deployment in Axis, il suo stub può essere ottenuto digitando da riga di comando la seguente:

java org.apache.axis.wsdl.WSDL2Java http://localhost:8080/axis/MPHtoKMH.jws?wsdl

Listato 3.16 - Classi che verranno invocate dallo stubottenendo così un package di classi che andranno opportunamente compilate unitamente al client di testing.

import localhost.axis.MPHtoKMH_jws.*;public class MPHtoKMHClient { public static void main(String [] args) throws Exception { MPHtoKMHService sl = new MPHtoKMHServiceLocator(); MPHtoKMH mul = (MPHtoKMH)sl.getMPHtoKMH(); System.out.println("Risultato: 37MPH = " + mul.getMPHtoKMH(37)+"KMH"); }}

Listato 3.17 - Classe di testing stub

3.8.2 Dynamic ProxyIl metodo Dynamic Proxy, a differenza del metodo Stub, non crea una classe specifica per un dato Web Service prima della fase di esecuzione. Questo metodo utilizza un proxy per invocare la specifica operazione del Web Service.

Il proxy è una classe Java che, come nel caso dello Stub, implementa la SEI; il proxy è però creato a tempo di esecuzione ed ottenuto dal metodo getPort(), di JAX-RPC Service, il quale prende il nome della porta relativa al servizio che vogliamo invocare ed il nome della classe che rappresenta la SEI che viene implementata dal proxy. Possiamo vedere nel seguente frammento il codice necessario ad

73/103

http://localhost:8080/axis/MPHtoKMH.jws?wsdl


effettuare l’invocazione di un’operazione di un Web Service facendo uso del metodo Dynamic Proxy.

// WSURL.com: indirizzo d’esempio al quale si trova il web service// che vogliamo invocare.String namespace = "http://WSURL.com";// WSName: nome d’esempio del web service che vogliamo invocare.String portName = "WSName";// portQN: porta alla quale effettuare l’invocazione.QName portQN = new QName(namespace, portName);// WSName: nome della classe generata, che rappresenta il proxy.WSName proxy = service.getPort(portQN, ProxyName.class);// Invocazione del metodo di esempio ProxyMethod del web serviceproxy.getProxyMethod("...");

Listato 3.18 - Dynamic ProxyQuesto metodo è definito dynamic, cioè dinamico, perché il proxy é creato a tempo di esecuzione. È comunque necessario, come nel caso di Static Stub, conoscere a development-time l’interfaccia dell’operazione che viene invocata.

Il vantaggio di questo metodo è è la creazione di codice portabile ed indipendente dalla piattaforma.

3.8.3 Dynamic Invocation Interface (DII)Il metodo Dynamic Invocation Interface complica un poco il codice ma fornisce un livello di dinamicità più elevato. Non è più necessario conoscere l’URL del file WSDL a development-time. Inoltre JAX-RPC Service non viene più utilizzato per ottenere un proxy, bensì per l’istanziazione di JAX-RPC Calls, utilizzate per l’invocazione del Web Service.

Vediamo nel seguente frammento il codice che realizza la Dynamic Invocation Interface.

// WSURL.com: indirizzo d’esempio al quale si trova il web service// che vogliamo invocare.String namespace = "http://WSURL.com";// WSName: nome d’esempio del web service che vogliamo invocare.String portName = "WSName";// portQN: porta alla quale effettuare l’invocazione.QName portQN = new QName(namespace, portName);// getMethod: nome dell’operazione da invocare.String operationName = "getMethod";// Creo la chiamata call.Call call = service.createCall();// Imposto le caratteristiche della chiamata.// Setto la porta alla quale viene fatta l’invocazione.call.setPortTypeName(portQN);

74/103


// Setto il nome dell’operazione da invocare.call.setOperationName(new QName(namespace, operationName));// Setto la codifica.call.setProperty(Call.ENCODINGSTYLE_URI_PROPERTY, "");// Setto lo stile dell’operazione.call.setProperty(Call.OPERATION_STYLE_PROPERTY, "rpc");// Aggiungo il parametro "param1", di cui specifico il tipo ed il// fatto che \‘e un parametro d’ingresso.call.addParameter("param1", <xsd:string>, ParameterMode.IN);// Setto il tipo di ritorno.call.setReturnType(<xsd:string>);Creo l’array dei parametri da passare nell’invocazione.Object[] inParams = new Object[] {"..."};// Effettuo l’invocazione passando l’array dei parametri inParams// ed acquisisco il risultato.String ret = (String) call.invoke(inParams);

Listato 3.19 - Dynamic Invocation InterfaceIl vantaggio di utilizzare DII sta nel fatto che per invocare una procedura remota non è necessario conoscere il file WSDL e non è richiesta la generazione di classi, come avviene nei casi di Dynamic Proxy e Static Stub.

Devono però essere conosciuti l’indirizzo del servizio, le operazioni che mette a disposizione ed i parametri da queste accettati. Queste informazioni vengono utilizzate dal client DII dinamicamente a runtime.

Se consideriamo anche in questo caso la classe http://localhost:8080/axis/MPHtoKMH.jws?wsdl , la quale ricordiamo effettua la conversione da MPH a KMH, precedentemente presentata nel paragrafo dedicato al deployment in Axis, il suo client di testing in modalità DII potrà essere implementato nella seguente maniera:

import org.apache.axis.client.*;import javax.xml.namespace.QName;import javax.xml.rpc.ParameterMode;import javax.xml.rpc.encoding.XMLType;public class MPHtoKMHClientDII {

public static void main(String[] args) throws Exception {String endpoint = "http://localhost:8080/axis/MPHtoKMH.jws";Service service = new Service();Call call = (Call) service.createCall();call.setTargetEndpointAddress(new java.net.URL(endpoint));call.setOperationName("getMPHtoKMH");call.addParameter("op1", XMLType.XSD_DOUBLE, ParameterMode.IN);

75/103

http://localhost:8080/axis/MPHtoKMH.jws?wsdl


//call.addParameter("op2", XMLType.XSD_INT, ParameterMode.IN);call.setReturnType(XMLType.XSD_DOUBLE);Double ret = (Double) call.invoke(new Object[] {new Double(37)});System.out.println("Risultato:" + ret);}

}Listato 3.20 - Classi di test DII

3.8.4 Dynamic Discovery and Invocation (DDI)Dynamic Discovery and Invocation rappresenta la soluzione più dinamica nell’invocazione di Web Service. Questo metodo è un’evoluzione del DII appena descritto, con la differenza per DDI non è necessario conoscere in anticipo l’indirizzo del servizio, le sue operazioni ed i parametri d’ingresso di queste ultime. Tutte queste informazioni verranno reperite a tempo di esecuzione grazie al servizio UDDI, di cui abbiamo parlato nel capitolo precedente, che permette di cercare Web Service ed ottenere così tutto ciò che è necessario sapere per invocarli.

Prima di presentare frammenti di codice che hanno caratterizzato il progetto, a titolo esemplificativo verrà presentata parte della classe DispatcherSoapBindingImpl.java, la quale implementa il metodo getCittas, il quale ottiene un elenco di città di una data nazione previo interrogazione del registro UDDI in modalità DDI.

Si evidenzia comunque, che esistono diversi modi possibili per realizzare la Dynamic Discovery and Invocation.

1. Richiedere al servizio UDDI informazioni relative al Web Service che vogliamo invocare, fra le quali otteniamo l’URL del file WSDL che lo descrive. Questo può essere fatto utilizzando le librerie UDDI4J.

2. Eseguire il parsing del documento WSDL, ad esempio attraverso l’utility WSDL4J di Axis, ed ottenere le informazioni necessarie all’invocazione del Web Service come namespace, nome dell’operazione e parametri.

3. Invocare il servizio utilizzando il metodo DII con i valori ottenuti al passo precedente.

package com.service.specchio;import java.net.*;import java.util.*;;import javax.wsdl.*;;import javax.xml.namespace.QName;import org.apache.axis.client.Call;import org.uddi4j.*;import com.ibm.wsdl.factory.WSDLFactoryImpl;public class DispatcherSoapBindingImpl

implements com.service.specchio.Dispatcher_PortType{:::: public java.lang.String getCittas(java.lang.String in0)

76/103


throws java.rmi.RemoteException { //t-model finger print associato al servizio String tmodelFingerPrint="uuid:E470C400-0269-11DD-ACCE-D6A9BB0AE7F0";

Object [] parametro= new Object[1];parametro[0]= in0;

Vector listBTemplate=null;System.out.println("Avvio chiamata a UDDI .....");

try{

System.out.println("getMeteoService: Cerco i binding Template..."); listBTemplate=findBindinTemplate( tmodelFingerPrint); System.out.println("getMeteoService: Fine ricerca binding Template.

Trovati: "+listBTemplate.size());}catch(Exception e){

System.out.println("ERRORE : Container non attivo!");}

Object risposta=null;if (listBTemplate!=null){// Intercetto il binding associato e scorro la lista.AccessPoint accessPoint = null;BindingTemplate bindingTemplate = null;

for(int i=0; i<listBTemplate.size(); i++) {

try {//Cerco il binding template con un punto di accesso HTTPbindingTemplate = (BindingTemplate)listBTemplate.elementAt(i);accessPoint = bindingTemplate.getAccessPoint();// ottenuta la lista di binding template, possiamo ottenere// la lista delle URL associateVector tmodelInstanceInfoVector = bindingTemplate.

getTModelInstanceDetails().getTModelInstanceInfoVector();

for(int k=0; k<tmodelInstanceInfoVector.size(); k++) {TModelInstanceInfo instanceInfo =(TmodelInstanceInfo)

tmodelInstanceInfoVector.elementAt(k);InstanceDetails details =

instanceInfo.getInstanceDetails();OverviewDoc wsdlImpl =

details.getOverviewDoc();try {

risposta= (String) parseWSDLCittas( wsdlImpl.getOverviewURLString(), parametro);

System.out.println("Presa la risposta+ : "+risposta);

if (risposta!=null) { i++; break;

}//if

77/103


} catch (MalformedURLException e) {// TODO Auto-generated catch blockcontinue;

}//catch

}//for

}catch (WSDLException e) {// TODO Auto-generated catch blockcontinue;

}//catch

}//for

}else return (String)null;

System.out.println("FINE CHIAMATA");System.out.println("\t \t \t");String temp= ""+risposta.toString();

return (java.lang.String)temp; }//getCittas::::

}// DispatcherSoapBindingImplListato 3.21 - Classi DispatcherSoapBindingImpl con DDI

78/103


4 Global Weather Web Service

4.1 IntroduzioneIn questo capitolo, verrà presentata la parte implementativa del progetto Global Weather, mediante realizzazione di diagrammi UML, ovvero Class Diagram, Use Cases, e Sequence Diagram, in modo tale da fornire una quanto più esaustiva visita correlata del sistema proposto, ed ottenere quindi un buon livello di comprensione dell'architettura posta in esame.

A tal proposito, risulta doveroso evidenziare che trattandosi di un'applicazione Web, se pur basata su Web Service, questi risulta sempre essere basata su sistemi ad oggetti che hanno alcune peculiarità: l'interfaccia utente che coincide con un Internet browser e la comunicazione tra il cliente e il server la quale avviene tramite il protocollo HTTP mediante scambio di messaggi SOAP. Si tratta quindi di un'applicazione che rispecchia perfettamente il pattern MVC (Model View Controll) dove:

● la Vista è l'interfaccia per l'interazione con l'utente, come vedremo tale livello coinciderà con delle pagine web che verranno presentate all'utente finale da parte di alcune servlet dedite alla raccolta dei dati inseriti ed alla successiva richiesta di elaborazione degli stessi da parte della logica di controllo;

● il Controllo è appunto la logica per la gestione del flusso di dati tra gli schemi e le operazioni sul modello, come vedremo tale livello coinciderà con Web Service locale, il quale fungerà da intermediario tra i Web Service remoti ed il Service Registry;

● il Modello sono i componenti che rappresentano i dati e la logica del problema, come vedremo tale livello coinciderà con i Service Provider che risponderanno alla richieste;

79/103


4.2 Il WorkflowL'applicazione fornisce le previsioni meteo della città di una data nazione scelta, i cui valori delle misure rilevate vengono appositamente fornite in KM/H. Tale risultato, risulta essere l'esito delle seguenti attività:

Illustrazione 4.1: WS Global Weather – Passo 1 : selezione della nazione

1. Una Servlet, denominata DispatcherServices, riceve in input dalla pagina web ServizioWeb.html, il nominativo della nazione (di default è impostata l'Italia) di cui si vuole ottenere l'elenco delle città, tramite l'invocazione del metodo getCittas.

call.invoke("getCittas", inx)2. La richiesta di elenco delle città, viene raccolta e gestita da un apposito Web Service locale,

denominato DispatcherService, il quale funge da interfaccia per la classe DispatcherSoapBindingImpl mediante la quale si implementa un Web Service coordinatore verso altri servizi web dedicati, invocati attraverso la metodologia Dynamic Discovery and Invocation (DDI). Nella fattispecie tale operazione consiste nei seguenti passi:

■ il DispatcherService, richiedere al servizio UDDI locale informazioni relative al Web Service che vogliamo invocare tramite il rispettivo Tmodel FingerPrint, ed ottiene una lista di URL di file WSDL che soddisfano tale richiesta, ovvero un Binding Template.

//t-model finger print associato al servizio String tmodelFingerPrint=

"uuid:E470C400-0269-11DD-ACCE-D6A9BB0AE7F0"; ...

listBTemplate=findBindinTemplate( tmodelFingerPrint);...

■ Ottenuto il Binding Template, il DispatcherService, man mano che effettua la scansione della lista di Binding Template, esegue il parsing del documento WSDL, attraverso l’utility WSDL4J di Axis realizzata nel metodo parseWSDLCittas, ed ottiene le informazioni necessarie all’invocazione del Web Service come namespace,

80/103


nome delle operazioni e rispettivi parametri. Successivamente, invocherà il servizio attualmente puntato in lista tramite metodologia DII. Nel caso particolare invocherà la richiesta dell'elenco delle città tramite il metodo denominato getCitiesByCountry(), mentre riceverà la risposta da uno dei Service Provider registrati presso il servizio UDDI locale tramite il metodo getCitiesByCountryReturn().

if (listBTemplate!=null){... for(int i=0; i<listBTemplate.size(); i++) {try {//Cerco il binding template con un punto di accesso HTTPbindingTemplate = (BindingTemplate)listBTemplate.elementAt(i);accessPoint = bindingTemplate.getAccessPoint();// ottenuta la lista di binding template, possiamo ottenere// la lista delle URL associateVector tmodelInstanceInfoVector = bindingTemplate.

getTModelInstanceDetails().getTModelInstanceInfoVector();

for(int k=0; k<tmodelInstanceInfoVector.size(); k++) {TModelInstanceInfo instanceInfo = (TmodelInstanceInfo)

tmodelInstanceInfoVector.elementAt(k);InstanceDetails details = instanceInfo.getInstanceDetails();OverviewDoc wsdlImpl = details.getOverviewDoc();risposta= (String) parseWSDLCittas( wsdlImpl.getOverviewURLString(), parametro);

...Risulta doveroso precisare che i Service Provider presenti nel Service Registry locale sono la società WebServiceR che fornisce alcuni Web Service gratuitamente via HTTP, e la società SpecchioLocale, la quale, implementa Web Service sulla macchina locale. Si precisa che al momento dell'invocazione del servizio, verranno gestiti in primis i servizi della società WebServiceR se disponibile una connessione alla rete Internet, altrimenti, al fine di garantire un discreto livello di fault tollerance verranno invocati i servizi meteo fornito dalla società SpecchioLocale, la quale fornisce le previsioni meteo per i soli comuni di Roma, Milano o Napoli.

3. Ottenuta la risposta da uno dei service provider presenti nel Binding Template, il DispatcherService inoltra una risposta XML, contenente la lista delle città richieste, alla servlet DispatcherService, tramite il metodo getCittasReturn().

String temp= ""+risposta.toString();return (java.lang.String)temp;

4. La servlet DispatcherServices, ottenuto l'elenco delle città in XML, effettuerà un parsing degli stessi tramite la classe readXMLCittà.java, la quale implementa a sua volta un parser JDOM.

infocittà=new ReadXmlCitta((String) call.invoke("getCittas", inx));

81/103


Illustrazione 4.2: WorkFlow richiesta elenco città

5. L'elenco elaborato delle città, verrà presentato in un menù a tendina, mediante il quale l'utente sceglierà una città di proprio interesse, ed unitamente alla nazione associata viene formulata una richiesta di informazioni meteo la quale verrà raccolta in prima istanza da una seconda servlet denominata CallDispatcherServices.

Illustrazione 4.3: WS Global Weather – Passo 2 : selezione della città

6. Una volta che l'utente sceglie la propria città di interesse, la servlet CallDispatcherServices inoltra la richiesta delle previsioni meteo al DispatcherService tramite il metodo getMeteos.

Object[] in1 = new Object[]{new String(citta), new String(nazione)};...(String) call.invoke("getMeteoS", in1)

7. Il Web Service coordinatore, a questo punto, applica la stessa metodologia esposta al precedente punto 2, otterrà quindi una lista di Binding Template che gli permetteranno di

82/103


inoltrare a sua volta la specifica richiesta di previsioni meteo ai Service Provider Identificati.

String tmodelFingerPrint="uuid:E470C400-0269-11DD-ACCE-D6A9BB0AE7F0"; ...listBTemplate=findBindinTemplate( tmodelFingerPrint);...if (listBTemplate!=null){... for(int i=0; i<listBTemplate.size(); i++) {

try {//trovato il Binding Template con un punto di accesso HTTPbindingTemplate = (BindingTemplate)listBTemplate.elementAt(i);accessPoint = bindingTemplate.getAccessPoint();// ottenuta la lista di binding template, possiamo ottenere// la lista delle URL associateVector tmodelInstanceInfoVector = bindingTemplate.

GetTModelInstanceDetails().getTModelInstanceInfoVector();

for(int k=0; k<tmodelInstanceInfoVector.size(); k++) {TModelInstanceInfo instanceInfo = (TmodelInstanceInfo)

tmodelInstanceInfoVector.elementAt(k);InstanceDetails details = instanceInfo.

getInstanceDetails();OverviewDoc wsdlImpl = details.getOverviewDoc();try {

risposta= (String)parseWSDLMeteo( wsdlImpl.getOverviewURLString(), param);

Nel caso particolare la richiesta verrà invocata con il metodo getWeather(), mentre la risposta gli verrà fornita dal metodo getWeatherReturn(). Si noti che, anche in questo caso, il DispatcherService può ottenere le previsioni meteo essenzialmente da due Service Provider registrati nel Service Registry locale, nella fattispecie verranno invocati in primis i servizi della società WebServiceR se disponibile una connessione alla rete Internet, altrimenti, al fine di garantire un discreto livello di fault tollerance verrà invocato il servizio meteo locale fittizio fornito dalla società SpecchioLocale, la quale fornisce le previsioni meteo per i soli comuni di Roma, Milano o Napoli.

8. Ottenuta la risposta da uno dei service provider, il DispatcherService inoltra una risposta XML, contenente le previsioni meteo della città prescelta, alla servlet CallDispatcherServices, tramite il metodo getMeteosReturn().

...String temp= ""+risposta.toString();return (java.lang.String)temp;

9. La servlet CallDispatcherServices, ottenute le previsioni meteo in XML, effettuerà un parsing delle informazioni ottenute tramite la classe ParsRisposta, la quale implementa a sua volta un parser JDOM.

83/103


Illustrazione 4.4: WorkFlow previsioni meteo in MPH

10. Una volta ottenute le previsioni meteo elaborate, la servlet CallDispatcherServices inoltrerà un'ulteriore richiesta al Web Service coordinatore DispatcherService, per la conversione delle unità di misura espresse in MPH a KMH, tramite l'invocazione del metodo getMPHtoKMHs().

//conversione vento in KMH call.setOperationName("getMPHtoKMHs");Object[] in2 = new Object[]{new Double(wind)};

Double VelVento= (Double) call.invoke(in2);...

11. Il Web Service coordinatore, a questo punto, applica la stessa metodologia esposta al precedente punto 2, otterrà quindi una lista di Binding Template che gli permetteranno di inoltrare a sua volta la specifica richiesta di conversione di unità di misura (da MPH a KMH) ai Service Provider che soddisfano tale tipo di richiesta. Nel caso particolare la richiesta verrà invocata con il metodo ChangeLengthUnit(), mentre la risposta gli verrà fornita dal metodo ChangeLengthUnitReturn().

String tmodelFingerPrint="uuid:4ADF92C0-43C4-11DD-92C0-E3E95A90B2AF"; ...

listBTemplate=findBindinTemplate( tmodelFingerPrint);...if (listBTemplate!=null){

// Intercetto il binding associato e scorro la lista.... for(int i=0; i<listBTemplate.size(); i++) {

try {//Cerco il binding template con un punto di accesso HTTPbindingTemplate = (BindingTemplate)

listBTemplate.elementAt(i);accessPoint = bindingTemplate.getAccessPoint();// ottenuta la lista di binding template, possiamo // ottenere la lista delle URL associateVector tmodelInstanceInfoVector = bindingTemplate.

GetTModelInstanceDetails().

84/103


getTModelInstanceInfoVector();for(int k=0; k<tmodelInstanceInfoVector.size(); k++) { TModelInstanceInfo instanceInfo =

(TmodelInstanceInfo)tmodelInstanceInfoVector.elementAt(k);

InstanceDetails details = instanceInfo.getInstanceDetails();

OverviewDoc wsdlImpl = details.getOverviewDoc(); try { risposta= (Double) parseWSDLConversione(

wsdlImpl.getOverviewURLString(), param);Si noti che, anche in questo caso, il DispatcherService può ottenere le conversioni da MPH a KMH essenzialmente da due Service Provider registrati nel Service Registry locale, nella fattispecie verranno invocati in primis i servizi della società WebServiceR se disponibile una connessione alla rete Internet, altrimenti, al fine di garantire un discreto livello di fault tollerance verrà invocato il servizio di conversione fornito dalla società SpecchioLocale.

12. Ottenuta la risposta da uno dei service provider presenti nel Binding Template, il DispatcherService inoltra una risposta XML, contenente il valore MPH convertito in KMH, alla servlet CallDispatcherServices, tramite il metodo getMPHtoKMHReturn().

13. La servlet CallDispatcherServices, estrapolerà dal namespace <double> il valore convertito da MPH a KMH.

Illustrazione 4.5: WorkFlow previsioni meteo in KMH

14. Una volta che la servlet CallDispatcherServices ottiene le misure convertite, propone le previsioni meteo della città prescelta in KMH, tramite la visualizzazione di una pagina web creata ad hoc.

85/103


Illustrazione 4.6: WS Global Weather – Passo 3 : esito previsioni meteo

Si noti, che durante tutte le attività descritte, viene eseguito 'in background' un handler denominato LogHandler, implementato dall'omonima classe, il quale memorizza all'interno del file denominato MyService.log17 i timestamp dell'attivazione del Web Service coordinatore DispatcherService. Tali informazioni potranno successivamente essere utilizzate ai fini statistici.

Fri Apr 04 22:39:34 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 22:44:31 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 22:46:40 CEST 2008: service Dispatcher accessed 2 time(s).Fri Apr 04 23:04:29 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 23:13:16 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 23:19:44 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 23:19:47 CEST 2008: service Dispatcher accessed 2 time(s).Fri Apr 04 23:26:40 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 23:31:20 CEST 2008: service Dispatcher accessed 1 time(s).Fri Apr 04 23:35:59 CEST 2008: service Dispatcher accessed 1 time(s).Sat Apr 05 12:56:14 CEST 2008: service Dispatcher accessed 1 time(s).Sat Apr 05 13:12:01 CEST 2008: service Dispatcher accessed 1 time(s).Sat Apr 05 13:49:11 CEST 2008: service Dispatcher accessed 1 time(s).

17 Sito in C:\Documents and Settings\Giuseppe Specchio

86/103


4.3 Class DiagramIn questa sezione verranno presentate ad una ad una le classi principali dell'applicazione Global Weather, sulla base di una suddivisione strutturale di classi lato client e classi lato server.

4.3.1 Class Diagram del presentation layer

Illustrazione 4.7: Class Diagram della servlet DispatcherServices

Come già descritto nel paragrafo dedito alla descrizione del workflow, la servlet DispatcherServices, viene utilizzata per intercettare la richiesta HTTP da parte dell'utente per al fine di inoltrare una richiesta di una lista di città associate ad una data nazione, appositamente parsate con la classe ReadXmlCitta.

Illustrazione 4.8: Class Diagram della classe readXmlCitta

87/103


La servlet CallDispatcherServices, viene utilizzata per intercettare la coppia (nazione, città) fornita dalla servlet DispatcherServices al fine di gestire il flusso dati relativo alle previsioni meteorologiche, il quale verrà appositamente parsato con la classe ParsRisposta .

Illustrazione 4.10: Class Diagram della servlet CallDispatcherServices

Volendo ottenere una visione associativa, di tali classi dedite alla gestione del livello di presentazione dell'applicazione Global Weather, otteniamo la seguente rappresentazione:

88/103

Illustrazione 4.9: Class Diagram della servlet CallDispatcherServices


Illustrazione 4.11: Associazione tra classi di livello presentation

In ultima analisi si tenga presente che tale classi sono raccolte nel package denominato servizio.specchio.it.

Illustrazione 4.12: package del livello presentation

89/103


4.3.2 Class Diagram della business logicCome per il livello presentation della nostra applicazione anche la logica di business è stata strutturata all'interno di un package, denominato com.service.specchio

Illustrazione 4.13: package del Web Service coordinatore

Con l'interfaccia Dispatcher_Portype vengono definiti i servizi forniti dal Web Service coordinatore verso l'esterno, mediante implementazione l'interfaccia RMI.Remote, in modo tale da poter gestire le chiamate ai metodi come se fossero delle RMI (Remote Method Invocation). La definizione dei servizi resi pubblici sono definiti nella classe WebBrockerSoapBindStub, la quale implementando ed estendendo la classe Stub, ha al suo interno la definizione ed i metodi d'accesso ai servizi, come l'URL del servizio, ovvero i parametri sia di input che di output etc.

La classe DispatcherSoapBindingImpl vengono implementati i metodi che verranno invocati dal Service Requestor.

90/103


Illustrazione 4.14: Relazioni con la classe Dispatcher_PortType

La classe DispatcherServiceLocator rappresenta la definizione del Web Service locale. Tale classe estende la classe Service di Apache AXIS, ed implementa la classe DispatcherService, quale

91/103


Illustrazione 4.15: Relazioni con la classe DispatcherServiceinterfaccia dove sono definiti le firme dei metodi che il DispatcherService espone.

In conclusione con classe LogHandler che estende la superclasse BasicHandler, si realizza l'handler che verrà eseguito durante la fase di attraversamento della catena dei Service Engine AXIS. In

92/103


particolare, questi realizzerà un servizio di logging per il Web Service coordinatore.

Illustrazione 4.16: Class Diagram dell'handler

4.3.3 Class Diagram del meteo fornito dal Web Service fittizioIl diagramma del Web Servizio fittizio ideato al fine di garantire un discreto livello di fault tollerace, viene strutturato su un'architettura simile a quella del Web Service coordinatore DispatcherService, fatta eccezione nel mancato uso dell'Handler.

Anche questi, viene realizzato all'interno di un package dedicato, denominato NET.webserviceX.www.

Illustrazione 4.17: package del Meteo fittizio

La definizione dei metodi è racchiusa nell'interfaccia GlobalWeatherSoap, mentre l'accesso a tale servizio web viene racchiuso nella classe GlobalWeatherSoapStub. Nella classe GlobalWeatherSoapBindingImpl, viene implementato il servizio offerto verso un potenziale Service Requestor che ne richiederà l'uso.

93/103


94/103


4.3.4 Class Diagram del Web Service di conversioneIl diagramma del Web Servizio fittizio ideato al fine di garantire un discreto livello di fault tollerace, viene strutturato su un'architettura simile a quella del Web Service coordinatore DispatcherService, fatta eccezione nel mancato uso dell'Handler.

Anche questi, viene realizzato all'interno di un package dedicato, denominato comy.it.service.

Illustrazione 4.18: package del WS di conversione fittizio

La definizione dei metodi è racchiusa nell'interfaccia LengthUnit, mentre l'accesso a tale servizio

95/103


viene racchiuso nella classe LengthUnitSoap_PortType. Nella classe LengthUnitSoap_BindingImpl, viene implementato il servizio offerto verso un potenziale Service Requestor che ne richiederà l'uso.

96/103


97/103


4.4 Use CasesIn questa sezione verranno presentati i principali Uses Cases, ovvero i casi d'uso dell'applicazione Global Weather in modo tale da poter fornire un'idea chiara dei requisiti del sistema dal punto di vista utente.

4.4.1 Use Case Scelta Nazione

Illustrazione 4.19: Scelta Nazione

● Parti interessate e interessi :Un utente richiede attraverso front-end di ottenere la lista delle città associata da una data nazione scelta;

● Livello : “Obiettivo Lista delle città”

● Attore primario, attori secondari : Utente

● Precondizioni : Il Web Service deve essere attivo

● Post-condizione di successo : Il sistema procede alla fornitura dell'elenco delle città della nazione scelta

● Post-condizione di fallimento : L’utente viene invitato a fornire una nazione valida.

● Descrizione :

1. l’utente attraverso il front-end proposto inserisce il parametro Nazione.

2. Il Web Service coordinatore DispatcherService interroga il registro UDDI ed in base all'esito della risposta invoca il servizio.

3. Una volta ottenuta la risposta, fornisce all'utente un menù contenente la lista delle città della nazione scelta.

4.4.2 Use Case Scelta Città

Illustrazione 4.20: Scelta della Città

● Parti interessate e interessi : Un utente richiede attraverso front-end di ottenere le previsioni meteo di una data città scelta;

98/103


● Livello : “Obiettivo Previsioni Meteorologiche della città scelta”



● Post-condizione di successo : Il sistema procede alla fornitura delle previsioni meteorologiche delle città associate alla nazione scelta precedentemente

● Post-condizione di fallimento : Non può esserci una condizione di fallimento poiché l'utente è obbligato a scegliere la città di interesse da un menù a sola lettura.

● Descrizione :

1. l’utente attraverso il front-end proposto seleziona il parametro Città.

2. Il Web Service coordinatore DispatcherService interroga il registro UDDI ed in base all'esito della risposta invoca il servizio.

3. Una volta ottenuta la risposta, fornisce le previsioni meteorologiche in MPH.

4.4.3 Use Case Previsioni Meteorologiche

Illustrazione 4.21: Previsioni Meteorologiche in KMH

● Parti interessate e interessi : Un utente vuole ottenere le previsioni meteo di una data città scelta con le misure espresse in KMH;

● Livello : “Obiettivo Previsioni Meteorologiche della città scelta espresse in KMH”



● Post-condizione di successo : Il sistema procede alla conversione in KMH delle misure espresse in MPH .

● Post-condizione di fallimento : Non può esserci una condizione di fallimento poiché laddove non fossero disponibili servizi remoti, la conversione viene effettuata dal Web Service di conversione fittizio.

● Descrizione :

1. Il Web Service coordinatore DispatcherService interroga il registro UDDI ed in base all'esito della risposta invoca il servizio di conversione.

2. Una volta ottenuta la risposta, fornisce un valore convertito da MPH a KMH.

3. Le previsioni meteorologiche vengo presentate in KMH

99/103


4.5 Sequence DiagramIn questa sezione verranno presentati i principali Sequence Diagram dell'applicazione Global Weather, ovvero i diagrammi di sequenza che caratterizzano l'interazione temporale tra i vari oggetti che vengono invocati durante l'esecuzione dell'applicazione.

4.5.1 Sequence Diagram per la richiesta dell'elenco città

Illustrazione 4.22: Sequence Diagram relativo alla richiesta di un elenco di città di una data nazione

100/103


4.5.2 Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in MPH

Illustrazione 4.23: Sequence Diagram relativo alla richiesta di previsioni meteorologiche espresse in MPH

101/103


4.5.3 Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in KMH

Illustrazione 4.24: Sequence Diagram relativo alla conversione delle misure espresse in MPH a KMH

102/103


5 Bigliogragia1. Dispense fornite dal Prof. M. Bianchi durante il corso di Laboratorio di Sistemi Distribuiti

del corso di Laurea Specialistica in Informatica dell'Università di Roma – Tor Vergata.

2. Building Web Services with Java – Second Edition – S. Graham e altri.

3. Java Web Service , tutto ed altre – Apogeo

4. Java 2 SDK 1.4 Edition - Apogeo

103/103