Studio delle problematiche legate alla realizzazione di una applicazione enterprise basata su Web Service

  
CAPITOLO 1 
1.2 FINALITÀ DEL LAVORO 
 
In E-TREE è presente ormai da tempo l’EIP, Enterprise Information Portal. Si 
tratta di un portale aziendale che permette l’accesso a tutti i dipendenti 
dell’azienda e offre loro dei permessi, a seconda  del ruolo che ricoprono, per 
gestire le risorse dell’azienda. 
 
Quello che mi è stato proposto è stato rendere disponibile una porzione del 
portale via servizio web, e tale porzione è stata fissata nella gestione dei profili 
degli utenti: quindi riconoscimento della login tramite username e password, 
creazione, aggiornamento e rimozione dei profili, eccetera. 
 
Ma dove sta il vantaggio di tutto ciò? Rendendo disponibile via web service tale 
porzione si potranno sfruttare i vantaggi che offre tale tecnologia: ad esempio 
(e per ora rimango volontariamente nel vago) il servizio di login potrà essere 
interrogato da client tra loro assolutamente eterogenei: postazioni fisse di 
lavoro, o dispositivi portatili, cellulari, palmari o navigatori satellitari per auto 
che siano, basta che supportino una versione adeguata della macchina virtuale 
java. 
 
Tutto ciò scrivendo una sola volta il servizio web e rendendolo disponibile sulla 
rete. 
 
Tutti questi concetti saranno esposti di seguito. 
 
 
1.3 ORGANIZZAZIONE DEL LAVORO 
 
Temporalmente il lavoro è stato suddiviso nelle seguenti parti. 
 
Il primo mese è stato totalmente dedicato allo studio della tecnologia dei web 
service, cercando documentazioni (a volte anche introvabili e tutt’altro che 
complete) sulla Rete o su materiale cartaceo che mi è stato gentilmente 
offerto in azienda. Fase questa che comunque non è mai finita, ma si è 
protratta per tutto il corso dello stage. 
Durante questo periodo non è stata mai messa mano a codice, se non per 
provare alcuni esempi forniti dai tutorial relativi all’argomento. Piuttosto, il 
tempo è stato occupato studiando e installando i numerosi strumenti che 
sarebbero serviti. 
 
Lo sviluppo dell’applicazione ha occupato le successive 8 settimane, periodo 
durante il quale sono stati sviluppati, nell’ordine, i seguenti moduli: 
 
• sviluppo del codice relativo al servizio web da esporre; 
• sviluppo del codice per la gestione del database; 
• sviluppo del codice relativo a 2 tool che permettono la pubblicazione e la 
rimozione del servizio su un registro IBM; 
• sviluppo del codice relativo all’implementazione di un client interrogabile 
da browser internet; 
  
INTRODUZIONE
• sviluppo del codice relativo all’implementazione di un client via 
dispositivo J2ME (nel caso specifico, un telefono cellulare); 
• sviluppo di alcune cose minori, come la stesura di codice XML per la 
creazione di deployment descriptors, file WSDL, e altre particolarità che 
saranno descritte in seguito. 
 
Come si vede i client implementati sono 2: quello interrogabile da browser e 
quello da dispositivo J2ME; altri client, come quello relativo ad un dispositivo 
di navigazione satellitare erano solo questione di tempo e perfettamente 
realizzabili; l’autore e il tutore aziendale hanno ritenuto opportuno e sufficiente 
la realizzazione di questi due, visto che crearne altri nulla avrebbe aggiunto 
allo scopo del lavoro. 
 
Per quel che riguarda l’organizzazione del testo, esso è stato diviso in due 
grosse parti: 
 
• la prima riguarda i web service in generale, nella quale si cercherà di 
spiegare la loro natura, la loro architettura, i vantaggi che essi 
apportano, e gli strumenti che possono utilizzare; in questa parte si 
cercherà di scendere il meno possibile nei dettagli implementativi 
(lasciati alla seconda parte) e si tenderà piuttosto a fornire una loro 
descrizione di più ampio respiro; 
• la seconda descrive nei particolari l’applicazione sviluppata dall’autore, 
spiegando le sue funzionalità e i vantaggi che essa trae dalla sua natura 
distribuita. 
 
 
1.4 E-TREE 
 
1.4.1 DESCRIZIONE DELL’AZIENDA 
 
