JAXB and the root element

Recently I helped a friend to implement the client of a web service using Axis2 and Tomcat, developing the client first and the jsp after. After testing the web service with SoapUI we started to develop the client with Eclipse.

The problem with this web service is that the body of the method is an entire xml string contained in a CDATA element, not only for for the request but also for the answer, of course this creates problem to generate the java objects from the wsdl file since the element is not defined as XML.

Luckily we received the xsd files so we generated the java classes with JAXB data binding which is implemented, and it can be executed, through the application xjc that you can find inside the bin folder of the Java Virtual Machine. Note that JAXB is the default databinding of Apache Cxf.

JAXB worked nicely but we had the problem to extract from the xml string the node container which needed to be declared as root element, in other words you need to use the @XMLRootElement annotation otherwise you can have the exception:

unexpected element (…) , Expected elements are (none).

when you unmarshal (from string to java object) the element.

 

Advertisements

Axis2: codegen Ant task; perchè no ?

Sempre piccola nota per chi genera web services a partire da file wsdl.

Fino ad ora avevo suggerito di usare il wizard di Axis2 su Eclipse perchè più completo di quello di Netbeans. Ebbene si usarlo alla fine è comodo ma non mi accontento soprattutto quando il wizard lascia qualche parametro implicito come la cartella resources.

Vi spiego meglio: se generate il codice dal wizard e, tra l’altro usate xmlbeans, vi ritrovete la cartella resources come root nel progetto java. In questa cartella ci sono il file wsdl ricopiato, il file services.xml e una cartella usata da Xmlbeans per gli schema generati. Fatto sta che se rilanciate il wizard per un altro web services tale cartella viene sovrascritta, in particolare il file services.xml viene sovrascritto.

Questo accade perchè l’output di default va nella root del progetto fatta eccezione per la cartella src in cui ci vanno le classi generate. Per impedire questo dovete sapere che il comando del codegen prende il parametro -R dove si puo’ indicare un path alternativo per la cartella resources.

A questo punto siccome mi piace automatizzare le cose (pigrizia da programmatore) mi sono chiesto se ne vale la pena usare il comando Ant relativo che permette di impostare tutte le opzioni.

A mia sorpresa scopro che il path che va specificato per il tag targetResourcesFolderLocation deve essere relativo al path specificato nel tag output.

Cmq era giusto per ricordarvi che è comodo poterlo usare basta importare alcuni package come specificato nella pagina:

http://ws.apache.org/axis2/tools/1_4_1/CodegenToolReference.html

Web services, sicurezza e Axis2

Ultimamente mi sono addentrato nel mondo della sicurezza dei web services. Nel progetto in cui lavoro viene usato Axis2 come container per i web services. Axis2 ha una struttura modulare che permette di aggiungere moduli che implementano le specifiche WS, parliamo in tal caso di WS-Security e WS-SecurityPolicy e WS-Policy gestite dal modulo Rampart.

Occorre subito dire che i moduli sono legati alle versione di Axis2 e quindi abbiamo Rampart 1.3 basato su Axis2 1.3 mentre Rampart 1.4 con Axis2 1.4.

In particolare in azienda stiamo usando WSO2 Esb che è appunto un Enterprise Service Bus ovvero permette di definire politiche di routing e filtering tra i web services.

Piccola nota: per quello che ne so non è il massimo in quanto non è conforme allo standard JBI che altri esb rispettano.

WSO2 Esb è basato su Apache Synapse e integra tra l’altro Axis2 con Rampart offrendo una carina interfaccia web dove è possible creare sequenze di web services e filtri.

La versione che fino ad ora abbiamo usato è la 1.6 che si basa su Axis2 1.3 e di conseguenza Rampart 1.3 mentre la versione 1.7 è passata su Axis2 1.4.

L’interfaccia web permette di aggiungere sicurezza nella connessione tra 2 web services grazie all’upload del file che ne specifica le policy ovvero che indica, secondo le speficiche, quali parti del messaggio vengono firmate e criptate più una serie di opzioni.

