In questo articolo vedremo due esempi pratici del pattern Content-Based Router (CBR).
Il primo consiste nella realizzazione pratica di una classe CBR, il secondo riguarda la configurazione di un componente CBR già realizzato e disponibile da un prodotto d‘integrazione.
Nei precedenti articoli si sono introdotti i principali pattern d‘integrazione message-based (vedere [1] e [2]).
Esempio di implementazione di un Content-based Router
Riprendendo l‘esempio precedentemente introdotto (vedere [2]), concentriamoci sulla parte in cui, a seconda del tipo di prodotto che si vuole comprare, bisogna inoltrare il messaggio contenente l‘ordine all‘opportuna destinazione.
Supponiamo quindi di avere una semplice applicazione client che ha la possibilità di acquistare due possibili prodotti sportivi: una maglietta di Football Americano della squadra dei Pittsburgh Steelers o una maglietta di Basket della squadra dei Los Angeles Lakers.
A secondo dell‘ordine di acquisto, la richiesta deve essere inoltrata o al gestore vendite della National Footbal League – NFL (per la maglietta di Football), o al gestore vendite della National Baket Asscoiation – NBA (per la maglietta di Basket).
Piuttosto che fare conoscere le N possibili destinazioni al client (nell‘esempio proposto sono solo due per motivi didattici) e far sì che sia lui a capire quale deve essere l‘opportuno destinatario del messaggio, è opportuno (e vantaggioso!) prevedere un componente di router centralizzato che si occupi di “smistare” opportunamente i messaggi implementando le regole del pattern Content Base Router (vedere [3]).
I vantaggi del pattern CBR sono molti. La logica di routing è centralizzata nel Router e non negli N client. Se l‘algoritmo dovesse essere modificato si interverrebbe in un punto centrale così come se le destinazioni dovessero cambiare (modificate / tolte / aggiunte) l‘intervento risulterebbe circoscritto al solo Router.
Nel nostro scenario d‘esempio si procede quindi a creare un componente di router che disaccoppia il client dalle le due possibili destinazione (il gestore vendita NFL per la maglietta di footbal americano e il gestore vendite NBA per la maglietta di Basket).
Sviluppiamo quindi un semplice router per gestire lo scenario d‘esempio appena descritto.
Il client dovrà specificare nel contenuto del messaggio l‘identificativo del tipo di ordine. Per fare questo prevediamo una opportuna proprietà JMS di nome “KIND”.
Se il client deve acquistare una maglietta di Football Americano valorizzerà la proprietà “KIND” con il valore “NFL”:
TextMessage message = queueSession.createTextMessage();message.setStringProperty("KIND","NFL");message.setText(msg);queueSender.send(message);
mentre per l‘acquisto di una maglietta di basket si specificherà come valore della proprietà “KIND” il valore “NBA”:
TextMessage message = queueSession.createTextMessage();message.setStringProperty("KIND","NBA");message.setText(msg);queueSender.send(message);
Da notare come a secondo dell‘acquisto cambia il contenuto dell‘header JMS ma non la destinazione del QueueSender che è sempre la stessa: quella del Content Based Router(CBR).
this.queue = << lookup JNDI.this.queueConnectionFactory = << lookup JNDI.this.queueConnection = this.queueConnectionFactory.createQueueConnection();this.queueSession = this.queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);this.queueSender = queueSession.createSender(queue);
Costruiamo ora una semplice classe che implementa l‘algoritmo di Content Base Routing che, in base al contenuto della proprietà JMS, invia il messaggio all‘opportuna destinazione.
La classe
public class SampleCBR extends JFrame implements MessageListener{
si mette in ascolto sulla coda di input queue/CBR_Input dalla quale arriveranno le richieste d‘ordine
ctx = new InitialContext();Object obj = ctx.lookup("ConnectionFactory");ConnectionFactory factory = (ConnectionFactory)obj;queueConnectionFactory = (QueueConnectionFactory)factory;queueSession = queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);Queue queueInput = (Queue)ctx.lookup ("queue/CBR_Input");QueueReceiver queueReceiver = queueSession.createReceiver(queueInput);queueReceiver.setMessageListener(this);queueConnection.start();
ed effettua la lookup delle due code di ouput, la coda queue/CBR_Output_1 sulla quale è in ascolto il gestore degli ordini NFL
Queue queueOutput1 = (Queue)ctx.lookup("queue/CBR_Output_1");
queueSender1 = queueSession.createSender(queueOutput1);
e la coda queue/CBR_Output_2 sulla quale è in ascolto il gestore degli ordini NBA
Queue queueOutput2 = (Queue)ctx.lookup("queue/CBR_Output_2");queueSender2 = queueSession.createSender(queueOutput2);
Ad ogni ricezione del messaggio di un ordine d‘acquisto, verrà invocato dal sistema di Messaging il metodo onMessage(). All‘interno di tale metodo è implementata la seguente logica di routing del messaggio:
- se la property KIND del messaggio JMS vale "NFL", il messaggio viene indirizzato sulla coda di Output_1 (dove è in ascolto il gestore degli ordini dei prodotti NFL)
- se la property KIND del messaggio JMS vale "NBA", il messaggio viene indirizzato sulla coda di Output_2 (dove è in ascolto il gestore degli ordini dei prodotti NBA)
- altrimenti non viene effettuato nessun inoltro e viene stampato il messaggio di errore
public void onMessage(Message message) {TextMessage msg = null;String kind=null;try {if (message instanceof TextMessage) {msg = (TextMessage) message;kind = msg.getStringProperty("KIND");if("NFL".equals(kind)){queueSender1.send(msg);}else if("NBA".equals(kind)){queueSender2.send(msg);}else{System.err.println("# ERRORE: NO Routing! #
");}} else {System.err.println(CLASS_NAME + ".onMessage: Message of wrong type:!");}} catch (JMSException e) {System.out.println(CLASS_NAME + ".onMessage: " + e.getMessage());e.printStackTrace();} catch (Throwable t) {System.exit(-1);}}
Utilizzo di un ESB Content-Based Routing
Vediamo ora di vedere come lo stesso esempio visto in precedenza verrebbe "risolto" utilizzando un prodotto d‘integrazione.
I tool EAI mettono a disposizione dei componente CBR "ready-to-use" in cui è possibile personalizzare ad hoc le regole di configurazione del routing.
Ad esempio utilizzando il prodotto Sonic ESB (vedere [SONIC]) è possibile utilizzare i componenti CBR della suite provvedendo a configurarli per le proprie specifiche esigenze.
Per il nostro esempio, dal Tool di configurazione del prodotto bisogna specificare le condizioni di routing (Conditions) in base al valore della proprietà JMS "KIND" e la relativa destinazione (Address) nel caso in cui la condizione risulti soddisfatta.
Si configura quindi il CBR per inoltrare il messaggio ricevuto alla destinazione ESBSample.Q5 se la proprietà KIND JMS è presente e valorizzata con la stringa "NFL", mentre viene inoltrato alla destinazione ESBSample.Q6 se è valorizzata con la stringa "NBA".
Una volta configurato ed effettuato il deploy del componente (MokaCustomeRouterService) nel Container d‘interesse (SampleContainer) è possibile verificare il corretto funzionamento mediante il client di test JMS.
Inoltrando un messaggio avente proprietà KIND valorizzata con la stringa NFL, si deve verificare che il messaggio si inoltrato alla destinazione ESBSampleQ5 visto che il CBR trova soddisfatta la regola di routing "NFL".equals(XQ_getProperty("KIND")).
Se invece si specifica nel messaggio la proprietà KIND uguale a NBA si deve verificare che il messaggio si inoltrato alla destinazione ESBSampleQ6.
Nella figura sottostante si vede il caso in cui il messaggio si riferisce ad un acquisto di un prodotto NFL e quindi viene inoltrato alla destinazione ESBSampleQ5.
La figura seguente riassume l‘esempio fino ad ora spiegato.
Il CBR così ottenuto può essere utilizzato in modalità drag-and-drop dal tool BPM per il design di un processo di business.
Conclusioni
In questo articolo, che conclude la miniserie dedicata all‘introduzione dei pattern di integrazione, si sono presentati due esempi pratici di CBR: il primo riguardava lo sviluppo da zero, il secondo invece la configurazione di un componente disponibile da un prodotto d‘integrazione. Si è visto come in entrambi i casi la conoscenza del pattern è fondamentale per un corretto sviluppo e/o utilizzo del CBR.
1S.Rossini"Integration Patterns (I)" Mokabyte 100 Ottobre 20052S.Rossini"Integration Patterns (II)" Mokabyte 101 Novembre 20053Gregor Hohpe, Bobby Woolf"Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" Addison-Wesley, 20044http://www.eaipatterns.com/index.html5Alur, Crupi, Malks"Core J2EE Patterns: Best Practices and Design Strategies"6Floyd Marinescu"EJB Design Patterns: Advanced Patterns, Processes and Idioms"7Ed Roman, Scott Ambler, Tyler Jewell"Mastering Enterprise JavaBeans"8Sun Java Center J2EE Patternshttp://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html9Sun Blueprints Design Patterns Cataloghttp://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html10Gamma, Helm, Johnson, Vlissides
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.
Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.
Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).
Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.
Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.
Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242