E-TREE, la Web Company del gruppo Etnoteam, è specializzata nella 
realizzazione di soluzioni di e-business. Nata nel 1998, è una delle aziende del 
panorama Internet italiano che spicca per le forti competenze tecnologiche 
oltre che per la rapida crescita e i risultati ottenuti. 
 
Con oltre 160 persone specializzate nello sviluppo applicativo e nello studio 
grafico, E-TREE è stata incaricata di progettare, realizzare ed integrare 
numerose soluzioni di elevata complessità sia in Italia che in Europa. 
 
E-TREE abbraccia completamente la tecnologia J2EE (Java 2 Enterprise 
Edition), alla base delle piattaforme enterprise leader di mercato, per la 
realizzazione di soluzioni multicanale per B2B, B2C, ICRM, Content 
Management, Marketing e Community Building, oltre a soluzioni dedicate alla 
Mobile Community. 
 
Internamente alla società si è sviluppata Webanana, la divisione specializzata 
nelle diverse aree inerenti l'aspetto grafico e creativo della realizzazione dei 
  
CAPITOLO 1 
siti Web. Le sue principali attività sono l'ideazione e la realizzazione di concept 
grafici, animazioni multimediali, interfacce utente e filmati digitali. 
 
La conoscenza di Internet, la metodologia di progetto, la competenza e la 
maturità raggiunta fanno di E-TREE un'azienda in grado di offrire diverse 
soluzioni di e-business e di servizi completi e all'avanguardia in grado di 
soddisfare completamente le esigenze del singolo cliente. 
Tra i clienti più importanti E-TREE vanta nomi quali Assicurazioni Generali, BNL 
Multiservizi, Il Sole24 Ore, Motonline, Ducati, Benetton, Gruppo Seat, Italia On 
Line, Telecom Italia, H3G, Wind, Blu, Save, Snaidero, Zoppas. 
 
E-TREE oggi è presente con le sue sedi a Treviso, Roma, Milano, Capodistria 
(Slovenia), San Francisco (USA). 
 
1.4.2 THE NO-SLEEPING COMPANY 
 
The No-sleeping Company, la compagnia che non dorme: l’autore si è accorto 
della veridicità di questo motto l’11 febbraio 2002, giorno in cui ha iniziato 
l’esperienza di tirocinio di 400 ore prevista dal Corso di Diploma in Ingegneria 
Informatica. 
 
Subito ci si rende conto di come l’ambiente sia sostanzialmente diverso da 
quello che ci si potrebbe aspettare entrando in una qualsiasi azienda. Il modo 
di lavorare è manifestatamente rivolto alla dinamicità: gli orari sono flessibili, i 
progetti sono stimolanti, oltre che numerosi e impegnativi. Per far fronte a 
questo, E-TREE offre un vasto ambiente extra-lavorativo negli spazi interni dei 
loft che la compongono: oltre all’ampia area lavorativa, sono infatti presenti 
anche palestre, piste da bowling, cucine, biliardi, calcetti, e perfino sale dove 
provare strumenti musicali e letti. Lo scopo di tutto ciò è quello di presentare 
al lavoratore un ambiente piacevole e stimolante. Ma questo deve anche 
portare ad assumersi una certa responsabilità nei confronti di ciò che si sta 
facendo, quindi si è subito messi di fronte al fatto che è importante imparare a 
gestire le proprie risorse, visto che molto è lasciato al libero arbitrio di ognuno. 
 
Detta così sembra che l’anarchia possa regnare sovrana, ma non è così, visto 
che dal settembre 1998 (mese in cui è nata) fino ad oggi, E-TREE ha avuto 
una crescita a dir poco vertiginosa, che non ha pari in altre aziende dello 
stesso settore. 
  
p a r t e   p r i m a
i web service 
in questa parte:
 
• il web service  
• la comunicazione  
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2.1 DEFINIZIONE 
 
Il termine Web Service ha raggiunto molta popolarità nel corso dell’ultimo 
anno. Molti produttori di software (grandi e piccoli) hanno annunciato di voler 
sviluppare iniziative basate su web service. Molte organizzazioni sono 
impegnate nella definizione di standard per i web service. Anche se sembra ci 
sia una certa convergenza di idee su cosa significhi questo termine, non c’è 
ancora una singola e universale definizione adottata per spiegare questa 
tecnologia. 
 
Noi comunque adotteremo una definizione proposta dalla IBM, che appare 
sufficientemente chiara e precisa: 
 
“Un Web Service è un’interfaccia che descrive una collezione di operazioni 
accessibili attraverso una rete mediante un sistema di messaging basato su 
XML. Un web service assolve ad uno specifico compito o ad una classe di 
compiti. Un web service è descritto usando una notazione standard XML, 
chiamata descrizione del servizio, la quale fornisce tutti i dettagli necessari per 
interagire col servizio, inclusi i formati dei messaggi, i protocolli di trasporto e 
la residenza del servizio. 
La natura dell’interfaccia nasconde i dettagli implementativi del servizio in 
modo tale che esso possa essere usato indipendentemente dalla piattaforma 
hardware e software sulla quale è sviluppato, e indipendentemente dal 
linguaggio di programmazione col quale è scritto. Questo permette alle 
applicazioni basate su web service di essere orientate ai componenti e 
indipendenti dalla tecnologia di sviluppo. I web service possono essere usati 
da soli o in congiunzione con altri web service per costruire complesse 
aggregazioni di servizi”. 
C A P I T O L O
2
IL WEB SERVICE
  
CAPITOLO 2 
 
Seguendo la definizione proposta da IBM, un web service è quindi un 
componente software indipendente dalla piattaforma e dai dettagli 
implementativi coi quali è sviluppato. 
Esso può essere: 
 
• descritto usando un linguaggio di descrizione; 
• pubblicato in un registro di servizi; 
• ricercato attraverso un meccanismo standard (a runtime o design time); 
• invocato con una apposita API, di solito attraverso una rete; 
• congiunto con altri web service. 
 
Ci sono altre definizioni proposte da Microsoft e Sun, ma esse sembrano meno 
esaurienti di quella appena costruita. 
Insomma, c’è una comune idea su cosa sia un web service, ma non esiste una 
precisa definizione che metta d’accordo tutti. Molti sviluppatori amano dire: 
 
“Non riesco a definire un web service, ma quando lo vedo lo riconosco”. 
 
 
2.2 PERCHÉ SCEGLIERE I WEB SERVICE? 
 
I web service sono destinati a ridefinire il modo con cui in futuro verrà 
utilizzata la Rete, che oltre a proporre connessioni sempre attive e disponibili e 
a supportare un numero sempre maggiore di dispositivi (PC, telefoni cellulari, 
Pda, ecc), permetterà di assemblare applicazioni che consentiranno ai privati 
di accedere a servizi tagliati a misura delle loro esigenze, e alle aziende di 
comunicare e di gestire attraverso il web i loro rapporti con clienti, partner e 
fornitori, in modi neppure immaginabili solo poco tempo fa. 
 
A tutt’oggi la maggior parte delle applicazioni è progettata come un insieme 
monolitico di funzioni, la cui capacità di coesistere e di interagire con altre 
applicazioni è il risultato di un complesso lavoro di integrazione. Ciò genera di 
solito strutture difficili da modificare qualora vengano meno le condizioni che 
avevano determinato la loro necessità di lavorare insieme. Con la 
standardizzazione dei componenti dei servizi web questo problema viene ad 
essere completamente superato, con grandi vantaggi sulla possibilità di 
utilizzare la Rete per supportare e migliorare i processi di business. 
 
Caratteristica fondamentale dei web service è infatti la loro modularità: a 
differenza delle applicazioni tradizionali, i web service saranno costituiti da 
blocchi, ciascuno dei quali potrà, per eseguire nel modo migliore i compiti che 
gli sono stati affidati, fare a sua volta ricorso ad altri componenti. 
 
Un altro vantaggio molto importante dei web service è il fatto che essi 
incorporano dei protocolli standard per la chiamata ai servizi e per la 
trasmissione dei dati. Come avviene questo? 
 
  
IL WEB SERVICE
Premettiamo una cosa: un web service si basa su dei principi che possono 
sembrare sorprendentemente semplici, e non sono nulla di nuovo nel mondo 
dell’architettura distribuita su Internet: 
 
• il service provider definisce un formato per le richieste al suo servizio e 
per le risposte che lo stesso servizio fornisce; 
• un client invia una richiesta al service provider attraverso la rete; 
• il service provider ascolta la richiesta, esegue qualche azione e ritorna  
una risposta. 
 
