Telerefertazione medica su TCP/IP: Progetto e Realizzazione degli opportuni Web-Service

UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica e dell Automazione Telerefertazione medica su TCP/IP: Progetto e Realizzazione degli opportuni Web-Service Tesi di laurea di: D ALBERTO STEFANO Relatore: PROF. ING. ALDO FRANCO DRAGONI Correlatori PROF. PAOLO PULITI PROF. GUIDO TASCINI Anno Accademico 2006/2007

Capitolo 1. Struttura del progetto 1.1 1.2 1.3 Scopo e contenuto del documento... pag. 3 Descrizione del progetto applicativo pag. 3 Modello organizzativo... pag. 5 1.4 Glossario dei termini pag. 7 Capitolo 2. Il Web service 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 Introduzione al Web service...... pag. 8 Cosa sono i Web services e come funzionano...... pag. 10 XML Schema... pag. 11 UDDI pag. 13 WSDL.. pag. 13 SOAP pag. 15 Perché creare un Web Service...... pag. 17 2.4 Apache Axis......... pag. 18 Capitolo 3. Preparazione dell ambiente di sviluppo 3.1 Lato Server... pag. 21 3.3 Fase di deploy.. pag. 36 Capitolo 4. La comunicazione Client-Server 4.1 Servizi offerti lato server.. pag. 41 4.2 Axis Attachment... pag. 57 Capitolo 5. Struttura del database 5.1 5.2 5.3 Specifica delle operazioni pag. 60 Specifiche di progetto.. pag. 61 Progettazione concettuale della base di dati. pag. 68 Un primo schema scheletro.. pag. 68 1

5.3.1 5.3.2 Sviluppo delle componenti dello scheletro (inside-out)... pag. 68 5.4 Traduzione verso il modello relazionale.. pag. 75 5.5 Codifica SQL... pag. 78 Capitolo 6. Configurazione Server di sviluppo 6.1 Ambiente di sviluppo.... pag. 82 6.2 Installazione Java sul Server... pag. 83 6.3 Installazione TOMCAT su Server.. pag. 83 6.4 Installazione Oracle Database 10g XE..... pag. 85 6.5 Installazione e configurazione di Apache....... pag. 92 Capitolo 7. Problematiche e miglioramenti 7.1 Il server Linux..... pag. 94 7.2 Interoperabilità ed evoluzioni future pag. 97 7.3 Possibili sviluppi futuri..... pag. 98 Capitolo 8. Pubblicazione 8.1 Il firewall di Linux... pag. 101 8.2 Il comando iptables...... pag. 102 2

1. Struttura del progetto 1.1 Scopo e contenuto del documento Scopo del presente documento è definire le specifiche per l impostazione lato client e lato server sia a livello concettuale che fisico dell applicativo JTELEMED. 1.2 Descrizione del Progetto Applicativo Per Telemedicina si intende l erogazione di servizi sanitari, laddove la distanza rappresenti un fattore critico da parte di professionisti nell assistenza sanitaria che utilizzino tecnologie dell informazione e della comunicazione per lo scambio di informazioni rilevanti, per la diagnosi, il trattamento e la prev.enzione delle patologie e per l educazione continuativa degli operatori sanitari, nell interesse del miglioramento della salute e delle comunità assistite. Figura 1 Telemedicina La Telemedicina utilizza le tecnologie della telecomunicazione per erogare assistenza sanitaria specialistica, spesso a notevoli distanze, con la possibilità di contenere i costi delle prestazioni. Questo avviene in special modo quando l Assistenza Sanitaria è rivolta ad aree isolate o comunque dove non sia disponibile direttamente la prestazione specialistica del medico. L introduzione della telemedicina permette : diagnosi e cure più rapide; minor numero di spostamenti sia del personale medico che dei pazienti; riduzione dei costi per personale, compreso quello di emergenza; comunicazioni più veloci; 3

Capitolo 1 Struttura del progetto aggiornamento più semplice e rapido delle informazioni riguardanti diagnosi e metodi di cura; miglior sostegno allo staff medico per la formazione sia teorica che pratica. Nell ottica di capillarizzare l offerta sanitaria, può essere importante pensare ad una struttura informatica che renda indipendenti le due fasi tipiche della diagnostica: l esecuzione dell esame la sua refertazione. Mentre è possibile pensare di localizzare alcuni macchinari (di basso costo) anche nei poliambulatorii più piccoli o distanti, può risultare sconveniente portare in questi poliambulatorii personale di alta specializzazione. Il termine Telemedicina si presta a svariate definizioni, non sempre univoche in letteratura, che spesso focalizzano l attenzione solo su alcuni aspetti della materia. Si tratta sostanzialmente della trasmissione in tempo reale di informazioni a carattere scientifico tra medico e cittadino o tra addetti ai lavori, attraverso sistemi di comunicazione di tipo telematico/informatico. La definizione più esaustiva del termine è senz altro quella concordata a livello CEE da una Commissione di esperti, che ha redatto un documento sulle prospettive di sviluppo della telemedicina in Europa (Advanced Informatics in Medicine - AIM 1990) con l obiettivo di migliorare la qualità dei servizi sanitari, facilitare la formazione professionale di medici e infermieri ed ottimizzare il trasferimento qualificato di dati ed esperienze tra i vari Paesi europei. Secondo la Commissione Europea, organizzatrice tra l altro dell EHTO (European Health Telematics Observatory Osservatorio delle applicazioni mediche della telematica), la telemedicina è "l integrazione, monitoraggio e gestione dei pazienti, nonché l educazione dei pazienti e del personale, usando sistemi che consentano un pronto accesso alla consulenza di esperti ed alle informazioni del paziente, indipendentemente da dove il paziente o le informazioni risiedano". 4