Di solito avreste bisogno di criptare solo il corpo del messaggio, il cosiddetto SOAP body ma le specifiche indicano che è possible specificare alcune parti dell’header. Questo è al momento per me importante perchè nel progetto è stato definito un header customizzato da aggiungere nei messaggi trasmessi. Fatto sta che ho scoperto che Rampart genera un NullPointerException quando si indica una qualunque parte dell’header e quindi si riesce solo a criptare solo il body.

Non so ancora se la versione successiva, Rampart 1.4, abbia risolto questo bug ma me lo auguro di cuore, devo anche dire che qualora lo risolvesse non è poi il massimo in quanto il progetto fino ad ora si è basato sulla versione 1.3 di Axis2 ed è seccante fare un cambiamento di versione mentre il progetto va avanti.

Alla prossima (sperando aver trovato la soluzione)

Aggiornamento:

Alla fine ho migrato alla versione successiva: Axis2 1.4. Nonostante quel bug sia risolto ne esiste almeno un altro a cui sto girando attorno. Un requisito importante è che ho scoperto che WCF (dal lato .NET) supporta solo le specifiche WS-SecurityPolicy 1.2 significa che, a livello di interoperabilità, sono costretto ad usare Axis2 1.4 poichè il precedente non supporta queste specifiche.

Ora tutto ciò comporta che stub e skeleton vanno rigerenerati e vanno aggiornate le versioni di WSO2 Esb e Application Server, speriamo bene.

Junit e SoapUI, strumenti per testare web services

In genere durante il processo di sviluppo di una applicazione una delle fasi sottovalutate è quella di testing.

La fase testing dovrebbe in teoria iniziare non appena i requisiti della applicazione sono stati definiti e dovrebbe poi continuare per il tutto il processo di sviluppo poichè all’aumentare della complessità della applicazione i test devono garantirne il suo funzionamento e, dunque, esistono diversi livelli di test da quelli di unità a quelli di sistema e validazione (acceptance test).

Indipendentemente dai livelli esistono test di varia natura da quelli funzionali a quelli di robustezza e performance. In sostanza come avete potuto capire il tutto puo’ richiedere abbastanza tempo e quindi se si cerca di rendere quanto più automatica questa fase è meglio.

Nel mondo Java il tutto inizia con le librerie di Junit. Rilasciate con licenza Common Public Licence 1.0 sono arrivate, al momento in cui scrivo, alla versione 4.5 (del 8/8/2008). Esse permettono di automatizzare la fase di testing scrivendo metodi che contengono alcune chiamate alle librerie e tra queste esistono i metodi “assertEquals()” che verificano che 2 oggetti (quello atteso e quello di cui si dispone) sono uguali (da cui poi tuttte le derivazioni come il confronto tra booleani, stringhe ecc.).

Nonostante siamo alla versione 4.x la serie precedente, 3.x, viene mantenuta questo perchè le classi che contengono i metodi devono essere opportunamente scritte, in particolare con la 3.x ad esempio i nomi dei metodi devono avere una certa struttura (testXXX, cioè devono iniziare per test) mentre la 4.x permette di avere una certa elasticità usando pero’ le annotazioni come javadoc. Eclipse 3.4 annovera tra le sue librerie sia Junit 3 (3.8.2) e Junit 4 (4.3.1) e permette di creare Test case usando l’una o l’altra libreria. In questo esempio vedere come creare Junit Test case con la versione 4.

Un’ultima cosa che dovete sapere su Junit è che potete raggruppare i Test case in Test suite che eseguono più test. Inoltre quando si scrivono metodi per i test può capitare che questi condividano degli oggetti inizializzati; Junit permette di inizializzare, e poi distruggere, risorse condivise tramite i metodi setUp() e tearDown(), vi lascio poi scoprire il tutto facendovi spulciare la documentazione.

Ant, non solo vi permette di automatizzare il tutto con il suo Junit task, ma vi crea anche, a partire dai risultati di ogni test, dei sempli report.

Quando create dei web services usando il plugin di Axis2, Codegen Wizard, per Eclipse probabilmente avrete notato l’opzione che genera anche i test cases che alla fine non sono altro che semplici client che dovete inizializzare dando l’end point da contattare e costruendo gli oggetti che da passare allo stub. Inoltre potete modificare il file Ant generato per generare i report che vi avevo accennato prima.

Junit è pero’ la punta di un iceberg. Difatti si sono evolute applicazioni che si occupano solo della fase di testing come Cactus, Fitnesse (che è un wiki che fa acceptance test) , Selenium che allargano l’orizzonte anche alle applicazioni web, lo stesso Spring tra l’altro contiene un modulo per il testing. Se poi parliamo di performance esiste jMeter (a cui SOAPUI fa concorrenza).

SoapUI è una applicazione rivolta ai web services che abbiamo già incontrato quando vi ho accennatto alla possibilità di validare i file wsdl per migliorare l’interoperabilità.

Una delle funzionalità carine è quella di creare al volo una richiesta SOAP automaticatimente generata a partire dal file wsdl, generando poi report e test di copertura su file wsdl.

Junit non è poi l’unico testing framework esistono TestNG ed anche Nunit (che è il porting di Junit per .NET) e una miriade di applicazioni che vengono usate per testare i vari linguaggi.

A questo punto vi auguro buona esplorazione in questo mondo che, anche per me, si sta rivelando sempre più grande e al tempo stesso affascinante (soprattutto come sviluppatore pigro che vorrebbe automatizzare tutto ciò :-) ).

P.S: Occorre dire che lo stesso Eclipse nel suo piccolo permette di testare on-line il servizio web. Difatti cliccando con il tasto destro del mouse sul file wsdl dovreste ritrovarvi nel menu contestuale la voce Web Services da cui la sotto voce Test with Web Services Explorer che è una interfaccia web che vi permette di compilare i campi  da mandare nella richiesta SOAP e subito sotto vedere la risposta.

Link interessante: http://wso2.org/library/3862

Alla prossima

Axis2 e la gestione dei soap header

Come avete potuto notare attualmente sono focalizzato sui web services, in particolar modo sto lavorando con Axis2 che funziona non solo come container ma mette a disposizione strumenti per lo sviluppo come wsdl2java. Andiamo per ordine.

Un servizio web, come qualcuno di voi sa, non è altro che una serie di operazioni compiute da una applicazione (in questo caso scritta in java) che è raggiunta via web. In particolar modo queste operazioni si scambiano per lo più messaggi SOAP.

Questi messaggi SOAP sono sostanzialmente messaggi scritti in XML che viaggiano su protocollo HTTP e sono strutturati in un header e in un body.

La descrizione di questi messaggi, legati alle operazioni di cui fanno parte, è fatta dai file WSDL che appunto descrivono il web service. Talvolta, anzi spesso, questi file WSDL sono accompagnati da XML schema (file con estensione xsd) che descrivono la struttura degli elementi dei messaggi.

Molte volte avrete necessità di inserire questi elementi nel body ma puo’ capitare di voler metterli nell’header. Per far cio’ dovete specificare l’header come elemento soap:header all’interno della soap:operation (scusate se entro nel dettaglio, comunque potete vedere le specifiche WSDL)

Axis2 fornisce strumenti automatici che partono dal file WSDL e creano delle classi java, chiamate stub e skeleton, a cui si appoggieranno i vostri client e server (lo strumento è chiamato WSDL2Java ed puo’ essere incluso come plugin in Eclipse e in Netbeans) . Al momento della creazione avrete necessita’ di decidere quale parser utilizzare di solito a scelta tra ADB, Xmlbeans, Jibx. Questi parser trasformano gli elementi XML dichiarati nel file WSDL in oggetti java.

Se avete mai realizzato un web service con gli strumenti di Axis2 avrete notato, facendo anche la più semplice operazione, che normalmente gli elementi vengono incapsulati nel body. Ma se aggiungete un elemento header come accennato sopra cosa accade ?

