Spring WS Sviluppare WebService in Java

Transcript

1 Spring WS Sviluppare WebService in Java 1.1 Introduzione Nell ambito della programmazione Java è particolarmente utile avere una certa familiarità con i WebService e la tecnologia che li supporta. In particolare negli ultimi anni questa tecnologia si è diffusa notevolmente in virtù della facilità di sviluppo e di condivisione di piattaforme. Tuttavia è necessario chiarire cosa è un servizio Web: un web service è un applicazione disponibile sul web che si rende disponibile agli utenti attraverso una comoda interfaccia denominata WSDL. Questa interfaccia è utile in quanto numerosi ambienti di programmazione permettono di leggerne il contenuto e di creare le apposite classi per gestire le chiamate al servizio stesso. 1.2 Sviluppo Software Sviluppare un WebService è particolarmente semplice se si sfruttano le funzionalità si SpringWS. In particolare in questa guida tenterò di rispondere ad alcune delle domande + diffuse in merito alla creazione di un web service. Inoltre verrà allegato un progetto d esempio utile per esercitarsi e capire appieno le potenzialità di Spring. Sulla base di queste considerazioni consideriamo i seguenti punti: 1) Scaricare le librerie necessarie al funzionamento di SpringWS: aspectjweaver.jar commons-codec-1.3.jar commons-dbcp jar commons-httpclient-3.1.jar commons-logging jar commons-pool.jar ibatis jar jdom-1.0.jar jaxen-1.1-beta-5.jar saaj-api.jar saaj-impl.jar spring jar spring-core jar spring-ws all.jar wsdl4j jar che sono liberamente condivise sul web (docjar.com, jarfinder.com) 2) Definire gli oggetti che dovranno essere scambiati attraverso il servizio e realizzare lo schema xsd corrispondente. 3) Importare il progetto in Eclipse/NetBeans quindi a partire dallo schema xsd creare le classi di binding attraverso JAXB (in alternativa sul web è disponibile un tool da linea di comando) 4) Sviluppare le classi di Endpoint e Service 5) Definire il web.xml

2 6) Definire il file di configurazione di SpringWS 1.3 Definizione del Xsd Schema La definizione di uno schema Xsd è piuttosto semplice perché riguarda sostanzialmente gli elementi che devono essere scambiati e come questi vengano incapsulati nella chiamata e nella risposta. Supponiano che si voglia inviare una banale stringa che debba poi essere stampata in output. La definizione dell elemento è la seguente: - <element name="salutorichiesta" type="string"/> - <element name="salutorisposta" type="string"/> Tuttavia questo non basta!!! Per far funzionare il servizio è necessario incapsulare la stringa all interno di un oggetto che per consuetudine dovrà avere (per i due casi) la seguente nomenclatura: - ServiceRequest - ServiceResponse L xsd completo è il seguente: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" elementformdefault="qualified"> <!-- REQUEST --> <element name="servicerequest"> <complextype> <all> <element name="salutorichiesta" type="string"/> </all> </complextype> </element> <!-- RESPONSE --> <element name="serviceresponse"> <complextype> <all> <element name="salutorisposta" type="string"/> </all> </complextype> </element> </schema> Notiamo in particolare la presenza del tag ComplexType che definisce un oggetto che contiene all interno un secondo oggetto di tipo stringa. Il targetnamespace ed il tns presenti nell intestazione dello schema devono inoltre essere modificati perché determineranno la posizione delle classi di binding nel progetto (definiscono il package) mentre i nomi utilizzati per gli elementi saranno invece i nomi della classi di binding.

