Apache ServiceMix
Francesco D’Addio
Danilo Ricci
Obiettivo della tesina
• Studiare e fornire una panoramica sugli
Enterprise Service Bus
• In particolare studiare dettagliatamente
ServiceMix
• Fornire esempi pratici sull’impiego di
ServiceMix:
– come Web Service
– come ESB
Cos’è un Enterprise Service Bus
• Può esser definito come un middleware in
grado di integrare varie tecnologie, al fine
di creare servizi ampiamente disponibili
per il riuso.
Enterprise Service Bus
• I servizi chiave forniti da un ESB
includono:
1. Protocolli di trasporto per i servizi
2. Definizione e scoperta dei servizi deployati
3. Gestione ed instradamento dei messaggi
Enterprise Service Bus (2)
ESB supporta:
• l’eterogeneità dei messaggi, intesa sia in termini
di molteplicità di modelli (sincroni, asincroni,
publish e subscribe), sia in termini di molteplicità
di formati(SOAP, XML).
• molteplici protocolli di trasporto per
l’instradamento (FTP, HTTP, JMS).
• scoperta dei servizi, memorizzando informazioni
su di essi (schemi,WSDLs e politiche).
• una gestione centralizzata e un accesso
distribuito ai servizi.
Enterprise Service Bus (3)
Si fa spesso riferimento ai requisiti minimi di un ESB,
come sistema di consegna di messaggi.
L’acronimo TRANS definisce un ESB come un’entità
software in grado di:
• Transforms:
trasformare i messaggi da un formato
ad un altro.
• Routes:
inoltrare i messaggi ai servizi registrati,
garantendo quality-of-service.
• Augments:
arricchire il contenuto del messaggio
con informazioni riguardanti il
richiedente.
• Notifies:
notificare ai listeners registrati.
• Secures:
assicurare la consegna del messaggio.
Apache ServiceMix
• Rilasciato sotto licenza Apache, è un
Enterprise Service Bus (Open Source)
• Combina le funzionalità di Service
Oriented Architecture e Event Driven
Architecture.
• La sua realizzazione si basa sulle
semantiche e le APIs della specifica JBI
(Java Business Integration) JSR-208.
Obiettivi Apache ServiceMix
• Permettere a componenti e servizi di essere integrati in
maniera indipendente.
• Garantire il disaccoppiamento dei servizi, agendo da
mediatore tra essi.
• Consentire agli utenti la possibilità di plug and play.
• Fornire un ambiente di esecuzione per il deploy e
l’attivazione dei servizi, associati a tools di progetto in
grado di definirne le interazioni.
• Fornire un’infrastruttura software che permette l’impiego
di architetture SOA (Service-Oriented Architecture).
Ambiente senza ServiceMix
Ambiente con ServiceMix
Java Business Integration
L’aspetto chiave delle architetture JBI è il
disaccoppiamento dei servizi, cosicché, la
business logic non risulta essere caricata dai
dettagli dell’infrastruttura, richiesti per
l’invocazione ed il consumo dei servizi. Ciò
garantisce un’architettura flessibile ed
estensibile.
All’interno di JBI, sia i Binding Components che i
Service Engine Components, possono
assumere il ruolo di fornitori di servizi e/o
consumatori di servizi.
Ambiente JBI
Componenti JBI: BC e SE
JBI definisce il contatto fra un ESB ed i componenti che
l'ESB gestisce. In JBI esistono due tipi di componenti:
• Binding Component (BC):
sono essenzialmente adattatori di protocollo
(consentono di agganciare il bus JBI a fonti di dati/servizi
esterni come ad esempio database, web services,
servizi CORBA ecc…)
• Service Engine (SE):
sono componenti interni al bus che implementano una
logica applicativa (consentono di applicare delle logiche
applicative ai messaggi che fluiscono nel bus, ad
esempio logiche di routing, logiche di trasformazione o
logiche di processo)
Componente JBI: NMR
Uno dei componenti chiave utilizzati
nell’architettura JBI è il Normalized Message
Router (NMR).
Il NMR effettua il routing dei messaggi dai BC
verso i SE nelle comunicazioni inbound e dai SE
verso i BC nelle comunicazioni outbound.
I servizi presentano delle interfacce, che
costituiscono un insieme di operazioni; ciascuna
operazione è composta da zero o più messaggi.
Normalized Message
JBI utilizza un formato normalizzato per la rappresentazione dei messaggi all’interno
dell’ambiente di sviluppo.
Un messaggio normalizzato è costituito dalle seguenti parti:
•
Proprietà del messaggio:
costituiscono i dati extra associati al messaggio.
Possono contenere informazioni sulla sicurezza,
informazioni su specifici componenti, etc.
•
Carico del messaggio:
racchiuso in un documento XML.
•
Allegati del messaggio
JBI: Service Invocations
La specifica JBI definisce la chiamata a servizio come istanza di un interazione tra un service
consumer e un service provider.
Quattro metodi di chiamate a servizio, chiamati Service Invocation, sono richiesti da qualsiasi
implementazione JBI.
Questi metodi sono definiti dal Message Exchange Pattern (MEP) e sono:
•
In-Only:
Il consumatore invia una richiesta al fornitore senza nessuna gestione dei fault
•
Reliable In-Only:
Il consumatore invia una richiesta al fornitore del servizio.
Il provider può rispondere con un errore se non riesce a elaborare la richiesta.
•
In-Out:
Il consumatore invia una richiesta al fornitore, con aspettative di risposta.
Provider può rispondere con un errore se non riesce a elaborare la richiesta.
•
In Optional-Out:
Il consumatore invia una richiesta al fornitore, che può tradursi in una risposta.
Sia il consumatore che il fornitore hanno la possibilità di generare un errore in risposta a un
messaggio ricevuto durante l'interazione.
Java Business Integration
Ambiente ServiceMix
ServiceMix
• Il progetto combina, efficacemente, le caratteristiche di
SOA ed EDA per lo sviluppo ed il deploy di applicazioni
aziendali integrate. In particolare, supporta l’architettura
guidata dagli eventi, per gli eventi che si verificano sia
all’interno, che all’esterno del bus.
• I servizi sono disaccoppiati e si mettono in ascolto, sul
bus, delle richieste di servizio.
• Il bus è responsabile delle caratteristiche di Quality of
Service (QoS), quali persistenza del messaggio,
garanzia di consegna, gestione dei fallimenti, etc.
Funzionamento di ServiceMix
•
ServiceMix mette a disposizione 2 tipi di componenti:
–
–
Le Service Unit (SU)
Le Service Assembly (SA)
•
Le SU si dividono (concettualmente) tra BC e SE.
Sono i componenti che si interfacciano col NMR e le
vere unità funzionali. ServiceMix mette a disposizione
dei componenti standard per semplificare lo sviluppo
delle applicazioni
•
Le SA hanno il semplice ruolo di accorpare tutte le SU
di un progetto per permettere il suo deploy
ServiceMix e WebService
•
ServiceMix può avere 2 diversi tipi di
rapporto con i Web Service:
I. Come semplice Gateway
II. Come Web Service vero e proprio
I. ServiceMix come Gateway
Axis
ServiceMix
Http
HTTP
endPoint
Client
HTTP
endPoint
Normalized Message Router
Firewall
Internet
Firewall
Client
Http
WEB Service
SOAP Binding
Servizio
Web Services
Web Server
Gateway
II. ServiceMix come WebService
ServiceMix
Client
HTTP-SOAP
BC
SE
Normalized Message Router
II. ServiceMix come WebService(2)
• Per utilizzare ServiceMix come Web Service basta farlo
interfacciare con il mondo esterno attraverso un BC
compatibile con il protocollo http-soap
• Quindi una volta che arriveranno dal mondo esterno
delle invocazioni a servizio queste verranno prima
normalizzate dal BC e poi attraverso l’ NMR saranno
inviate al servizio appropriato.
• Il servizio sarà costituito da uno o più SE che
processeranno la chiamata e la spediranno indietro sul
NMR una volta finita la computazione.
II. ServiceMix come WebService(3)
• Per l’interfacciamento http-soap ServiceMix
mette a disposizione due tipi di BC:
Servicemix-http e Servicemix-cxf-bc
• Come SE sono particolarmente adatti:
Servicemix-jsr181 e Servicemix-cxf-se
ma in realtà il servizio potrebbe essere
implementato da ogni tipo di SE.
Scelte progettuali
• Abbiamo scelto di approfondire e fare un
esempio pratico su come trasformare
ServiceMix in un Web Service.
• Infatti utilizzare ServiceMix come semplice
gateway non sfrutta a pieno tutte le potenzialità
della piattaforma.
• I componenti di ServiceMix che utilizzeremo per
il nostro esempio sono:
– Servicemix-cxf-bc
– Servicemix-cxf-se
ESEMPIO
Ricerca Libri WebService
Specifica
• Il client invierà al Web Service una richiesta per
scoprire quali operazioni possono essere
effettuate
• Il Web Service offrirà al client la possibilità di
effettuare le ricerche dei libri in due modalità,
attraverso:
– L’ autore
– Il titolo
• Quindi il client sceglierà uno dei 2 metodi messi
a sua disposizione e invierà la richiesta
• Infine il Web Service si connetterà al database
(nel nostro caso un file .txt) e restituirà al client il
risultato
Diagramma degli stati
Richiesta
operazioni
Cerca autore
Richiesta
operazioni
S0
S1
Risposta
Cerca titolo
S2
Creazione del Maven Project
• ServiceMix mette a disposizione diversi Maven
archetypes per aiutare a creare il progetto in
modo più rapido
• Ci sarà una cartella del progetto che conterrà
tutte le sottocartelle per ogni SU – SA
• Questo comando genererà la cartella projectroot chiamata “wsdl-cxf-service” contenente il
pom.xml del progetto
mvn archetype:create
-DarchetypeGroupId=org.apache.servicemix.tooling
-DarchetypeArtifactId=servicemix-project-root
Il tipo di archetype
-DgroupId=progetto.tesina
Il package del progetto
-DartifactId=wsdl-cxf-service
Il nome del componente
Creazione del CXF-BC
• Noi ora utilizzeremo l’archetipo
servicemix-cxf-bc-service-unit per creare
la SU servicemix-cxf-bc del progetto, con il
seguente comando:
mvn archetype:create
-DarchetypeGroupId=org.apache.servicemix.tooling
-DarchetypeArtifactId=servicemix-cxf-bc-service-unit
-DgroupId=progetto.tesina
-DartifactId=cxf-bc-su
Creazione del CXF-BC (2)
• COSA E’ STATO CREATO???
• Prima di tutto è stata creata la directory cxf-bcsu contenente:
– Un file pom.xml file per la compilazione dell’ SU del
progetto
– Una directory src/main/resources con all’ interno:
• un file xbean.xml per la configurazione della SU
• un file service.wsdl per la descrizione del nostro servizio
• Inoltre Maven nel file pom.xml nella cartella
principale del progetto ha aggiunto il modulo:
<module>cxf-bc-su</module>
Configurazione CXF-BC
• I file generati automaticamente dovranno essere
modificati per ottenere l’implementazione
desiderata.
• Per brevità mostriamo direttamente i file
modificati:
– File pom.xml
– File Service.Wsdl
– File xbean.xml
• Di seguito discuteremo delle parti più
significative di ognuno.
service.wsdl
…
<wsdl:service name="LibriService">
Definizione del servizio
<wsdl:port binding="tns:LibriSOAPBinding" name="soap">
<soap:address location="http://localhost:8080/LibriService/" /> e dell’indirizzo su cui
</wsdl:port>
è in attesa
</wsdl:service>
…
<wsdl:binding name="LibriSOAPBinding" type="tns:Libri">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="CercaAutore">
<wsdl:input>
<soap:body use="literal" />
Definizione di input,
</wsdl:input>
output e fault in
<wsdl:output>
<soap:body use="literal" />
CercaAutore
</wsdl:output>
<wsdl:fault name="UnknownWord">
<soap:fault use="literal" name="UnknownWord" />
</wsdl:fault>
</wsdl:operation>
…
</wsdl:binding>
…
service.wsdl (2)
Definizione
…
<wsdl:portType name="Libri">
dell’operazione
<wsdl:operation name="CercaAutore">
CercaAutore
<wsdl:input message="tns:CercaAutoreRequest"/>
<wsdl:output message="tns:CercaAutoreResponse"/>
<wsdl:fault name="UnknownWord“ message="tns:UnknownWordFault"/>
</wsdl:operation>
…
…
<wsdl:message name="CercaAutoreRequest">
<wsdl:part name="payload" element="typens:CercaAutore"/>
</wsdl:message>
<wsdl:message name="CercaAutoreResponse">
<wsdl:part name="payload" element="typens:CercaAutoreResponse"/>
</wsdl:message>
<wsdl:message name="UnknownWordFault">
<wsdl:part name="payload" element="typens:UnknownWordFault"/>
</wsdl:message>
…
Definizione
dei messaggi
service.wsdl (3)
...
<xsd:element name="CercaAutore">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CercaAutoreResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="UnknownWordFault">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="word" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
…
Definizione di tipi complessi
utilizzati nell’operazione
CercaAutore
xbean.xml
<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0"
xmlns:libri="http://progetto/tesina">
<cxfbc:consumer
wsdl="classpath:service.wsdl"
targetService="libri:LibriService"
targetInterface="libri:Libri"/>
</beans>
Riferimento al
servizio
Riferimento
all’interfaccia
implementata
Riferimento al
wsdl del servizio
Creazione del CXF-SE
• Ora invece per creare la SU servicemix-cxf-se
useremo l’archetipo servicemix-cxf-se-serviceunit, con il seguente comando:
mvn archetype:create
-DarchetypeGroupId=org.apache.servicemix.tooling
-DarchetypeArtifactId=servicemix-cxf-se-service-unit
-DgroupId=progetto.tesina
-DartifactId=cxf-se-su
Creazione del CXF-SE (2)
• COSA E’ STATO CREATO???
• Prima di tutto è stata creata la directory cxf-se-su
contenente:
– Un file pom.xml file per la compilazione dell’ SU del progetto
– Una directory src/main/resources con un file xbean.xml per la
configurazione della SU
– Una directory src/main/java contenente il file .java
/progetto/tesina/ExampleService.java per l’implementazione del
nostro servizio
• Inoltre Maven nel file pom.xml nella cartella principale
del progetto ha aggiunto il modulo:
<module>cxf-se-su</module>
Configurazione CXF-SE
• Nel pom.xml aggiungiamo il plugin “org.apache.cxf”:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf-version}</version>
<executions>
<execution>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${basedir}/target/jaxws</sourceRoot>
Indica dove si trova la wsdl
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/service.wsdl</wsdl>
<extraargs>
<extraarg>-verbose</extraarg>
</extraargs>
</wsdlOption>
Il comando da utilizzare per la trasformazione
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
Configurazione CXF-SE(2)
• Il precedente plugin serve a generare in
automatico i java classes dal file WSDL.
• Quindi il prossimo passo è copiare il file WSDL,
che abbiamo modificato nel cxf-bc-su, nel cxfse-su in modo da poter generare i java classes
da questo.
• Copiamo quindi il file service.wsdl:
– Dalla directory cxf-bc-su/src/main/resources
– Alla directory cxf-se-su/src/main/resources
Configurazione CXF-SE(3)
• Ora dobbiamo configurare questa SU per farle
realmente implementare il WebService.
• Nel file xbean.xml che è stato generato
automaticamente bisogna settare un
collegamento con la classe java che svolgerà il
servizio:
<cxfse:endpoint>
<cxfse:pojo>
<bean class="progetto.tesina.LibriImpl" />
</cxfse:pojo>
</cxfse:endpoint>
Definisce il percorso
in cui si trova il file java
che implementa il servizio
LibriImpl.java
Il file LibriImpl.java dovrà realizzare il servizio; in particolare dovrà:
• Far parte del package del servizio:
– package progetto.tesina;
• Importare i tipi definiti nella wsdl:
–
–
–
–
–
–
import progetto.tesina.types.CercaAutore;
import progetto.tesina.types.CercaAutoreResponse;
import progetto.tesina.types.CercaTitolo;
import progetto.tesina.types.CercaTitoloResponse;
import progetto.tesina.types.RichiestaOperazioni;
import progetto.tesina.types.RichiestaOperazioniResponse;
• Fare riferimento al servizio di apparteneza e implementare
l’interfaccia definita nella wsdl:
– @WebService(serviceName = "LibriService", targetNamespace =
"http://progetto/tesina", endpointInterface = "progetto.tesina.Libri")
– public class LibriImpl implements Libri {
• Definire le 3 operazioni:
– public void cercaAutore(Holder<String> name) throws UnknownWordFault
– public void cercaTitolo(Holder<String> name) throws UnknownWordFault
– public void richiestaOperazioni(Holder<String> name) throws UnknownWordFault
Creazione del Service Assembly (SA)
• Ora creiamo la SA con il seguente comando:
mvn archetype:create
-DarchetypeGroupId=org.apache.servicemix.tooling
-DarchetypeArtifactId=servicemix-service-assembly
-DgroupId=progetto.tesina
-DartifactId=cxf-sa
• Cosa è stato Creato?
• E stata creata la cartella cxf-sa con al suo
interno un file pom.xml
• Inoltre Maven nel file pom.xml nella cartella
principale del progetto ha aggiunto il modulo:
<module>cxf-sa</module>
Configurazione CXF-SA
• Ora dobbiamo aggiungere le Service Units che abbiamo creato al
Service Assembly
• Maven farà questo automaticamente dopo che avremo aggiunto le
corrette dipendenze nel file pom.xml della SA.
• Useremo il groupId, l’ artifactId e la version che troviamo nel
pom.xml della SA
<dependencies>
…
<dependency>
<groupId>progetto.tesina</groupId>
<artifactId>cxf-se-su</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>progetto.tesina</groupId>
<artifactId>cxf-bc-su</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
…
</dependencies>
I riferimenti alle 2 SU
che fanno parte del
progetto
Compilazione e deploy
• Finalmente dopo aver creato e configurato le
nostre SU e aver creato la SA e aggiunto a
questa le dipendenze con le SU, siamo pronti
per la compilazione del progetto.
• Per compilare il nostro progetto basta eseguire il
comando:
mvn install
• Questo comando creerà nella directory della SA
un file jar che servira’ per mettere in deploy
l’applicazione
ESEMPIO
Ricerca Libri JMS-ESB
Presentazione
In questo esempio implementeremo la
ricerca libri gestendo le richieste tramite
JMS.
L’obiettivo sarà mettere in evidenza il ruolo
dell’NMR nella comunicazione tra i vari
componenti dell’applicazione.
Architettura del progetto
ServiceMix
Client
JMS
BC
SE
SE
SE
myJmsSu
myStaticRoutinSlip
myS1Pojo
myS2Pojo
Normalized Message Router
Componenti
• Una JMS Service Unit (SU) che si comporta come un Binding
Component (BC), mettendosi in attesa di un messaggio su una
coda. Inoltre si occupa della traduzione necessaria per spedire il
messaggio nel Normalize Message Router(NMR); per far questo
useremo il componente servicemix-jms.
• Una Static Routing Slip SU che controlla il flusso dei nostri
messaggi nel NMR; per fare questo useremo il Service Engine(SE)
servicemix-eip.
• Una SU per ciascuno dei nostri due servizi S1 e S2. Per questi
servizi noi useremo una semplice implementazione POJO.
– S1 è il servizio vero e proprio; infatti fornirà i metodi cercaAutore
cercaTitolo e richiestaOperazioni.
– S2 è un servizio banale che aggiungerà solo un tag all’output del
servizio S1.
Abbiamo deciso di creare questo servizio per mostrare come funziona il
routing dei messaggi attraverso l’ NMR.
• Infine ci sarà una Service Assembly (SA) che metterà insieme tutte
queste SU in una sola unità che andrà in deploy.
Scambio di messaggi
•
•
•
Un client manda un messaggio su una coda JMS e aspetta la risposta su una coda
JMS temporanea.
Il messaggio viene smistato al Service1 (S1) che svolge alcune operazioni. L’output
di S1 viene inviato al Service2 (S2) che a sua volta esegue altre operazioni.
Infine l’output di S2 viene restituito al sistema esterno tramite la coda temporanea.
Client
myJmsSu
myStaticRoutingSlip
myS1Pojo
myS2Pojo
Creazione del Progetto
• ServiceMix è fornito con alcune Maven archetypes che
costruiscono automaticamente la struttura dei
componenti di cui si ha bisogno nei vari progetti.
• Creiamo una directory che conterrà il progetto: per
comodità la chiameremo “Project_Home”.
package
delJMS SU
Il nome
del
Il tipo
di archetype
• Abbiamo
bisogno
di creareIlla
nostra
usando
progetto
componente
l’archetypedidiMaven
Maven che fornisce
il BC JMS
servicemix-jms:
Project_Home> smx-arch su jms-consumer "-DgroupId=progetto.tesina2" "-DartifactId=myJmsSu"
• Ora creiamo la nostra Static Routing Slip SU; per fare
questo usiamo l’archetype di Maven che fornisce il SE
servicemix-eip:
Project_Home> smx-arch su eip "-DgroupId=progetto.tesina2" "-DartifactId=myStaticRoutingSlip"
Creazione del Progetto (2)
• Ora creiamo una SU per ciascun servizio POJO
usando l’archetype di Maven per il SE
servicemix-bean:
Project_Home> smx-arch su bean "-DgroupId=progetto.tesina2" "-DartifactId=myS1Pojo"
Project_Home> smx-arch su bean "-DgroupId=progetto.tesina2" "-DartifactId=myS2Pojo"
• Ora dobbiamo inglobare tutte queste SU in una
SA che potrà essere messa in deploy. Per
creare la SA usiamo il comando:
Project_Home> smx-arch sa "-DgroupId=progetto.tesina2" "-DartifactId=mySa"
Creazione del Progetto (3)
• Dopo l’esecuzione dei precedenti comandi vengono
create delle cartelle che raggruppano tutti i file di ogni
SU/SA.
• Per configurare il comportamento dei nostri componenti
JBI affinché svolgano le loro funzionalità effettive
occorrerà modificare il file xbean.xml che si trova nella
directory /src/main/resources di ogni nostra SU.
• Il file pom.xml serve per la compilazione dell’ SU del
progetto
• Per fare il deploy occorrerà impacchettare tutte le SU
dentro la SA. Per fare questo occorre modificare il file
pom.xml che si trova nella directory principale della SA.
MyJMSQueueTest
• Questo è il punto di accesso e di uscita del
nostro progetto. Vengono ricevuti dei messaggi
e, eventualmente, rispediti indietro.
• Implementeremo il JMS request/response
tramite code temporanee.
• Il servizio MyJMSQueueTest è inglobato in un
BC SU (MyJmsSu).
• Il file xbean.xml generato automaticamente
(nella directory myJmsSu/src/main/resource) va
modificato così:
xbean.xml
MyJMSQueueTest (2)
• Riportiamo il codice del file xbean.xml dopo la modifica:
<?xml version="1.0" encoding="UTF-8"?>
Indica il componente
<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
a cui va passato
xmlns:test="http://test"
xmlns:amq="http://activemq.org/config/1.0">
l’output
<jms:endpoint service="test:MyJmsQueueTest"
endpoint="jmsQueue"
targetService="test:MyStaticRoutingSlipService"
La politica di scambio
targetEndpoint="myStaticRoutingSlipSu"
dei messaggi utilizzata
role="consumer"
destinationStyle="queue"
jmsProviderDestinationName="myJmsQueueTest"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
connectionFactory="#connectionFactory"></jms:endpoint>
<amq:connectionFactory id="connectionFactory" brokerURL="tcp://localhost:61616" />
</beans>
MyStaticRoutingSlipService
• La situazione che abbiamo è di un client che mette un messaggio in
una coda e la BC SU MyJmsQueueTest lo estrae e lo smista verso
la prima SE SU, ovvero MyStaticRoutingSlipService
• Questo servizio si occupa di smistare il messaggio al primo servizio,
aspettare la risposta e quindi girarla ai servizi successivi. La sua
configurazione viene definita in:
myStaticRoutingSlip/src/main/resources/xbean.xml
• Riportiamo il codice da sostituire nel file xbean.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:eip="http://servicemix.apache.org/eip/1.0"
xmlns:test="http://test">
<eip:static-routing-slip service="test:MyStaticRoutingSlipService" endpoint="myStaticRoutingSlipSu">
<eip:targets>
<eip:exchange-target service="test:MyS1PojoService" endpoint="myS1PojoSu"/>
<eip:exchange-target service="test:MyS2PojoService" endpoint="myS2PojoSu"/>
</eip:targets>
</eip:static-routing-slip>
</beans>
Indica l’ordine in cui vanno chiamati le
varie SU residenti sull’NMR
MySnPojoService
• Ora bisogna definire una SE SU per ciascun servizio a cui verranno
smistati i messaggi.
MyS1Pojo svolgerà effettivamente il servizio, mentre MyS2Pojo
aggiungerà solo un tag per testimoniare di aver processato il
messaggio.
• Per configurare i servizi va modificato il file
mySnPojo/src/main/resources/xbean.xml, in questo modo (la n
dovrà essere sostituita, per ogni servizio, con il rispettivo numero “1”
o “2”):
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:bean="http://servicemix.apache.org/bean/1.0"
xmlns:test="http://test">
<bean:endpoint service="test:MySnPojoService" endpoint="mySnPojoSu" bean="#myBean"/>
<bean id="myBean" class="progetto.tesina2.MyBean"/>
</beans>
Fa riferimento alla posizione in cui si
trova il file con l’implementazione
Metodo onMessageExchange
Svolge il servizio restituendo l’output,
che verrà inserito nel messaggio normalizzato.
public void onMessageExchange(MessageExchange exchange) throws
MessagingException {
if (exchange.getStatus() == ExchangeStatus.ACTIVE) {
InOut inOut = (InOut)exchange;
NormalizedMessage normalizedMessage =inOut.getInMessage();
String outMessage =processa(normalizedMessage);
I nostri
POJO verranno chiamati due volte: StringSource(outMessage));
normalizedMessage.setContent(new
La prima
quando viene invocato il servizioinOut);
MessageUtil.transferInToOut(inOut,
(con lo stato ACTIVE)
channel.send(inOut);
La }seconda al termine di tutta la computazione
(con lo stato DONE)
}
Trasforma il messaggio
Noi vogliamo modificare il messaggio
in un messaggio in uscita
solo quando lo stato è ACTIVE.
e infine lo spedisce indietro
Build e deploy
• Il file pom.xml della SA va modificato aggiungendo le
dipendenze a tutte le SU del progetto.
• Ora siamo pronti per il build delle nostre SU
• Da linea di comando entrare nella directory principale di
ogni SU (myJmsSu, myStaticRoutingSlip, myS1Pojo,
myS2Pojo) ed eseguire il comando: mvn install
• Infine possiamo fare il build della nostra SA accedendo
nella direcotory principale della SA ed eseguendo il
comando: mvn install
• Quest’ultimo comando genererà il file jar che servirà per
il deploy del progetto
Conclusioni
• Nonostante un alto costo iniziale dovuto alla
scarsa documentazione e alla sua complessità,
una volta acquisita dimestichezza offre un
grande supporto per lo sviluppo di applicazioni.
• Abbiamo visto che ServiceMix è una tecnologia
particolarmente versatile, può essere utilizzata
semplicemente come ESB sia per simulare altre
teconologie (nel nostro caso abbiamo
approfondito l’utilizzo come Web Service)