Ebbene occorre purtroppo dire che lo stub permette di richiamare il servizio passando l’elemento che vogliamo aggiungere nell’header senza nessun problema mentre cio’ non accade con lo skeleton. In particolare lo skeleton viene richiamato da un’altra classe che è automaticamente generata ed il cui nome finisce in genere per MessageReceiverInOut. Questa classe ha un metodo che si chiama invokeBusinessLogic, essa recupera il messaggio in ricezione e invia il messaggio in uscita dal web service una volta richiamato lo skeleton.

Dovete sapere che Axis2 ha diversi stati o sessioni cioè strutture dati (classi java) che memorizzano, in breve, lo stato delle operazioni e dei messaggi. Ogni messaggio, in particolare è incapsulato nella classe MessageContext la quale sta a livello inferiore dell’OperationContext che è la classe che rappresenta lo stato della operazione. Ci sono stati di livello superiore per avere un dettaglio vederei riferimenti a fondo pagina.

Di conseguenza il metodo invokeBusinessLogic prende un MessageContext ingresso e restituisce un nuovo MessageContext in uscita. Succede pero’ che il metodo che dovrete implementare nello skeleton  restituisce solo un oggetto che viene messo in un messaggio SOAP creato sull’istante dal metodo invokeBusinessLogic.

Quindi a nulla vale aver creato nello skeleton il soap envelope (messaggio SOAP) con tanto di header perchè appunto nel metodo invokeBusinessLogic viene creato un nuovo messaggio SOAP (in cui andrà il risultato del metodo dello skeleton) non curandosi del messaggio creato nello skeleton.

Allo stato attuale quindi o dovete modificare a mano la classe MessageReceiverInOut oppure dovete pensare a soluzioni come quella di includere un header dentro al body. Dovete pensare che le classi generate non sono intoccabiliti semplicemente assistono chi vuole creare un servizio web quindi se volete modificatele pure.

Questo problema è stato verificato con Axi2 1.3 e Axis2 1.4 e con i parser ADB e Xmlbeans.

Riferimenti:

Fare il debug di web services

Nel precedente articolo, vi ho accennato all’uso di Eclipse, Tomcat e Axis2 per la creazione di web services.

Vi sarete chiesti: come faccio a sapere che il tutto stia funzionando passo per passo oltre a vedere l’output da console ?

Potete usare 2 modi:

1) vedere i messaggi scambiati tra client e server

2) usare il debug remoto

Se non usate Axis2, ma un semplice client server che comunicano tramite una porta, puo’ esservi utile TCPMon una applicazione java che si esegue da un unico jar file a cui dovete configurare come porta locale una porta che il vostro client deve chiamare e la server port la porta del vero server. In pratica esso funziona come proxy permettendovi di vedere i messaggi scambiati.

Se usate Axis2 potete usare il SOAPMonitor che, come TCPMon, è una sorta di proxy che si infrappone nella comunicazione. Non sono riuscito a farlo funzionare su Axis2 1.4, in rete ho trovato un tipo che lo ha fatto funzionare ma non voglio perderci tempo, mentre ci sono riuscito su Axis2 1.3 semplicemente estraendo dal file soapmonitor-1.3.jar (presente in Axis2) le classi in esso contenute e copiandole nella root directory di Axis2 (stiamo parlando della directory di Axis2 che sta dentro Tomcat).

Alternativamente al SOAPMonitor c’è il tracer di WSO2 Web Services Application Server o WSAS. Questo application server è formato da Tomcat e Axis più la serie di moduli che si appoggiano ad Axis come Apache Rampart per quanto riguarda la sicurezza (WS-Security) o Sandesha per quanto riguarda l’affidabilità (WS-ReliableMessaging). Nell’interfaccia web di Axis2 avete sicuramente notato la sezione dedicata ai moduli che possono essere agganciati a tutti i web services o solo ad alcuni. Ebbene WSAS permette di averli già tutti installati (vi risparmia la fatica) offrendo dalla sua interfaccia web una serie di tool tra cui il tracer.