Capitolo 1 Struttura del progetto 1.3 Modello organizzativo Figura 2 Organizzativo Modello L applicativo JTELEMED consta di tre entità: RICHIEDENTE REFERTANTE (o EROGANTE) REPOSITORY Il RICHIEDENTE è caratterizzato dall insieme delle strutture che producono i dati digitali di un esame clinico e che si interfacciano nel nostro sistema come dei client di laboratorio: sono quelli che attivano il processo di refertazione e attendono i risultati. Una prerogativa importante di tutto il nostro applicativo è il mantenimento della privacy. Per questo motivo i richiedenti non saranno mai individuati attraverso dati anagrafici personali ma attraverso un identificativo univoco. Il REFERTANTE è, invece, l insieme di coloro che forniscono il servizio di refertazione, una clinica specializzata, un semplice medico o una equipe di medici accreditati. Il cuore del sistema è rappresentato dal REPOSITORY CENTRALE, che altro non è che un server relazionale, cioè un server che gestisce un DataBase. 5

Capitolo 1 Struttura del progetto L effettuazione di un esame presso un laboratorio e la conseguente archiviazione del dato in forma digitale genera ciò che viene chiamato evento. L evento non è il dato clinico vero e proprio ma rappresenta una sorta di meta-dato clinico del dato digitale generato dai laboratori. E composto da una serie di informazioni che riguardano il dato digitale prodotto dall evento come ad esempio: l unità che ha erogato la prestazione, la data e l ora dell esame, la struttura che l ha prodotto, il dottore richiedente ed il codice dell impegnativa, lo stato della fase di refertazione, e, cosa molto importante il link che consente di scaricare il dato. Ogni evento quindi viene immagazzinato all interno di un apposito raccoglitore, definito appunto repository. Qualsiasi esame che può essere memorizzato in forma digitale può essere associato ad un evento. Chiarito il funzionamento dell applicativo, non rimane altro che definire un meccanismo di comunicazione tra il Repository e i suoi utilizzatori. Come già detto in precedenza il repository centrale non è altro che un server relazionale ovvero un server che gestisce un database; in realtà il suo funzionamento è ben più ampio in quanto, oltre ad interfacciarsi con la base di dati, esso fornisce servizi accessibili con un semplicissimo browser sia lato richiedente che lato refertante: esso realizza cioè un architettura web service. Nel prossimo capitolo vedremo nel dettaglio la sua realizzazione. 6

Capitolo 1 Struttura del progetto 1.4 Glossario dei termini Termine Descrizione Sinonimi Collegamenti JTelemed E l applicativo che si vuole realizzare al fine di fornire un servizio di telemedicina a distanza Telemedicina Uso di strumenti telematici per effettuare esami clinici a distanza Esame clinico Indagine specialistica a scopo diagnostico di un organismo vivente o di un organo. Diagnosi Individuazione del quadro morboso di un paziente in base alla valutazione dei sintomi, all anamnesi e alle analisi strumentali e di laboratorio Cura Insieme dei rimedi usati per guarire da una malattia Richiedente Strutture accreditate che producono i dati digitali di un esame clinico e che si interfacciano nel nostro sistema. Refertante Colui che fornisce il servizio di refertazione Refertazione Il risultato fornito dal refertante derivante da una diagnosi Laboratori Locali dotati di apposite apparecchiature per ricerche cliniche Evento Effettuazione di un esame presso un laboratorio e conseguente archiviazione del dato in forma digitale Repository Server relazionale, ovvero un server che gestisce un DataBase. Applicativo Sistema telematico di assistenza medica Esame, Analisi, Ricerca, Indagine Valutazione, Opinione, Accertamento Terapia, Trattamento Utente, Client di laboratorio, Utente richiedente Clinica, Laboratorio, Medico, Utente Erogante, Utente Refertante Diagnosi Clinica Esito, Risultato Server Telemedicina JTelemed Telemedicina Refertante, Refertazione Refertante, Refertazione Esame clinico Laboratorio Diagnosi, Cura Refertante Richiedente, Refertante, Repository Richiedente, Refertante, Evento 7

2. Il Web service 2.1 Introduzione al Web service Il paradigma del Service Oriented Computing è visto come una rivoluzione nella comunità informatica e i Web Service una sua realizzazione. La possibilità di vedere il Web come un grande sistema informativo in cui sono forniti innumerevoli servizi offre agli utenti finali un potentissimo strumento che va al di là del mero scambio di informazioni che al momento rappresenta il Web. I servizi web, meglio noti come web services, sono diventanti uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM, Microsoft e Sun, vengono spesso descritti come una vera e propria rivoluzione nel mondo del web ed in particolare per tutto quanto attiene allo sviluppo di applicazioni distribuite ed all'integrazione di applicazioni. Secondo la definizione data dal World Wide Web Consortium (W3C) un Web Service (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 (descritta in un formato automaticamente elaborabile quale, ad esempio, il Web Services Description Language) utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta" SOAP: tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. Focalizzando l attenzione sul concetto di servizio è ovvio immaginare, anche alla luce di quanto detto finora, come gli attori in causa siano necessariamente il fornitore e il richiedente. Questo tipo di paradigma è il medesimo che si riscontra nella tipica interazione di tipo client-server. Attraverso la SOA (Service Oriented Architecture) questa interazione viene arricchita con un ulteriore attore detto Service Directory o Service Broker che, come mostrato in figura 1, si inserisce all interno della comunicazione tra fornitore e fruitore del servizio. 8