Tuttavia, mentre negli anni passati molti service providers avevano standard 
proprietari e modelli di dati realizzati apposta per eseguire le operazioni sopra 
descritte,  ora con questa tecnologia possiamo fare affidamento all’ eXtensible 
Markup Language (XML) per la comunicazione sulla rete, la quale viaggia sul 
semplice e conosciuto protocollo HTTP. Questo significa un’accesso più 
semplice e soprattutto standard alle risorse di rete e permette agli sviluppatori 
di concentrarsi su altri aspetti del loro lavoro. 
 
Così come Java è diventato famoso perché garantisce la portabilità del codice 
in rete, così XML garantisce la portabilità dei dati che in quella rete si 
spostano. 
 
Non è lo scopo di questo testo fornire una descrizione dettagliata di XML, tanto 
è vero che qualsiasi web developer sarebbe in grado di sviluppare un web 
service senza conoscerne la sintassi. Piuttosto, sarà ben più importante 
acquistare familiarità con quei protocolli e quei formati che di XML fanno uso 
per assolvere ad alcuni precisi compiti di questo vasto mondo. 
Tuttavia forniamo nell’ Appendice A una breve esplorazione dei principi su cui 
si basa XML, sugli obiettivi per i quali è stato creato e sul perché serva al 
nostro scopo. 
 
Nel prossimo paragrafo cominceremo a studiare l’architettura su cui si basa un 
web service. 
 
 
  
CAPITOLO 2 
2.3 L’ARCHITETTURA 
 
L’architettura base di un web service è semplice da risultare quasi 
imbarazzante. Essa è sufficientemente generale da poter essere applicata ad 
una moltitudine di situazioni ed è illustrata nella figura 2.1. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Come si può vedere tale architettura contiene tre ruoli fondamentali: un 
service requestor, un service provider, e un service registry. 
 
• Il service provider (fornitore del servizio) è responsabile della creazione 
della service description (descrizione del servizio), della pubblicazione di 
tale descrizione su uno o più service registry, e della ricezione delle 
richieste da parte di uno o più service requestor. Un service provider, 
quindi, potrebbe essere qualsiasi compagnia che ospita un web service e 
lo rende disponibile sulla rete. Si può pensare al service provider come 
alla parte server della relazione client-server tra il service requestor e il 
service provider. 
 
• Il service requestor (utilizzatore del servizio) è responsabile della ricerca 
della service description pubblicata su uno o più service registry ed è 
responsabile dell’utilizzo della stessa service description per 
l’invocazione dei web service ospitati dal service provider. Qualsiasi 
utilizzatore di un web service può essere considerato un service 
requestor. Si può pensare al service requestor come alla parte client 
della relazione client-server tra il service requestor e il service provider 
(tanto che nel corso della trattazione useremo indifferentemente le 
diciture service requestor, requestor o client). 
 
• Il service registry (registro di servizi) è responsabile della gestione delle 
service descriptions fornitegli dal service provider e dei permessi forniti 
ai service requestors per la ricerca delle service descriptions contenute 
nel registro. Il ruolo del service registry è semplice: verificare che la 
Service 
requestor 
Service 
registry 
Service 
provider
Find Publish 
Bind
FIGURA 2.1 – architettura base di un web service
  
IL WEB SERVICE
relazione tra il service requestor e il service provider possa aver luogo. 
Una volta verificatolo, la sua presenza nello schema non è più 
necessaria; il resto della comunicazione avviene direttamente tra 
service requestor e service provider. 
 
Come si può vedere, nella figura sono presenti anche tre operazioni: 
publish, find e bind. Queste operazioni definiscono le relazioni tra i tre ruoli 
sopra esposti. 
 
• L’operazione di publish (pubblicazione) non è altro che l’operazione 
di registrazione del servizio nel service registry da parte del service 
provider. Quando un service provider pubblica la descrizione del suo 
servizio web su un service registry, rende disponibili le specifiche del 
servizio esposto ad una comunità di service requestors. 
Semplicemente, e molto spesso, il ruolo del server registry può 
essere interpretato dalla rete stessa, rendendo l’atto di pubblicazione 
una banale operazione di spostamento della descrizione del servizio 
dentro una cartella specifica di un web application server. 
Altre implementazioni di service registry, come UDDI (Universal 
Description, Discovery and Integration, che tra l’altro sarà usata 
dall’autore per la pubblicazione della sua applicazione), definiscono 
una realizzazione dell’operazione di publish davvero completa e 
sofisticata. 
 
