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
Premessa
La presente documentazione viene redatta come progetto conclusivo del corso di Laboratorio di
Sistemi Distribuiti del corso di Laurea Specialistica in Informatica dell'Università di Roma – Tor
Vergata, svolto nell'a.a.2007-2008.
Sulla base di tali premesse è stata sviluppata una Web Application basata su tecnologie Web Service
denominata Global Weather , la quale, come si può intuire dal nominativo scelto, fornisce le
previsioni meteorologiche di una data città, previa selezione della nazione di appartenenza, i cui
valori delle misure rilevate vengono appositamente convertite da MP/H a KM/H.
Al fine di meglio strutturare la documentazione di tale applicazione, si è deciso di strutturare
l'argomentazione nei seguenti capitoli:
● Capitolo 1 : introduzione al concetto di architettura orientata ai servizi (SOA);
● Capitolo 2 : presentazione del modello Web Service, quale implementazione di un modello
SOA su rete Internet;
● Capitolo 3 : presentazione delle tecnologie utilizzate per l'implementazione del Web Service
Global Weather;
● Capitolo 4 : documentazione UML dell'applicazione Global Weather.
2/103
Indice generale
Premessa............................................................................................................................................... 2
Introduzione..........................................................................................................................................5
1SOA: Service-Oriented Architecture.................................................................................................. 8
1.1Introduzione................................................................................................................................ 8
1.2Caratteristiche di una SOA......................................................................................................... 8
1.3Come funziona una SOA............................................................................................................ 9
2I Web Service....................................................................................................................................11
2.1Introduzione.............................................................................................................................. 11
2.2Scenari Complessi.....................................................................................................................12
2.3Tecnologie.................................................................................................................................13
2.4XML..........................................................................................................................................14
2.4.1Struttura di un documento XML....................................................................................... 14
2.4.2DTD: Document Type Definition..................................................................................... 16
2.4.3XML Schema.................................................................................................................... 16
2.4.4Namespece XML.............................................................................................................. 16
2.4.5Lavorare con i documenti XML........................................................................................17
2.4.5.1Elaborazione tramite SAX.........................................................................................17
2.4.5.2Elaborazione tramite DOM....................................................................................... 18
2.5Il protocollo SOAP................................................................................................................... 20
2.5.1Il messaggio SOAP e modelli di scambio.........................................................................21
2.5.2Utilizzo dell’intestazione.................................................................................................. 23
2.5.3Gestione degli Errori......................................................................................................... 23
2.5.4SOAP su HTTP................................................................................................................. 24
2.5.5SOAP e RPC..................................................................................................................... 25
2.5.6SOAP Encoding................................................................................................................ 26
2.5.7SOAP con Allegati............................................................................................................ 27
2.5.8SOAP e Java......................................................................................................................29
2.6Il linguaggio WSDL..................................................................................................................29
2.6.1L'elemento Type................................................................................................................ 32
2.6.2L'elemento Message.......................................................................................................... 33
2.6.3L'elemento PortType......................................................................................................... 34
2.6.4L'elemento Binding........................................................................................................... 35
2.6.5L'elemento Service............................................................................................................ 37
2.7Il protocollo UDDI....................................................................................................................43
2.7.1Il contesto architetturale di UDDI.....................................................................................44
2.7.1.1I ruoli in UDDI.......................................................................................................... 44
2.7.1.2Il registro UDDI........................................................................................................ 44
2.7.2Rappresentazione delle informazioni in UDDI.................................................................44
2.7.2.1Struttura di UDDI...................................................................................................... 45
2.7.2.2Interazioni con UDDI................................................................................................ 47
2.7.2.3Esempio..................................................................................................................... 48
2.8Tecnologie per Web Services di seconda generazione..............................................................51
3Web Services : tecnologie.................................................................................................................53
3.1Introduzione.............................................................................................................................. 53
3/103
3.2Java........................................................................................................................................... 53
3.3TomCat......................................................................................................................................53
3.4Axis........................................................................................................................................... 53
3.4.1L'architettura di Axis......................................................................................................... 54
3.4.2Installazione di AXIS........................................................................................................ 56
3.4.3Deployment di Web Service su Axis.................................................................................57
3.4.4Strumenti per il monitoraggio delle comunicazioni..........................................................62
3.5MySQL..................................................................................................................................... 65
3.6jUDDI....................................................................................................................................... 65
3.6.1Installazione di jUDDI...................................................................................................... 65
3.7UDDI4J..................................................................................................................................... 71
3.7.1Installazione di UDDI4J....................................................................................................72
3.8Tecniche di invocazione di Web Service.................................................................................. 72
3.8.1Stub creato da WSDL........................................................................................................72
3.8.2Dynamic Proxy................................................................................................................. 73
3.8.3Dynamic Invocation Interface (DII)................................................................................. 74
3.8.4Dynamic Discovery and Invocation (DDI)....................................................................... 76
4Global Weather Web Service............................................................................................................ 79
4.1Introduzione.............................................................................................................................. 79
4.2Il Workflow............................................................................................................................... 80
4.3 Class Diagram..........................................................................................................................87
4.3.1Class Diagram del presentation layer................................................................................87
4.3.2Class Diagram della business logic...................................................................................90
4.3.3Class Diagram del meteo fornito dal Web Service fittizio................................................93
4.3.4Class Diagram del Web Service di conversione................................................................95
4.4Use Cases.................................................................................................................................. 98
4.4.1Use Case Scelta Nazione...................................................................................................98
4.4.2Use Case Scelta Città........................................................................................................ 98
4.4.3Use Case Previsioni Meteorologiche................................................................................ 99
4.5Sequence Diagram.................................................................................................................. 100
4.5.1Sequence Diagram per la richiesta dell'elenco città........................................................100
4.5.2Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in MPH. .101
4.5.3Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in KMH. 102
5Bigliogragia.................................................................................................................................... 103
4/103
Introduzione
Spiegare cosa sia il “Web 2.0”, ovvero cosa si nasconda dietro tale termine, è cosa veramente
ardua,. Questo perché oggi siamo di fronte più ad un cambiamento culturale che ad un'innovazione
tecnologica vera e propria come era stata Internet anni fa, possiamo dire oramai nella versione 1.0,
ovvero nell'oramai ex epoca della new economy, e sopratutto perché in linea di massima noi
informatici diventiamo matti quando una cosa è eterna e soprattutto siamo caratterizzati dal 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.0
2 Un wiki è un sito Web gestito da un sistema che permette a ciascuno dei suoi utilizzatori di aggiungere contenuti,
ma anche di modificare i contenuti esistenti inseriti da altri utilizzatori.
3 È un neologismo che descrive una categorizzazione collaborativa di informazioni mediante l'utilizzo di parole
chiave, dette tag, scelte liberamente.
5/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 × 10 38
indirizzi, mentre IPv4 gestisce soltanto fino a circa 4 miliardi (4 × 109) di indirizzi.
5 Voice over Internet Protocol, è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando
una connessione Internet o un'altra rete dedicata che utilizza il protocollo IP, anziché passare attraverso la rete
telefonica tradizionale (PSTN). Ciò consente di eliminare le relative centrali di commutazione e di economizzare
sulla larghezza di banda occupata. Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali,
codificati in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti collegati sta
parlando.
6 AJAX, acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo web per creare applicazioni web
interattive. L'intento di tale tecnica è quello di ottenere pagine web che rispondono in maniera più rapida, grazie allo
scambio in background di piccoli pacchetti di dati con il server, così che l'intera pagina web non debba essere
ricaricata ogni volta che l'utente effettua una modifica. Questa tecnica riesce, quindi, a migliorare l'interattività, la
velocità e l'usabilità di una pagina web.
7 RSS , acronimo di RDF Site Summary ed anche di Really Simple Syndication, è uno dei più popolari formati per la
distribuzione di contenuti Web; è basato su XML, da cui ha ereditato la semplicità, l'estensibilità e la flessibilità.
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 Introduzione
Una Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) è un modello
architetturale per la creazione di sistemi residenti su una rete che focalizza l’attenzione sul concetto
di servizio. Un sistema costruito seguendo la filosofia SOA è costituito da applicazioni, chiamate
servizi, ben definite ed indipendenti l’una dall’altra, che risiedono su più computer all’interno di
una rete (ad esempio la rete interna di una azienda o una rete di connessione fra più aziende che
collaborano: intracompany o intercompany network). Ogni servizio mette a disposizione una certa
funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando, in questo
modo, applicazioni di maggiore complessità.
SOA è una forma particolare di Distributed System, la cui definizione è la seguente:
Un Distributed System (Sistema distribuito) consiste di vari agenti software distinti che devono
lavorare insieme per svolgere alcuni compiti. Inoltre, gli agenti in un sistema distribuito non
operano nello stesso ambiente di calcolo, quindi devono comunicare per mezzo di stack di
protocolli hardware/software su una rete.
Questo significa che le comunicazioni in un sistema distribuito sono intrinsecamente meno veloci e
affidabili rispetto a quelle che utilizzano invocazione diretta del codice e memoria condivisa. Ciò ha
importanti implicazioni architetturali perché i sistemi distribuiti richiedono che gli sviluppatori (di
infrastruttura e applicazioni) considerino la latenza, fattore imprevedibile dell’accesso remoto, e
tengano presente questioni relative alla concorrenza e la possibilità di fallimenti parziali.
1.2 Caratteristiche di una SOA

