Università degli Studi di Bologna FACOLTA’ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica I web services come soluzione per l’interoperabilità e l’interazione automatica fra sistemi software Tesi di Laurea di: STEFANO RICCIARELLI Relatore: Prof. ANTONIO NATALI Correlatori: Prof. ENRICO DENTI Ing. LUCA BICCI Anno Accademico

Obiettivi  Analisi delle tecnologie dei Web Services  Comprensione del loro impatto nello sviluppo del software  Valutazione di costi e benefici dell’esposizione di un componente come Web Service  Sperimentazione su un case study reale (progetto EBroker)

Introduzione Forte esigenza di integrazione fra sistemi software: –Adozione pervasiva dell’information tecnology (contesti EAI e B2B) –Passaggio da una elaborazione confinata ad una esigenza di comunicazione fra sistemi Obiettivi: –Eterogeneità dei sistemi –Contesto distribuito e globale –Semplicità I WEB SERVICES

Nascita e standardizzazione Storia: –Inizialmente insieme di specifiche proprietarie a partire dal 1999 –Dal 2001 specifiche raccolte dal W3C: inizia un processo di standardizzazione –Consenso allargato da parte delle più importanti aziende dell’IT Obiettivi della standardizzazione: –Definizione coerente dell’architettura complessiva –Affermazione di un unico standard globalmente condiviso –Standard Royalty-Free I WEB SERVICES

Cos’è un Web Service Un Web Service: –E’ un sistema software identificato da un URI –E’ descritto da un documento XML rintracciabile mediante discovery –Interagisce con altri sistemi attraverso scambio di messaggi XML veicolati da protocolli internet-based Architettura –Modello service-oriented –Insieme di specifiche organizzate a Stack I WEB SERVICES

Service Oriented Architecture Service Requestor Discovery Agency Service Provider Service Description Client Publish Interact Find Service Description Wire Stack Description Stack Discovery Agency Stack Security Management QoS HTTP SOAP XML Schema WSDL

Quadro generale X language SW Component X language SW Component XML WSDL Y language SW Component X interface WSDL XML X interface X language 1. Analisi delle problematiche e delle soluzioni per adattare il componente agli standard dei web services 3. Nuovi scenari per i web services e limiti di WSDL 2. Verifica dell’effettiva interoperabilità con linguaggi diversi

Progettare un Web Service Analisi del contesto di sviluppo New Service Interface Existing Service Interface New Web Service green fieldtop-down Existing Application bottom-upmeet-in-the- middle Pattern di progettazione Esposizione di un componente “legacy” secondo gli standard dei web services (case study EBroker) Esposizione di un componente “legacy” secondo gli standard dei web services (case study EBroker)

Definizione del servizio Individuazione delle funzionalità da esportare –Semplice codifica secondo le regole di WSDL Definizione delle strutture dati –Estrazione della semantica dei dati –Trade off fra fruibilità e costi implementativi –Utilizzo di XML Schema per la descrizione dei dati Pattern di progettazione Definizione del servizio Stesura del documento WSDL (in un contesto bottom-up)

Implementazione del servizio Realizzazione dei binding fra applicazione e descrizione WSDL –Mapping fra metodi del componente e funzionalità esportate –Mapping fra dati applicativi e dati XML Schema Gestione operativa del binding: –istanziazione del componente –invocazione dei metodi –marshalling/unmarshalling dei dati –gestione della messaggistica SOAP –gestione della comunicazione di basso livello Deployment del servizio Pattern di progettazione Implementazione del servizio Definizione del servizio (in un contesto bottom-up) Utilizzo di una infrastruttura di supporto

Piattaforma di supporto Scopo –Fattorizzare molte delle problematiche comuni all’implementazione di servizi –Fornire dei tool semiautomatici di supporto anche per la fase di definizione del servizio –Abbattere i costi e i tempi di sviluppo Aspetti negativi –la scelta della piattaforma costituisce uno step del workflow di progettazione  dipendenza della soluzione dalla piattaforma scelta

