Archivi tag: spring

RestTemplate – Gestire contenuto Multipart-mixed

25/05/2022 admin

In questi giorni mi sono trovato a dover gestire il contenuto di servizio rest che a seguito di una chiamata GET restituiva un content di tipo multipart-mixed. Nel progetto precedente usavo jersey che gestiva in mod del tutto trasparente questo tipo di chiamata, in questo progetto avevo una dipendenza da Spring ed ero vincolato ad usare la classe RestTemplate, peccato che per questa template la lettura di questo tipo di contenuto non fosse così agevole.

Per risolvere ho letto la risposta come byte[] e poi ho usato la classe org.apache.commons.fileupload.MultipartStream presente nel in Commons FileUpload per leggere il contenuto da un byte[], scartare gli header e leggere solo il file di mio interesse

RestTemplate restTemplate = new RestTemplate();
byte[] bytes = restTemplate.getForObject(fileUlr, byte[].class);
String txt = new String(bytes);
String boundary = StringUtils.substringBefore(txt, "\r\n").substring(2);
MultipartStream multipartStream = new MultipartStream(new ByteArrayInputStream(bytes), 
		boundary.getBytes(), 1024, null);
boolean nextPart = multipartStream.skipPreamble();
while (nextPart) {
     	multipartStream.readHeaders();
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        multipartStream.readBodyData(bos);
        return bos.toByteArray();
}
return bytes;

RestTemplate restTemplate = new RestTemplate();

byte[] bytes = restTemplate.getForObject(fileUlr, byte[].class);

String txt = new String(bytes);

String boundary = StringUtils.substringBefore(txt, "\r\n").substring(2);

MultipartStream multipartStream = new MultipartStream(new ByteArrayInputStream(bytes),

boundary.getBytes(), 1024, null);

boolean nextPart = multipartStream.skipPreamble();

while (nextPart) {

multipartStream.readHeaders();

ByteArrayOutputStream bos = new ByteArrayOutputStream();

multipartStream.readBodyData(bos);

return bos.toByteArray();

}

return bytes;

JHIPSTER

TUTORIAL JHIPSTER – PRIMI PASSI

23/02/2018 admin

Durante la fase di scouting per valutare nuovi framework e nuove librerie mi sono imbattuto in JHIPSTER. Si tratta di una piattaforma di sviluppo che consente di generare una applicazione con quello che gli autori reputano il meglio che il panorama offre. Nel momento in cui scrivo la versione è la 4.14.0, che permette di realizzare una webapp basata su Spring Boot 1.5 e Angular 5, mentre la versione 5, già annunciata, promette il passaggio a Spring Boot 2 e l’introduzione di React per il client e la rimozione di Angular JS. JHIPSTER ha vinto il Duke’s Choice Award 2017 e si è classificato terzo al JAX Innovation award nella categoria maggior innovazione per l’ecosistema JAVA.

Avvicinarsi a JHIPSTER ci da il vantaggio di vedere concentrato il top delle tecnologie a disposizione del mondo JAVA e ci da l’opportunità di assemblarle riducendo al minimo i tempi di creazione della applicazione. Partiamo subito e tiriamo su il nostro primo progetto. Per usare JHIPSTER abbiamo sei approcci possibili:

JHipster Online è un tool online che ti guida nella creazione dell’app, va bene come prova ma allo stato attuale non consente di gestire modifiche successive
“Locale con YARN” è la modalità suggerita dagli autori. Si basa su YARN , che è il package manager sviluppato da facebook basato su NPM.
“Locale con NPM” è identica alla precedente, ma usa NPM il package manager di Node.js.
“Installazione tramite package manager” è ancora in beta
“Box Vagrant” è disponibile una macchina virtuale che contiene tutti gli strumenti necessari.
“Docker” è disponibile un container docker contenente gli strumenti necessari

Usiamo la modalità consigliata e seguiamo i seguenti passi:

Installiamo Java 8
Installiamo Node.js
Installiamo Yarn
installiamo Yeoman tramite il comando: yarn global add yo. Yeoman è un tool che consente di creare la struttura base di una app.
installiamo JHipster tramite il comando: yarn global add generator-jhipster

Seguendo questi step siamo in grado di creare la nostra app con front-end Angular, qualora volessimo usare AngularJS dobbiamo aggiungere altri due step:

Installare Bower: yarn global add bower. Bower è un package manager rimasto in maintenance, ormai sostituito da YARN e WEBPACK.
Installare Gulp: yarn global add gulp-cli. Gulp è un task manager.

A questo punto non resta che creare la nostra prima applicazione. Creiamo una directory e al suo interno lanciamo il comando: jhipster

E qui inizia il bello. Jhipster ci interroga sulle caratteristiche che vogliamo e il gioco è fatto, alla fine abbiamo una applicazione correttamente funzionante, da poter importare nel nostro editor preferito.

Per vederla funzionante lanciate il comando mvnw, che tirerà su il progetto su porta 8080.

SPRING WS

SPRING WS – TUTORIAL 10 – USARE LA VERSIONE 2.0

19/06/2014 admin

La versione 2.0 di Spring-ws introduce la dipendenza da Spring 3.0 e spinge verso l’uso delle annotation, lasciando il supporto deprecato delle classi che abbiamo imparato a conoscere nei precedenti articoli-

In questo articolo vedremo le nuove feature introdotte da Spring-ws.

Partiamo dalla creazione del progetto, che si avvale dei nuovi archetipi rilasciati da spring-ws e vediamo come creare il solito webservice per la libreria.

mvn archetype:create 
-DarchetypeGroupId=org.springframework.ws 
-DarchetypeArtifactId=spring-ws-archetype 
-DarchetypeVersion=2.0.2.RELEASE 
-DgroupId=it.finazzo 
-DartifactId=libreriaservice

mvn archetype:create

-DarchetypeGroupId=org.springframework.ws

-DarchetypeArtifactId=spring-ws-archetype

-DarchetypeVersion=2.0.2.RELEASE

-DgroupId=it.finazzo

-DartifactId=libreriaservice

Con la direttiva indicata Spring-ws crea la directory libreriaservice

Spostiamoci all’interno della cartella e creaiamo la struttura per il nostro IDE tramite la direttiva mvn eclipse:eclipse. A questo punto possiamo importare il progetto in Eclipse. Come si può notare nel file xml associato al dispatchet spring-servlet.xml è stata esplicitata la dipendenza dalle annotation, tramite il tag <sws:annotation-driven/>

Recuperiamo lo schema xsd che abbiamo creato nei precedenti articoli e lo copiamo sotto la cartella resources.

Definiamo il bean che si occupa della generazione del wsdl tramite il seguente tag

<sws:dynamic-wsdl 
id="libreria" 
portTypeName="Libreria" 
locationUri="http://localhost:8080/libreria/webservices" > 
<sws:xsd 
location="classpath:schema.xsd"/> 
</sws:dynamic-wsdl>

<sws:dynamic-wsdl

id="libreria"

portTypeName="Libreria"

locationUri="http://localhost:8080/libreria/webservices" >

<sws:xsd

location="classpath:schema.xsd"/>

</sws:dynamic-wsdl>

A questo punto definiamo l’endpoint che si preoccupa di gestire il servizio di Ricerca Libro. Nella definizione degli endpoint si cambia approccio, mentre prima il mapping veniva gestito tramite file xml, adesso tutto è demandato alle annotation:

l’annotazione @Endpoint definisce che una classe è un endpoint

l’annotazione @Autowired definisce il costruttore della costruttore qualora sia necessario fare l’injection di alcuni parametri