L’astrazione delle SOA non è legata ad alcuna specifica tecnologia, ma semplicemente definisce
alcune proprietà, orientate al riutilizzo e all’integrazione in un ambiente eterogeneo, che devono
essere rispettate dai servizi che compongono il sistema. In particolare un servizio dovrà:
● essere ricercabile e recuperabile dinamicamente. Un servizio deve poter essere ricercato in
base alla sua interfaccia e richiamato a tempo di esecuzione. La definizione del servizio in
base alla sua interfaccia rende quest’ultima (e quindi l’interazione con altri servizi)
indipendente dal modo in cui è stato realizzato il componente che lo implementa.
● essere autocontenuto e modulare. Ogni servizio deve essere ben definito, completo ed
indipendente dal contesto o dallo stato di altri servizi.
● essere definito da un’interfaccia ed indipendente dall’implementazione. Deve cioè essere
definito in termini di ciò che fa, astraendo dai metodi e dalle tecnologie utilizzate per
implementarlo. Questo determina l’indipendenza del servizio non solo dal linguaggio di
programmazione utilizzato per realizzare il componente che lo implementa ma anche dalla
piattaforma e dal sistema operativo su cui è in esecuzione: non è necessario conoscere come
un servizio è realizzato ma solo quali funzionalità rende disponibili.
● essere debolmente accoppiato con altri servizi (loosely coupled). Un’architettura è
debolmente accoppiata se le dipendenze fra le sue componenti sono in numero limitato.
Questo rende il sistema flessibile e facilmente modificabile.
● essere reso disponibile sulla rete attraverso la pubblicazione della sua interfaccia (in un
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 SOA

Gli attori di un sistema SOA sono tre:
● Service Provider
● Service Consumer
● Service Registry.
Il Service Provider è un’entità che mette a disposizione un qualche servizio. Tale servizio, per poter
essere trovato da altre entità che vogliono utilizzarlo, deve essere reso visibile sulla rete, in termine
tecnico Pubblicato. A tal fine il Service Provider comunica al Service Registry le informazioni
relative al servizio, perché vengano memorizzate. Il Service Registry possiede quindi le
informazioni, come URL e modalità di accesso, di tutti i servizi disponibili.
Nel momento in cui un Service Consumer dovrà utilizzare un servizio farà richiesta delle
informazioni ad esso relative al Service Registry. Con queste informazioni il Service Consumer
potrà comunicare direttamente con il Service Provider ed utilizzare il servizio.
In figura sono riportate le interazioni fra le entità appena descritte.
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 Introduzione
Promossi da società del calibro di Microsoft ed IBM, i servizi Web promettono di far integrare
sistemi software in modo standard sulla rete, mediante l'impiego di protocolli e tecnologie concrete
come SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) ed
UDDI (Universal Description, Discovery and Integration).
I Web Service sono soluzioni adottabili in contesti:
● Enterprise Application Integration8 (EAI)
● Business-to-Business9 (B2B)
● Business-to-Customer10 (B2C)
Tale tecnologia è stata adottata in maniera ufficiale W3C 11 intorno al Dicembre del 2001, il quale ha
formalizzato l'architettura con la seguente definizione:
“Un Web Service (o servizio web) è un sistema software progettato per supportare l’interoperabilità
tra diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è
quella di offrire un’interfaccia software attraverso la quale altri sistemi possono interagire con il
Web Service stesso tramite appositi messaggi: tali messaggi sono inviati tramite i protocolli di
livello applicativo (HTTP, FTP, SMTP ...) e formattati secondo lo standard XML.”
Illustrazione 2.1: Servizi Web: XML e

