Apache ServiceMix

1
Apache ServiceMix

• Francesco DAddio
• Danilo Ricci

2
Obiettivo della tesina

• Studiare e fornire una panoramica sugli
  Enterprise Service Bus
• In particolare studiare dettagliatamente
  ServiceMix
• Fornire esempi pratici sullimpiego di
  ServiceMix
• come Web Service
• come ESB

3
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.

4
Enterprise Service Bus

• I servizi chiave forniti da un ESB includono
• Protocolli di trasporto per i servizi
• Definizione e scoperta dei servizi deployati
• Gestione ed instradamento dei messaggi

5
Enterprise Service Bus (2)

• ESB supporta
• leterogeneità 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
  linstradamento (FTP, HTTP, JMS).
• scoperta dei servizi, memorizzando informazioni
  su di essi (schemi,WSDLs e politiche).
• una gestione centralizzata e un accesso
  distribuito ai servizi.

6
Enterprise Service Bus (3)

• Si fa spesso riferimento ai requisiti minimi di
  un ESB, come sistema di consegna di messaggi.
• Lacronimo TRANS definisce un ESB come unentità
  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.

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

8
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
  lattivazione dei servizi, associati a tools di
  progetto in grado di definirne le interazioni.
• Fornire uninfrastruttura software che permette
  limpiego di architetture SOA (Service-Oriented
  Architecture).

9
Ambiente senza ServiceMix
10
Ambiente con ServiceMix
11
Java Business Integration

• Laspetto chiave delle architetture JBI è il
  disaccoppiamento dei servizi, cosicché, la
  business logic non risulta essere caricata dai
  dettagli dellinfrastruttura, richiesti per
  linvocazione ed il consumo dei servizi. Ciò
  garantisce unarchitettura flessibile ed
  estensibile.
• Allinterno di JBI, sia i Binding Components che
  i Service Engine Components, possono assumere il
  ruolo di fornitori di servizi e/o consumatori di
  servizi.

12
Ambiente JBI
13
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)

14
Componente JBI NMR

• Uno dei componenti chiave utilizzati
  nellarchitettura 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.

15
Normalized Message

• JBI utilizza un formato normalizzato per la
  rappresentazione dei messaggi allinterno
  dellambiente 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

16
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.

17
Java Business Integration
18
Ambiente ServiceMix
19
ServiceMix

• Il progetto combina, efficacemente, le
  caratteristiche di SOA ed EDA per lo sviluppo ed
  il deploy di applicazioni aziendali integrate. In
  particolare, supporta larchitettura guidata
  dagli eventi, per gli eventi che si verificano
  sia allinterno, che allesterno 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.

20
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

21
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

22
I. ServiceMix come Gateway
Axis
ServiceMix
HTTP endPoint
HTTP endPoint
Http
Http
Client
WEB Service SOAP Binding
Normalized Message Router
Servizio
Firewall
Firewall
Web Services Gateway
Internet
Web Server
Client
23
II. ServiceMix come WebService
ServiceMix
Client
BC
SE
HTTP-SOAP
Normalized Message Router
24
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.

25
II. ServiceMix come WebService(3)

• Per linterfacciamento 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.

26
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

27
ESEMPIO Ricerca Libri WebService
28
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

29
Diagramma degli stati
Richiesta operazioni
Cerca autore
Richiesta operazioni
S1
Risposta
S2
S0
Cerca titolo
30
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 progetto
• mvn archetypecreate
• -DarchetypeGroupIdorg.apache.servicemix.tooling
  
• -DarchetypeArtifactIdservicemix-project-root
• -DgroupIdprogetto.tesina
• -DartifactIdwsdl-cxf-service

Il tipo di archetype
Il package del progetto
Il nome del componente
31
Creazione del CXF-BC

• Noi ora utilizzeremo larchetipo
  servicemix-cxf-bc-service-unit per creare la SU
  servicemix-cxf-bc del progetto, con il seguente
  comando
• mvn archetypecreate
• -DarchetypeGroupIdorg.apache.servicemix.tooling
  
• -DarchetypeArtifactIdservicemix-cxf-bc-service-u
  nit
• -DgroupIdprogetto.tesina
• -DartifactIdcxf-bc-su