Realizzazione dell’interazione Y Platform Runtime SOAP HTTP Y Service Ser./ Deser. Service Ties WSDL description Ser./ Deser. 1 X Platform Runtime X Client Ser./ Deser. Client Stubs Ser./ Deser. 22 JAX-RPC compliant Runtime Java Class

Serializzatori/Deserializzatori 1.Scrittura di serializzatori ad hoc per ogni classe Non richiede alcuna modifica alle classi del componente  Alti costi e tempi di sviluppo  Richiede competenze adeguate sulla specifica SOAP e sulla piattaforma adottata  Produce una soluzione specifica per la piattaforma di supporto scelta 2.Utilizzo dei serializzatori previsti dalle specifiche JAX- RPC Tempo di sviluppo nullo (per i serializzatori) Nessuna competenza richiesta Soluzione riutilizzabile con qualunque piattaforma JAX-RPC  Dipendentemente dalla ingegnerizzazione del componente può richiedere nessuna o molte modifiche ai sorgenti Le classi da esportare devono essere dei JavaBean

Sviluppo della prima soluzione 1.Individuazione delle classi da esportare 2.Modifica delle classi per renderle dei JavaBean (le modifiche non devono influenzare il comportamento del componente) 3.Generazione automatica del WSDL 4.Scelta della piattaforma di supporto Apache Axis, compatibile JAX-RPC 5.Utilizzo dei serializzatori di Axis per i JavaBean 6.Deployment del servizio con Axis su Tomcat 7.Sviluppo di un client Java 8.Testing e analisi dei messaggi SOAP

Testing Java Client EBroker Localhost – JVM 1.4 Tomcat Application Server Axis Pacakge Bean Ser/Deser Client Stubs Axis Runtime Bean Ser/Deser Ebroker Ties Java TcpMonitor SOAP La soluzione funziona, ma… WSDL description ?

Modellazione del case study EBroker Modello delle classi da esportare dello EBroker Alcune classi non vengono incluse nella generazione del WSDL in quanto non raggiungibili attraverso un legame statico

Carenze semantiche Inoltre si ha la stessa definizione di tipo Map per dati che modellano entità diverse! Descrizione XML Schema della classe Hashtable ! La descrizione XML Schema dei dati contenuta nel WSDL non rispecchia l’effettiva struttura dei dati, così come emerge dal modello delle classi dello EBroker

Problema concettuale I Web Services sono significativi in contesti di: Integrazione fra sistemi disaccoppiati senza pregressa conoscenza La descrizione WSDL deve esplicitare la semantica del servizio La descrizione WSDL deve esplicitare la semantica del servizio ? ? Per il momento “semantica di tipo di dato”

Nuova descrizione WSDL Occorre: –Diversificare le Hashtable –Esplicitare il tipo di chiavi e valori –… altre operazioni di analoga natura Realizzazione di appositi serializzatori Reingegnerizzazione del componente Nuova descrizione WSDL ! Le modifiche alle classi di interfaccia non devono implicare altre modifiche nel componente

Reingegnerizzazione

Nuova soluzione sviluppata Completa e corretta descrizione dei dati nel WSDL  ottima fruibilità del componente Contenimento dei costi di reingegnerizzazione grazie all’ampio uso dell’ereditarietà  Necessario realizzare appositi serializzatori per le nuove classi introdotte, ma… … si eredita dai serializzatori di Axis per le Hashtable apportando modifiche minime per la generazione automatica del WSDL

Integrazione con Microsoft.NET Scopo: realizzare un client.NET capace di consumare il web service EBroker Problemi: la descrizione XML Schema dei dati, sebbene valida, non è riconosciuta dai tool automatici di Visual Studio.NET Vincoli sulla soluzione: –Nessun onere deve ricadere sullo sviluppatore del client  realizzazione del client mediante tool automatici –Nessuna modifica radicale alla struttura interna dello EBroker

