elaborazione di un messaggio esattamente una volta

Question

perche lo scenario, come mostrato nell'immagine allegata:

1. Il Portale (produttore) invierà qualche messaggio per il bus a cui deve essere elaborato da più applicazioni (consumer) - PAYROLLAPP, HELPDESK ecc
2. più istanze di applicazioni consumer potrebbe essere in esecuzione, anche questi istanze possono essere aggiunte/ rimossi dinamicamente
3. Ora, è fondamentale garantire che il messaggio venga elaborato una sola volta, per applicazione i.e se PAYROLLAPP -1 elabora il messaggio, PAYROLLAPP -2 NON deve elaborarlo; naturalmente, nel diagramma sopra , HELPDESK - 1 deve elaborarlo. In breve, in caso di più istanze, esattamente uno deve elaborare il messaggio, una volta
4. Quando ho cercato risposte, la maggior parte delle cose riguardava la creazione di un 'consumatore selettivo' - un consumatore che accetta/rifiuta un messaggio basato su un po 'di logica - si prega di notare che non è possibile apportare modifiche/aggiunte/confezioni per le applicazioni mostrate nel diagramma; la logica deve risiedere da qualche parte nel provider che gestisce il bus

Si prega di guida circa lo stesso.

Aggiungendo ulteriori dettagli dopo la risposta di Petter:

1. Le voci alla a sinistra della linea di sinistra-punteggiata sono gli 'approcci' - JMS Pure, ESB, EAI
2. Gli elementi a destra della linea con punti a destra sono le "implementazioni"

Ora, la parte grande - QUERIES:

1. Indipendentemente dalla soluzione (JMS puri, ESB, EAI), fa parte sotto la linea tratteggiata (code per applicazioni specifiche) orizzontali deve da attuare?
2. In che modo l'utilizzo di ESB (JBoss ESB, ecc.), Invece di JMS "puro" (MQ attivo ecc.), Aiuta/ostacolare ? ESB offre vantaggi rispetto a JMS che è 'java-only' (?). Sono un po 'confuso - "ESB o JMS", anche dopo aver consultato discussioni come queste: JMS and ESB - how they are related?. Ha una risposta che dice "JMS non è adatto per l'integrazione di servizi REST, File system, S/FTP, Email, Hessian, SOAP ecc. Che sono meglio gestiti con un ESB che supporta questi tipi in modo nativo. Ad esempio, se hai un processo che scarica un file CSV di 500 MB a mezzanotte e vuoi che un altro sistema prelevi il file, analizza il file CSV e lo importi in un database, questo può essere facilmente eseguito da un ESB - mentre uno la soluzione con solo JMS sarà cattiva. Allo stesso modo, l'integrazione dei servizi REST, con il bilanciamento del carico/il failover a più istanze di back-end può essere eseguita meglio con un ESB che supporta HTTP/S in modo nativo. "Aggiunta solo alla mia confusione !!!
3. L'utilizzo del framework EAI (Apache Camel ecc.) È un approccio completamente diverso dal puro approccio JMS o ESB? Se sì, come e quali sono i pro/contro?
4. mi hanno detto che da sola ESB non aiuterà, BPM (? O altro) deve essere utilizzato per definire e negozio la logica ‘instradamento’ - è vero?

Answer 1

vedo il punto. Questo potrebbe essere un po 'complicato con JMS "puro".

Ciò che essenzialmente si vuole fare è lasciare che il portale pubblichi messaggi su un argomento, ma non lasciare che i PAYROLLAPP si abbonino a quell'argomento (poiché tutti riceveranno una copia del messaggio). Quindi, ciò di cui hai bisogno è una qualche logica intermedia che distribuisca il messaggio dalla sottoscrizione dell'argomento a una coda per tipo di applicazione. Da quella coda, il carico normale bilanciato (il modello di consumatore in competizione) può essere implementato con JMS.

Diversi provider JMS hanno implementazioni speciali che possono compiere questo compito ActiveMQ has its Virtual Destinations, WebSphere MQ has its server side subscriptions that can subscribe from a topic to a queue. Nel caso in cui il tuo provider JMS non abbia alcun modo per gestirlo, potresti voler aggiungere del middleware di routing alla tua topologia. Apache Camel è bello, leggero, ma ce ne sono molti altri che possono configurare alcuni percorsi nel mezzo senza influenzare le applicazioni reali.

Aggiornamento per domande dettagliate

1. le code sotto la linea deve essere di sicuro (se le applicazioni di messaggistica utilizza). La casella "Alcune distribuzioni logiche" non dovrebbe essere necessaria. La casella "Alcuni logica di routing" potrebbe essere un ESB o in questo caso molto, essere implementata nel server di messaggistica, ad esempio ActiveMQ con destinazioni virtuali (o WebSphere MQ o forse RabbitMQ tra gli altri).

2. Ci sono un sacco di buzwords nel dominio di integrazione. Semplificato (a seconda di chi lo chiedi - ESB può anche essere visto come un modello architettonico, ma cerchiamo di mantenerlo semplice), un ESB è un'applicazione server (o una topologia di più server in pratica) che è il fulcro di un panorama di integrazione. Il server ESB semplicemente contenere la logica e flussi di messaggi di piccole dimensioni che prende i messaggi (file, o qualsiasi altra cosa) da un'applicazione e li indirizza a molte applicazioni, trasformarli in altri formati, cripta, converte da un protocollo di trasporto come ad esempio HTTP/SOAP per file etc