32
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
• ltmodulegtcxf-bc-sult/modulegt

33
Configurazione CXF-BC

• I file generati automaticamente dovranno essere
  modificati per ottenere limplementazione
  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.

34
service.wsdl

• ltwsdlservice name"LibriService"gt
• ltwsdlport binding"tnsLibriSOAPBinding"
  name"soap"gt
• ltsoapaddress location"http//localhost8080/Li
  briService/" /gt
• lt/wsdlportgt
• lt/wsdlservicegt
• ltwsdlbinding name"LibriSOAPBinding"
  type"tnsLibri"gt
• ltsoapbinding style"document"
  transport"http//schemas.xmlsoap.org/soap/http"
  /gt ltwsdloperation name"CercaAutore"gt
• ltwsdlinputgt
• ltsoapbody use"literal" /gt lt/wsdlinputgt
  
• ltwsdloutputgt
• ltsoapbody use"literal" /gt lt/wsdloutputgt
  
• ltwsdlfault name"UnknownWord"gt ltsoapfaul
  t use"literal" name"UnknownWord"
  /gt lt/wsdlfaultgt
• lt/wsdloperationgt
• lt/wsdlbindinggt

Definizione del servizio e dellindirizzo su cui
è in attesa
Definizione di input, output e fault
in CercaAutore
35
service.wsdl (2)
Definizione delloperazione CercaAutore

• ltwsdlportType name"Libri"gt
• ltwsdloperation name"CercaAutore"gt
• ltwsdlinput message"tnsCercaAutoreRequest"/gt
  ltwsdloutput message"tnsCercaAutoreResponse"/gt
  ltwsdlfault name"UnknownWord
  message"tnsUnknownWordFault"/gt
• lt/wsdloperationgt
• ltwsdlmessage name"CercaAutoreRequest"gt
• ltwsdlpart name"payload" element"typensCercaAu
  tore"/gt
• lt/wsdlmessagegt
• ltwsdlmessage name"CercaAutoreResponse"gt
• ltwsdlpart name"payload" element"typensCercaAu
  toreResponse"/gt
• lt/wsdlmessagegt
• ltwsdlmessage name"UnknownWordFault"gt
• ltwsdlpart name"payload" element"typensUnknown
  WordFault"/gt
• lt/wsdlmessagegt

Definizione dei messaggi
36
service.wsdl (3)

• ...
• ltxsdelement name"CercaAutore"gt
• ltxsdcomplexTypegt
• ltxsdsequencegt ltxsdelement name"name"
  type"xsdstring"/gt lt/xsdsequencegt
• lt/xsdcomplexTypegt
• lt/xsdelementgt
• ltxsdelement name"CercaAutoreResponse"gt
• ltxsdcomplexTypegt
• ltxsdsequencegt ltxsdelement name"name"
  type"xsdstring"/gt
• lt/xsdsequencegt
• lt/xsdcomplexTypegt
• lt/xsdelementgt
• ltxsdelement name"UnknownWordFault"gt
• ltxsdcomplexTypegt
• ltxsdsequencegt
• ltxsdelement name"word" type"xsdstring"/gt
  lt/xsdsequencegt
• lt/xsdcomplexTypegt
• lt/xsdelementgt

Definizione di tipi complessi utilizzati
nelloperazione CercaAutore
37
xbean.xml

• ltbeans xmlnscxfbc"http//servicemix.apache.org/c
  xfbc/1.0" xmlnslibri"http//progetto/tesi
  na"gt
• ltcxfbcconsumer wsdl"classpathservice.wsdl"
  targetService"libriLibriS
  ervice" targetInterface"
  libriLibri"/gt
• lt/beansgt

Riferimento al servizio
Riferimento al wsdl del servizio
Riferimento allinterfaccia implementata
38
Creazione del CXF-SE

• Ora invece per creare la SU servicemix-cxf-se
  useremo larchetipo servicemix-cxf-se-service-unit
  , con il seguente comando
• mvn archetypecreate
• -DarchetypeGroupIdorg.apache.servicemix.tooling
  
• -DarchetypeArtifactIdservicemix-cxf-se-service-u
  nit
• -DgroupIdprogetto.tesina
• -DartifactIdcxf-se-su

39
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
  limplementazione del nostro servizio
• Inoltre Maven nel file pom.xml nella cartella
  principale del progetto ha aggiunto il modulo
• ltmodulegtcxf-se-sult/modulegt

40
Configurazione CXF-SE

• Nel pom.xml aggiungiamo il plugin
  org.apache.cxf
• ltplugingt
• ltgroupIdgtorg.apache.cxflt/groupIdgt
• ltartifactIdgtcxf-codegen-pluginlt/artifactIdgt
• ltversiongtcxf-versionlt/versiongt
• ltexecutionsgt
• ltexecutiongt
• ltphasegtgenerate-sourceslt/phasegt
  ltconfigurationgt
  ltsourceRootgtbasedir/target/jaxwslt/sourceRootgt
  ltwsdlOptionsgt
• ltwsdlOptiongt
  ltwsdlgtbasedir/src/main/resources/service.
  wsdllt/wsdlgt
• ltextraargsgt
• ltextraarggt-verboselt/extraarggt
• lt/extraargsgt
• lt/wsdlOptiongt
• lt/wsdlOptionsgt
• lt/configurationgt
• ltgoalsgt
• ltgoalgtwsdl2javalt/goalgt
• lt/goalsgt
• lt/executiongt

Indica dove si trova la wsdl
Il comando da utilizzare per la trasformazione
41
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

42
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
• ltcxfseendpointgt
• ltcxfsepojogt
• ltbean class"progetto.tesina.LibriImpl"
  /gt lt/cxfsepojogt
• lt/cxfseendpointgt

Definisce il percorso in cui si trova il file
java che implementa il servizio
43
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.RichiestaOperazioniRe
  sponse
• Fare riferimento al servizio di apparteneza e
  implementare linterfaccia definita nella wsdl
• _at_WebService(serviceName "LibriService",
  targetNamespace "http//progetto/tesina",
  endpointInterface "progetto.tesina.Libri")
• public class LibriImpl implements Libri
• Definire le 3 operazioni
• public void cercaAutore(HolderltStringgt name)
  throws UnknownWordFault
• public void cercaTitolo(HolderltStringgt name)
  throws UnknownWordFault
• public void richiestaOperazioni(HolderltStringgt
  name) throws UnknownWordFault

44
Creazione del Service Assembly (SA)

• Ora creiamo la SA con il seguente comando
• mvn archetypecreate
• -DarchetypeGroupIdorg.apache.servicemix.tooling
  
• -DarchetypeArtifactIdservicemix-service-assembly
  
• -DgroupIdprogetto.tesina
• -DartifactIdcxf-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
• ltmodulegtcxf-salt/modulegt

45
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
• ltdependenciesgt
• ltdependencygt
• ltgroupIdgtprogetto.tesinalt/groupIdgt
• ltartifactIdgtcxf-se-sult/artifactIdgt
• ltversiongt1.0-SNAPSHOTlt/versiongt
• lt/dependencygt
• ltdependencygt
• ltgroupIdgtprogetto.tesinalt/groupIdgt
• ltartifactIdgtcxf-bc-sult/artifactIdgt
• ltversiongt1.0-SNAPSHOTlt/versiongt
• lt/dependencygt
• lt/dependenciesgt

I riferimenti alle 2 SU che fanno parte
del progetto
46
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
  lapplicazione

47
ESEMPIO Ricerca Libri JMS-ESB
48
Presentazione

• In questo esempio implementeremo la ricerca
  libri gestendo le richieste tramite JMS.
• Lobiettivo sarà mettere in evidenza il ruolo
  dellNMR nella comunicazione tra i vari
  componenti dellapplicazione.

49
Architettura del progetto
ServiceMix
Client
SE myStaticRoutinSlip
BC myJmsSu
SE myS1Pojo
SE myS2Pojo
JMS
Normalized Message Router
50
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 alloutput 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.

51
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. Loutput di S1 viene
  inviato al Service2 (S2) che a sua volta esegue
  altre operazioni.
• Infine loutput di S2 viene restituito al sistema
  esterno tramite la coda temporanea.

Client
myJmsSu
myStaticRoutingSlip
myS1Pojo
myS2Pojo
52
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
  larchetype di Maven che fornisce il BC JMS
  servicemix-jms