Integrazione con Microsoft.NET Nuova descrizione WSDL compatibile con i tool automatici di.NET Sviluppo di appositi serializzatori lato server per il mapping fra i dati dello EBroker e la nuova descrizione WSDL new WSDL description Ser./ Deser. Classi EBroke r Classi EBroke r

Costi di sviluppo  Sviluppo di serializzatori ad hoc  richiesta comprensione approfondita del meccanismo di serializzazione di Axis (non esiste documentazione!)  Rilevanti problemi implementativi  Discreto livello di riuso dei serializzatori esistenti  Costi e tempi di sviluppo del web service complessivamente elevati ma lato client… Sviluppo di un client.NET capace di interagire con il web service Java a costi irrisori e tempi record Il processo di standardizzazione e le migliorie ai tool automatici possono portare ad un rapido cambiamento dell’attuale situazione dei costi (in un contesto bottom-up)

Web client Soluzione finale con client.NET Node B – JVM 1.4 EBroker Node A – Win2k OS Tomcat Application Server Internet Information Services (IIS).NET Framework C# Code Behind Autogenerated Proxy ASP.NET Page SOAP C# Internet Explorer HTML Client Page TcpMonitor ISAPI/.NET Axis Runtime EBroker Ties Bean Ser/Deser RecMap Ser/Deser ….. Ser/Deser SOAP Java HTTP WSDL description

Discovery Agency Service Requestor Discovery Agency Service Provider Service Description Client Publish Interact Find Service Description Obiettivo: interazione dinamica in un contesto B2B globale Web Service Architecture WSDL non basta. Servono delle metainformazioni di categorizzazione Discovery Agency come punto di incontro fra domanda e offerta di servizi

Registri UDDI – Modello d’uso UDDI Business Registry I motori di ricerca e le diverse applicazioni interrogano il registro alla ricerca dei servizi desiderati 3. Service Type Reistrations Le compagnie software e gli organismi di standardizzazione popolano il registro con la descrizione di differenti tipi di servizi 1. Business Registrations Le aziende popolano il registro con la descrizione dei servizi che offrono 2. Avviene l’integrazione vera e propria fra le diverse aziende che operano sul web 4.

Semantica per una interazione automatica Interazione automatica fra sistemi senza reciproca conoscenza Formalizzazione di concetti ed entità Standardizzazione globalmente condivisa + + Nuovo contesto di sviluppo: non più esposizione di un componente come web service (bottom-up) ma implementazione di un’interfaccia standard definita da appositi enti

Una semantica più evoluta E’ possibile una semantica che non sia semplice associazione concetto-standard? RDF OWL

Web Services e Business Process Service Level Agreement Composition Business Level Agreement Orchestration Interface Description Implementation Description Policy Presentation XML Schema } WSDL WSCI BPEL4WS Description Stack Interfaccia dinamica e statefull del web service Realizzazione di un web service come composizione di altri web service Interfaccia statica e stateless del web service

BPEL4WS Microsoft XLANG IBM WSFL BEA BPEL engine BPEL process Service Client Service Business Process Execution Language for Web Services  è una specifica eseguibile di un processo Implementazione BPWS4J di IBM Implementazione BPWS4J di IBM

Progettare in modo nuovo Applicazione come logica di flusso che coordina un insieme di web services: –Elevato riuso dei componenti –Produzione di applicazioni più comprensibili e facilmente gestibili –Rapida modificabilità delle applicazioni –Realizzazione di applicazioni mediante utilizzo di tool grafici Standard?

Conclusioni Si è acquisito il know-how necessario per esporre con successo un componente come web service, garantendo per esso una reale interoperabilità cross-platform Si sono compresi i nuovi scenari e le potenzialità dei web services nell’ambito della interazione automatica o guidata che potranno coinvolgere i progetti futuri

Università degli Studi di Bologna FACOLTA’ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica I web services come soluzione per l’interoperabilità e l’interazione automatica fra sistemi software Tesi di Laurea di: STEFANO RICCIARELLI Relatore: Prof. ANTONIO NATALI Correlatori: Prof. ENRICO DENTI Ing. LUCA BICCI Anno Accademico FINE