Per quanto riguarda il tracer ho trovato WSAS 2.1 più stabile di WSAS 2.2 e 2.3 (ultima versione al momento in cui scrivo). Quello di 2.2 mi geneva una eccezione mentre leggevo un messaggio quello di 2.3 funziona ma in WSAS esiste uno strumento che permette di provare un web service da interfaccia web (una volta selezionato il web service cliccate su Try it) che mi ha funzionato meglio su 2.1 che su 2.3. Poi ovviamente fate voi.

2) Come per le applicazioni stand alone potete inserire dei breakpoint nel codice e fare il debug potete fare lo stesso anche per i web services a patto che l’application server ve lo consente (Tomcat di sicuro) e che dal vostro IDE (di sicuro Eclipse) possiate lanciare l’applicazione in debug mode. In sostanza IDE e application server si accordano su una porta per il debug; Il tutto è dovuto alla Java Platform Debugger Architecture. Cercate “eclipse remote debug” in Google e troverete esempi come questi:

http://it.newinstance.it/2005/10/04/remote-debugging-tomcat-with-eclipse/

http://flexblog.faratasystems.com/?p=267

http://www.eclipsezone.com/eclipse/forums/t53459.html

http://www.onjava.com/pub/a/onjava/2005/08/31/eclipse-jboss-remote-debug.html?page=1

Web Services con Eclipse 3.4, Tomcat 6.0.16 e Axis2 1.4

Per un progetto in azienda sto lavorando con i web services, usiamo pero’ vecchie versioni di eclipse e axis2 poichè il progetto è iniziato con quelle versioni e non si può cambiare strumento durante lo sviluppo, come è giusto che sia. Per i fatti miei però ho sperimentato la generazione di web services dapprima con Netbeans 6.1 e poi con Eclipse 3.4.

Introduzione

Come da titolo dovete scaricare Eclipse, Tomcat e Axis2. Io ho scaricato Eclipse 3.4 per Java EE, Tomcat Core e Axis2 il file war ma anche la standard binary distributition perchè essa contiene dei comandi che il war file non ha.

Tomcat è un application server e dovrà lanciare Axis2 che funge da contenitore per i vostri web services e vi permette anche di gestirli. Con Eclipse dovrete creare le classi java per il client e il server.

Iniziamo

Una volta estratta la standard binary distribution, create la variabile di ambiente AXIS2_HOME in modo che punti ad essa e poi copiate il file war nella cartella /webapps di Tomcat. Ora, se volete, potete far partire tomcat lanciandolo dalla sua cartella /bin e con il vostro browser andare all’url:

http://localhost:8080

8080 è in genere la porta su cui Tomcat gira. Dovreste vedere la pagina di Tomcat, se cliccate a sinistra su Tomcat manager vedete la lista di applicazioni tra cui c’è Axis2. Cliccateci sopra e vi compare la pagina di Axis2. Come primo link c’è “Services” che indica gli attuali web services che stanno girando tra cui ci sarà anche il nostro.

Come vi ho già detto nella standard binary distribution ci sono dei comandi che nel war non sono presenti e sono java2wsdl e wsdl2java (vedere qui per tutti i parametri)

Se siete nuovi nel mondo dei web services dovete sapere che i file wsdl sono dei file xml che descrivono i web services percio’ prima di proseguire vi consiglio di studiarvi XML, i file xml schema e i file wsdl in generale (potete dare una occhiata al sito w3schools). Occorre saperlo perchè grazie al comando wsdl2java potete creare, a partire dal file wsdl, ciò che sta sotto la comunicazione tra client e webservice ovvero stub e skeleton.

Stub e skeleton sono delle classi java che fungono da proxy ovvero il vostro client chiamerà lo stub per la comunicazione mentre il webservice userà lo skeleton per ricevere, ed eventualmente trasmettere, i dati.

