Università degli Studi
di Modena e Reggio Emilia
Facoltà d’Ingegneria - sede di Modena
Corso di Laurea in Ingegneria Informatica
Interoperabilità di componenti software fra sistemi
operativi eterogenei attraverso il protocollo SOAP.
Confronto e sperimentazione
Relatore
Chiar.mo Prof.
Sonia Bergamaschi
Correlatore
Ing. Maurizio Vincini
Tesi di Laurea di
Sandro Bernardini
Obiettivi
• Studio del protocollo SOAP (Simple Object Access Protocol) e
del linguaggio WSDL (Web Services Description Language) in
riferimento alle specifiche del consorzio W3C (World Wide
Web Consortium).
• Studio ed utilizzo dei principali toolkit che implementano
il protocollo SOAP:
– Apache SOAP 2.2.
– Microsoft SOAP Toolkit.
– Apache Axis.
• Integrazione del sistema MOMIS con il protocollo SOAP.
Protocollo SOAP
• Il protocollo SOAP (Simple Object Access Protocol) nasce nel
dicembre 1999, da collaborazioni fra Microsoft, IBM,
Sun, ecc.
• È diventato un protocollo standard ed attualmente è
disponibile la specifica 1.2 rilasciata dal consorzio W3C
nel Dicembre 2001.
• È un protocollo basato su XML e nasce con lo scopo di
migliorare il trasporto dei dati fra sistemi distribuiti
eterogenei decentralizzati.
• SOAP rappresenta il mezzo per mettere in contatto
piattaforme diverse: tralasciando problematiche legate
alle comunicazioni fisiche, ai sistemi operativi, ai
linguaggi di programmazione ed ai protocolli di
comunicazione.
Vantaggi e Svantaggi SOAP
 Vantaggi:
• Interoperabilità di applicazioni su piattaforme diverse.
• Sfrutta tecnologie Web già consolidate:
– XML  per esprimere le informazioni
– HTTP  per trasportare le informazioni
• Ma rimane indipendente dal protocollo di trasporto (ad
esempio può funzionare via email, HTTPS, FTP, ecc.).
• Non ha problemi con i Firewall:
– Messaggi testuali
 semplifica l’analisi ed il monitoraggio del traffico in ingresso.
– Utilizzo di porte TCP/IP standard
 non sono necessarie configurazioni del firewall “rischiose”.
 Svantaggi:
• Prestazioni (la serializzare in XML/deserializzare da XML del payload
informativo, per moli elevate di dati, riduce la velocità delle applicazioni).
Altre caratteristiche di SOAP
• Non specifica nulla sulle applicazioni in uso.
• Non gestisce il routing dei messaggi.
• Non gestisce l’affidabilità dei dati.
Mantenere la max
semplicità
Per avere la max
flessibilità ed
espandibilità
max
Interoperabilità
Linguaggio WSDL
• Linguaggio basato sulla grammatica XML.
• Definisce in modo strutturato e standard le specifiche d’interfaccia di
un servizio Web.
• Se un servizio remoto fornisce il documento WSDL che lo descrive,
allora un client può reperire automaticamente tutte le informazioni
sul servizio stesso.
 si facilita il compito dello sviluppatore.
 si rende standard la rappresentazione di un servizio.
• Attualmente è disponibile la specifica 1.1 rilasciata dal consorzio
W3C nel Marzo 2001.
 Facilita lo sviluppo di nuove applicazioni.
Apache SOAP 2.2
• Conforme alla specifica SOAP 1.1 del W3C.
• Sul lato client estende Java con alcuni package.
• Sul lato server è semplice codice Java +
deployment descriptor per la pubblicazione.
• Limitazioni:
– Non supporta il linguaggio WSDL.
– Presenta delle limitazioni rispetto alla specifica 1.1
(Attributo encodingStyle e mustUnderstand hanno valore predefinito, non
supporta l’elemento root XML, non supporto l’attributo actor).
Microsoft SOAP Toolkit 2.0
• Aggiunge le funzionalità SOAP ai principali linguaggi di
programmazione di casa Microsoft (come Visual Basic e VC++).
• Conforme alle specifiche SOAP 1.1 del W3C.
• Supporta la specifica WSDL 1.1 del W3C.
• Per pubblicare i servizi richiede la presenza del web
server di casa Microsoft: IIS (Internet Information Server).
• Il toolkit permette di eseguire chiamate a servizi o
pubblicare questi attraverso due livelli di API (Application
Program Interface):
– high (sfruttano il supporto WSDL facilitando lo sviluppatore, che può
ignorare alcuni meccanismi).
– low (forniscono una maggiore flessibilità).
Servizio Add
Client
Web Server: IIS
int: 2
int: 4
6
Apache SOAP
Visual Basic +
Microsoft SOAP Toolkit
Apache SOAP per tutti i valori di risposta richiede sempre la loro tipologia.
Ad esempio: <return xsi:type="xsd:int">6</return> è la risposta attesa, dove
viene specificato esplicitamente che si tratta di un intero.
Microsoft SOAP Toolkit non specifica la tipologia dei dati inviati.
Ad esempio: <return>6</return> è la risposta inviata.
Problema: Apache SOAP e Microsoft SOAP Toolkit di base sono incompatibili.
(Apache SOAP rigetta i dati inviati dal server).
 È stato necessario introdurre un nuovo deserializzatore sul client Apache SOAP, in