JMS è una parola piuttosto confusa e ignorata. Java ha in qualche modo dominato il dominio della messaggistica aziendale negli ultimi anni, quindi JMS è talvolta usato come sinonimo di Messaging. Tuttavia, la messaggistica (o la messa in coda dei messaggi, la messaggistica asincrona, il MOM = middleware orientato ai messaggi, ecc.) Deve essere semplicemente considerata come una famiglia di protocolli di trasporto simili dotati di un server di inoltro centrale. Is non è affatto una cosa solo Java. Molti ESB di successo messe a punto con cui ho lavorato in realtà leva su un backbone di messaggistica

1. Nella tua situazione, non vorrei andare troppo in profondità nelle accademici/differenze filosofiche tra ESB e software EAI. Molto probabilmente faranno praticamente le stesse cose per te. Invece, guarda i fatti concreti come prezzo, supporto, impronta delle risorse, monitoraggio, tecnologia. caratteristiche, la curva di apprendimento, ecc Che si tratti di Camel/ServiceMix, Mule, JBoss ESB, Microsoft BizTalk, IBM Message Broker, Tibco ecc

2. Hah! Era forse un venditore? Un ESB andrà bene. Un server di messaggistica funzionerà anche nel tuo caso, come ad esempio ActiveMQ come già indicato. Le tute BPM vanno bene per orchestrare i processi di business semi-automatizzati o se c'è una grande logica di business nel livello di integrazione. Altrimenti, evita quella complessità aggiuntiva.

Answer 2

1. Indipendentemente dalla soluzione (JMS puri, ESB, EAI), fa parte sottostante la linea tratteggiata orizzontale (code specifici dell'applicazione) deve essere attuata?

I consumatori devono essere attuati in modo tale che il lavoro con te scelto una soluzione, ma non dovreste preoccuparvi di creazione della coda per ogni consumatore o la logica di distribuzione (supponendo che i consumatori possono consumare direttamente dalla tecnologia prescelta)

1. che modo l'utilizzo di ESB (JBoss ESB, ecc), invece di JMS 'puri' (MQ attivo, ecc), Help/ostacolare? ESB offre vantaggi rispetto a JMS che è 'java-only' (?). Sono un po 'confuso -' ESB o JMS ', anche dopo aver fatto riferimento a thread come questi: JMS e ESB - come sono correlati ?. Ha una risposta che dice "JMS non è adatto per l'integrazione di servizi REST, File system, S/FTP, Email, Hessian, SOAP ecc. Che sono meglio gestiti con un ESB che supporta questi tipi in modo nativo. Ad esempio, se hai un processo che scarica un file CSV di 500 MB a mezzanotte e vuoi che un altro sistema prelevi il file, analizzi CSV e importi in un database, questo può essere facilmente realizzato da un ESB - mentre una soluzione con JMS sarà cattivo. Allo stesso modo, l'integrazione dei servizi REST, con bilanciamento del carico/failover a più istanze di back-end può essere migliorata con un ESB che supporta HTTP/S in modo nativo. "Ha aggiunto solo alla mia confusione !!!

mia opinione è che sarebbe ESB overcomplicate questa soluzione. È progettato (tra le altre cose) per aiutare l'integrazione con diverse tecnologie, ma anche soluzioni più semplici - ad esempio, Apache Camel fornisce un modo molto semplice di comunicare utilizzando una grande varietà di trasporti (incluso ActiveMQ).

Non tutte le implementazioni JMS soddisfano la connettività da altre lingue, ma ActiveMQ utilizza il suo connettore STOMP.

1. è l'utilizzo di framework EAI (Apache Camel, ecc) un approccio completamente diverso dalle JMS puri o approccio ESB? Se sì, come e quali sono i pro/contro?

Apache cammello e JMS sono tecnologie complementari, come lo sono JMS e ESB. Camel (& Spring Integration) sono leggeri, semplici e portatili. Gli ESB sono molto più pesanti e normalmente portano ad un maggiore accoppiamento con ESB/application server.

1. mi è stato detto che da soli ESB non aiuterà, BPM (? O altro) deve essere utilizzato per definire e memorizzare la logica ‘instradamento’ - è vero?

dipende da cosa la logica 'instradamento' è, mi sembra non si richiede la logica di routing, si richiedono solo garantire il recapito al 1payroll consumatori e 1 helpdesk consumatori. Il BPM sarebbe più utile se desideri dati pubblici selettivi/invoca un servizio basato su alcune caratteristiche di tali dati.

vi consiglio caldamente la lettura http://activemq.apache.org/virtual-destinations.html, utilizzando questi si farebbe:

1. Invia messaggio al broker ActiveMQ, su un VirtualTopic, per esempio VirtualTopic.X
2. Registra gli utenti di Payroll e Helpdesk come consumatori sulle code che ActiveMQ crea dinamicamente sull'argomento, ad es. Consumer.Payroll.VirtualTopic.X. Entrambi i consumatori di libri paga devono essere registrati con la stessa stringa.
3. ActiveMQ manterrà automaticamente un indicatore che rappresenta ciò che ciascun gruppo di consumatori non ha consumato. Ciò significa che il 100% dei messaggi verrà elaborato da un utente di Gestione stipendi, ma un messaggio non verrà mai inviato a> 1 consumatore di libri paga.
4. Aggiungi/rimuovi i consumatori a piacere.

N.B. Credo che altri prodotti, ad es. Apache QPID fornisce funzionalità simili - sono solo più consapevole di ActiveMQ e ho avuto successo con questo approccio