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

Client

Firew

all

Firew

all

ClientWeb Services

Gateway

Normalized Message Router

HTTPendPoint

HTTPendPoint

ServiceMixAxis

WEB ServiceSOAP Binding

Servizio

Http

Internet

Http

Web Server

II. ServiceMix come WebService

Client

Normalized Message Router

SEBC HTTP-SOAP

ServiceMix

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

S2S1

Cerca autore

Cerca titolo

Risposta

Richiestaoperazioni

S0

Richiestaoperazioni

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 project-root chiamata “wsdl-cxf-service” contenente il pom.xml del progettomvn archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeArtifactId=servicemix-project-root -DgroupId=progetto.tesina -DartifactId=wsdl-cxf-service Il package del progetto

Il nome del componente

Il tipo di archetype

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-bc-

su 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">

<wsdl:port binding="tns:LibriSOAPBinding" name="soap"> <soap:address location="http://localhost:8080/LibriService/" />

</wsdl:port></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" />

</wsdl:input><wsdl:output>

<soap:body use="literal" /></wsdl:output><wsdl:fault name="UnknownWord">

<soap:fault use="literal" name="UnknownWord" /></wsdl:fault>

</wsdl:operation>…</wsdl:binding>…

Definizione del servizio e dell’indirizzo su cui è in attesa

Definizione di input,output e fault inCercaAutore

service.wsdl (2)…<wsdl:portType name="Libri">

<wsdl:operation name="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>…

Definizionedell’operazioneCercaAutore

Definizionedei 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 complessiutilizzati 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 alwsdl del servizio

Riferimento alservizio

Riferimento all’interfacciaimplementata

Creazione del CXF-SE

• Ora invece per creare la SU servicemix-cxf-se useremo l’archetipo servicemix-cxf-se-service-unit, 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> <wsdlOptions> <wsdlOption>

<wsdl>${basedir}/src/main/resources/service.wsdl</wsdl> <extraargs>

<extraarg>-verbose</extraarg> </extraargs> </wsdlOption> </wsdlOptions> </configuration> <goals> <goal>wsdl2java</goal>

</goals> </execution> </executions> </plugin>

Indica dove si trova la wsdl

Il comando da utilizzare per la trasformazione

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 cxf-se-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 javache implementa il servizio

LibriImpl.javaIl 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 delprogetto

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

Client

Normalized Message Router

SE myStaticRoutinSlip

BCmyJmsSu

JMS

ServiceMix

SEmyS1Pojo

SEmyS2Pojo

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 myJmsSumyStaticRoutingSlipmyS1Pojo 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”.

• Abbiamo bisogno di creare la nostra JMS SU usando l’archetype di 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"

Il tipo di archetype di Maven

Il package delprogetto

Il nome delcomponente

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"?><beans xmlns:jms="http://servicemix.apache.org/jms/1.0"xmlns:test="http://test"xmlns:amq="http://activemq.org/config/1.0"><jms:endpoint service="test:MyJmsQueueTest" endpoint="jmsQueue" targetService="test:MyStaticRoutingSlipService" targetEndpoint="myStaticRoutingSlipSu" 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>

Indica il componentea cui va passato

l’output

La politica di scambio dei messaggi utilizzata

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 sitrova il file con l’implementazione

Metodo onMessageExchange

public void onMessageExchange(MessageExchange exchange) throws MessagingException {

if (exchange.getStatus() == ExchangeStatus.ACTIVE) { InOut inOut = (InOut)exchange; NormalizedMessage normalizedMessage

=inOut.getInMessage(); String outMessage =processa(normalizedMessage); normalizedMessage.setContent(new StringSource(outMessage)); MessageUtil.transferInToOut(inOut, inOut); channel.send(inOut);

}}

I nostri POJO verranno chiamati due volte:La prima quando viene invocato il servizio

(con lo stato ACTIVE)La seconda al termine di tutta la computazione

(con lo stato DONE)Noi vogliamo modificare il messaggio

solo quando lo stato è ACTIVE.

Svolge il servizio restituendo l’output,che verrà inserito nel messaggio normalizzato.

Trasforma il messaggioin un messaggio in uscita

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)