protocolli Internet
Sulla base di tali premesse, possiamo quindi affermare che la disponibilità di questi elementi sulla
rete, consente potenzialmente a chiunque di interagire con componenti software offerti dalle singole
aziende.
Uno scenario possibile potrebbe essere quello trattato nel capitolo successivo, nel quale si costruisce
una Web Application sfruttando Web Service forniti da altre società delle quali alcune comunicano
l'elenco delle città di una data nazione, altre invece forniscono le previsioni meteo di una città della
nazione prescelta ed infine altre società forniscono un servizio di conversione di unità di misura,
come quello da MPH a KMH. Tutte queste informazioni vengono gestite in backend dal nostro
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
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 Complessi

I possibili scenari possono avere complessità diverse, a partire da quelli più banali, anche oggi
realizzabili, fino ad arrivare alle ipotesi più fantasiose, dove i flussi di lavoro non sono altro che
aggregazioni di singole componenti realizzate da servizi Web.
Nelle ipotesi più elaborate, i singoli sistemi software dovrebbero essere in grado di ricercare i
servizi all’interno di appositi registri mondiali, che si dovrebbero occupare di realizzare il punto di
incontro tra cliente e fornitore.
Riprendendo l’esempio precedente, l’applicazione potrebbe utilizzare i registri di servizi Web per
individuare tutti i potenziali fornitori di un tipo di servizio. Ad esempio, l’applicazione potrebbe
aver bisogno di ottenere l'elenco delle città di una data nazione, ma non sapere chi fornisce questa
tipologia di servizio. A questo punto l’applicazione può:
1. accedere ad uno o più registri;
2. localizzare il servizio richiesto;
3. scaricare le informazioni tecniche che consentono la sua chiamata;
4. ingaggiare il servizio.
Service Registry
Scopre WSDL UDDI Registry Registra WSDL
Service Consumer Service Provider