Capitolo 2 Il Web Service Figura 3 Service Oriented Architecture Service Provider Chi realizza e mette a disposizione un servizio. Tramite l operazione di publish il servizio viene pubblicizzato, in quanto le caratteristiche del servizio realizzato vengono memorizzate all interno di un registry accessibile pubblicamente. Il Service Provider rimane, quindi, in attesa che un utente richieda tale servizio. Service Directory o Service Broker Questo componente si occupa della gestione del registry, permettendo, a chi ha necessità, di ricercare un servizio sulla base delle caratteristiche con le quali è stato definito e memorizzato. Naturalmente, il Service Directory può seguire politiche di controllo degli accessi sulle interrogazioni in modo da limitare la visibilità sui servizi inseriti. Nel presente lavoro il registry, viene considerato parzialmente accessibile. Service Requestor Rappresenta un potenziale utente che richiede un servizio. A tale scopo, tramite la primitiva di find l utente interagisce con il Service Directory per ottenere il servizio più adatto ai propri obiettivi. Una volta individuato si collega al Service Provider corrispondente (bind) e inizia a fruire del particolare servizio (use). 9

Capitolo 2 Il Web Service Partendo da questa considerazione si può dire che una architettura per e-service è un istanza di una SOA dove il mezzo di comunicazione è di tipo elettronico, mentre una architettura per Web Service è un istanza di una SOA dove il mezzo di comunicazione considerato è il Web. Figura 4 Pila Protocollare dei Web Service 2.2 Cosa sono i Web services e come funzionano Un Web service è un componente applicativo. Possiamo definirlo come un sistema software in grado di mettersi al servizio di un applicazione comunicando su di una medesima rete tramite il protocollo HTTP. Un Web service consente quindi alle applicazioni che vi si collegano di usufruire delle funzioni che mette a disposizione. Esso comunica tramite protocolli e standard definiti "aperti" e quindi sempre a disposizione degli sviluppatori ed ha una caratteristica molto particolare ed utile al suo scopo: è autocontenuto ed auto-descrittivo, cioè è in grado di farci sapere che funzioni mette a disposizione (senza bisogno di conoscerle a priori) e ci permette inoltre di capire come vanno utilizzate. Il protocollo HTTP si occupa di mettere in comunicazione il servizio web con l'applicazione che intende usufruire delle sue funzioni. Oltre ad HTTP però, i servizi web utilizzano molti altri standard web, tutti basati su XML, tra cui: 10

Capitolo 2 Il Web Service XML Schema UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language) SOAP (Simple Object Access Protocol) È importante sottolineare che XML può essere utilizzato correttamente tra piattaforme differenti (Linux, Windows, Mac) e differenti linguaggi di programmazione. XML è inoltre in grado di esprimere messaggi e funzioni anche molto complesse e garantisce che tutti i dati scambiati possano essere utilizzati ad entrambi i capi della connessione. Si può quindi dire che i Web service sono basati su XML ed HTTP e che possono essere utilizzati su ogni piattaforma e con ogni tipo di software. 2.2.1 XML Schema Abbiamo detto che un Web service è auto-descrittivo. Con XML Schema cominceremo a capire come fa un servizio web a disporre di questa caratteristica. XML Schema serve per definire qual è la costruzione legale di un documento XML, come fanno per esempio i DTD con le pagine web. Vediamo una lista delle principali funzioni di XML Schema: Definire gli elementi (tag) che possono apparire in un documento Definire gli attributi che possono apparire in un elemento Definire quali elementi devono essere inseriri in altri elementi (child) Definire il numero degli elementi child Definire quando un elemento deve essere vuoto o può contenere testo, elementi, oppure entrambi Definire il tipo per ogni elemento e per gli attributi (intero, stringa, ecc, ma anche tipi personalizzati) Definire i valori di default o fissi per elementi ed attributi Ecco un esempio di XML Schema in grado di descriverlo: 11

Capitolo 2 Il Web Service <?xml version="1.0"?> <!-- iniziamo lo schema --> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.xxxx.it/guida_ai_webservice" xmlns="http://www.xxxx.it/guida_ai_webservice" elementformdefault="qualified"> <!-- definiamo l'elemento libro --> <xs:element name="libro"> <xs:complextype> <xs:all> <!-- definiamo i vari elementi child di libro --> <xs:element name="titolo" type="xs:string" /> <xs:element name="autore" type="xs:string" /> <xs:element name="numerodipagine" type="xs:integer" /> </xs:all> </xs:complextype> </xs:element> </xs:schema> Per ora concentriamoci sul primo elemento: schema. Questo è l'elemento che racchiude tutti i tipi di dato che andiamo a descrivere. Il tag <schema> può avere diversi attributi. xmlns:xs="..." stabilisce che gli elementi che iniziano con 'xs' provengono dal namespace http://www.w3.org/2001/xmlschema. targetnamespace="..." definisce a quale namespace appartengono gli elementi definiti con questo schema. xmlns="..." definisce il namespace di default (quello applicato se non ne escplicitiamo uno) elementfromdefault="qualified" indica che ogni elemento usato nel documento XML che utilizzerà questo schema dovrà essere qualificato. Una volta aperto il tag <schema> bisogna inserire al suo interno tutti gli elementi che vogliamo definire per il nostro documento. Esistono sostanzialmente due tipi di elementi: gli elementi semplici non possono contenere altri elementi e avere attributi. Possono contenere solo testo. 12