In un precedente articolo ho spiegato come potete validare i vostri file wsdl in modo da diminuire i rischi di interoperabilità, pensate ad esempio ad un client (stub) realizzato in java ed un web service (skeleton) realizzato sotto .NET.

Il comando java2wsdl potete immaginare cosa fa.

Questi comandi, come descritto nella reference di Axis2 sono molto semplici da usare ma una interfaccia grafica non dispiace.

Il servizio andrà poi impacchettato in un archivio axis (file aar) e deployato (in altre parole copiato e spacchettato, lasciatemi passare il termine) nella cartella di Axis2 sotto Tomcat.

Ho dapprima provato il plugin di Netbeans ma personalmente credo che andrebbe migliorato perchè è possibile selezionare poche cose e, inoltre, obbliga alla all’inserimento di parametri (-g) a linea di comando (da dentro l’interfaccia!) per la generazione del client, in quanto, in automatico, lui crea lo skeleton e l’unico modo per creare lo stub è aggiungere il parametro; per il resto il plugin si comporta bene. Il tutorial che ho seguito è questo. Tuttavia ho poi proseguito per Eclipse anche se poi ho scoperto che il plugin è buggato ma ho trovato rimedio.

I plugin di Axis2 sono a mio avviso più completi e si scaricano dal sito di Axis2 e precisamente sono il Service Archive Wizard 1.4 e il Code Generator Wizard 1.4 che come vedete nella tabella richiedono Axis 1.4.

Il primo serve per creare l’archivio axis da copiare in Tomcat il secondo come interfaccia per i comandi java2wsdl e wsdl2java.

Non dovete fare altro che scaricare i plugin ed estrarli nella cartella plugins di Eclipse e correggere qualche bug :-) .

In pratica nella cartella del Code Generator c’è un file che si chiama plugin.xml, in questo file sono descritte le librerie di cui il plugin si serve, tra queste notate che c’è l’archivio jar stax-api-1.0.1.jar ma questo non si trova nella cartella lib del plugin e dovete scaricarlo dalla rete (vedete qui). C’è poi un pacchetto che manca proprio e che è backport-util-concurrent-3.1.jar (lo trovate nella cartella /lib di Axis2) che dovete aggiungere nella cartella lib e nel file plugin.xml (in pratica tutto cio’ serve per risolvere l’eccezione java.lang.reflect.invocationTargetException che si manifesta all’ultimo passaggio del wizard).

Nel caso in futuro avete degli errori lanciate Eclipse in debug mode da console in questa maniera:

eclipse -clean -debug

L’opzione debug vi permette di vedere eventuali errori da console, clean pulisce una cache che Eclipse usa quando crea i vostri progetti (per altri parametri vedere qui). Se ancora avete problemi come ultima speranza rimuovete il plugin che vi da fastidio dalla cartella nascosta .metadata/.plugins che si trova nel vostro workspace.

Non fate partire ancora Eclipse perchè voglio segnalarvi un altro plugin che vi permette di lanciare/fermare Tomcat da Eclipse questo plugin lo trovate qui ed è semplice da installare come spiega il sito (in pratica va poi messo nella cartella dropins di Eclipse e occorre configurare il plugin indicando il path di tomcat).

Ok ora siete pronti per lanciare Eclipse, dovrete creare un progetto java e seguire questa guida suddivisa in 2 parti che vi spiega per filo e per segno tutto.

Durante la guida vi ritrovete a creare il codice java per lo stub dal file wsdl, il wizard vi chiede l’inclusione delle librerie del codegen ma questa non va e perciò dovrete farlo a mano agggiungendole direttamente nel vostro Build Path prendendole dalla cartella lib del plugin Codegen. Attenzione potrebbe essere un problema del Mac, ho notato che in debug mode, al momento della creazione del codice eclipse pensa di trovare il plugin nella cartella /eclipse/Contents/MacOS/plugins e non, come dovrebbe essere, in /eclipse/plugins, perciò se siete sotto Mac copiate i 2 plugin anche in quella cartella (da creare) e cosi al momento della generazione pesca correttemente i jar file della cartella lib.

