Università degli Studi di Modena e Reggio Emilia Facoltà dIngegneria - 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 È 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 , HTTPS, FTP, ecc.). Non ha problemi con i Firewall: –Messaggi testuali semplifica lanalisi 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 laffidabilità 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 dinterfaccia 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 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 lelemento root XML, non supporto lattributo 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 Apache SOAP Web Server: IIS Visual Basic + Microsoft SOAP Toolkit 6 int: 2 int: 4 Apache SOAP per tutti i valori di risposta richiede sempre la loro tipologia. Ad esempio: 6 è 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: 6 è 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 levoluzione 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 Visual Basic + Microsoft SOAP Toolkit Web Server:Tomcat Apache Axis int: 6 Servizio Add WSDL Add Java2WSDL int: 2 int: 4 I due toolkit sono perfettamente compatibili. È possibile utilizzare il supporto WSDL.

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. Strumento che facilita il lavoro dello sviluppatore. WSDL2Java WSDL Exchange Client Apache Axis Web Server: Tomcat Apache Axis float:0.90 String: USA String: Italy

Il sistema MOMIS Il sistema MOMIS (Mediator EnvirOnment for Multiple Information Source) nasce dalla collaborazione fra lUniversità di Modena e Reggio Emilia e lUniversità 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 allarchitettura ad oggetti distribuiti CORBA. Allinterno 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 dinteroperabilità. È un protocollo binario Problemi nellattraversare i firewall. Richiede lutilizzo di porte TCP/IP non standard aumentare i rischi in termini di sicurezza.

MOMIS e SOAP Per superare le difficoltà del protocollo IIOP è nata lidea dintegrare 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 Corba Global Schema Client VB + MST IIS Server Apache Axis Tomcat Applicazione ASP Richiesta SOAP Risposta SOAP Richiesta Corba Risposta Corba Funzionamento del servizio: 1.Lutente 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. 6.Il client recupera il valore della risposta e lo invia allapplicazione ASP. 7.Il valore della risposta viene visualizzato allinterno del browser Internet. Ambiente Microsoft/Windows Ambiente Unix/Solaris Internet Firewall WSDL ClassiLocali

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 dintegrazione. Possibilità di aprire lutilizzo dei servizi MOMIS a diversi linguaggi di programmazione attivi su differenti architetture rendere possibile linteroperabilità. Possibilità di utilizzare in remoto i servizi SOAP di MOMIS: - senza incontrare difficoltà nellattraversare i firewall. - sfruttando la porta TCP/IP standard.

Conclusioni Lo sviluppo della tesi si è concentrato sul concetto dinteroperabilità offerto da SOAP verificando questo nellutilizzo 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 dimplementazione 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 lintegrazione di tutti i servizi MOMIS con il protocollo SOAP.