SOAP
Codice Impl
Applicat Proxy
Service Contract
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
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 Tecnologie
La visione dei Web Service è supportata da una serie di tecnologie sviluppate in fase iniziale dalle
maggiori aziende del settore, talvolta come membri di un consorzio.
Alcune tecnologie sono comunemente accettate, altre sono più conosciute, mentre altre ancora sono
proposte di singole aziende che non è chiaro se avranno successo in futuro.
Uno stack di tecnologie consolidato è presente nell'illustrazione 3.
Illustrazione 2.3: Pila concettuale dei Web Service

Di queste:
● Protocolli di Livello Applicativo. Il protocollo di trasporto preferito per lo scambio di
messaggi applicativi, ed il più utilizzato, è HTTP/HTTPS anche se sarebbe possibile
utilizzarne altri, come FTP e SMTP;
● XML. È un meta linguaggio utilizzato per creare nuovi linguaggi, atti a descrivere
documenti strutturati.
● SOAP. È il protocollo XML di scambio dei messaggi che consente la programmazione
distribuita dei servizi Web;
● WSDL. Consente di descrivere il servizio tramite un documento XML, in modo similare la
linguaggio IDL (Interface Description Language) di CORBA;
● UDDI. È un servizio di directory che consente agli utenti di localizzare i servizi Web.
13/103
2.4 XML
XML eXtensible Markup Language, è un linguaggio, indipendente dai sistemi e dall'hardware, che
permette di descrivere dei dati e la loro struttura all'interno di un documento XML, ovvero di un file
di testo UNICODE che contiene i dati e gli elementi di markup che definiscono la struttura dei dati
stessi.
Il markup XML assomiglia a quello del linguaggio HTML, in quanto consiste in un tag e attributi
aggiunti ai dati all'interno del file di testo. La somiglianza apparente tra XML e HTML si limita
comunque al loro aspetto superficiale: infatti XML e HTML sono profondamente differenti, sia per
il loro scopo sia che per la loro capacità.
Prima di tutto, sebbene un documento XML possa essere creato, letto e compreso da una persona, il
suo scopo primario consiste nella comunicazione di dati da un computer all'altro. Di conseguenza,
accade frequentemente che i documenti XML vengano generati ed elaborati da un programma e non
da un utente umano, anche se quest'ultimi sia in grado di farlo. Un documento XML definisce la
struttura dei dati contenuti al suo interno in modo che un programma che lo riceve sia in grado di
interpretarlo. È quindi possibile affermare che XML è uno strumento per trasferire informazioni e la
loro organizzazione da un programma all'altro. Lo scopo di HTML, dall'altra parte, consiste
essenzialmente nel fornire la descrizione di come i dati dovranno apparire quando vengono
visualizzati o stampati. Infatti le uniche informazioni strutturali che solitamente appaiono nei
documenti HTML sono relative all'aspetto dei dati dal punto di vista visivo.
In secondo luogo, HTML fornisce un insieme di tag essenzialmente prefissato e dedicato
principalmente alla presentazione dei dati, invece, XML è un linguaggio tramite il quale è possibile
definire nuovi insiemi di tag e attributi adatti a svariate tipologie di dati, anche di tipo
personalizzato.
Naturalmente, una volta inventato un insieme di elementi di markup XML adatti a descrivere un
tipo particolare di dato, sarà necessario rendere disponibile le regole per interpretare documenti
XML di quel tipo, in modo tale da poterli creare, leggere o modificare. La definizione di tali
elementi di markup utilizzati all'interno di un documento XML può essere inclusa direttamente
all'interno del documento, oppure sotto forma di un'entità separata come, ad esempio, un file
identificato da un URI, che possa essere referenziato all'interno di ogni documento di quel
particolare tipo.
Da un punto di vista implementativo, il linguaggio di programmazione Java, mette a disposizione
la libreria JAXP (Java API for XML Processing) la quale fornisce strumenti necessari per leggere,
creare e modificare documenti XML dall'interno dei nostri programmi. Per comprendere ed
utilizzare queste API, l'utente dovrebbe però acquisire una ragionevole familiarità oltre che con i
concetti fino ad ora esposti, anche il concetto di namespece XML, il quale verrà illustrato nel
paragrafo a seguire.
2.4.1 Struttura di un documento XML

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

