Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

102 dicembre
, anno 2005

Integration Patterns

Parte III: la pratica

Stefano Rossini

Stefano Rossini

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

MokaByte

Integration Patterns

Parte III: la pratica

Stefano Rossini

Stefano Rossini

  • Questo articolo parla di: Architetture dei sistemi, Programmazione & Linguaggi

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

Facebook
Twitter
LinkedIn
Stefano Rossini

Stefano Rossini

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

Stefano Rossini

Stefano Rossini

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
Tutti gli articoli
Nello stesso numero
Loading...

La Reflection in Java

Parte II

Service Oriented Architecture

Parte III: Maturity Model

Skill differenti per applicazioni J2EE di successo

La sfida del teamworking

Introduzione al workflow

Sistemi di gestione del flusso di lavoro

Firma digitale con dispositivo crittografico sicuro

I parte: le smart card

J2ME vs Symbian

Evoluzione e confronto

Architetture e tecniche di progettazione EJB

III parte: trasmissione dati tra strati con DTO

Java Business Integration

Parte III: Service Unit & Service Assembly

Applicazioni Desktop

Persistenza delle preferenze

Nella stessa serie
Loading...

Integration Patterns

Parte II

Integration Patterns

I parte

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte