Relazione sulla tecnologia. Giacomo Sacchetti Imad Zaza

Transcript

1 Relazione sulla tecnologia Giacomo Sacchetti Imad Zaza 22 ottobre 2006

2 2

3 Indice 1 Gli Web Services Introduzione World Wide Web Service Oriented Architecture XML Web Services Transport XML Base technology Messaging Description Composizione Ciclo di vita Pubblicazione di un servizio Scoperta di un servizio UDDI AXIS Introduzione Installazione di Axis Architettura di Axis Struttura principale Handler e Chain Percorso del messaggio lato server Percorso del messaggio lato client Primi passi con Axis Web Service Deployment Descriptor Applicazioni di esempio Codifica dei dati Gestione delle eccezioni Il tool WSDL2Java Generazione di un servizio web Creazione dell interfaccia

4 4 INDICE Creazione del WSDL Creazione dei bindings con WDSL2Java Il servizio PasswordCollector A Web Semantico 53 A.1 Il Web attuale A.2 Il progetto Semantic Web

5 Introduzione Lo scopo di questa relazione è mostrare un esempio di utilizzo della tecnologia Apache Axis. Per descrivere le funzionalità offerte da questa tecnologia, sarà prima mostrata una breve panoramica sull architettura dei Web Services, considerandola come una fase intermedia per il passaggio da Web tradizionale a Semantic Web, per poi concentrarci sulla descrizione di questa particolare soluzione, mostrando anche dei semplici esempi applicativi. La trattazione ed i relativi esempi sono stati sviluppati e testati sul sistema operativo Mac OS X 10.4 (Tiger), con server web Apache 2.2 e Tomcat come application server. La versione della servlet Axis è la 1.4 (tralasciamo la definizione delle librerie collegate, i cui dettagli sono specificati nel capitolo 2). 5

6 6 INDICE

7 1 Gli Web Services 1.1 Introduzione Il concetto di integrazione è diventato negli ultimi anni un concetto fondamentale per il software. La nascita e l enorme successo che ha riscontrato il World Wide Web, ha causato una crescita esponenziale delle esigenze di integrazione (anche in contesti diversi), per la natura dello Web stesso, cioè un sistema per lo scambio di informazioni tra agenti per mezzo di una rete. L integrazione di software diversi ha determinato, nell ultimo decennio, dei compromessi tra flessibilità di utilizzo e scalabilità: le soluzioni create hanno portato da un lato alla creazione di linguaggi di programmazione flessibili ma utilizzabili solo in sistemi fortemente accoppiati (ad esempio DCOM di Microsoft), dall altro lato a sistemi debolmente accoppiati ma ad una difficile integrazione tra software, in termini di facilità di utilizzo, costi, manutenibilità (ad esempio lo standard CORBA). Gli Web Services rappresentano una soluzione importante, che trae vantaggio dallo strumento di comunicazione (finora utilizzato principalmente da utenti umani) per eccellenza: il web. Gli Web Services costituiscono inoltre una parte importante del percorso di evoluzione da Web tradizionale a Web Semantico 1. I services rappresentano una qualsiasi funzione che ha una certa utilità e possono considerarsi come componenti software riutilizzabili: possiamo combinare tali services per creare una funzione più complessa. Inoltre questi services operano in un sistema molto aperto, cioè un sistema dove l utilizzatore di un servizio 1 Una breve descrizione del Web Semantico è riportata nell appendice A 7

8 8 CAPITOLO 1. GLI WEB SERVICES ed il fornitore del servizio possono operare su piattaforme diverse (sia software che hardware), ma sono in grado di fornire un soddisfacente livello di interoperabilità. Inoltre questo meccanismo di comunicazione è molto flessibile, in quanto il cambiamento nodo non compromette la possibilità di conoscere il suo contenuto informativo. Per questo lo sviluppo di un software Web Services non segue le metodologie di sviluppo tradizionali: la progettazione e realizzazione si basano principalmente sull aggregazione di componenti già sviluppati da terzi. 1.2 World Wide Web Per comprendere gli argomenti che tratteremo in seguito è opportuno precisare un insieme di concetti che stanno alla base dell architettura del World Wide Web, che indicheremo d ora in avanti con la sigla WWW. Seguendo quanto descritto in [Web Arch], abbiamo: Agenti Persone o software che operano sul WWW (server, spider, browser,...). Identificatori Un URI (Uniform Resource Identifier) è un etichetta associabile a qualunque risorsa disponibile nel sistema Risorse Sono tutto ciò che è identificato da un URI Rappresentazioni Sono un insieme di formati di dato che definiscono le informazioni che descrivono lo stato di una risorsa Protocolli Sono regole che definiscono le modalità di comunicazione tra agenti Il processo di comunicazione avviene in questo modo: per conoscere lo stato di una risorsa è necessario conoscerne la locazione (l URI), sottoponendo questa ad una particolare operazione è possibile così ottenere una rappresentazione dello stato di una risorsa. I dati ottenuti saranno presentati all utente finale, in funzione dei metadati associati, per mezzo di un agente. La semantica dell informazione è attribuita dall utente umano, gli agenti hanno solo il compito di trasferire i dati da interpretare (accade così per il Web tradizionale e per i Web Services, per il Web Semantico ogni agenti disporrà di informazioni semantiche e regole di inferenza che gli consentiranno di capire i dati che stà trasferendo). 1.3 Service Oriented Architecture La Service Oriented Architecture (SOA) è l evoluzione del modello classico di distributed computing: è un modello dove ogni nodo (della rete) è un entità