Una Document Type Definition è un file in cui è riportata la definizione di tutti gli elementi, e dei
loro attributi, usati nel documento XML, specificando inoltre la correlazione tra di essi. Tale file
permette ad un’applicazione di sapere se il documento XML che sta analizzando è corretto o no,
dato che gli elementi, essendo stati creati dallo sviluppatore, risulterebbero privi di significato senza
una loro definizione.
Una DTD definisce quindi la struttura di un particolare tipo di documento XML, rispetto al quale si
può valutare la conformità di una data istanza XML.
Le DTD, primo strumento di questo genere, presentano però delle limitazioni: possiedono una
sintassi complessa (non sono scritte in XML), non permettono di specificare tipi di dato e sono
difficilmente estendibili.
2.4.3 XML Schema

Uno strumento, creato allo stesso scopo delle DTD, che supera le limitazioni di queste ultime è
XML-Schema.
Un documento XML-schema definisce:
● gli elementi e gli attributi che possono comparire in un documento;
● quali elementi sono elementi figlio;
● l’ordine ed il numero degli elementi figlio;
● se un elemento è vuoto o può includere testo;
● i tipi di dato per gli elementi e gli attributi;
● i valori di default ed i valori costanti per gli elementi e gli attributi.
Rispetto alle DTD, gli XML-Schema sono estensibili e scritti in XML, rendono possibile la
definizione di tipi di dato e di vincoli, ammettono l’ereditarietà e supportano i namespace.
2.4.4 Namespece XML

In precedenza è stato affermato che un documento XML permette di identificare una DTD esterna
tramite un URI, di includere dichiarazioni di marckup esplicite o di fare entrambe le cose
contemporaneamente. Cosa succede però nel caso in cui si vogliano combinare due o più documenti
XML, ognuno de quali ha una propria DTD per ottenere un singolo documento? La risposta breve è
che non è sempre possibile. Infatti, ammettendo che i documenti siano due, dato che la DTD di ogni
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 XML

Nei paragrafi precedenti è stato introdotta la nozione di XML processor come modulo utilizzato da
un'applicazione per leggere documenti XML. Un XML processor si occupa di effettuare il parsing
del contenuto di un documento e di mettere a disposizione dell'applicazione gli elementi ed i relativi
attributi: per questa ragione, l'XML processor viene spesso chiamato parser XML. Questi è quindi
un modulo di programma che si occupa di suddividere il testo scritto in un determinato linguaggio
nei suo componenti base, quindi da un punto di vista meramente implementativo un'applicazione
accede al contenuto di un documento sfruttando le API messe a disposizione da un parser XML, ed
il parser si occupa di svolgere tutte le operazioni necessarie per individuare ed interpretare le
informazioni che compongono il documento stesso.
Il linguaggio di programmazione Java supporta due API complementari per l'elaborazione di un
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 SOAP

SOAP è l’acronimo di Simple Object Access Protocol e nell’intenzione dei suoi sviluppatori
dovrebbe costituire un protocollo d’accesso ad oggetti remoti, basato su XML e semplice da
utilizzare.
Tale protocollo è in effetti semplice, ed in certi sensi “user friendly” ovvero, lo sviluppatore può
curiosare all’interno dei messaggi scambiati tra i vari nodi, visto che la comunicazione è in XML e
questo ne ha decretato un successo tale da promuovere SOAP a standard affermato.
Come vedremo, la semplicità del protocollo lascia però aperte numerose questioni che invece sono
risolte in tecnologie distribuite più mature, come CORBA ed RMI.
SOAP definisce la struttura dei singoli messaggi che vengono scambiati tra i nodi, definendo una
serie di tag XML specifici.
Utilizzando come riferimento questi elementi, chi riceve il messaggio è in grado di conoscere
informazioni importanti sul messaggio stesso; nella forma più semplice, la struttura di un messaggio
SOAP consente di mettere ordine e trasmettere le informazioni in modo strutturato.
Un esempio di messaggio SOAP è presente nel seguente listato:
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<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 scambio

Un messaggio SOAP è contenuto da un elemento XML più esterno chiamato envelope (busta) che
funge da raccoglitore di tutti gli altri elementi. Al suo interno può essere presente l’elemento header
(intestazione) che può contenere metainformazioni sul messaggio, come dati sull’autenticazione,
criteri di sicurezza o sulla transazione distribuita in corso. Si noti però che questi aspetti non sono
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.
SOAP
Envelope
Header
Entries
[Header
Element]
Body
Element
[Fault
Element]
[Attachment]
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
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:Envelope
xmlns: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);
<SOAP-ENV:Envelope
● attributo encodingStyle. Indica quale standard è stato utilizzato per codificare il contenuto
del messaggio (si veda il paragrafo SOAP Encoding).
22/103
<SOAP-ENV:Envelope
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’intestazione