questo modo, il client accetta la risposta del server VB anche se non è specificato il tipo di
dato inviato.
Discorso analogo scambiando le architetture fra client ed il server.
Apache Axis
• Rappresenta l’evoluzione di Apache SOAP 2.2, da cui
eredita le caratteristiche di base.
• Elimina i difetti del predecessore:
 È perfettamente compatibile con Microsoft SOAP Toolkit.
 Supporta le specifiche WSDL 1.1.
• Novità:
– Supporto parziale delle specifiche SOAP 1.2.
– Supporto per la pubblicazione automatica dei servizi (Java Web
Service).
– Generazione automatica (direttamente da un browser Internet) del
documento WSDL per un servizio pubblicato.
– Tool WSDL2Java e Java2WSDL.
Tool Java2WSDL
• Costruisce automaticamente il documento WSDL che descrive il
servizio implementato da una classe Java.
Client
Servizio Add
Web Server:Tomcat
int: 2
int: 4
int: 6
 I due toolkit sono
perfettamente compatibili.
 È possibile utilizzare il
supporto WSDL.
Apache Axis
Java2WSDL
Visual Basic +
Microsoft SOAP
Toolkit
WSDL
Add
Tool WSDL2Java
• Costruisce automaticamente tutte le classi/interfacce Java a partire
da un documento WSDL, cioè:
– Sul lato client, tutti gli oggetti Java necessari per accedere al servizio.
– Sul lato server, tutti gli oggetti Java necessari per implementare il
servizio.
Web Server: Tomcat
Client
String: USA
String: Italy
WSDL2Java
WSDL
float:0.90
Exchange
Apache Axis
 Strumento che facilita il lavoro dello sviluppatore.
Apache Axis
Il sistema MOMIS
• Il sistema MOMIS (Mediator EnvirOnment for Multiple Information Source)
nasce dalla collaborazione fra l’Università di Modena e Reggio
Emilia e l’Università di Milano e Brescia.
• MOMIS è stato progettato per fornire un accesso integrato ad
informazioni eterogenee.
• Attualmente la gestione dei dati per il sistema MOMIS è affidata
all’architettura ad oggetti distribuiti CORBA.
• All’interno di CORBA è possibile utilizzare il protocollo IIOP (basato
su TCP/IP) per la trasmissione dati, il quale presenta tre notevoli
svantaggi:
 Utilizzabile solo fra nodi con architettura CORBA
 Limite al concetto d’interoperabilità.
 È un protocollo binario
 Problemi nell’attraversare i firewall.
 Richiede l’utilizzo di porte TCP/IP non standard
 aumentare i rischi in termini di sicurezza.
MOMIS e SOAP
• Per superare le difficoltà del protocollo IIOP è nata l’idea d’integrare
il sistema MOMIS con il protocollo SOAP.
• Nella tesi si è sviluppato un primo servizio MOMIS utilizzabile in
remoto attraverso il protocollo SOAP (il quale sfrutta, come
protocollo di trasporto, HTTP sulla porta standard 80).
• Lato server sviluppato con Apache Axis
 è stato riutilizzato il modulo SIDesigner per accedere ai dati di MOMIS.
• Lato client sviluppato con:
– Apache Axis.
– Microsoft SOAP Toolkit (Visual Basic/ASP).
Servizio MOMIS/SOAP
Ambiente Microsoft/Windows
1.
L’utente richiede il servizio direttamente da un browser Internet.
2.
La relativa applicazione ASP richiama il client VB + MST.
3.
Il client invia la richiesta al server tramite un messaggio SOAP.
4.
Il server Apache Axis accede tramite CORBA al Global Schema del
sistema MOMIS per recuperare le informazioni necessarie.
5.
Il server invia la risposta del servizio al client tramite un messaggio
SOAP.
IIS
6.
Il client recupera il valore della risposta e lo invia all’applicazione
ASP.
VB + MST
7.
Il valore della risposta viene visualizzato all’interno del browser
Internet.
Applicazione ASP
Client
Funzionamento del servizio:
Richiesta Corba
Richiesta SOAP
Server
Apache Axis
Risposta SOAP
Corba
Global
Risposta Corba Schema
Firewall
WSDL
Internet
ClassiLocali
Tomcat
Ambiente Unix/Solaris
MOMIS e SOAP
• Il servizio permette di evidenziare le potenzialità di
SOAP:
 Possibilità di estendere il sistema MOMIS con SOAP, senza la
necessità di riprogettare/riorganizzare il sistema già presente
 semplice processo d’integrazione.
 Possibilità di aprire l’utilizzo dei servizi MOMIS a diversi
linguaggi di programmazione attivi su differenti architetture
 rendere possibile l’interoperabilità.
 Possibilità di utilizzare in remoto i servizi SOAP di MOMIS:
- senza incontrare difficoltà nell’attraversare i firewall.
- sfruttando la porta TCP/IP standard.
Conclusioni
• Lo sviluppo della tesi si è concentrato sul concetto d’interoperabilità
offerto da SOAP verificando questo nell’utilizzo pratico: dagli esempi
più semplici fino al caso reale del sistema MOMIS.
• Nel fare ciò sono state prese in considerazione, e fatte interagire,
due diversi tipi d’implementazione SOAP:
– Apache, che essendo basato su Java, si rivolge a diverse architetture.
– Microsoft, che si rivolge ai linguaggi di programmazione (di
conseguenza alle architetture) di casa Microsoft.
• Gli sviluppi futuri di questa tesi riguarderanno l’integrazione di tutti i
servizi MOMIS con il protocollo SOAP.