• L’operazione di find (ricerca) è duale all’operazione di publish. Con 
l’operazione di find il service requestor definisce dei criteri di ricerca, 
come ad esempio il tipo di servizio, o altri aspetti come la qualità 
garantita dal servizio, e così via. Il service registry confronta tali 
criteri di ricerca con la collezione di descrizioni di servizi che ospita. 
Il risultato dell’operazione di find è una lista di descrizioni di servizi 
che soddisfano ai criteri di ricerca. Ovviamente il grado di 
sofisticazione dell’operazione di find varia a seconda del livello di 
implementazione del service registry che la fornisce: il più semplice 
dei service registries può fornire un’operazione di ricerca che non è 
nient’altro che una chiamata HTTP GET senza parametri; in questo 
caso tale operazione ritorna al service requestor tutte le descrizioni 
di servizio presenti, ed è compito del requestor stesso scegliere 
quelle che fanno al suo caso. Al contrario, UDDI fornisce facoltà di 
ricerca estremamente potenti. 
 
• L’operazione di bind incorpora la relazione client-server tra il service 
requestor e il service provider: essa può essere vista come l’effettiva 
comunicazione che avviene tra queste due entità. Per ora ci si può 
limitare ad accettare questa definizione di comunicazione molto 
generale, tenendo presente che l’architettura dei web service 
permette di realizzarla in modo statico (per esempio come codifica 
manuale del modo in cui l’applicazione client invoca il servizio), 
oppure in modi molto più sofisticati e dinamici. 
 
 
  
CAPITOLO 2 
2.4 LE SCELTE EFFETTUATE 
 
Si tenga presente come, ogni volta che un’architettura service-oriented viene 
sviluppata, ci possono essere differenti tecnologie per adempiere ad ogni 
scopo, e quella appena esposta non fa differenza. 
 
Infatti esistono diversi modi per: 
 
• implementare un service registry; 
• descrivere i servizi per poterli esporre su di un server registry; 
• realizzare la comunicazione tra requestor e provider, cioè l’operazione di 
bind. 
 
Rispettivamente, le scelte effettuate sono le seguenti: 
 
• per implementare il service registry, come già detto, noi sceglieremo 
per la nostra applicazione quello fornito da UDDI; la scelta è stata 
dettata dalla potenza e dalla completezza della suddetta tecnologia. 
Essa sarà prima studiata nel paragrafo 3.4, per poi essere 
effettivamente utilizzata dall’applicazione come descritto nel paragrafo 
6.3; 
• per la descrizione dei servizi sceglieremo il linguaggio WSDL (Web 
Service Description Language), un linguaggio di descrizione ovviamente 
basato su XML. La scelta è stata dettata dal fatto che esso è ormai è 
uno standard riconosciuto dalla maggior parte dei servizi, ed è molto 
potente. Esso sarà studiato nel paragrafo 3.3, e poi utilizzato nel modo 
descritto dal paragrafo 6.3; 
• per la comunicazione, la parte più importante, la nostra scelta ricadrà 
sul protocollo SOAP (Simple Object Access Protocol), semplicemente 
perché si tratta del protocollo basato su XML più usato per la 
comunicazione nei web service. In particolare si utilizzeranno due sue 
specifiche implementazioni, come vedremo nel capitolo 4. 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3.1 LE COMPONENTI 
 
In questo capitolo spiegheremo gli strumenti usati per la comunicazione 
nell’architettura di un web service: 
 
• il protocollo SOAP; 
• il linguaggio WSDL; 
• il registro UDDI. 
 
Non entreremo nei dettagli implementativi, poiché questa è una trattazione 
prettamente teorica. Le maniere su come realizzare il servizio, su come farne il 
deploy su un servlet container, su come realizzare il requestor e su come 
implementare tutto il resto saranno trattate rigorosamente nella seconda 
parte, quando si descriverà l’applicazione. 
 
 
3.2 IL PROTOCOLLO SOAP 
 
3.2.1 COS’È SOAP? 
 
SOAP (Simple Object Access Protocol) è un protocollo basato su XML, ed è 
forse il più diffuso per lo scambio dei messaggi nei web service. SOAP fornisce 
un semplice e consistente meccanismo che permette ad un’applicazione di 
mandare un messaggio XML ad un’altra applicazione. 
 
C A P I T O L O
3
LA COMUNICAZIONE
  