Il 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 Errori

Abbiamo 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:Envelope
xmlns: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
</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 HTTP

Come 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.1
Host: www.webservicex.net
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://www.webserviceX.NET/GetWeather"
<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”.
La 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 OK
<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 OK
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<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 SOAP

Il 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 Encoding

Il 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 Allegati

Oltre 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.0
Content-Type: Multipart/Related; boundary=MIME_boundary;
type=text/xml;
start="<info@giuseppespecchio.it>"
Content-Description: Questa è una descrizione opzionale del messaggio.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:info@giuseppespecchio.it"/>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
27/103
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <info@giuseppespecchio.it>
...binary TIFF image...
--MIME_boundary--
Listato 2.9 - Un esempio di SOAP con allegati

L’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 Java

Fino 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 WSDL

WSDL è 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
WSDL
Document
[Types]
{Messages}
[Operations]
{Port Types}
{Bindings}
[Ports]
{Services}
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
</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 Type

Abbiamo 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: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 definitions

Dato 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" />
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>
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 Message

Continuando 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 Message

Così 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 PortType

Questo 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 PortType

Come 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 Binding

Una 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" />
<soap:operation
soapAction="http://www.webserviceX.NET/GetWeather"
style="document" />
<wsdl:input>
<soap:body use="literal" />
35/103
</wsdl:input>
<wsdl:output>
</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
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)
e l'altro il tipo del binding cioè il nome del nostro <portType>.

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
style="document" />
ed un attributo transport.
<soap:binding
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>
e per ognuna di queste definiamo il valore soapAction e confermiamo lo stile attraverso
36/103
soap:operation.
<soap:operation
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>
</wsdl:input>
<wsdl:output>
</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 Service

service è 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 Service

Scegliamo il nome per il servizio
e colleghiamo una porta al al binding;

per questa porta definiamo un punto di comunicazione con l'attributo location.
37/103
<soap:address
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: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:complexType>
<s:sequence>
name="CityName" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetWeatherResponse">
<s:complexType>
<s:sequence>
name="GetWeatherResult"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetCitiesByCountry">
<s:complexType>
<s:sequence>
</s:sequence>
</s:complexType>
38/103
</s:element>
<s:element name="GetCitiesByCountryResponse">
<s:complexType>
<s:sequence>
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:message>
<wsdl:message name="GetCitiesByCountryHttpGetOut">
</wsdl:message>
<wsdl:message name="GetWeatherHttpPostIn">
39/103
<wsdl:part name="CityName" type="s:string" />

</wsdl:message>
<wsdl:message name="GetWeatherHttpPostOut">
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpPostIn">
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpPostOut">
</wsdl:message>
<wsdl:portType name="GlobalWeatherSoap">
around the world.
</documentation>
<wsdl:input message="tns:GetWeatherSoapIn" />
<wsdl:output message="tns:GetWeatherSoapOut" />
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
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">
around the world.
</documentation>
<wsdl:input message="tns:GetWeatherHttpGetIn" />
<wsdl:output message="tns:GetWeatherHttpGetOut" />
</wsdl:operation>
40/103
(full / part).
</documentation>
<wsdl:input message="tns:GetCitiesByCountryHttpGetIn" />
<wsdl:output message="tns:GetCitiesByCountryHttpGetOut" />
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="GlobalWeatherHttpPost">
around the world.
</documentation>
<wsdl:input message="tns:GetWeatherHttpPostIn" />
<wsdl:output message="tns:GetWeatherHttpPostOut" />
</wsdl:operation>
(full / part).
</documentation>
<wsdl:input message="tns:GetCitiesByCountryHttpPostIn" />
<wsdl:output message="tns:GetCitiesByCountryHttpPostOut" />
</wsdl:operation>
</wsdl:portType>
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<soap:operation
style="document" />
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<soap:operation
soapAction="http://www.webserviceX.NET/GetCitiesByCountry"
style="document" />
<wsdl:input>
41/103