3 Dopo aver completato l editing dello schema xsd, possiamo passare all operazione di binding delle classi sfruttando l opzione Generate presente in Eclipse e scegliendo come metodologia per il binding JAXB. Il risultato è il seguente: Come possiamo vedere è presente una classe di tipo ObjectFactory che contiene una serie di metodi per la creazione di oggetti di tipo ServiceRequest e ServiceResponse. La letteratura informatica raccomanda in generale di creare gli oggetti associati agli elementi del xsd attraverso l utilizzo della classe ObjectFactory. 1.4 Classi Endpoint e Service In questa sezione definiremo le classi necessarie all implementazione del servizio vero e proprio. La classe di Endpoint specifica appunto l endpoint del servizio (dove questo è collocato) e come utilizzare il servizio per effettuare la chiamata (quale metodo del servizio deve essere utilizzato). La classe di Service invece implementa il servizio, nel senso che qui sono previste tutte quelle funzionalità aggiuntive che debbano essere effettuate sull oggetto che riceviamo. Prima di effettuare la trattazione specifica delle classi, è doveroso fare una puntualizzazione: il servizio che andremo a sviluppare permetterà lo scambio di banali messaggi di testo ma, per effettuare tali tipi di operazioni, dovrà ricevere un oggetto di tipo JAXBElement<ServiceRequest> e rispondere con un oggetto di tipo JAXElement<ServiceResponse>. È chiaro che questa è una complicazione soprattutto, lo vedremo in seguito, in merito alla ricezione dell oggetto che ci è stato inviato ma è necessaria al fine di fornire uno strumento che si possa utilizzare in qualsiasi circostanza. Infatti inviando un oggetto piuttosto che un insieme di stringhe, valori numerici, ecc. è particolarmente + semplice da gestire e utilizzare lato back end Classe Endpoint La classe Endpoint viene creata come estensione di una classe astratta presente nel package di SpringWS e denominata AbstractMarshallingPayloadEndpoint che prevede la funzionalità di deserializzazione (unmarshalling) del payload della richiesta e la serializzazione (marshalling) della risposta. In particolare si definisce un costruttore a due argomenti (il servizio ed il marshaller) che sarà utile al momento della creazione del file di configurazione di SpringWS, e si sovrascrive un metodo contenuto appunto nella classe astratta la cui firma è public Object invokeinternal(object obj) throws Exception. Questo metodo verrà utilizzato dalla classe di Endpoint per effettuare la chiamata effettiva al servizio effettuando appunto il marshalling e l unmarshalling. Il risultato è il seguente: public Object invokeinternal(object object) throws Exception JAXBElement<ServiceRequest> request = null; if(object instanceof javax.xml.bind.jaxbelement) request = ((javax.xml.bind.jaxbelement<servicerequest>) object);