9 1.3. SERVICE ORIENTED ARCHITECTURE 9 capace di fornire servizi ad altri nodi, attraverso la pubblicazione di un interfaccia, che gli utilizzatori possono trovare e dalla quale possono ricavare le informazioni per usufruire del servizio. Questa interfaccia consente di mostrare un insieme di funzioni utili, fornendo il nome delle operazioni, il formato dei parametri di ingresso e uscita, i protocolli per invocare tali funzioni. Esistono, in questa architettura, tre tipi di nodi: Service Provider (SP) è il fornitore del servizio, che si occupa di sviluppare funzioni ed offrirle attraverso un interfaccia omogenea Service Broker (SB) è un archivio in cui vengono collezionate le descrizioni sui servizi forniti da un certo SP Service Requestor (SR) è l entità che richiede l utilizzo delle funzioni di un SP Tali tipi di nodi non sono esclusivi, cioè un nodo può ricoprire più ruoli contemporaneamente. Generalmente un SP segnala ad un SB, attraverso un operazione di publish, che è disponibile un servizio. Il SB rende disponibile questa informazione ai SR, che lo interrogano tramite una operazione di find. Un SR che ottiene la descrizione dell interfaccia di un SP può utilizzare le funzioni tramite un operazione di bind. Uno schema di questo modello è rappresentato nella figura 1.1. Lo scopo fondamentale della SOA è la realizzazione dell accoppiamento debole Service Provider Publish Bind Service Broker Find Service Requestor Figura 1.1: Modello SOA (loose coupling). Come è suggerito in [Hao He], esistono due principali problemi nella realizzazione di un applicazione che si prefigge il riuso di componenti:

10 10 CAPITOLO 1. GLI WEB SERVICES le dipendenze reali e le dipendenze artificiali. Ad esempio, chi viaggia spesso oltreoceano e vuol usare il proprio notebook, ha la dipendenza reale della corrente elettrica ed la dipendenza artificiale dell adattatore di corrente. Lo scopo della SOA non è eliminare completamente le dipendenze artificiali, ma ridurle al minimo, ottenendo così l accoppiamento debole e lasciando inalterate le dipendenze reali. Volendo fare un esempio dell architettura SOA nella vita reale, possiamo pensare ad un lettore CD, che fornisce il servizio di riproduzione dei CDROM; questo lettore CD è dotato di un interfaccia dotata di alcune funzionalità: play, stop, pause,... e questa stessa interfaccia è presente anche in altri lettori CD, in modo che sia possibile cambiare il lettore (o anche il supporto) ed ottenere lo stesso servizio. Per raggiungere lo scopo di loose coupling sono introdotti due vincoli sull architettura: Generalità delle interfacce le interfacce sono semplici, contengono informazioni strutturare sulle operazioni offerte, senza dettagli semantici Messaggi descritti non prescrittivi I messaggi sono vincolati nella struttura da uno schema estendibile che è contenuto nell interfaccia, non indicano il comportamento del sistema. 1.4 XML Web Services La scelta del Web come infrastruttura per la realizzazione degli Web Services non è solamente giustificata dalla sua semplicità e diffusione: l introduzione di un nuovo paradigma può incontrare larghi consensi solamente se la sua introduzione è rapida ed ha costi sostenuti. In realtà il termine Web è abusato perchè il vero cardine dei Web Services è il sistema di indirizzamento globale fornito dagli URI. Riferendoci a [WSA], che è il documento di base dei WS, abbiamo che: poichè ad ogni servizio è associato un URI, in base alle considerazione precedenti, questo è una risorsa del Web la descrizione è scritta il XML, un linguaggio universalmente noto, humanreadable e soprattutto indipendente dal livello di presentazione i messaggi per interagire con il servizio, i cui dettagli sono contenuti nella descrizione, sono documenti XML trasportati per mezzo di protocolli Internet (HTTP, FTP, SMTP,...) Proprio per lo stretto legame con il linguaggio XML, parleremo in seguito di XML Web Service. Per quanto riguarda le caratteristiche del servizio, quelle di

11 1.4. XML WEB SERVICES 11 base per realizzare un WS queste sono, come descritto in precedenza, lo scambio di messaggi, la descrizione del servizio, la pubblicazione e scoperta della descrizione di un servizio. Tuttavia, al fine di agevolare la comunicazione in particolari contesti, tali caratteristiche sono solitamente estese ed, in particolare, possono essere presenti le seguenti: Gestione delle transazioni Una transazione è composta da una serie di messaggi e, nel caso in cui uno di questi non superi qualche vincolo, è da considerarsi nulla tutta la sequenza e conseguentemente la transazione è fallita Rielable messaging Un messaggio deve essere ricevuto una sola volta dal destinatario. Nel caso in cui il messaggio vada perduto, deve esistere un meccanismo per richiedere automaticamente al mittente il re-invio, senza coinvolgere l applicazione Autenticazione dei messaggi Deve essere possibile stabilire in modo certo il mittente del messaggio Confidenzialità ed integrità dei messaggi Se è necessario i messaggi devono essere cifrati, in modo che siano disponibili solo per il legittimo destinatario. Caching È preferibile poter conservare una copia dei messaggi in modo da migliorare le performance Correlazione Un messaggio deve poter essere collegabile con altri relativi allo stesso flusso informativo. Message routing Un messaggio può seguire percorsi diversi in base allo stato della rete Gestione delle sessioni Un messaggio deve essere considerato valido in un determinato lasso di tempo Gli XML Web Services costituiscono una particolare istanza della SOA: le interfacce ed i servizi sono espressi tramite un opportuno linguaggio XML che soddisfa la genericità e l estendibilità. Allo stesso modo i messaggi sono espressi tramite un opportuno XML, in modo da soddisfare il vincolo description not prescription. La struttura degli XML Web Services può essere schematizzata come mostrato in figura 1.2. In riferimento a questo schema, ogni protocollo o linguaggio è da considerarsi aperto, nel senso che a parte i primi due livelli (transport e XML Base) gli altri sono standard de facto, adottati in seguito alle proposte fatte dai maggiori produttori di software. Analizziamo adesso le proposte fatte per ciascun livello.