</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GlobalWeatherHttpGet" type="tns:GlobalWeatherHttpGet">
<http:binding verb="GET" />
<http:operation location="/GetWeather" />
<wsdl:input>
<http:urlEncoded />
</wsdl:input>
<wsdl:output>
<mime:mimeXml part="Body" />
</wsdl:output>
</wsdl:operation>
<http:operation location="/GetCitiesByCountry" />
<wsdl:input>
<http:urlEncoded />
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GlobalWeatherHttpPost"
type="tns:GlobalWeatherHttpPost">
<http:binding verb="POST" />
<http:operation location="/GetWeather" />
<wsdl:input>
<mime:content
type="application/x-www-form-urlencoded" />
</wsdl:input>
<wsdl:output>
42/103
</wsdl:output>
</wsdl:operation>
<http:operation location="/GetCitiesByCountry" />
<wsdl:input>
<mime:content
type="application/x-www-form-urlencoded" />
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<soap:address
</wsdl:port>
<wsdl:port name="GlobalWeatherHttpGet" binding="tns:GlobalWeatherHttpGet">
<http:address
</wsdl:port>
<wsdl:port name="GlobalWeatherHttpPost"
binding="tns:GlobalWeatherHttpPost">
<http:address
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Listato 2.17 - Listato completo del WSDL del Web Service Global Weather
2.7 Il protocollo UDDI

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

Ci 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.
Registro
UDDI
Publisher Utente
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 UDDI

Ricapitolando 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
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 businessEntity

Ad 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 businessService

I 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 bindingTemplate

Infine 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à 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: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:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
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>
<businessService
businessKey="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 UDDI

Il 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 generazione

Nelle 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 Introduzione
L’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 Java
Il 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 è 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 TomCat
Tomcat è 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 è la 5.0.27.
3.4 Axis
Axis è 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 Axis

L’ 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.
Illustrazione 3.2: Architettura Axis lato client

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

Dal 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.
Direcotry S tructure:
axis-1_2
webapps lib docs samples
axis
WEB-INF
lib
classes
web.xml
……
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
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 Axis

Il 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
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"

returnQName="getCittasReturn" returnType="rtns:string"
</operation>
<operation name="getMPHtoKMHs" qname="operNS:getMPHtoKMHs"

returnQName="getMPHtoKMHsReturn" returnType="rtns:double"
<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.wsdd
All’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/"
...
<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"/>
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"
returnQName="getMeteoSReturn" returnType="rtns:string"
</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.wsdd
A 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.wsdd

java org.apache.axis.client.AdminClient ‘‘PackagePath’’/undeploy.wsdd
La 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
3.4.4 Strumenti per il monitoraggio delle comunicazioni

Axis 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.java
Si 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/"
<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"/>
value="org.apache.axis.monitor.SOAPMonitorService"/>
<parameter name="scope" value="Application"/>
</service>
</deployment>
Listato 3.3 - deploy-SOAPMonitor.wsdd

chiamato ad esempio deploy-SOAPMonitor.wsdd, ed eseguendo il comando
java org.apache.axis.client.AdminClient deploy-monitor.wsdd
Dopo 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
Illustrazione 3.10: SOAPMonitor
3.5 MySQL
Il 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 jUDDI
jUDDI è 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 jUDDI

Requisito 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 MySQL

Il 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 jUDDI

Settaggio dei privilegi generali per l’utente jUDDI:
REPLACE INTO mysql.user SET
Host = ’%’, # 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 jUDDI

Cancellazione 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; # required
Listato 3.7 - Cancellazione degli utenti con campo “User” vuoto

Settaggio dei privilegi db e host per l’utente jUDDI:
INSERT INTO mysql.db SET
Host = ’%’,
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.sql
Listato 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
quit
Passiamo 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 use
juddi.dataSource=java:comp/env/jdbc/juddiDB
Listato 3.11 - modifiche al file juddi.properties

dobbiamo 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>
</parameter>
<parameter>
<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>
</parameter>
<parameter>
<name>validationQuery</name>
<value>select count(*) from PUBLISHER</value>
</parameter>
</ResourceParams>
</Context>
69/103
Listato 3.12 - modifiche al file server.xml

Effettuata 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 è “$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
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 UDDI4J
UDDI4J è 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 UDDI4J

Per 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 Service

La 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 WSDL

Il 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 service
stub.getStubMethod("...");
Listato 3.15 - Esempio di Stub

Necessaria è 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 stub

ottenendo 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 Proxy

Il 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
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 service
proxy.getProxyMethod("...");
Listato 3.18 - Dynamic Proxy

Questo 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 Interface

Il 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
//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 HTTP