l’annotazione @PayloadRoot(localPart = “RicercaLibroRequest”, namespace = “http://finazzo.it/libreria/schema”) definisce la regola di mapping dell’endpoint

Una volta definiti gli endpoint passiamo alla definizione del mapping degli endpoint, tramite la classe PayloadRootAnnotationMethodEndpointMapping

<bean id="payloadMapping" 
class="org.springframework.ws.server.endpoint.
mapping.PayloadRootAnnotationMethodEndpointMapping"/>

<bean id="payloadMapping"

class="org.springframework.ws.server.endpoint.

mapping.PayloadRootAnnotationMethodEndpointMapping"/>

Questa è la classe responsabile di instradare i messaggi verso l’opportuno endpoint in base all’analisi del messaggi soap ricevuti e le regole definite di attivazione definite tramite annotation.

Qui trovate l’archetipo estratto dal progetto appena descritto, in modo da poter provare di persona quanto fatto.

SPRING WS

SPRING WS – TUTORIAL 9 – GESTIONE CLIENT

19/06/2014 admin

Nell’articolo di oggi vedremo le API che Spring-Ws mette a disposizione per la realizzazione di un client.
Alla base di tutto vi è la classe WebServiceTemplate che offre i metodi per l’invio e la ricezione dei messagi.I messaggi possono essere inviati e ricevuti come puro stream oppure possono essere soggetti al processo di marshalling e unmarshalling.

Occorre prima di tutto definire il nostro client nei file di configurazione di Spring, tramite la solita definizione di bean.

<bean id="client" 
class="org.springframework.ws.client.core.WebServiceTemplate">
<property name="defaultUri" 
value="http://example.com/WebService" />
<property name="messageFactory" ref="messageFactory" />
</bean>

<bean id="client"

class="org.springframework.ws.client.core.WebServiceTemplate">

<property name="defaultUri"

value="http://example.com/WebService" />

</bean>

La property defautUrl indica la URL dei servizi da invocare, mentre la messageFactory individua la classe responsabile della generazione dei messaggi da inviare.

Come factory Spring mette a disposizione 2 implementazioni:

SaajSoapMessageFactory basata su SAAJ
AxiomSoapMessageFactory basata su Axiom

In assenza del valore Spring userà di default l’implementazione basata su SAAJ.

Nei file xml di Spring-Ws setteremo la factory desiderata come

<bean id="messageFactory" 
class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory" /> 
<bean id="messageFactory" 
class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory" />

<bean id="messageFactory"

class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory" />

<bean id="messageFactory"

class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory" />

A questo possiamo sfruttare il nostro client per invocare il servizio e gestirne il risultato.

StreamSource source = new StreamSource(new StringReader(MESSAGE));
StreamResult result = new StreamResult(System.out);
client.sendSourceAndReceiveToResult(source, result);

StreamSource source = new StreamSource(new StringReader(MESSAGE));

StreamResult result = new StreamResult(System.out);

client.sendSourceAndReceiveToResult(source, result);

In source è disponibile il messaggio nel formato atteso dal servizio remoto e nella System.out verrà riversato la risposta del server.

Invocazione coclusa con minimo sforzo. A questo punto andrebbe analizzata la risposta per gestire le nuove azioni da intraprendere.

Come ulteriore aiuto Spring-Ws ci da la possibilità di sfruttare le tecniche di marshalling e unmarshalling per ottenere degli oggetti già pronti per l’uso.

Per fare cià occorre valorizzare il marshaller e l’unmarshallere all’interno del nostro client.

&lt;bean id="client" 
class="org.springframework.ws.client.core.WebServiceTemplate"&gt;
&lt;property name="defaultUri" value="http://example.com/WebService" /&gt;
&lt;property name="messageFactory" ref="messageFactory" /&gt;
&lt;property name="marshaller" ref="Marshaller" /&gt;
&lt;property name="unmarshaller" ref="Marshaller" /&gt;
&lt;/bean&gt;

<bean id="client"

class="org.springframework.ws.client.core.WebServiceTemplate">

</bean>

Per la defizione del marshaller si rimanda all’articolo dedicato.

Definito il marshaller e l’unmarshaller verrà usato il seguente metodo che restituisce un oggetto valorizzato

Object response = client.marshalSendAndReceive(requestPayload);

1	Object response = client.marshalSendAndReceive(requestPayload);

dove requestPayload è il bean che descrive la richiesta del sistema opportunamente valorizzata.

Nel caso in cui dobbiate gestire gli header SOAP dovete definire una classe che implementi l’interfacciaWebServiceMessageCallback.

Tale interfaccia definisce il metodo public void doWithMessage(WebServiceMessage message) che consente di modificare il messaggio prima del suo invio al server.

In questo caso invocherete il metodo

client.marshalSendAndReceive(requestPayload, new WebServiceMessageCallback() {
public void doWithMessage(WebServiceMessage message) {
((SoapMessage)message).setSoapAction("action");
}
});

client.marshalSendAndReceive(requestPayload, new WebServiceMessageCallback() {

public void doWithMessage(WebServiceMessage message) {

((SoapMessage)message).setSoapAction("action");

}

});

SPRING WS

SPRING WS – TUTORIAL 8 – AUTENTICAZIONE

19/06/2014 admin

Una volta creati i nostri servizi ci preoccuperemo di applicare delle policy di sicurezza al fine impedirne l’utilizzo a utenti non autorizzati

Le policy di sicurezza si basano su 3 aspetti:

l’autenticazione
la firma
la crittografia

Implementando meccanismi di autenticazione si limita l’accesso ad utenti conosciuti dal sistema, con l’utilizzo della firma si certifica un contenuto e con la crittografia si trasforma il flusso di dati in un flusso impossibile da leggere senza l’opportuna chiave.

Nell’articolo di oggi vedremo gli strumenti che offre Spring-ws per gestire l’autenticazione.

Spring-ws mette a disposizione 2 implementazioni dell’interfaccia Interceptor:

XwsSecurityInterceptor basato sull’implementazione della SUN XWSS Xml and Web Service Security
Wss4jSecurityInterceptor basato sull’implementazione di Apache WSS4J

Per iniziare vedremo il caso di autenticazione più semplice, ovvero quello che prevede di inviare come header della soap un tag chiamato UsernameToken che prevede 2 attributi in chiaro contenenti username e password.

E’ un meccanismo molto semplice da usare che va abbinato ad altre tecniche come la crittografia, visto che l’invio in chiaro dei dati di accesso non è cosa bella.

Scegliamo di usare l’implementazione XwsSecurityInterceptor, che prevede la definizione di un file contenente le policy di sicurezza.

All’interno del file definiamo la regola di sicurezza

<xwss:SecurityConfiguration dumpMessages="false" 
xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">
<xwss:RequireUsernameToken  
passwordDigestRequired="false" nonceRequired="false"/>
</xwss:SecurityConfiguration>

<xwss:SecurityConfiguration dumpMessages="false"

xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">

<xwss:RequireUsernameToken

passwordDigestRequired="false" nonceRequired="false"/>

</xwss:SecurityConfiguration>

Stiamo dicendo al nostro modulo che ogni richiesta per essere accettata deve contenere il token UsernameToken, che la password non deve essere crittografata e che non è richiesto il nonce. Per maggiori dettagli sugli attributi del token Username rimando alle specifiche di SUN. Per informazioni sul Nonce ripassate concetti di crittografia.

A questo punto definiamo l’interceptor e le sue regole

<bean id="wsSecurityInterceptor"
class="org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor">
<property name="policyConfiguration" value="classpath:securityPolicy.xml"/>
<property name="callbackHandlers">
<list>
<ref bean="passwordValidationHandler"/>
</list>
</property>
</bean>
<bean id="passwordValidationHandler"
 class="org.springframework.ws.soap.security.xwss.
callback.SimplePasswordValidationCallbackHandler">
 <property name="users">
 <props>
 <prop key="Valerio">Finazzo</prop>
 </props>
 </property>
</bean>

<bean id="wsSecurityInterceptor"

class="org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor">

<list>

</list>

</property>

</bean>

<bean id="passwordValidationHandler"

class="org.springframework.ws.soap.security.xwss.

callback.SimplePasswordValidationCallbackHandler">

<props>

<prop key="Valerio">Finazzo</prop>

</props>

</property>

</bean>

Il nostro interceptor carica le regole da applicare dal file di policy definito precedentemente, mentre con il bean passwordValidationHandler definiamo gli utenti che possono accedere ai nostri servizi, in questo caso username/password Valerio/Finazzo

Qualora nella nostra richiesta non sia presente il token usernameToken il server genera un FAULT specificando l’errore.

Per testare quanto fatto consiglio SoapUi con cui potete creare agevolmente le request e aggiungere gli header per la sicurezza, ottenendo qualcosa del genere

<soapenv:Envelope 
xmlns:sch="http://www.example.org/schema" 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header><wsse:Security 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-14" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>Valerio</wsse:Username>
<wsse:Password 
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
Finazzo</wsse:Password>
</wsse:UsernameToken></wsse:Security>
</soapenv:Header>
<soapenv:Body>
<sch:RicercaLibroRequest>
<!--Optional:-->
<sch:titolo>?</sch:titolo>
<!--Optional:-->
<sch:nome>?</sch:nome>
<!--Optional:-->
<sch:cognome>?</sch:cognome>
</sch:RicercaLibroRequest>
</soapenv:Body>
</soapenv:Envelope>

<soapenv:Envelope

xmlns:sch="http://www.example.org/schema"

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header><wsse:Security

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<wsse:UsernameToken wsu:Id="UsernameToken-14"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<wsse:Username>Valerio</wsse:Username>

<wsse:Password

Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">

Finazzo</wsse:Password>

</wsse:UsernameToken></wsse:Security>

</soapenv:Header>

<soapenv:Body>

<sch:RicercaLibroRequest>

<sch:titolo>?</sch:titolo>

<sch:nome>?</sch:nome>

<sch:cognome>?</sch:cognome>

</sch:RicercaLibroRequest>

</soapenv:Body>

</soapenv:Envelope>

Nel prossimo articolo vedremo tecniche più avanzate per gestire l’autenticazione.

SPRING WS

SPRING WS – TUTORIAL 7 – GESTIRE LE ECCEZIONI

18/06/2014 admin

In questo articolo vedremo la gestione delle eccezioni e i meccanismi che Spring-ws offre per la loro gestione.

Spring mette a disposizione un gestore delle eccezioni che carica la mappa delle eccezioni e crea opportunamente i fault in corrispondenza di ogni eccezioni.

<bean id="exceptionResolver" 
class="org.springframework.ws.soap.server.endpoint.SoapFaultMappingExceptionResolver">    
<property name="defaultFault" value="SERVER"/>
<property name="exceptionMappings">
<value>it.finazzo.libreria.exception.LibroException=SERVER,Invalid request</value>
</property>
</bean>

<bean id="exceptionResolver"

class="org.springframework.ws.soap.server.endpoint.SoapFaultMappingExceptionResolver">

<value>it.finazzo.libreria.exception.LibroException=SERVER,Invalid request</value>

</property>

</bean>

Nel nostro esempio stiamo dicendo al gestore delle eccezioni che in corrispondenza di una eccezione LibroException deve essere creato un fault con i parametri indicati, come quello mostrato sotto.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring xml:lang="en">Invalid request</faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header/>

<SOAP-ENV:Body>

<SOAP-ENV:Fault>

<faultcode>SOAP-ENV:Server</faultcode>

<faultstring xml:lang="en">Invalid request</faultstring>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Per chi usale annotazioni e non vuole file xml con lunghe configurazione Spring mette a disposizione la annotazione @SoapFault. Una volta definita una eccezione è possibile definire il fault da lanciare e i parametri con cui configurarla

Possiamo ottenere un fault analogo a quello descritto sopra definendo così la nostra eccezione

<span style="color: #0d293f;">@SoapFault(faultCode = FaultCode.SERVER, faultStringOrReason="<span style="color: #000000;">Invalid request</span>")
</span>public class LibroException extends Exception

1 2	<span style="color: #0d293f;">@SoapFault(faultCode = FaultCode.SERVER, faultStringOrReason="<span style="color: #000000;">Invalid request</span>") </span>public class LibroException extends Exception

e aggiungendo tra i bean di Spring l’opportuna implementazione

<bean id="exceptionAnnotationResolver" 
class="org.springframework.ws.soap.server.endpoint.SoapFaultAnnotationExceptionResolver" />

1 2	<bean id="exceptionAnnotationResolver" class="org.springframework.ws.soap.server.endpoint.SoapFaultAnnotationExceptionResolver" />

Per chi ha creato il progetto tramite Maven ricordarsi di aggiungere la dipendenza dalle librerie di spring-ws che supportano le feature della jdk 1.5.

SPRING WS

SPRING WS – TUTORIAL 6 – USARE GLI INTERCEPTOR

18/06/2014 admin

In questo articolo vedremo come poter intercettare le richieste di servizio per effettuare le operazioni prima e dopo l’esecuzione dell’endpoint.

Fondamentale l’interceptor ci permette di:

loggare le richieste e le risposte inviate
applicare dei meccanismi di sicurezza alle richieste pervenute
gestire i fault di sistema

Per definire un interceptor occorre implementare l’interfaccia EndpointInterceptot che presenta i seguenti metodi:

handleRequest
handleResponse
handleFault

Il metodo handleRequest viene invocato prima dell’esecuzione dell’endpoint e il suo utilizzo principale è quello di bloccare l’esecuzione di un servizio.

Il metodo handleResponse viene invocato dopo l’esecuzione dell’endpoint e il sul utilizzo principale è quello di elaborare la risposta, magari aggiungendo attributi.

Il metodo handleFault viene invocato dopo l’esecuzione di un fault con finalità analoghe a quelle del metodo handleResponse.

Per chi non avesse particolari esigenze Spring offre già alcune implementazioni di interceptor:

PayloadLoggingInterceptor
PayloadValidatingInterceptor
PayloadTransformingInterceptor

Il PayloadLoggingInterceptor permette di loggare le richieste e le risposte.

Il PayloadValidatingInterceptor valida le richieste e le risposte in base ad uno schema xsd indicato nelle sue properties.

Il PayloadTransformingInterceptor effettua una transformazione delle richieste e delle risposte basate su XSLT. Viene usato quando il server gestisce più versioni dello stesso servizio.

Nel nostro progetto applichiamo un logger delle richieste e delle risposte e un validatore, ottenendo una configurazione di questo tipo.

<bean 
class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
<property name="mappings">
        <props>
            <prop key="{http://www.example.org/schema}RicercaLibroRequest">ricercaLibroEndpoint</prop>
        </props>
    </property>
    <property name="interceptors">
	    <list>
              <ref bean="loggingInterceptor"/>
              <ref bean="validatingInterceptor"/>
          </list>
        </property>
    </bean>
<bean id="loggingInterceptor"  
      class="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor"/>

<bean id="validatingInterceptor" 
      class="org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor">
    <property name="schema" value="classpath:schema.xsd"/>
    <property name="validateRequest" value="true"/>
    <property name="validateResponse" value="true"/>
</bean>

<bean

class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">

<props>

<prop key="{http://www.example.org/schema}RicercaLibroRequest">ricercaLibroEndpoint</prop>

</props>

</property>

<list>

</list>

</property>

</bean>

<bean id="loggingInterceptor"

class="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor"/>

<bean id="validatingInterceptor"

class="org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor">

</bean>

SPRING WS

SPRING WS – TUTORIAL 5 – USARE IL MARSHALLING

18/06/2014 admin

In questo articolo vedremo le tecniche di marshalling che mette a disposizione Spring-ws per la gestione dei messaggi di richiesta e risposta dei web services.

Tutte le implementazione degli endpoint fornite dal framework prevedono 2 proprietà:

marshaller
unmarshaller

Il marshaller è responsabile di serializzare l’oggetto in un frammento xml, mentre l’unmarsheller effettua l’operazione contraria.

Sono previste più implementazioni dei marsheller, pertanto lo sviluppatore può scegliere con libertà l’implementazione più conveniente. Personalmente utilizzo jaxb2 che è disponibile a partire da java 6 con la virtual machine.

Per le altre implementazioni JAXB1, Castor, XMLBEANS rimando alla javadoc disponibile su spring-ws.

Definiamo il bean che descrive il marshaller e lo settiamo come attributo dell’endpoint

<bean id="jaxb2Marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
       <property name="contextPath" value="it.finazzo.libreria.schema"/>
       <property name="schema" value="classpath:schema.xsd"/>
</bean>
<bean id="ricercaLibroEndpoint" class="it.finazzo.libreria.ws.RicercaLibroEndpoint">
      <property name="marshaller" ref="jaxb2Marshaller"></property>
      <property name="unmarshaller" ref="jaxb2Marshaller"></property>
</bean>

</bean>

</bean>

La property schema del marshaller serve per la validazione della richiesta, mentre nella property contextPath specifichiamo il package dove sono disponibili le classi per il marshalling. Tali classi possono essere generate in automatico tramite un plugin disponibile per Maven. Per sfruttare questo plugin occorre inserire questo frammento nel pom.xml

<plugin>
       <groupId>com.sun.tools.xjc.maven2</groupId>
       <artifactId>maven-jaxb-plugin</artifactId>
       <executions>
             <execution>
                 <phase>generate-sources</phase>
                  <goals>
                      <goal>generate</goal>
                  </goals>
             </execution>
       </executions>
       <configuration>
            <generatePackage>it.finazzo.libreria.schema</generatePackage>
       </configuration>
</plugin>

<groupId>com.sun.tools.xjc.maven2</groupId>

<artifactId>maven-jaxb-plugin</artifactId>

<phase>generate-sources</phase>

<goals>

<goal>generate</goal>

</goals>

</execution>

</executions>

<generatePackage>it.finazzo.libreria.schema</generatePackage>

</configuration>

</plugin>

e definire le resources

<resource> 
<directory>src/main/resources</directory> 
<filtering>true</filtering>
</resource>

<directory>src/main/resources</directory>

</resource>

Tale plugin analizza i file xsd disponibili nella directory resource e genera le classi nel package configurato.

Infine occorre cambiare l’implementazione dell’endpoint estendendo la classe di spring-ws che supporta il marshalling:

public class RicercaLibroEndpoint extends AbstractMarshallingPayloadEndpoint {
protected Object invokeInternal(Object arg0) throws Exception {
return new RicercaLibroResponse();
}
}

public class RicercaLibroEndpoint extends AbstractMarshallingPayloadEndpoint {

protected Object invokeInternal(Object arg0) throws Exception {

return new RicercaLibroResponse();

}

A questo punto mvn install e proviamo il frutto delle nostre fatiche.

SPRING WS

SPRING WS – TUTORIAL 4 – MAPPING DEI SERVIZI

18/06/2014 admin

Nell’articolo di oggi vedremo come mappare i servizi e gestire la loro implementazione.

Occorre prima di tutto scegliere la tecnica di gestione per i messaggi xml. Possiamo usare delle librerie di gestione di messaggi xml come JDOM o SAX oppure delle tecniche di marshalling per la trasformazione di flussi xml in classi java e viceversa, come JAXB e XMLBEANS.

Spring-ws supporta tutte le principali librerie per la gestione dei file xml pertanto la scelta della libreria deve essere fatta valutando anche l’ambiente a disposizione.

In questo caso ho scelto JDOM, una libreria opensource che semplifica la gestione di DOM. Occorre modificare il file pom.xml per introdurre le dipendenza dalla libreria JDOM. Nel nostro caso si traduce in questo set di dipendenze:

<dependency>
<groupId>jdom</groupId>
<artifactId>jdom</artifactId>	
<version>1.0</version>	
</dependency>	    
<dependency>	        
<groupId>jaxen</groupId>	        
<artifactId>jaxen</artifactId>	        
<version>1.1</version>	    
</dependency>	    
<dependency>	        
<groupId>javax.xml.soap</groupId>	        
<artifactId>saaj-api</artifactId>	        
<version>1.3</version>	        
<scope>runtime</scope>	    
</dependency>	    
<dependency>	        
<groupId>com.sun.xml.messaging.saaj</groupId>	        
<artifactId>saaj-impl</artifactId>	        
<version>1.3</version>	        
<scope>runtime</scope>	    
</dependency>

</dependency>

<groupId>jaxen</groupId>

<artifactId>jaxen</artifactId>

</dependency>

<groupId>javax.xml.soap</groupId>

<scope>runtime</scope>

</dependency>

<groupId>com.sun.xml.messaging.saaj</groupId>

<scope>runtime</scope>

</dependency>

All’interno del file spring-ws-servlet.xml definiamo il bean che implementa il servizio di RicercaLibro.

<bean id="ricercaLibroEndpoint" class="it.finazzo.libreria.ws.RicercaLibroEndpoint"/>

1	<bean id="ricercaLibroEndpoint" class="it.finazzo.libreria.ws.RicercaLibroEndpoint"/>

Tale classe estende la classe di Spring che gestisce l’integrazione con JDOM

public class RicercaLibroEndpoint extends AbstractJDomPayloadEndpoint {
	protected Element invokeInternal(Element arg0) throws Exception {		return null;
	}
}

public class RicercaLibroEndpoint extends AbstractJDomPayloadEndpoint {

protected Element invokeInternal(Element arg0) throws Exception { return null;

}

Definiti il bean ci preoccupiamo di definire il mapping dei servizi, ovvero quale classe invocare in corrispondenza di uno specifico servizio:

<bean 
class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
<property name="mappings">
<props>
<prop key="{http://www.example.org/schema}RicercaLibroRequest">
ricercaLibroEndpoint
</prop>
</props>
</property>
</bean>

<bean

class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">

<props>

ricercaLibroEndpoint

</prop>

</props>

</property>

</bean>

In questo caso stiamo dicendo al gestore delle mappe dei servizi, la classe implementata da Spring-Ws, che il servizio RicercaLibro deve invocare l’endpoint ricercaLibroEndpoint. Per la gestione del mapping spring-ws offre 2 diverse implementazione da scegliere in base al contesto in cui vi trovate.

PayloadRootQNameEndpointMapping
SoapActionEndpointMapping

Il mapping basato su Payload prevede l’analisi della richiesta per stabilire quale servizio stiamo invocando. Tale meccanismo è più lento ma è indipendente dalla specifica SOA e pertanto può essere usato sia in caso di SOA 1.1, 1.2 o qualsiasi altro livello di trasporto.

Il secondo mapping sfrutta l’header SOAPAction, che permette di individuare il corretto routing senza analizzare tutta la risposta. Pertanto è più veloce ma è valido solo con la SOA 1.1, poichè nella SOA 1.2 tale parametro è stato reso deprecato.

A questo punto non resta che provare il nostro servizio tramite Soap Ui e verificare il corretto funzionamento del routing.

SPRING WS

SPRING WS – TUTORIAL 3 – CREARE IL PROGETTO

18/06/2014 admin

Dopo aver definito il contratto passiamo all’implementazione del nostro server con servizi SOA. Per fare ciò usiamo Maven, che permette di automatizzare parte dei processi nella gestione del nostro sistema

Per chi non conoscesse Maven rimando alla serie di articoli pubblicati nella sezione Documentazione.

Apriamo una shell nella directory che ospita il nostro workspace e lanciamo il seguente comando

mvn archetype:generate 
-DarchetypeGroupId=org.springframework.ws 
-DarchetypeArtifactId=spring-ws-archetype 
-DarchetypeVersion=1.5.9 
-DgroupId=it.finazzo.libreria 
-DartifactId=libreria

mvn archetype:generate

-DarchetypeGroupId=org.springframework.ws

-DarchetypeArtifactId=spring-ws-archetype

-DarchetypeVersion=1.5.9

-DgroupId=it.finazzo.libreria

-DartifactId=libreria

con questo comando stiamo dicendo a maven di creare un nuovo artefatto basato sull’archetipo di spring-ws versione 1.5.9.

A questo punto Maven ha creato una directory con l’alberatura tipica di una web application e i file xml configurati per la sua gestione.

Per semplificare i prossimi step possiamo importare il progetto tramite la direttiva eclipse:eclipse di maven. Troviamo 2 file xml pronti per essere modificati, il classico web.xml dove è definita la servlet preposta a ricevere i messaggi e il file spring-ws-servlet.xml dove definiremo le varie componenti del nostro server.

Nella directory WEB-INF inseriamo il file xsd contenente la struttura dei nostri servizi e nel file spring-ws-servlet.xml definiamo un bean che possa gestirlo.

&lt;bean id="gestioneLibri" 
class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition"&gt;
&lt;property name="schema" ref="schema"/&gt;                                               
&lt;property name="portTypeName" value="Libreria"/&gt;                           
&lt;property name="locationUri" value="/gestioneLibri/webservices"/&gt;                      
&lt;/bean&gt;
&lt;bean id="schema" class="org.springframework.xml.xsd.SimpleXsdSchema"&gt;
&lt;property name="xsd" value="/WEB-INF/schema.xsd"/&gt;
&lt;/bean&gt;

<bean id="gestioneLibri"

class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">

</bean>

</bean>

Il bean ‘schema’ mappa il file xsd tramite una classe implementata da Spring e il bean ‘gestioneLibri’ si preoccupa di generare il file wsdl a partire dall’analisi dello schema xsd e dalle proprietà definite, secondo quanto indicato nel precedente articolo.

A questo punto tramite la direttiva install creiamo il file war e facciamo il deploy della nostra applicazione su tomcat.

Una volta attivato il contesto il file wsdl sarà disponibile all’indirizzo http://<server>:<port>/<context>/gestioneLibri.wsdl.

Nel prossimo articolo vedremo come gestire le chiamate ai servizi esposti.

www.valeriofinazzo.it

Archivi tag: spring

RestTemplate – Gestire contenuto Multipart-mixed

TUTORIAL JHIPSTER – PRIMI PASSI

SPRING WS – TUTORIAL 10 – USARE LA VERSIONE 2.0

SPRING WS – TUTORIAL 9 – GESTIONE CLIENT

SPRING WS – TUTORIAL 8 – AUTENTICAZIONE

SPRING WS – TUTORIAL 7 – GESTIRE LE ECCEZIONI

SPRING WS – TUTORIAL 6 – USARE GLI INTERCEPTOR

SPRING WS – TUTORIAL 5 – USARE IL MARSHALLING

SPRING WS – TUTORIAL 4 – MAPPING DEI SERVIZI

SPRING WS – TUTORIAL 3 – CREARE IL PROGETTO

Il sito dell'ingegnere Valerio Finazzo