12 Management Security 12 CAPITOLO 1. GLI WEB SERVICES Aggregation { Description Messaging SOAP XML Base Technology Transport (HTTP, FTP,...) { Figura 1.2: XML Web Services Transport In questo layer sono considerati gli aspetti propri della trasmissione dei messaggi, tramite l uso di alcuni protocolli. Non esiste alcuna limitazione per i protocolli di rete utilizzati, è sufficiente che il flusso di esecuzione continui a seguire il modello publish - find - bind. Quello che si vuol adottare è l indipendenza dal canale di comunicazione, per cui protocolli come SSL o JMS non sono indicati: si preferisce agire direttamente sul linguaggio XML. Lo standard de facto è HTTP XML Base technology Con questo termine si vuol indicare che XML ha un ruolo essenziale per ogni livello sovrastante, quindi ogni informazione o proprietà da esprimere và codificata in XML. Viene pertanto sfruttata la funzionalità di marshalling dell XML: le informazioni strutturate sono convertite in un testo in formato Unicode, in modo da poter scambiare informazioni tra sistemi eterogenei indipendentemente della codifica utilizzata; una volta ricevuto il dato, ogni nodo compie un operazione di unmarshall, riportando i dati alla propria codifica. L elaborazione dell XML non è vincolata a particolari schemi, cioè ogni sistema può decidere autonomamente come trattare i dati XML.

13 1.4. XML WEB SERVICES Messaging Come già accennato in precedenza, la comunicazione dei Web Services si basa fondamentalmente sullo scambio di messaggi, utilizzando la codifica XML. Nonostante qualsiasi testo in XML possa essere considerato un messaggio, è opportuno dare una struttura ai messaggi, in modo che l interazione tra servizi ed utilizzatori sia possibile senza dover progettare ogni volta i messaggi. Lo standard di fatto in questo livello è dunque SOAP (Simple Object Access Protocol). SOAP Il Simple Object Access Protocol è lo strumento largamente più utilizzato per rappresentare messaggi XML. Esistono varie versioni di questo protocollo, che hanno notevoli differenze l una dall altra, ma nella presente trattazione ci riferiremo all ultima versione (la 1.2). Possiamo pensare al meccanismo SOAP come ad una busta (envelope), composta da un intestazione opzionale ed un contenitore in cui inserire dati e metadati da comunicare, ed il tutto codificato in XML. Ogni busta è atomica, cioè contiene al proprio interno tutto quello di cui necessita per interpretare i dati trasportati. Una comunicazione tra nodi SOAP è SOAP Envelope SOAP Header SOAP Body Figura 1.3: Struttura messaggio SOAP costituita dalla trasmissione di una busta da un nodo mittente ad un nodo destinatario, detto anche ultimate receiver, per distinguerlo dagli intermediari SOAP, che sono i nodi in grado di processare parti del messaggio alla scopo di fornire funzionalità aggiuntive. In particolare un intermediario riceve un messaggio SOAP e lo inoltra, eventualmente riscrivendo alcune parti dell header, ma non

14 14 CAPITOLO 1. GLI WEB SERVICES modificando il body. Il ruolo e le funzionalità degli intermediari non sono definite nel protocollo SOAP, viene cosà lasciato spazio libero ad estensioni. Una caratteristica che è importante sottolineare per SOAP è il binding framework, che stabilisce una serie di vincoli che il protocollo di trasporto deve rispettare per trasmettere i messaggi SOAP Description La descrizione è l attività il cui obiettivo è informare un possibile utilizzatore sul funzionamento e sulle caratteristiche del servizio. Tale descrizione, per la sua complessità, può essere definita in livelli. così come mostrato nelle figura 1.4. Il primo livello ha l obiettivo di descrivere l interfaccia da cui ricavare le Description Business Level Agreements Service Level Agreements Composition Orchestration Presentation Policy Implementation Description Interface Description XML Schema Figura 1.4: Description informazioni necessarie per utilizzare un servizio. Il linguaggio de facto per questa attività e WSDL (Web Service Description Language). WSDL Il WSDL divide l interfaccia del servizio in due componenti logiche distinte: la Service Interface Definition e la Service Implementation Definition. La prima descrive il tipo di servizio come una definizione di una classe in OOP, la seconda è un implementazione completa di tale classe.

15 1.4. XML WEB SERVICES 15 Interface Description Service Implentation Definition Service Port Service Interface Definition Binding Port Type Message Type Figura 1.5: wsdl Service Interface Definition La definizione dell interfaccia astratta è fornita per mezzo di: wsdl:porttype che definisce le operazioni del servizio wsdl:message che definisce gli XML dei messaggi semplici wsdl:types che definisce i tipi XML complessi dei messaggi wsdl:binding che definisce il rapporto tra messaggi e trasporto Service Implementation Definition La definizione dell implementazione è fornita da wsdl:service che è una collezione di elementi wsdl:port wsdl:port che è un elemento che rappresenta il legame tra un URI ed un wsdl:binding Composizione È stato accennato nei paragrafi precedenti che, nel modello SOA, un nodo potrebbe fornire il servizio di raggruppamento di servizi di altri nodi. Questo

16 16 CAPITOLO 1. GLI WEB SERVICES servizio è però difficilmente ottenibile mediante i meccanismi SOAP-wsdl, poichè le informazioni che essi forniscono sono state-less. Il concetto di stato di una comunicazione è importante però per le applicazione B2B: in questi ambiti abbiamo una conversazione tra agenti, cioè una scambio di messaggi in un determinato arco temporale, dotato delle proprietà ACID. In questo caso per integrazione si intende quella tra processi, cioè entità in grado di scambiare un insieme prestabilito di messaggi con altri, secondo un insieme di vincoli, dipendenze, regole, in modo da ottenere una sequenza significativa. È giustificata quindi l introduzione di un livello ulteriore che fornisca la funzionalità per poter conoscere lo stato della conversazione e di descrivere il comportamento di un processo. Tale linguaggio avrà ovviamente sintassi XML e deve permettere di: definire una sequenza stabilire l ordine di invio e ricezione dei messaggi determinare l inizio e la fine di una sequenza esprimere regole, vincoli, dipendenze, relazioni tra messaggi fornire visione globale del servizio solo in base al flusso di messaggi La soluzione più utilizzata in questo momento è BPEL4WS. L utilizzo di questo tipo di linguaggi non ha chiari impatti nel mondo dei WS, poichè non rientra nella categoria delle funzionalità basic. Un codice scritto in BPEL4WS è destinato ad essere eseguito su un nodo dell architettura SOA, tramite un opportuno engine, che coordina l attivitaà dei vari processi, attraverso lo scambio di messaggi. Ogni processo BPEL è ovviamente un servizio, dotato di interfaccia wsdl. I processi sono suddivisibili in: Astratti specificano la sequenza dei messaggi Eseguibili specificano come un partecipante si comporti durante un fase del protocollo Le attività sono classificate in: Basic come un componente interagisce con un processo esterno Structured come i componenti agiscono nel complesso

17 1.4. XML WEB SERVICES Ciclo di vita Abbiamo precedentemente accennato al fatto che qualunque software è riconducibile ad un WS: è necessario solo sovrapporgli un interfaccia in XML. Possiamo allora schematizzare il ciclo di vita di un software che implementi in WS in quattro fasi e precisamente build, deploy, run e manage.tali operazioni possono consistere in: creare un nuovo servizio e la relativa interfaccia mediante gli strumenti presenti nell ambiente del SP (librerie, linguaggi di programmazione, scripts,...) trasformazione di un software esistente in un servizio tramite la creazione di un interfaccia composizione di altri servizi tramite l orchestrazione dei flussi di messaggi originati dal loro utilizzo Nello specifico di un SP, le quattro fasi consistono in: Build In questa fase si sviluppa il software e l interfaccia Deploy In questa fare si procede alla pubblicazione dell interfaccia ed all integrazione con il sistema che ospita il servizio Run si raggruppano le interazioni con gli utilizzatori Manage si raggruppano le attività per la pubblicazione, l auditing e la manutenzione del servizio Nel caso di un SR abbiamo invece: Build insieme delle operazioni per la localizzazione di un servizio, creazione del software per il binding Deploy insieme delle attività per l esecuzione il software Run invocazione vera e propria, eventuale tempo di attesa o di servizio Manage gestione, manutenzione e controllo dei risultati ottenuti Per quanto riguarda la fase di build, possiamo individuarne quattro categorie: Green field è il ciclo di sviluppo di un WS quando non esistono né il software né l interfaccia. Solitamente quindi si crea l applicazione software vera e propria (che ovviamente implementa la logica del servizio nel SP), poi si crea l interfaccia XML, cioè il file wsdl relativo al servizio appena creato (la creazione di tale file è generalmente affidata a tool automatici)

18 18 CAPITOLO 1. GLI WEB SERVICES Top down In questo caso abbiamo da sviluppare un applicazione in base ad un interfaccia già definita (tipicamente è il caso di un accordo tra business partner) Bottom up In questo caso abbiamo un applicazione potenzialmente in grado di fornire un servizio ed è sufficiente creare l interfaccia che descrive il servizio. Meet in the middle Abbiamo sia l interfaccia che l implementazione, dobbiamo eseguire un processo di adattamento dei due elementi Per quello che riguarda il SR, ci sono fondamentalmente due modi per integrarsi con un servizio: Static Binding Quando il servizio è stato già selezionato prima dell esecuzione dell applicazione per conto della quale il SP agisce Dynamic Binding Quando il servizio è scelto a tempo di esecuzione in base alle caratteristiche espresse dalla sua interfaccia Pubblicazione di un servizio Il passo successivo alla creazione della descrizione di un servizio è notificare l esistenza dello stesso, tramite l operazione di pubblicazione. Esistono due principali strategie per la pubblicazione: la pubblicazione diretta, cio e il SR richiede direttamente al SP la descrizione del servizio offerto. In questo caso i nodi si conoscono già perché il SR è a conoscenza dell URI per ottenere l informazione richiesta. utilizzare un service broker, cioè un particolare nodo, detto anche discovery agent, che offre un servizio di archiviazione delle descrizione di servizi di altri nodi della rete Scoperta di un servizio L operazione find consiste nell ottenere le descrizione di un servizio. È possibile distinguere due classi di scoperta di un servizio: la scoperta a tempo di progettazione, cioè prima che avvenga l integrazione tra nodi la scoperta a runtime, in cui i risultati della ricerca sono le caratteristiche definite nell interfaccia stessa

19 1.4. XML WEB SERVICES 19 Sicuramente l approccio a tempo di esecuzione è più elegante, ma la limitazione espressiva del wsdl rendono il suo utilizzo improbabile, oltre al fatto che per quanto riguarda la sicurezza va gestita la fiducia tra i nodi UDDI Lo standard UDDI, Universal Description Discovery and Integration, attualmente alla terza versione, è utilizzato per la pubblicazione e scoperta di descrizioni di servizi. La sua struttura è molto simile a quella di un servizio di directory con associata una struttura dati per memorizzare descrizioni di servizi. La nascita dell UDDI ha qualche analogia con lo sviluppo del sistema DNS: finchè il numero di servizi è limitato, gestire la pubblicazione e la scoperta possono essere svolte manualmente; quando il numero dei servizi supera un certo limite, o non è stimabile a priori, è necessario uno strumento che ci consenta di accedere alle informazioni necessarie e rilevanti. Abbiamo dunque un registro, che può essere anche replicato tra vari nodi, per fornire servizi di: Pagine bianche informazioni di base sul fornitore del servizio ( , indirizzi,...), in modo da avere identificatori del mondo reale Pagine gialle informazioni sul servizio in base alla categoria di appartenenza Pagine verdi informazioni su come accedere e come utilizzare un servizio In riferimento alla figura 1.6 un insieme di nodi, gli operator nodes, contiene una copia del contenuto del registro e vi è un meccanismo per la sincronizzazione periodica. Un elemento di questo registro ha la struttura logica che è rappresentata nella figura 1.7. Un elemento businessentity contiene informazioni di base per individuare un servizio nel mondo reale. Ognuno di questi elementi può offrire più businessservice, le infrmazioni per accedere ad essi contenute in un bindingtemplate. Ci sono fondamentalmente tre categorie di registri UDDI: Internal registry sono utilizzati all interno di un organizzazione per integrare applicazioni interne, SP e SR appartengono allo stesso dominio amministrativo Portal registry sono utilizzati per segnalare la disponibilità di un servizio nei confronti di partners esterni, di cui si conosce il dominio di trust Marketplace registry sono utilizzati per fornire servizi verso utenti esterni, non appartenenti ad un dominio fidato

20 20 CAPITOLO 1. GLI WEB SERVICES UDDI Specifications + Replication Replication Operator Node Operator Node Operator Node UDDI Schema Figura 1.6: UDDI <businessentity> - Name, contact, description - Identifiers and categories <publisherassertion> - Relationship between two companies <businessservice> - Grouping of logical services <bindingtemplate> - Technical information of a single web service - URL access points for service <tmodel> - Specification implemented by web service - URL pointer to specifications Figura 1.7: UDDI Entry

21 2AXIS Forniremo in questo capitolo una descrizione di Axis, illustrando i passi necessari per la configurazione e dei semplici esempi applicativi. 2.1 Introduzione Axis (Apache extensible Iteraction System) è un framework per la costruzione di agenti SOAP. È scritto in Java ed offre, oltre al supporto a WSDL, una serie di piccole, ma utili, funzionalità quali: un tool per la generazione delle classi Java da WSDL, un tool di monitoraggio di pacchetti TCP/IP, un server stand-alone. Axis funziona come Web Application, cioè per funzionare necessita di essere installata su un server J2EE compilant. Nel nostro caso utilizzeremo Apache Tomcat, un servlet engine del progetto Jakarta, largamente utilizzato anche in produzioni aziendali. 2.2 Installazione di Axis Il processo di installazione che illustreremo è stato realizzato sul sistema operativo Mac OS X (Tiger). La versione di Tomcat installata su tale sistema operativo è la ed useremo l ultima versione stabile di Axis (al momento la 1.4). Al momento dell avvio di Tomcat, le informazioni mostrate sono le seguenti neperobook: giacomo$ sudo /Library/Tomcat/bin/startup.sh 21

22 22 CAPITOLO 2. AXIS Using CATALINA_BASE: /Library/Tomcat Using CATALINA_HOME: /Library/Tomcat Using CATALINA_TMPDIR: /Library/Tomcat/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home Per installare Axis sarà sufficiente installare la web application nella cartella CATALINA BASE/webapps. Nel nostro caso Tomcat è configurato per stare in ascolto sulla porta 8080, per cui Axis sarà raggiungibile all indirizzo: La pagina di Axis visualizzata al precedente indirizzo è mostrata nella figura 2.1. Per validare l installazione di Axis è sufficiente visitare il link Validation Figura 2.1: Homepage dell applicazione web Axis presente in tale pagina. Solitamente quello di cui si ha bisogno, perché non sono incluse in Axis, sono le seguenti librerie: SAAJ API ( javax.xml.soap.soapmessage ) JAX-RPC API ( javax.xml.rpc.service ) Apache-Axis ( org.apache.axis.transport.http.axisservlet )

23 2.3. ARCHITETTURA DI AXIS 23 Jakarta-Commons Discovery ( org.apache.commons.discovery.resource ) Jakarta-Commons Logging ( org.apache.commons.logging.log ) Log4j ( org.apache.log4j.layout ) IBM s WSDL4Java ( com.ibm.wsdl.factory.wsdlfactoryimpl ) JAXP implementation ( javax.xml.parsers.saxparserfactory ) Activation API ( javax.activation.datahandler ) Le librerie opzionali sono Mail API ( javax.mail.internet.mimemessage ) XML Security API ( org.apache.xml.security.init ) Java Secure Socket Extension ( javax.net.ssl.sslsocketfactory ) Il modo più semplice per non avere complicazioni con il CLASSPATH è collocare tali librerie nella directory CATALINA BASE/common/lib. La pagina di validazione, se le librerie sono correttamente installare, dovrebbe essere come quella nella figura 2.2. Va precisato che la visualizzazione corretta di tale pagina di validazione è una condizione necessaria ma non sufficiente. 2.3 Architettura di Axis Forniremo in questa sezione la descrizione dell architettura di Axis, entrando anche nello specifico lavoro che compiono le classi che lo implementano Struttura principale Essendo un processore SOAP, il lavoro fondamentale di Axis è processare messaggi. Tali messaggi vengono elaborati passando per una serie di handler. Il numero e l ordine in cui questi handler vengono invocati dipende dalla configurazione del servizio. L oggetto che passa tra un handler e l altro è il Message- Context. Tale oggetto contiene tutte le informazioni necessarie per l elaborazione del messaggio stesso. Gli handler sono solitamente raggruppati in insiemi ordinati per formare una chain.

24 24 CAPITOLO 2. AXIS Handler e Chain Figura 2.2: Pagina di validazione di Axis Una chain è una collezione di handler ed è a sua volta un handler, poichè l interfaccia org.apache.axis.chain estende l interfaccia Handler (sempre del package org.apache.axis), integrandola con alcuni metodi per l aggiunta e la rimozione degli handler, come mostrato nella figura (2.3). Ogni handler che appartiene alla chain ha la possibilità di leggere il messaggio e modificarlo prima di passarlo all handler successivo. Alcuni handler hanno la caratteristica di avere un pivot point. Tale pivot point è un handler in cui una richiesta cessa di essere processata e inizia ad essere processata una risposta. I chain che hanno un pivot point sono anche detti targeted chain. Esistono tre di tipi di handler: Handler di trasporto sono gli handler che possono svolgere operazioni di compressione dati, autenticazione e si differenziano in base al tipo di protocollo di trasporto usato (HTTP, SMTP,... ). Handler globali sono handler che processano qualsiasi messaggio diretto ad Axis, qualsiasi sia il Web Service e qualsiasi sia il protocollo di trasporto usato. Handler server-specific serve per far sì che l handler venga usato solo con un

25 2.3. ARCHITETTURA DI AXIS 25 << interface >> Handler << abstract >> BasicHandler << interface >> Chain << concrete >> SimpleChain Figura 2.3: Handlers e Chains determinato servizio, in modo da implementare funzionalità come crittografia, autenticazione, etc Percorso del messaggio lato server Nel momento in cui arriva un messaggio SOAP sul server, questo viene letto dal TransportListener che lo inserisce in un oggetto Message. Quest ultimo viene poi inserito in un MessageContext, un oggetto contiene anche informazioni tra cui SOAPAction e transportname, che rispettivamente indicano un parametro presente nell header del messaggio ed il tipo di protocollo di trasporto usato. A questo punto il MessageContext viene passato alla catena handler di trasporto, che contiene una request chain, una response chain o entrambi. Se la chain di trasporto è configurata, allora il MessageContext è passato al metodo invoke() dell handler. Dopo essere passato per la chain di trasporto, il MessageContext passa per la chain globale, se definita. Infine il MessageContext arriva alla chain server-specific che lo invierà ad un provider. Il provider, che è anch esso un handler, si occupa della logica di codifica e background del servizio.

26 26 CAPITOLO 2. AXIS Figura 2.4: Percorso messaggio lato server Percorso del messaggio lato client Il percorso del messaggio dal lato del client è speculare rispetto a quello del server, con la differenza che non esiste un provider (perchè non è fornito alcun servizio). Il Sender si occupa di gestire le operazioni relative al protocollo di trasporto e di inviare/ricevere messaggi. Le chain che si possono definire lato client sono le stesse definibili per il server. Figura 2.5: Percorso messaggio lato client 2.4 Primi passi con Axis Il modo più semplice per realizzare un servizio web con Axis è copiare il file sorgente Java nella cartella di Axis e rinominare il file con estensione jws. Ad esempio, se abbiamo la seguente classe: 1 public class PasswordCollector { Listing 2.1: Classe di esempio

27 2.4. PRIMI PASSI CON AXIS 27 2 private DbText db; 3 4 public String tostring () { 5 [...] 6 } 7 8 [...] 9 } per avere il servizio web sarà sufficiente copiare il file PasswordCollector.java in CATALINA HOME/webapps/axis/PasswordCollector.jws e tale servizio sarà così raggiungibile all indirizzo: Richiedendo la risorsa con questo indirizzo, Axis si occuperà di compilare la classe, pubblicare il servizio e convertire le chiamate SOAP in chiamate di funzioni Java. Aggiungendo il suffisso?wsdl all URI precedente Axis genererà automaticamente la specifica WSDL del servizio, per cui per l esempio precedente avremo: Listing 2.2: WSDL Generato da Axis 1 <?xml version="1.0" encoding="utf-8"?> 2 <wsdl:definitions 3 targetnamespace=" 4 xmlns:apachesoap=" 5 xmlns:impl=" 6 xmlns:intf=" 7 xmlns:soapenc=" 8 xmlns:wsdl=" 9 xmlns:wsdlsoap=" 10 xmlns:xsd=" 11 <!--WSDL created by Apache Axis version: Built on Apr 22, 2006 (06:55:48 PDT)--> 13 <wsdl:message name="tostringrequest"> 14 </wsdl:message> 15 <wsdl:message name="tostringresponse"> 16 <wsdl:part name="tostringreturn" type="xsd:string"/> 17 </wsdl:message> 18 <wsdl:porttype name="passwordcollector"> 19 <wsdl:operation name="tostring"> 20 <wsdl:input message="impl:tostringrequest" 21 name="tostringrequest"/> 22 <wsdl:output message="impl:tostringresponse" 23 name="tostringresponse"/> 24 </wsdl:operation> 25 </wsdl:porttype>

28 28 CAPITOLO 2. AXIS 26 <wsdl:binding name="passwordcollectorsoapbinding" 27 type="impl:passwordcollector"> 28 <wsdlsoap:binding style="rpc" 29 transport=" 30 <wsdl:operation name="tostring"> 31 <wsdlsoap:operation soapaction=""/> 32 <wsdl:input name="tostringrequest"> 33 <wsdlsoap:body 34 encodingstyle=" 35 namespace=" use="encoded"/> 36 </wsdl:input> 37 <wsdl:output name="tostringresponse"> 38 <wsdlsoap:body 39 encodingstyle=" 40 namespace=" 41 use="encoded"/> 42 </wsdl:output> 43 </wsdl:operation> 44 </wsdl:binding> 45 <wsdl:service name="passwordcollectorservice"> 46 <wsdl:port 47 binding="impl:passwordcollectorsoapbinding" 48 name="passwordcollector"> 49 <wsdlsoap:address 50 location=" 51 </wsdl:port> 52 </wsdl:service> 53 </wsdl:definitions> 1 Axis fornisce anche un package Java per poter utilizzare i servizi web dal lato client. Ad esempio per poter utilizzare la funzionalità tostring del servizio PasswordCollector il codice è il seguente: Listing 2.3: Test.java 2 import org.apache.axis.client.call; 3 import org.apache.axis.client.service; 4 5 public class Test { 6 public static void main(string [] args) { 7 try { 8 String endpoint = 9 " 10 Service service = new Service(); 11 Call call = (Call) service.createcall(); 12 call.settargetendpointaddress(new java.net.url(endpoint)); 13 call.setoperationname("tostring"); 14 String ret = (String) call.invoke(new Object [] {} );

29 2.5. WEB SERVICE DEPLOYMENT DESCRIPTOR System.out.println("La risposta del servizio e : "+ret); 16 } catch (Exception e) { 17 System.err.println(e.toString()); 18 } 19 } 20 } Come è facile vedere dal codice precedente, alle righe 10 e 11 vengono creati gli oggetti Service e Call, che sono gli oggetti standard di JAX-RPC per memorizzare i metadati sul servizio da richiamare. L impostazione dell endpoint URL definisce il destinatario del messaggio SOAP. Sul tipo dei parametri del metodo chiamato e sul tipo di ritorno parleremo nei paragrafi seguenti. 2.5 Web Service Deployment Descriptor I file jws sono sicuramente un modo semplice per trasformare classi Java in servizi web, ma non sempre sono la miglior scelta. Ad esempio, non sempre disponiamo del codice sorgente di un applicazione che vogliamo rendere disponibile sul Web. Inoltre, la configurazione che possiamo specificare sul servizio è molto limitata: si pensi alla gestione dei tipi oppure ai meccanismi di sicurezza. La soluzione a questo problema è l utilizzo dei WSDD (Web Service Deployment Descriptor). Un file WSDD è scritto in XML e contiene un insieme di direttive per indicare quali funzionalità pubblicare con Axis. Un esempio di file WSDD per pubblicare il servizio PasswordCollector potrebbe essere: Listing 2.4: Semplice file WSDD 1 <deployment xmlns=" 2 xmlns:java=" 3 <service name="passwordcollector" provider="java:rpc"> 4 <parameter name="classname" 5 value="net.nepero.portal159.passwordcollector.passwordcollector" /> 6 <parameter name="allowedmethods" value="*" /> 7 </service> 8 </deployment> In generale l elemento service può essere costituito da: in flusso di richieste, un pivot Handler (o provider), un flusso di risposta. Per quanto riguarda il provider, in questo caso abbiamo che è java:rpc ed indica il servizio Java RPC (org.apache.axis.providers.java.rpcprovider). La classe che il provider deve instanziare è definita dal parametro chiamato classname ed i parametri a cui possiamo accedere sono definiti da allowedmethods, separati da virgola oppure specificando * se si vuol dar l accesso a tutti i metodi

30 30 CAPITOLO 2. AXIS pubblici. Un ulteriore parametro che possiamo specificare è scope, che serve a definire il tipo di azione che il provider deve compiere sull oggetto Java che definisce il servizio. I possibili valori di scope e le relative azioni sono: request: in questo caso ad ogni richiesta del servizio viene instanziato un nuovo oggetto application: viene creato un oggetto singleton alla prima richesta ed il suo stato è condiviso alle richieste successive session: viene creato un nuovo oggetto per ogni sessione attivata Per specificare lo scope è sufficiente inserire il parametro con nome scope tra quelli del servizio, ad esempio: Listing 2.5: File WSDD con scope 1 <deployment xmlns=" 2 xmlns:java=" 3 <service name="passwordcollector" provider="java:rpc"> 4 <parameter name="classname" 5 value="net.nepero.portal159.passwordcollector.passwordcollector" /> 6 <parameter name="allowedmethods" value="*" /> 7 <parameter name="scope" value="request" /> 8 </service> 9 </deployment> Per configurare gli handler di servizio, è necessario aggiungere, nel file WSDD, un elemento handler per ognuno di essi ed un elemento requestflow all interno delle specifiche del servizio, per impostare l ordine di esecuzione. Ad esempio Listing 2.6: File WSDD con service-handler 1 <deployment xmlns=" 2 xmlns:java=" 3 <handler name="log" type="java:net.nepero.portal159.log.loghandler"> 4 <parameter name="filename" value="login.log" /> 5 </handler> 6 <service name="passwordcollector" provider="java:rpc"> 7 <requestflow> 8 <handler type="log" /> 9 </requestflow> 10 <parameter name="classname" 11 value="net.nepero.portal159.passwordcollector.passwordcollector" /> 12 <parameter name="allowedmethods" value="*" /> 13 <parameter name="scope" value="request" /> 14 </service> 15 </deployment>

31 2.5. WEB SERVICE DEPLOYMENT DESCRIPTOR 31 In questo caso il servizio LogHandler si occuperà di monitorare le informazioni riguardanti le richieste al servizio PasswordCollector, come mostrato dal listato 2.7 (la definizione di un logger è di notevole importantanza durante lo sviluppo dello web service per fare debugging). 1 package net.nepero.portal159.log; 2 Listing 2.7: Codice dell handler del servizio 3 import org.apache.axis.axisfault; 4 import org.apache.axis.handler; 5 import org.apache.axis.messagecontext; 6 import org.apache.axis.handlers.basichandler; 7 8 import java.io.fileoutputstream; 9 import java.io.printwriter; 10 import java.util.date; public class LogHandler extends BasicHandler { 13 public void invoke(messagecontext msgcontext) throws AxisFault 14 { 15 try { 16 Handler servicehandler = msgcontext.getservice(); 17 String filename = (String)getOption("filename"); 18 if ((filename == null) (filename.equals(""))) 19 throw new AxisFault("Server.NoLogFile", 20 "Errore nella configurazione del logger.", 21 null, null); 22 FileOutputStream fos = new FileOutputStream(filename, 23 true); 24 PrintWriter writer = new PrintWriter(fos); 25 Integer numaccesses = 26 (Integer)serviceHandler.getOption("accesses"); 27 if (numaccesses == null) 28 numaccesses = new Integer(0); 29 numaccesses = new Integer(numAccesses.intValue() + 1); 30 Date date = new Date(); 31 String result = date + ": servizio " + 32 msgcontext.gettargetservice() + 33 " richiesto " + numaccesses + " volte."; 34 servicehandler.setoption("accesses", numaccesses); 35 writer.println(result); 36 writer.close(); 37 } catch (Exception e) { 38 throw AxisFault.makeFault(e); 39 } 40 } 41 }

32 32 CAPITOLO 2. AXIS Per poter pubblicare il servizio appena configurato con il file WSDD sono necessarie alcune operazioni ben più complesse di una semplice copia del file, come nel caso precedentemente descritto. Innanzitutto le informazioni su tutti i servizi installati sono registrate nel file di configurazione server-config.wsdd, contenuto nella cartella WEB-INF di Axis. Quindi per installare il servizio si può procedere attraverso la modifica di questo file oppure utilizzando il tool Admin- Client di Axis. Per utilizzare questo tool, che è sicuramente il modo più semplice per pubblicare un servizio, è sufficiente richiamarlo da linea di comando tramite: java org.apache.axis.client.adminclient Per poter effettuare un deploy di un servizio sarà necessario specificare come paramentro il nome del file WSDD che ne descrive la configurazione: java org.apache.axis.client.adminclient passwordcollector.wsdd È disponibile avere la lista dei servizi attualmente installati tramite il comando java org.apache.axis.client.adminclient list 2.6 Applicazioni di esempio Analizziamo in questo paragrafo come realizzare le applicazioni lato client, cioè i SR. Un semplice codice per interagire con il servizio echo è il seguente: Listing 2.8: Client.java 1 import org.apache.axis.constants; 2 import java.xml.rpc.paramatermode; 3 import java.net.url; 4 import org.apache.axis.client.call; 5 import org.apache.axis.client.service; 6 7 public class Client { 8 public static void main(string [] args) { 9 String endp = " 10 String message = "hello!"; 11 Service service = new Service(); 12 Call call = (Call) service.createcall(); 13 call.settargetendpointaddress( new URL(endp) ); 14 call.setoperationname("echo"); call.addparameter("message", Constants.XSD_STRING, 17 ParameterMode.IN); call.setreturntype(constants.xsd_string); 20 String ret = (String) call.invoke(

33 2.6. APPLICAZIONI DI ESEMPIO new Object[] { message } ); 22 System.out.println("Ho inviato: " + message + "\n"); 23 System.out.println("Ho ricevuto: " + ret); 24 } 25 } Rispetto all esempio del paragrafo precedente, và notata alle righe 16, 17 e 18 la definizione dei tipi di dato dei parametri di input ed output che verranno poi introdotti nel messaggio SOAP che deriva dalla serializzazione dell oggetto che rappresenta il messaggio. Avremo in questo caso: Listing 2.9: SOAP Request 1 <?xml version="1.0" encoding="utf-8"?> 2 <SOAP-ENV:Envelope xmlns:xsd=" 3 xmlns:soap-env= 4 xmlns:xsi=" 5 <SOAP-ENV:Body> 6 <ns1:echo xmlns:ns1=" 7 <message xsi:type="xsd:string">hello!</message> 8 </ns1:echo> 9 </SOAP-ENV:Body> 10 </SOAP-ENV:Envelope> E la risposta del server sarà: Listing 2.10: SOAP Response 1 <?xml version="1.0" encoding="utf-8"?> 2 <SOAP-ENV:Envelope xmlns:xsd=" 3 xmlns:soap-env= 4 xmlns:xsi=" 5 <SOAP-ENV:Body> 6 <ns1:echoresponse xmlns:ns1=" 7 <response xsi:type="xsd:string">hello!</response> 8 </ns1:echoresponse> 9 </SOAP-ENV:Body> 10 </SOAP-ENV:Envelope> Analizziamo adesso un esempio più complesso di interazione tra client e web service che fà uso anche degli header SOAP. La gestione è più complessa perché è necessario far uso delle API per gestire dati in XML. Ad esempio, per creare il messaggio: Listing 2.11: SOAP con header 1 <?xml version="1.0" encoding="utf-8"?> 2 <SOAP-ENV:Envelope xmlns:xsd="

34 34 CAPITOLO 2. AXIS 3 xmlns:soap-env= 4 xmlns:xsi=" 5 <SOAP-ENV:Header> 6 <x:authentication> 7 <x:login>zaza</x:login> 8 <x:password>zaza</x:password> 9 </x:authentication> 10 </SOAP-ENV:Header> 11 <SOAP-ENV:Body> 12 <ns1:echo xmlns:ns1=" 13 <message xsi:type="xsd:string">hello!</message> 14 </ns1:echo> 15 </SOAP-ENV:Body> 16 </SOAP-ENV:Envelope> Una possibile implementazione Java potrebbe essere: 1 import java.net.url; 2 Listing 2.12: Esempio utilizzao SOAP Header 3 import javax.xml.parsers.documentbuilder; 4 import javax.xml.parsers.documentbuilderfactory; 5 import org.w3c.dom.document; 6 import org.w3c.dom.element; 7 import org.apache.axis.client.service; 8 import org.apache.axis.client.call; 9 import org.apache.axis.message.soapenvelope; 10 import org.apache.axis.message.soapheaderelement; 11 import org.apache.axis.message.rpcelement; 12 import org.apache.axis.message.rpcparam; public class Client { 15 public static void main (String [] args) { 16 String endp = " 17 String message = "hello!"; 18 // Creazione XML 19 DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); 20 DocumentBuilder db = dbf.newdocumentbuilder(); 21 Document doc = db.newdocument(); 22 // Costruisco gli elementi <authentication>, <login> e <password> 23 Element auth = doc.createelementns(" 24 "Authentication"); 25 Element login = doc.createelementns(" 26 "login"); 27 Element password = doc.createelementns(" 28 "password"); 29 // Assemblo gli elementi 30 login.appendchild( doc.createtextnode("zaza") );

35 2.7. CODIFICA DEI DATI password.appendchild( doc.createtextnode("zaza") ); 32 auth.appendchild(login); 33 auth.appendchild(password); 34 // Creo l header 35 SOAPHeaderElement she = new SOAPHeaderElement(auth); 36 // Costruisco un messaggio SOAP 37 SOAPEnvelope envelope = new SOAPEnvelope(); 38 // Aggiungo l header al messaggio 39 envelope.addheader(she); 40 // Creo la codifica RPC del messaggio e della chiamata del metodo 41 // e lo aggiungo al body del messaggio SOAP 42 Object [] params = new Object [] { message }; 43 RPCElement rpccall = new RPCElement(" 44 "echo", params); 45 envelope.addbodyelement(rpccall); 46 // Uguale all esempio di client senza header 47 Service service = new Service(); 48 Call call = (Call) service.createcall(); 49 call.settargetendpointaddress( new java.net.url(endp)); 50 // Effettuo la chiamata passando l envelope 51 SOAPEnvelope respenv = call.invoke (envelope); 52 // Recupero il risultato dal messaggio SOAP di risposta 53 RPCElement resprpc = (RPCElement) respenv.getfirstbody(); 54 RPCParam result = (RPCParam) resprpc.getparams().get(0); 55 System.out.println("Ricevuto: " + 56 (String) result.getvalue()); } 59 } 2.7 Codifica dei dati Una aspetto molto importante nell utilizzo dei Web Services ed in particolare di Axis è la codifica dei dati, cioè la rappresentazione dei parametri in ingresso ed uscita di un servizio. In Axis, i dati vengono mappati usando le regole definite nella specifica JAX-RPC e la tabella 2.1 ne mostra un riassunto. Per quanto riguarda le collezioni di Java (Vector, ArraList,... ) non esistono serializzatori o deserializzatori specifici e quindi l unico modo per inviare tali collezioni è usare gli array di SOAP. Anche per quanto riguarda i tipi definiti dall utente, non è possibile trasferirli direttamente tramite Axis, senza prima effettuare il mapping con un serializzatore o deserializzatore. Axis fornisce una serie di serializzatori e deserializzatori il cui compito è convertire tipi Java e codificarli nello standard JAX-RPC. Uno dei serializzatori più flessibili è BeanSerializer: con questo è possibile convertire qualunque classe Java scritta seguendo lo stile dei