bindingTemplate = (BindingTemplate)listBTemplate.elementAt(i);
accessPoint = bindingTemplate.getAccessPoint();
// ottenuta la lista di binding template, possiamo ottenere
// la lista delle URL associate
Vector 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 block
continue;
}//catch
}//for
}catch (WSDLException e) {
// TODO Auto-generated catch block
continue;
}//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
::::
}// DispatcherSoapBindingImpl
Listato 3.21 - Classi DispatcherSoapBindingImpl con DDI
78/103
4 Global Weather Web Service
4.1 Introduzione
In 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 Workflow
L'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";
...
...
■ 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().
...
try {

getTModelInstanceDetails().getTModelInstanceInfoVector();

TModelInstanceInfo instanceInfo = (TmodelInstanceInfo)
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().
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";
...
...
...
try {
//trovato il Binding Template con un punto di accesso HTTP
GetTModelInstanceDetails().
TModelInstanceInfo instanceInfo = (TmodelInstanceInfo)
InstanceDetails details = instanceInfo.
getInstanceDetails();
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().
...
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";
...
...
// Intercetto il binding associato e scorro la lista.
...
try {
bindingTemplate = (BindingTemplate)
listBTemplate.elementAt(i);
// ottenuta la lista di binding template, possiamo
// ottenere la lista delle URL associate
GetTModelInstanceDetails().
84/103
TModelInstanceInfo instanceInfo =
(TmodelInstanceInfo)
InstanceDetails details =
instanceInfo.getInstanceDetails();
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).
Sat Apr 05 12:56:14 CEST 2008: service Dispatcher accessed 1 time(s).
17 Sito in C:\Documents and Settings\Giuseppe Specchio
86/103
4.3 Class Diagram

In 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
Illustrazione 4.9: Class Diagram della servlet CallDispatcherServices
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.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 logic

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

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 DispatcherService

interfaccia 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 fittizio
Il 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.

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 conversione

Il 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 Cases

In 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à.
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 :
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 Diagram

In 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 Bigliogragia
1. 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

Java WebServices

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Java WebServices

Caricato da

Copyright:

Formati disponibili

Progetto Laboratorio di Sistemi Distribuiti Giuseppe Specchio

Corso di Laurea Specialistica in Informatica

Giuseppe Specchio Matr.0120444 A.A. 2007-2008

Tale definizione, ovviamente non è da considerarsi di carattere esaustivo, soprattuto poiché

servizio bidirezionale, un'applicazione e non naviga semplicemente in un sito.

1 SOA: Service-Oriented Architecture

1.2 Caratteristiche di una SOA

1.3 Come funziona una SOA

Illustrazione 1.1: Esempio di Architettura SOA.

Illustrazione 2.1: Servizi Web: XML e

sistema al fine di completare l’accettazione e l’evasione della richiesta di previsioni meteo,

2.2 Scenari Complessi

Scopre WSDL UDDI Registry Registra WSDL

Service Consumer Service Provider

Illustrazione 2.3: Pila concettuale dei Web Service

2.4.1 Struttura di un documento XML

Listato 2.1 - Un semplice esempio di messaggio XML

2.4.2 DTD: Document Type Definition

2.4.3 XML Schema

2.4.4 Namespece XML

2.4.5 Lavorare con i documenti XML

2.4.5.1 Elaborazione tramite SAX

Illustrazione 2.5: Elaborazione SAX di un documento XML

2.4.5.2 Elaborazione tramite DOM

Illustrazione 2.6: Elaborazione DOM di un documento XML

Le classi SAXBuilder e DOMBuilder hanno vari costruttori in overloading che permettono di

documento (il default è false).

2.5 Il protocollo SOAP

Listato 2.2 - Un semplice esempio di messaggio SOAP

2.5.1 Il messaggio SOAP e modelli di scambio

Illustrazione 2.7: struttura di un messaggio

Illustrazione 2.8: Modello di scambio one-way

Illustrazione 2.9: Modello di scambio Request/Response

Illustrazione 2.10: Un esempio di catena di ascoltatori SOAP, con

2.5.2 Utilizzo dell’intestazione

Listato 2.3 - un esempio di header

2.5.3 Gestione degli Errori

Listato 2.4 - un esempio di Fault SOAP

● faultstring. Contiene sostanzialmente una descrizione dell’errore leggibile dall’essere

2.5.4 SOAP su HTTP

Listato 2.5 - Una richiesta SOAP su HTTP

Listato 2.6 - una risposta SOAP su HTTP

2.5.5 SOAP e RPC

<Wind> from the WSW (250 degrees) at 7 MPH (6 KT):0</Wind>

Listato 2.7 - Un esempio di RPC con SOAP

2.5.6 SOAP Encoding

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

Listato 2.8 - Un esempio di encoding SOAP

2.5.7 SOAP con Allegati

Listato 2.9 - Un esempio di SOAP con allegati

2.5.8 SOAP e Java

2.6 Il linguaggio WSDL

Illustrazione 2.12: Struttura di un documento WSDL1.1

Listato 2.10 - Struttura di un documento WSDL1.1

2.6.1 L'elemento Type

Listato 2.11 - Definizione del tag definitions

2.6.2 L'elemento Message

Listato 2.13 - Definizione dei blocchi Message

2.6.3 L'elemento PortType

Listato 2.14 - Definizione di un nuovo blocco PortType

2.6.4 L'elemento Binding

Listato 2.15 - Definizione di un blocco Binding relativo al metodo GlobalWeatherSoap

ed il secondo appartenente a SOAP.

Ovviamente sono due elementi diversi.