Se non vedete il codige generato provate a fare un refresh del progetto. Volevo farvi notare che quando il wsdl viene caricato il plugin carica anche gli XML schema collegati (se ve ne sono) e quindi fa un controllo sulla validità, potete notare il caricamento se usate Eclipse in debug mode; tra l’altro una volta che avete creato il file wsdl potete validarlo selezionandolo e cliccando sulla voce di validazione dal menu contestuale aperto con il tasto destro del mouse.

Quando vi viene chiesto di compilare fatelo usando il file build.xml (tasto destro ed “esegui” dal menu contestuale) che viene automaticamente generato e conosce tutte le dipendenze.

Quando eseguirete il client avrete una eccezione riguardo il file jar woden API che è mancante questo perchè con Axis 2 1.4 questo package è richiesto; prendetelo dalla cartella lib di Axis2 e aggiungetelo al vostro build path. Ho semplicemente aggiunto solo il jar delle woden API.

Non vi preoccupate del warning su log4j è perchè non trova il suo file di configurazione.

Quando andate a generare lo skeleton che dovete riempire fate caso al fatto che i parametri in ingresso del metodo terminano con un numero.

Notate anche che quando generate lo stub questo ha come sottoclassi le richieste e le risposte mentre quando generate lo skeleton queste sono messe nei rispettivi file.

Nella parte 2 del tutorial vi verrà chiesto di usare il file services.xml che è stato generato nella cartella resources, ebbene in teoria dovreste poterlo selezionare in pratica dovrete inserire il suo path a mano.

Tra l’altro vi faccio notare che, sempre nella parte 2, il file wsdl viene generato nuovamente nella cartella resources, il file è pressocchè identico a quello di partenza anche se è questo che viene usato per la generazione del servizio con il Service Archiver.

Nella parte 2 vi viene chiesto di inserire la parte del client ebbene inserite il codice usato nella parte 1 e non quello proposto.

Se siete arrivati fino alla fine del tutorial complimenti! La strada per connettere e dare più funzionalità ai web services è lunga ma ora avete la basi per poterne creare.

Aggiornamento 1

Se avete avuto occasione di creare da zero wsdl, avete visto la comoda possibilità di includere XML schema dentro in modo da separare la descrizione del servizio dai tipi usati nei messaggi.

In questo ambito ho scoperto che il plugin Service Archiver ha un bug, semplicemente non include l’XML schema usato dal file WSDL dentro l’archivio aar creato e dovete purtroppo farlo a mano, a meno che c’è qualcuno che vuole modificare il codice (dovrebbe essere semplice ma non ho voglia, considerate che c’è la libreria WSDL4J che puo’ aiutarvi). Per modificarlo spacchettare il file aar (una volta rinominato in zip), aggiungete il file e rimpacchettate.

Aggiornamento 2 (uso di Xmlbeans su Eclipse 3.2, Tomcat 6 e Axis2 1.3, da verificare con Axis2 1.4)

Se durante la creazione del web service avete usato Xmlbeans come data binding ovete prestare attenzione a 2 cose in caso di errore:

-) La cartella resources contiene una cartella generata da Xmlbeans che si chiama schemaorg_apache_xmlbeans. Questa cartella contiene la cartella system la quale a sua volta contiene delle cartelle indicate da una combinazione di numeri. In una di queste si deve trovare il file TypeSystemHolder.class, questo file potrebbe esservi richiesto quando lanciate il client. Dovete quindi aggiungere la cartella resources come Class Folder tra le librerie del progetto e non come src folder.

-) In fase di creazione del web service con il Service Archiver Wizard potreste aver bisogno di aggiungere tra le librerie esterne quelle di di Xmlbeans ovvero il file Xbeans-packaged.jar che si trova nella cartella build/lib.

Alla prossima

P.S. Ho usato la java virtual machine 1.5.0_13