CAPITOLO 3 
Un messaggio SOAP è una trasmissione di dati da un mittente SOAP ad un 
destinatario SOAP, e qualunque applicazione che supporti il protocollo può 
parteciparvi in veste di mittente o destinatario. I messaggi SOAP possono 
essere combinati per supportare diversi tipi di comunicazione, incluso il ben 
noto richiesta/risposta, il messaging asincrono ad una via, o la notifica di 
eventi. 
 
SOAP è un protocollo ad alto livello che definisce solo la struttura dei messaggi 
e le regole per la loro lettura e scrittura. Esso è completamente indipendente 
dal protocollo di trasporto sottostante, in modo tale che i messaggi SOAP 
possano viaggiare su HTTP (ed è questo che useremo), JMS (Java Message 
Service), o anche sui protocolli di trasporto per la posta elettronica come SMTP 
(Simple Mail Transfer Protocol). Attualmente il protocollo HTTP è quello più 
usato per il trasporto di messaggi SOAP: questo approccio permette tra l’altro 
di evitare le limitazioni alla comunicazione imposte dai firewall, limitazioni che 
invece affliggono i sistemi enterprise che usano architetture basate su oggetti 
distribuiti come COM+, CORBA o EJB. 
 
3.2.2 ARCHITETTURA E MESSAGGI SOAP 
 
Attualmente sono disponibili diverse implementazioni di SOAP ([1], [2], [3]) 
che fanno riferimento alla specifica tecnica presentata il 5-05-2000 dal SOAP 
forum (Microsoft, IBM, HP, Jona….) al W3C (World Wide Web Consortium, un 
consorzio di aziende del settore informatico che si occupa di stabilire standard 
di riferimento per il Web). 
 
Però l'interoperabilità di queste diverse implementazioni viene assicurata dalla 
conformità di un messaggio SOAP (call o response) allo SCHEMA XML definito 
dallo standard (che prevede due parti obbligatorie: envelope e body, e una 
parte opzionale, header). 
 
La figura 3.1 illustra il ciclo di una chiamata SOAP. Il client utilizza una 
particolare implementazione di SOAP (chiamiamola Client-side SOAP), la quale 
presenterà un parser che si occuperà di codificare in XML la chiamata a 
metodo remoto del client. Il canale SOAP (HTTP) instrada la chiamata verso il 
Web Server indicato nell'header. Il Web Server passa il pacchetto SOAP al 
proprio parser presente nel Server-side SOAP, che lo de-parserizza ed effettua 
l'invocazione del metodo. In seguito riceve il risultato della chiamata e 
costruisce un pacchetto di risposta SOAP well-formed. Questo pacchetto viene 
rispedito al parser del client, che lo de-parserizza e presenta il risultato 
all'applicazione. Lo standard non definisce né il modello a oggetti né il 
linguaggio delle entità comunicanti su differenti server. 
 
  
LA COMUNICAZIONE
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Le implementazioni di SOAP che noi utilizzeremo per l’applicazione sono 2: 
- Apache-SOAP dell’Apache Group per la parte SOAP del requestor 
interrogabile da browser e per la parte SOAP del provider; 
- Enhydra kSOAP per la parte SOAP del requestor via dispositivo J2ME. 
 
Pur se diverse (la seconda è molto più limitata della prima in quanto risiede su 
un dispositivo limitato nell’hardware) esse rispettano le specifiche del 
protocollo SOAP e sono quindi compatibili. 
Ovviamente per ora eviteremo di entrare nei dettagli delle 2 implementazioni, 
però per fissare un po’ le idee vale la pena vedere quali operazioni bisogna 
eseguire per creare un messaggio con Apache-SOAP, senza comunque entrare 
nei dettagli di un esempio: lo vedremo quando si tratterà di utilizzarla per 
l’applicazione. 
 
Una spiegazione del funzionamento di kSOAP la si può trovare in appendice C. 
Client Web Server 
Server-side SOAP
de-parsing
parsing 
Logica del   
servizio 
Client-side SOAP 
parsing 
de-parsing 
Logica 
dell’applicazione 
chiamata soap codificata in 
XML (nome del metodo da 
chiamare, parametri, 
ecc.): 
 
<SOAP:envelope> 
(informazioni..) 
</SOAP:envelope> 
risposta soap codificata in 
XML: 
 
<SOAP:envelope> 
(informazioni..) 
</SOAP:envelope> 
FIGURA 3.1 – diagramma dell’architettura SOAP