Capitolo 2 Il Web Service gli elementi complessi possono contenere testo, altri elementi e attributi in qualsiasi combinazione. 2.2.2 UDDI L'UDDI (acronimo di Universal Description Discovery and Integration) è 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 offerti su internet. L UDDI permette quindi la scoperta e l'interrogazione dei servizi offerti sul web, delle aziende che li offrono e della maniera per usufruirne. Una "registrazione" UDDI consiste, infatti, di tre diverse componenti: Pagine bianche (White Pages): indirizzo, contatti (dell'azienda che offre uno o più servizi) e identificativi; Pagine gialle (Yellow Pages): categorizzazione dei servizi basata su tassonomie standardizzate; Pagine verdi (Green Pages): informazioni (tecniche) dei servizi fornite dall'azienda L'UDDI è uno degli standard alla base del funzionamento dei Web Service: è stato progettato per essere interrogato da messaggi in SOAP e per fornire il collegamento ai documenti WSDL che descrivono i vincoli protocollari ed i formati dei messaggi necessari per l'interazione con i Web Service elencati nella propria directory. 2.2.3 WSDL Il WSDL serve a specificare dove si trovano i servizi e le operazioni esposte dal servizio web. Cominciamo subito a vedere come un documento WSDL definisce un Web service. All'interno del documento esistono quattro elementi principali: <types> <message> 13

Capitolo 2 Il Web Service <porttype> <binding> > <definitions> <types> <!-- definizione dei tipi di dato utilizzati... --> </types> <message> <!-- definizione di uno dei messaggi impiegati dal web service per comunicare con l'applicazione client -- </message> <!-- naturalmente può esistere più di un elemento message all'interno del documento --> <porttype> <!-- definisce una "porta" e le operazioni che possono essere eseguite dal web service. Definisce inoltre i messaggi coinvolti nelle operazioni elencate --> </porttype> <binding> <!-- definisce il formato del messaggio ed i dettagli di protocollo per ogni porta --> </binding> </definitions> I types, message e porttype sono elementi del messaggio WSDL all interno di definitions e sono usati per definire le operazioni: <types> è usato per definire i tipi base necessari allo scambio dell informazione. <message> è usato per definire il messaggio spedito e ricevuto ed utilizza i tipi definiti in types. <porttypes> è usato per definire il funzionamento delle porte allocate dal servizio come i messaggi da utilizzare in input e output. Gli elementi binding e service sono usati per definire il protocollo associato all operazione: <binding> è usato per definire il protocollo da utilizzare per comunicare con la porta su cui è allocata l operazione (HTTP, SOAP, ). <service> è usato per definire una porta come URL attraverso la quale si trova il servizio. 14

Capitolo 2 Il Web Service Il WSDL inoltre definisce quattro tipi di operazioni attraverso il tag <operations>: One-way: è una chiamata asincrona al servizio. Request-responce: chiamata sincrona al servizio. Sollicit-responce: invia una risposta dopo un sollecito. Notification: ricevere una notifica. 2.2.4 SOAP E utile sapere che tutte le informazioni che vengono definite da WSDL, è grazie a SOAP (Simple Object Access Protocol) se vengono scambiate tra il Web service è l'applicazione che vi accede. Questo protocollo fornisce una via per comunicare tra applicazioni eseguite su sistemi operativi diversi, con diverse tecnologie e linguaggi di programmazione, tramite HTTP ed XML. Un messaggio SOAP è un documento XML che contiene i seguenti elementi: Envelope, identifica il documento come un messaggio SOAP; Un elemento Header opzionale, contenete informazioni specifiche per l'applicazione, che non sarà approfondito in questa sede ma che permette di definire alcuni messaggi, anche con diversi destinatari nel caso il messaggio dovesse attraversare più punti di arrivo; Body è un elemento indispensabile che contiene le informazioni scambiate dalle richieste/risposte; Fault è un elemento opzionale che fornisce informazioni riguardo ad eventuali errori manifestati durante la lettura del messaggio. Le regole principali per realizzare un messaggio SOAP sono le seguenti: Deve essere ovviamente codificato con XML Deve utilizzare il SOAP Evenelope namespace (http://www.w3.org/2001/12/soapenvelope) Deve utilizzare il SOAP Encoding namespace (http://www.w3.org/2001/12/soapencoding) 15

Capitolo 2 Il Web Service Non deve contenere il collegamento ad un DTD e non deve contenere istruzioni per processare XML Lo "scheletro" di un messaggio SOAP: <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope (http://www.w3.org/2001/12/soap-envelope)" soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> <soap:header>... </soap:header> <soap:body>... <soap:fault>... </soap:fault> </soap:body> </soap:envelope> All'interno dell'elemento Envelope abbiamo definito i namespace soap evelope ed encoding che come abbiamo visto sono richiesti per questo tipo di documento. Se non vengono definiti o si definiscono diversamente le applicazioni coinvolte nella comunicazione potrebbero generare un errore o scartare il messaggio. 16

Capitolo 2 Il Web Service 2.3 Perché creare un Web Service La ragione principale per la creazione e l'utilizzo di Web Service è il "disaccoppiamento" che l'interfaccia standard esposta dal Web Service rende possibile fra il sistema utente ed il Web Service stesso: modifiche ad una o all'altra delle applicazioni possono essere attuate in maniera "trasparente" all'interfaccia tra i due sistemi; tale flessibilità consente la creazione di sistemi software complessi costituiti da componenti svincolati l'uno dall'altro e consente una forte riusabilità di codice ed applicazioni già sviluppate. I Web service hanno inoltre guadagnato consensi visto che, come protocollo di trasporto, possono utilizzare HTTP "over" TCP sulla porta 80; tale porta è, normalmente, una delle poche (se non l'unica) lasciata "aperta" dai sistemi firewall al traffico di entrata ed uscita dall'esterno verso i sistemi aziendali e ciò in quanto su tale porta transita il traffico HTTP dei web browser: ciò consente l'utilizzo dei Web Service senza modifiche sulle configurazioni di sicurezza dell'azienda (un aspetto che se da un lato è positivo solleva preoccupazioni concernenti la sicurezza). Un'ultima ragione che ha favorito l'adozione ed il proliferare dei Web Service è la mancanza, prima dello sviluppo di SOAP, di interfacce realmente funzionali per l'utilizzo di funzionalità distribuite in rete: EDI, RPC, ed altri tipi di API (Application Programming Interface) erano e rimangono meno conosciute e di facile utilizzo che non l'architettura dei Web Service. 17

Capitolo 2 Il Web Service 2.4 Apache Axis Axis è il motore opensource più famoso per la creazione di Web Services in Java. Axis è un progetto dell'apache Software Fondation e deriva da SOAP4J, un progetto regalato dall'ibm ad Apache. Brevemente, si tratta di un API di programmazione e deployment di Web services che permette di lavorare ad un livello di astrazione elevato, evitando così di dover maneggiare direttamente l envelope SOAP. Con Axis è possibile, dunque, implementare Web services e anche sviluppare client di servizi di terzi. Per semplicità, negli esempi che tratteremo viene esposto solo l aspetto di funzionalità RPC e non quello relativo ai vari approcci di messaging supportati da Axis. Ciò è comunque in linea con la maggior parte della casistica Web services che si basa su meccanismi request/response a dispetto del modello asincrono. Axis 1.4 disponibile all URL http://ws.apache.org/axis/ è composto da: una web application che si occupa di gestire l'ambiente di esecuzione dei servizi (routing, istance pooling, serializzazione e deserializzazione dei messaggi SOAP, ecc...); una API composta da classi di utilità per la scrittura di servizi web e da classi necessarie al funzionamento della web application e dei tool; una serie di tool, tra cui WSDL2Java per generare scheletri lato server e stub lato client dei servizi web a partire dalla descrizione WSDL; Java2WSDL per generare la descrizione come servizio web di una classe Java; diversi tool per l'amministrazione e la gestione dei servizi installati; un TCP monitor stand-alone ed un SOAP monitor integrato nella web application per controllare la forma dei messaggi scambiati tra i servizi nelle fasi di debug e test. 18

Capitolo 2 Il Web Service Tra le caratteristiche più interessanti di Axis c'è la possibilità di creare web service in maniera immediata a partire da classi Java molto semplici con estensione.jws (Java Web Service). Axis può essere quindi utilizzato in una serie di scenari anche molto diversi tra loro, ad esempio può servire per: la creazione di applicazioni client di servizi web già esistenti per i quali è disponibile il WSDL: utilizzando WSDL2Java si possono creare in maniera automatica gli stub per l'accesso a servizi esistenti implementati con qualsiasi piattaforma. Le applicazioni client che utilizzano gli stub non necessitano di ambienti di esecuzione particolari ma soltanto della presenza della libreria axis.jar nel proprio classpath; la comunicazione via JAX-RPC tra processi Java: le API di Axis implementano una versione di JAX-RPC, rendendo possibile lo sviluppo di applicazioni distribuite Java con protocollo di trasporto SOAP; la creazione di servizi web a partire da classi Java: Axis offre diversi meccanismi per l'implementazione dei servizi. Quello più semplice e completamente trasparente per il programmatore è JWS, ma sono disponibili anche modelli di servizi più complicati dove è possibile personalizzare, ad esempio, le modalità di serializzazione dei messaggi, la struttura dei package ed il formato dei parametri, senza mai occuparsi della descrizione WSDL o del formato SOAP dei messaggi, grazie all'integrazione tra l'ambiente di esecuzione e Java2WSDL; l'implementazione di servizi web a partire da descrizioni WSDL: il tool WSDL2Java è particolarmente utile quando, come nel caso di Zlatan, si parte dalla descrizione dei servizi per la realizzazione di un sistema piuttosto che dalla loro implementazione. I problemi principali di Axis riguardano lo stretto legame con il web application container Tomcat (anche se è possibile con qualche sforzo installare l'ambiente in altri server, come fatto con SJSAS8 in Zlatan) e la conformità soltanto parziale alle specifiche del WS-I. Riassumendo possiamo dire che Axis non è che un SOAP engine: questo significa che è un framework che si concentra unicamente sulle problematiche della creazione di client e server e per la gestione di messaggi SOAP; in pratica consiste in un insieme di tool per la 19

Capitolo 2 Il Web Service generazione automatica di classi e in una libreria che incapsula in classi Java l accesso alle tecnologie connesse ai Web Services. L architettura generale di Axis appare nella seguente figura nei suoi componenti principali: Fig. 5 - Architettura generale di Axis. Il requestor è un client che effettua una richiesta su alcuni dei protocolli supportati da Axis. Generalmente è usato HTTP. Il requestor può essere una desktop application, una web application, o un altro web service. Il motore Axis agisce agevolando la comunicazione tra client e web service maneggiando la traduzione ad e da web service standard. Axis permette allo sviluppatore di definire una serie di handlers, allacciati alla richiesta o alla risposta. Questi handlers sono simili a filtri servlet; ogni handler svolge uno specifico compito adando avanti fino al prossimo handler in linea. 20

3. Preparazione dell ambiente di sviluppo 3.1 Lato Server Innanzitutto occorre istallare la JDK, la JRE e l Application Server JAKARTA TOMCAT con la stessa procedura vista a livello client. Come IDE di sviluppo è stato scelto Eclipse: la versione a cui faremo riferimento è la WTP 1.5 AllInOne. Tale sigla sta per Web Tools Project, e contiene, fra l'altro, Eclipse 3.2. In questa versione ci sono già molte funzionalità rivolte al web, come suggerisce il nome. L'installazione è semplicissima, anzi, non necessita neanche di una installazione. Una volta scaricato il file compresso è sufficiente scompattarlo ed Eclipse è già pronto. Al termine dell'estrazione, nella directory "eclipse" (sotto la cartella di destinazione da noi scelta) troviamo tutti i file e le directory coinvolte. È interessante notare come il processo di installazione sia totalmente non invasivo a livello di sistema: in Windows, ad esempio, non vengono inserite chiavi nel registry, non vengono installate dll o file di sistema all'interno delle cartelle /Windows/System32. L'unica accortezza che bisogna avere, prima di utilizzare Eclipse, è quella di avere installato una java virtual machine (ad esempio scaricando il Java SE Development Kit sul sito Sun) che Eclipse stesso possa utilizzare per compilare ed eseguire le applicazioni. L'unica accortezza che bisogna avere, prima di utilizzare Eclipse, è quella di avere installato una java virtual machine (ad esempio scaricando il Java SE Development Kit sul sito Sun) che Eclipse stesso possa utilizzare per compilare ed eseguire le applicazioni. La prima volta che avviamo Eclipse viene chiesta la directory dove salvare i nostri progetti. Fig. 6 - Selezionare un workspace 21

Capitolo 3 Preparazione dell ambiente di sviluppo Attraverso la check box in basso alla finestra di dialogo sarà, quindi, possibile scegliere se utilizzare la medesima directory per tutti i progetti evitando di sceglierla di volta in volta. Una volta ultimata la selezione del workspace, verrà visualizzata una schermata di benvenuto. Fig. 7 Schermata di benvenuto di Eclipse Il passo successivo prevede l istallazione di APACHE AXIS che consiste nei due seguenti passi: Fig. 8 - Cartella scompattata di Axis. 22

Capitolo 3 Preparazione dell ambiente di sviluppo 1) Scompattare Axis, prendere la cartella lib e copiarla all'interno della installazione di Eclipse. 2) Prendere la cartella axis dentro webapps e incollarla sull'omonima cartella di Tomcat. A questo punto abbiamo tutti gli strumenti necessari per creare il nostro Web Service, ma prima di iniziare vediamo la disposizione delle varie librerie: per un corretto funzionamento dell applicativo lato server sono necessarie le seguenti librerie nella directory della JDK (nel nostro caso versione 1.5) C:\Programmi\Java\jdk1.5.0\jre\lib\ext.: dnsns.jar localedata.jar sunjce_provider.jar sunpkcs11.ja le librerie necessarie sotto C:\TOMCAT554\common\lib sono: activation.jar commons-el.jar jasper-compiler jdt.jar jasper-compiler.jar jasper-runtime.jar jsp-api.jar mail.jar naming-factory-dbcp.jar naming-factory.jar naming-resources.jar ojdbc14.jar servlet-api.jar 23

Capitolo 3 Preparazione dell ambiente di sviluppo le librerie necessarie sotto C:\TOMCAT554\ webapps\axis\web-inf\lib sono: activation.jar jaxrpc.jar axis-ant.jar log4j-1.2.8.jar axis.jar mail.jar commons-discovery- saaj.jar 0.2.jar wsdl4j-1.5.1.jar commons-logging- 1.0.4.jar Chiarite le posizioni delle varie librerie cominciamo a costruire il nostro web service a partire dalla IDE di sviluppo Eclipse: Innanzitutto selezionare dalla toolbar la voce File->New->Project (figura 1). Nella successiva finestra indicare il tipo di progetto che si vuole realizzare,nel nostro caso un Dinamic Web Project (figura 2). 24

Capitolo 3 Preparazione dell ambiente di sviluppo Figura 9 Creazione del Web Service Il primo step per la costruzione di un web service è rappresentato dalla scelta del tipo di progetto tra quelli che eclipse mette a disposizione. 25

Capitolo 3 Preparazione dell ambiente di sviluppo Figura 10 Creazione di un Web service Non è difficile riconoscere quale sia effettivamente il tipo di progetto da selezionare per la creazione di un web service: aprire la directory Web e selezionare la voce Dynamic Web Project 26

Capitolo 3 Preparazione dell ambiente di sviluppo Successivamente verrà chiesto di dare un nome al nuovo progetto e di lavorare con delle impostazioni. Per il nostro scopo è possibile utilizzare le impostazioni di default e una volta completata la procedura l interfaccia di eclipse appare nel seguente modo: Figura 11 - L interfaccia di Eclipse Come ultimo passo non rimane altro che testare il prototipo di applicazione costruito; per fare ciò basta lanciare l applicazione stessa all interno di Eclipse attraverso il comando Run. Poiché abbiamo però costruito una web application, occorre definire il server su cui far girare il progetto: Eclipse a questo scopo ci permette di impostare una sorta di server interno che si appoggia all Application Server istallato sulla macchina di sviluppo, nel nostro caso JAKARTA TOMCAT. Vediamo brevemente come funziona il tutto. Con il tasto destro del mouse ciccare sull icona del progetto che appare nella Resource Navigator view e scegliere Run As -> Run On Server (figura 12). 27

Capitolo 3 Figura 12 Impostare il server di Eclipse (1) Preparazione dell ambiente di sviluppo Successivamente selezionare dall elenco messo a disposizione il server desiderato, nel nostro caso Apache Tomcat v.5.5 (figura 5). Anche in questo caso è possibile modificare delle impostazioni, ma non è controindicativo utilizzare quelle di default. Concludendo tale procedimento guidato l istallazione del nostro server interno è completata e l applicazione è pronta per essere utilizzata (figura 13). Figura 13 - Impostare il server di Eclipse (2). E necessario selezionare dall elenco di figura lo stesso Application Server che si è istallato sulla macchina di lavoro. Come sempre facciamo riferimento al nostro caso che utilizza un Tomcat versione 5.5 28

Capitolo 3 Preparazione dell ambiente di sviluppo Figura 14 Impostare il server di Eclipse (3) Come ulteriore verifica della funzionalità del server possiamo utilizzare la Console: Figura 15 La Console di Eclipse Come vedremo più avanti Eclipse ci mette inoltre a disposizione un ulteriore strumento di controllo in fase di utilizzo dei servizi, il TCP/IP Monitor. 29

Capitolo 3 Preparazione dell ambiente di sviluppo Ora tutto il nostro sistema è funzionante, ma prima di ultimare il lavoro occorre fare un piccolo passo indietro. Conclusa la fase di editing con la creazione delle classi che implementano i servizi occorre costruire il descrittore dei servizi, il WSDL. Ricordiamo che il WSDL serve a specificare dove si trovano i servizi e le operazioni esposte dal servizio web. L Eclipse mette a disposizione un meccanismo rapido ed efficiente per la creazione automatica di tale descrittore che fisicamente non è altro che un file xml. Cliccare con il tasto destro del mouse sulla classe nella quale sono definiti i servizi che il nostro progetto vuole realizzare. Selezionando la voce Web Service -> Create Web Service (figura 16) si apre una finestra di impostazioni (figura 17): spuntare le due voci Publish the Web service e Monitor the Web service; inoltre se è necessario il TCP/IP Monitor spostare la barra (1) completamente in alto. Successivamente apparirà un ulteriore finestra nella quale è possibile selezionare Figura 16 Creazione del Web service (1) tutti i servizi da inserire nel wsdl e scegliere il cosiddetto Style and use impostandolo a RPC/Encoded. 30

Capitolo 3 Preparazione dell ambiente di sviluppo Questa caratteristica rappresenta la scelta del formato di un messaggio SOAP. Le possibili scelte di SOAP: Body di un messaggio SOAP sono: - document: il SOAP Body del documento contiene una o più "parts" che dal punto di vista di XML sono childnodes di SOAP:Body. Non ci sono particolari regole sulla struttura di questi nodi figli. - RPC: il SOAP:Body contiene un elemento il cui nome corrisponde al nome della procedura remota da invocare e un elemento per ogni parametro da fornire alla procedura. La serializzazione del SOAP: Body prevede: - encoded: le regole di serializzazione sono dettate dalla sezione 5 della specifica SOAP 1.1. - literal: i dati sono serializzati nel rispetto di una specifica XML che ad oggi è XML Schema Definition 1.0, domani potrebbe essere altro. In.NET tutto questo si trasforma nell'utilizzare, come decorazione dei nostri WebMethod, uno dei due seguenti attributi: - SoapRpcMethod: il SOAP:Body sarà RPC/encoded. - SoapDocumentMethod: SOAP:Body in formato document. Se la proprietà Use vale SoapBindingUse.Literal il body sarà document/literal, se invece Use vale SoapBindingUse.Encoded avremo un body document/encoded. Se la proprietà ParameterStyle vale SoapParameterStyle.Bare avremo i parametri inviati tra i SOAP Node posizionati direttamente all'interno del SOAP:Body. Se invece la proprietà ParameterStyle vale SoapParameterStyle.Wrapped i parametri saranno inviati tra i due SOAP node, racchiusi all'interno di un solo elemento, figlio di SOAP:Body. Il default di ASP.NET è Literal, Wrapped. 31

Capitolo 3 Preparazione dell ambiente di sviluppo Barra (1). Spostare la barra completamente in alto per avere il TCP/IP Monitor Opzioni da selezionare Figura 17 Impostare il server di Eclipse (2) Risultato di tutta questa procedura è un file.wsdl di cui riportiamo un piccolo frammento: INTESTAZIONE <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace="http://services.jtelemed.it" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://services.jtelemed.it" xmlns:intf="http://services.jtelemed.it" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <!--WSDL created by Apache Axis version: 1.3 Built on Oct 05, 2005 (05:23:37 EDT)--> 32

Capitolo 3 Preparazione dell ambiente di sviluppo DEFINIZIONE DEI METODI <wsdl:message name="openeventresponse"> <wsdl:part name="openeventreturn" type="xsd:int"/> </wsdl:message> <wsdl:message name="userinforesponse"> <wsdl:part name="userinforeturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="listeventsresponse"> <wsdl:part name="listeventsreturn" type="xsd:string"/> </wsdl:message> PORT TYPE <wsdl:porttype name="wsrepository"> <wsdl:operation name="echo" parameterorder="value"> <wsdl:input message="impl:echorequest" name="echorequest"/> <wsdl:output message="impl:echoresponse" name="echoresponse"/> </wsdl:operation> <wsdl:operation name="userinfo" parameterorder="utn_cn username password"> <wsdl:input message="impl:userinforequest" name="userinforequest"/> <wsdl:output message="impl:userinforesponse" name="userinforesponse"/> </wsdl:operation> 33

Capitolo 3 Preparazione dell ambiente di sviluppo BINDING wsdl:binding name="wsrepositorysoapbinding" type="impl:wsrepository"> wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> wsdl:operation name="echo"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="echorequest"> <wsdlsoap:body encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.jtelemed.it" use="encoded"/> </wsdl:input> <wsdl:output name="echoresponse"> <wsdlsoap:body encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.jtelemed.it" use="encoded"/> </wsdl:output> wsdl:operation> <wsdl:service name="wsrepositoryservice"> SERVIZI <wsdl:port binding="impl:wsrepositorysoapbinding" name="wsrepository"> <wsdlsoap:address location="http://localhost:8080/jtelemed/services/wsrepository"/> </wsdl:port> </wsdl:service> Infine per testare l effettivo funzionamento del nostro web service occorre creare un client che si interfacci con i servizi messi a disposizione. Anche in questo caso l Eclipse ha una via veloce ed efficiente: riprendendo lo schema di figura 5, basta selezionare Generate Sample JSPs. 34

Capitolo 3 Preparazione dell ambiente di sviluppo Nel Resource Navigator view di Eclipse apparirà una nuova directory: Lanciando l applicazione sul server appare una Directory Listing For samplewsrepository dove WSRepository, per noi, è la classe con la quale abbiamo costruito il Web service. La lista è composta da quatto link ai file.jsp evidenziati in figura. Selezionando TestClient.jsp si accede alla fase di testing dei servizi. Figura 18 Creazione del client di test 35

Capitolo 3 Preparazione dell ambiente di sviluppo 3.2 Fase di deploy Lo schema proposto dalla Sun Microsystem in quanto a Web Applications propone un modello descrittivo dell'alberatura del progetto in modo da separare e descrivere meglio tutta l'applicazione. Questo approccio ha, come sappiamo, gli indubbi vantaggi della standardizzazione. Da una parte consente a chi produce i tool di sviluppo e gli application server di rendersi compatibili (e magari certificati da Sun) con le nuove specifiche, dall'altra permette a chi sviluppa applicazioni Web di sapere che la struttura dell'applicazione deve essere fatta in un certo modo e che un qualunque application server, se certificato, tratterà l'applicazione allo stesso modo, garantendo quindi la portabilità assoluta. Il nodo centrale della standardizzazione, come sappiamo, è dato da una definizione precisa dell'alberatura dell'applicazione. Come sappiamo la root della Web Application dovrà contenere le pagine HTML o JSP. In alcuni casi le pagine JSP possono essere anche nella cartella JSP, in "css" ci sono i fogli di stile, in "js" i file contenenti codice Javascript e dentro "WEB-INF" c'è una determinata alberatura. In particolare a partire dalla cartella "classes" vengono espansi i package Java dell'applicazione, in "conf" ci sono i file deputati alla configurazione applicativa, in "lib" tutte le librerie esterne sotto forma di JAR o ZIP, in "tld" eventuali tag libraries, in "log" i log dell'applicazione. Supponiamo di aver creato la nostra applicazione utilizzando questo schema, ad un certo punto sarà necessario effettuare il deploy su una macchina differente da quella di sviluppo. La macchine di sviluppo, soprattutto se si utilizzano ambienti di sviluppo molto sofisticati, sono configurate diversamente da quelle di test, pertanto il passaggio da un ambiente all'altro potrebbe non essere indolore. Deploy - modo tradizionale Per eseguire il deploy di questa Web Application in modo tradizionale, se si utilizza Tomcat come application server, è necessario copiare l'alberatura così com'è sul file system della macchina server ed editare il file 36

Capitolo 3 Preparazione dell ambiente di sviluppo TOMCAT_HOME\conf\server.xml aggiungendovi la sezione relativa al nuovo context da creare per poter utilizzare la nuova Web Application attraverso HTTP. La sezione che ci serve è di questo genere: <ContextManager> <Context path="/nomeapplicazione" docbase="c:\nomeapplicazione" crosscontext="true" debug="0" reloadable="true" trusted="false" > </Context> </ContextManager> Sarà nostra cura inoltre modificare il CLASSPATH di sistema in modo da includere tutte le librerie esterne che debbano essere utilizzate dalle componenti della nostra applicazione. Questo metodo funziona indipendentemente da come sia organizzata la Web Applicaton. Al termine potremo raggiungere la nostra applicazione attraverso l'url: http://localhost:8080/nomeapplicazione/ Cosa accade però in fase di manutenzione? In altre parole, cosa succede quando dobbiamo riportare in ambiente di test delle modifiche che coinvolgono alcune parti della Web Application? Ci sono solitamente due alternative: si sovrascrive l'intera alberatura con la versione aggiornata si sovrascrivono selettivamente soltanto i file modificati In ogni caso gli interventi da effettuare manualmente sono molti e la procedura non troppo semplice, soprattutto se siamo di fronte ad applicazioni con un certo grado di complessità. 37

Capitolo 3 Preparazione dell ambiente di sviluppo Deploy - il file WAR La specifica proposta da Sun non si limita a descrivere l'alberatura per la costruzione dell'applicazione, ma ci consente anche di avere un buon sistema per effettuare il deploy dell'applicazione utilizzando un singolo file, il file WAR. Un file WAR, come sappiamo, viene generato attraverso il tool jar.exe contenuto nel JDK ed è pertanto un semplice file JAR rinominato. Il fatto che sia un WAR e non un JAR, indipendentemente dal contenuto, gli permette di essere automaticamente riconosciuto come una vera e propria Web Application completa e dotata di vita propria, in questo modo l'application server sarà in grado di autoconfigurarsi sapendo che il WAR contiene esattamente quel tipo di struttura. Per effettuare il deploy su Tomcat di un file WAR è sufficiente crearlo, dopo essersi posizionati all'interno della cartella contenente l applicazione, attraverso il comando: jar cvf nomeapplicazione.war. Dopo aver ottenuto il file nomeapplicazione.war l'operazione di deploy si limita allo spostamento del file WAR all'interno della cartella webapps di Tomcat. Subito dopo il restart dell'application Server potremo vedere la nostra applicazione utilizzando il solito url: http://localhost:8080/nomeapplicazione/ Quando l'application Server parte, si scompatta automaticamente il file WAR e si crea il context per poter raggiungere l'applicazione via http. Utilizzando questo metodo di deploy la manutenzione si riduce ai tre passi seguenti: creazione del nuovo file WAR copia del nuovo WAR sulla macchina di test eliminazione della vecchia alberatura estratta dal WAR precedente Eclipse mette a disposizione un comando per la crazione del file WAR senza dover andare a ricorrere al prompt dei comandi: 38

Capitolo 3 Preparazione dell ambiente di sviluppo Figura 19 - Creazione del WAR file. Cliccare con il tasto destro del mouse sull icona del progetto e selezionare la voce Export->WAR file. Successivamente verrà richiesta la path di destinazione del file e il nostro WAR è pronto per il deploy. Ora occorre spostare il file WAR appena creato all'interno della cartella webapps di Tomcat. A tal proposito possiamo utilizzare due alternative: Spostare fisicamente il file nella macchina di sviluppo Utilizzare il manager del tomcat Indirizzo del server Path del WAR file Fig. 20 - Tomcat Application Manager 39