4 else request = new JAXBElement<ServiceRequest>(new QName(" ServiceRequest.class, null, (org.altervista.marcoamato.types.servicerequest)object); System.out.println(request); try JAXBElement<ServiceResponse> _return = myservice.inviosaluto(request); return _return; catch (Exception ex) ex.printstacktrace(); throw new RuntimeException(ex); Come possiamo vedere, abbiamo un ciclo if in cui verifichiamo che, la richiesta inviata sia tipo JAXBElement o tipo ServiceRequest: nel primo caso l oggetto cosi com è viene utilizzato dal metodo mentre nel secondo caso si crea l oggetto JAXBElement sfruttando il costruttore in cui passiamo il QName (classe che definisce il QualifiedName come specificato nel xsd, rappresentato dall URI dell oggetto il package se vogliamo - e dal localpart - nome dell oggetti - ), la classe dell oggetto e l oggetto ricevuto dalla richiesta. Si crea quindi la risposta sfruttando il metodo dell oggetto service a cui passiamo la richiesta di tipo JAXBElement che abbiamo appositamente creato Classe Service La classe Service è molto + semplice rispetto alla classe di Endpont in quanto prevede un unico metodo a cui possiamo dare un nome a nostra scelta ma ricordando che tale metodo deve ricevere un oggetto di tipo JAXBElement<ServiceRequest> e deve restituire un oggetto di tipo JAXBElement<ServiceResponse>. Questo è il listato del codice: public JAXBElement<ServiceResponse> inviosaluto(jaxbelement<servicerequest> request) ServiceRequest req = request.getvalue(); ServiceResponse res = new org.altervista.marcoamato.types.objectfactory().createserviceresponse(); System.out.println(req.getSalutoRichiesta()); res.setsalutorisposta(req.getsalutorichiesta()); JAXBElement<ServiceResponse> response = new JAXBElement<ServiceResponse>(new QName(" ServiceResponse.class, null, res); return response; In questo caso sostanzialmente abbiamo fatto l operazione inversa all Endpoint in quanto costruiamo un oggetto JAXBElement<ServiceResponse> attraverso l oggetto ServiceResponse di cui abbiamo settato la risposta con il metodo setsalutorisposta creato al momento del binding con JAXB.

5 1.5 Web.xml e SpringWS servlet Dopo aver dunque generato le classi necessarie per implementare il servizio, definiamo gli ultimi due componenti ovvero il web.xml ed il file di configurazione di SpringWS. Infatti nell ambito di un progetto SpringWS sfruttiamo sostanzialmente le caratteristiche di un progetto Web Java in cui è presente il web.xml: si configurerà questo file in modo che risponda ad un servlet di Spring mappata attraverso ulteriore file di configurazione. Il descrittore è dunque il seguente: <?xml version="1.0" encoding="utf-8"?> <web-app version="2.4" xmlns=" xmlns:xsi=" xsi:schemalocation=" </web-app> <display-name>myservice</display-name> <servlet> <servlet-name>spring-ws</servlet-name> <servlet-class> org.springframework.ws.transport.http.messagedispatcherservlet </servlet-class> <init-param> <param-name>transformwsdllocations</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>spring-ws</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> Il file è del tutto simile a quelli comunemente utilizzati in altre applicazioni web sebbene osserviamo la presenza della servlet di Spring ovvero la classe MessageDispatcherServlet che permette l invio e la ricezione dei messaggi attraverso servlet. D altra importante è il server-name che definirà non solo il nome della servlet ma anche il nome del file di configurazione come: spring-ws-servlet.xml. Si aggiunge dunque al nome della servlet il suffisso servlet. Il file di configurazione di SpringWS è il seguente: 01 <?xml version="1.0" encoding="utf-8"?> 02 <beans xmlns=" 03 xmlns:xsi=" 04 xmlns:p=" 05 xmlns:context=" 06 xsi:schemalocation=" <!-- bean del servizio --> 12 <bean id="myservice" 13 class="org.altervista.marcoamato.service.myservice" /> <!-- bean che contiene la lista delle classi per cui 16 é necessario effettuare SERIALIZZAZIONE E DESERIALIZZAZIONE --> 17 <bean id="marshaller" class="org.springframework.oxm.jaxb.jaxb2marshaller"> 18 <property name="classestobebound"> 19 <list> 20 <value>org.altervista.marcoamato.types.servicerequest</value> 21 <value>org.altervista.marcoamato.types.serviceresponse</value> 22 </list> 23 </property> 24 </bean> <!-- bean che gestisce l'endpoint tramite un costruttore 27 a cui passiamo il servizio come parametro -->

6 28 <bean id="myserviceendpoint" 29 class="org.altervista.marcoamato.endpoint.myserviceendpoint"> 30 <constructor-arg ref="myservice" /> 31 <constructor-arg ref="marshaller" /> 32 </bean> <!-- 35 <bean id="myserviceendpointadapter" 36 class="org.springframework.ws.server.endpoint.adapter.genericmarshallingmethodendpointadapter"> 37 <constructor-arg ref="marshaller" /> 38 </bean> --> <bean class="org.springframework.ws.server.endpoint.mapping.payloadrootqnameendpointmapping"> 41 <property name="mappings"> 42 <props> 43 <prop key=" 44 </prop> 45 </props> 46 </property> 47 </bean> <bean id="endpointmapping" class="org.springframework.ws.soap.server.endpoint.mapping.soapactionendpointmapping"> 50 <property name="mappings"> 51 <props> 52 <prop key=" 53 </props> 54 </property> 55 </bean> <bean id="exceptionresolver" 59 class="org.springframework.ws.soap.server.endpoint.soapfaultmappingexceptionresolver"> 60 <property name="defaultfault" value="server"/> 61 <property name="exceptionmappings"> 62 <value> 63 org.springframework.oxm.validationfailureexception=client,invalid request 64 </value> 65 </property> 66 </bean> <!-- bean che identifica lo schema XSD --> 70 <bean id="schema" class="org.springframework.xml.xsd.simplexsdschema"> 71 <property name="xsd" value="/web-inf/schema/service.xsd" /> 72 </bean> <!-- bean che permette di creare automaticamente il servizio attraverso 75 l'xsd definito in precedenza --> 76 <bean id="contract" 77 class="org.springframework.ws.wsdl.wsdl11.defaultwsdl11definition"> 78 <property name="schema" ref="schema" /> 79 <property name="porttypename" value="saluto" /> 80 <property name="locationuri" value="/services" /> 81 <property name="targetnamespace" value=" /> 82 </bean> </beans> Leggiamo il listato in modo che sia chiaro come sia stato editato: - Nella riga 12 abbiamo il bean del servizio definito dalla classe - Nella riga definiamo il marshaller attraverso la classe Jaxb2Marsheller per cui è presente una proprietà classestobebound esplicitando nel tag list le classi per cui dovrà essere effettuato il binding - Nella riga definiamo il bean dell endpoint il costruttore prevede due argomenti: il servizio ed il marshaller opportunamente definiti precedentemente

7 - Nella riga definiamo il mapping per l endpoint utilizzando due classi come PayloadRootQNameEndpointMapping e SoapActionEndpointMapping. All interno di ciascuno di questi bean è presente una proprietà che definisce l oggetto che ci si aspetta di ricevere come richiesta - Nella riga definiamo l ExceptionResolver così come presente nella guida di SpringWS - Nella riga 70 definiamo il bean dello schema xsd di riferimento - Nella riga definiamo il bean che ci permetterà di pubblicare il wsdl. In questo bean sono presenti alcune proprietà tra cui lo schema, il porttypename che definisce il nome logico attribuito alle operazioni definite in un wsdl, la location Uri che definisce parte della posizione del wsdl, ed il targetnamespace che definisce l indirizzo a cui fare riferimento per visualizzare il wsdl. Attraverso il targetnamespace + location Uri + beanname.wsdl è possibile risalire all indirizzo della pubblicazione del wsdl e dunque per raggiungere il WebService appena creato. Per provare il progetto basterà utilizzare SoapUi e creare un nuovo progetto allegando il wsdl. Buon Lavoro a tutti!!!