• Project_Homegt smx-arch su jms-consumer
  "-DgroupIdprogetto.tesina2" "-DartifactIdmyJmsSu
  "
• Ora creiamo la nostra Static Routing Slip SU per
  fare questo usiamo larchetype di Maven che
  fornisce il SE servicemix-eip
• Project_Homegt smx-arch su eip
  "-DgroupIdprogetto.tesina2" "-DartifactIdmyStati
  cRoutingSlip"

Il tipo di archetype di Maven
Il package del progetto
Il nome del componente
53
Creazione del Progetto (2)

• Ora creiamo una SU per ciascun servizio POJO
  usando larchetype di Maven per il SE
  servicemix-bean
• Project_Homegt smx-arch su bean
  "-DgroupIdprogetto.tesina2" "-DartifactIdmyS1Poj
  o"
• Project_Homegt smx-arch su bean
  "-DgroupIdprogetto.tesina2" "-DartifactIdmyS2Poj
  o"
• Ora dobbiamo inglobare tutte queste SU in una SA
  che potrà essere messa in deploy. Per creare la
  SA usiamo il comando
• Project_Homegt smx-arch sa "-DgroupIdprogetto.t
  esina2" "-DartifactIdmySa"

54
Creazione del Progetto (3)

• Dopo lesecuzione 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.

55
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

56
MyJMSQueueTest (2)

• Riportiamo il codice del file xbean.xml dopo la
  modifica
• lt?xml version"1.0" encoding"UTF-8"?gt
• ltbeans xmlnsjms"http//servicemix.apache.org/jms
  /1.0"
• xmlnstest"http//test"
• xmlnsamq"http//activemq.org/config/1.0"gt
• ltjmsendpoint service"testMyJmsQueueTest"
• endpoint"jmsQueue"
• targetService"testMyStaticRoutingSlipSer
  vice"
• targetEndpoint"myStaticRoutingSlipSu"
• role"consumer"
• destinationStyle"queue"
• jmsProviderDestinationName"myJmsQueueTest
  "
• defaultMep"http//www.w3.org/2004/08/wsdl
  /in-out"
• connectionFactory"connectionFactory"gtlt/jmsen
  dpointgt
• ltamqconnectionFactory id"connectionFactory"
  brokerURL"tcp//localhost61616" /gt
• lt/beansgt

Indica il componente a cui va passato loutput
La politica di scambio dei messaggi utilizzata
57
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
• lt?xml version"1.0" encoding"UTF-8"?gt
• ltbeans xmlnseip"http//servicemix.apache.org/eip
  /1.0"
• xmlnstest"http//test"gt
• lteipstatic-routing-slip service"testMyStaticRou
  tingSlipService" endpoint"myStaticRoutingSlipSu"gt
  
• lteiptargetsgt
• lteipexchange-target service"testMyS1PojoService
  " endpoint"myS1PojoSu"/gt
• lteipexchange-target service"testMyS2PojoService
  " endpoint"myS2PojoSu"/gt
• lt/eiptargetsgt
• lt/eipstatic-routing-slipgt
• lt/beansgt

Indica lordine in cui vanno chiamati le varie
SU residenti sullNMR
58
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)
• lt?xml version"1.0" encoding"UTF-8"?gt
• ltbeans xmlnsbean"http//servicemix.apache.org/be
  an/1.0"
• xmlnstest"http//test"gt
• ltbeanendpoint service"testMySnPojoService"
  endpoint"mySnPojoSu" bean"myBean"/gt
• ltbean id"myBean" class"progetto.tesina2.MyBean"/
  gt
• lt/beansgt

Fa riferimento alla posizione in cui si trova il
file con limplementazione
59
Metodo onMessageExchange
Svolge il servizio restituendo loutput, che
verrà inserito nel messaggio normalizzato.

• public void onMessageExchange(MessageExchange
  exchange) throws MessagingException
• if (exchange.getStatus() ExchangeStatus.ACTIV
  E)
• 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.
Trasforma il messaggio in un messaggio in
uscita e infine lo spedisce indietro
60
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
• Questultimo comando genererà il file jar che
  servirà per il deploy del progetto

61
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
  lutilizzo come Web Service)