Uno scenario business che potrebbe comportare l'integrazione di una serie di sistemi informatici tramite JMS?

Question

qualcuno può darmi qualche suggerimento su una scenari di business in cui posso implementare Java Messaging Services (JMS). Il messaggio può essere inviato sia con coda (point-to-point) o un argomento (regolare abbonamento / durevoli).

Userò JMS (abilitati attraverso TIBCO Enterprise Messaging Services).

Gli scenari di business deve coinvolgere almeno 3 IT sistemi / applicazioni.

Answer 1

Il caso d'uso classico è quello di un Enterprise Service Bus con JMS come uno dei trasporti disponibili. In questo caso un numero qualsiasi di sistemi IT possono richiedere un servizio di invocazione ponendo un messaggio su una coda ben noto. Il fornitore di servizi di ascolto su quella coda determina in modo dinamico la risposta in base a campi Reply-To del messaggio JMS. Un esempio di un servizio tipico è quello di informarsi su o aggiornare cliente informazioni demografiche. Ai fini di indagine, questo sicuramente soddisfa la vostra esigenza di coinvolgere almeno 3 sistemi informatici da praticamente tutto trattare con i clienti avrebbe bisogno di richiedere questo servizio.

Un altro esempio con l'applicazione ampia è la registrazione. Ho diversi clienti che utilizzano i messaggi JMS per la cattura record di log provenienti da tutta la rete e li trasmette ad un hub di server centrali. Poiché è JMS, il mozzo centrale può essere altamente disponibili utilizzando i server ridondanti e può scalare orizzontalmente per assorbire i carichi stagionali.

Per pub / sub un esempio mi è piaciuto molto è da una compagnia di assicurazioni. Pubblicano eventi su argomenti che vengono sottoscritte in vari call center, ticker di notizie interne e partner commerciali. Durante un uragano a pochi anni fa, questi eventi inclusi gli aggiornamenti sulle previsioni di approdo e poi, dopo la tempesta passava gli aggiornamenti inclusi posizioni dei regolatori di reclami mobili e altri servizi di supporto. Pub / Sub è stato un ottimo modo per coordinare questa massiccia mobilitazione del personale e comunicare back to back di supporto a terra presso la sede.

Un caso pub / sub uso più banale con ampia applicabilità è la gestione dei sistemi. applicazioni strumentati possono pubblicare il loro status e le parti interessate possono ricevere tali notifiche. Se qualcosa si comporta in modo strano nella produzione, l'amministratore può abilitare dinamicamente un abbonamento a un flusso di diagnostica. Di solito senza abbonati, la diagnostica non sono prodotti. Tuttavia, senza alcuna interruzione nel sistema in esecuzione, semplicemente sottoscrivendo, messaggi di diagnostica da App vengono prodotti su richiesta.

In realtà è difficile trovare esempi in cui dovrebbe non essere utilizzato messaggistica JMS. La maggior parte dei comuni controindicazioni sono veramente messaggistica sincrona e l'obbligo di messaggi di processo in stretta sequenza. Tutti i fornitori di JMS io sono a conoscenza di quote di make per questi requisiti a vari livelli e sono a conoscenza di molte implementazioni di sistemi con questi requisiti. Tuttavia i casi di utilizzo ideale per la messaggistica JMS sono veramente asincrono o pseudo-sincrono di comunicazione e messaggi che sono atomico (cioè i messaggi non hanno dipendenze tra loro o alle istanze di broker specifiche).

Answer 2

Ecco alcuni degli scenari in cui abbiamo (rivenditore di generi alimentari) l'uso di messaggistica:

-Connection sistemi tra sedi remote, nel nostro caso POS e sistemi di gestione delle scorte nei negozi, e sistemi ERP e di previsione centrali: le modifiche dei dati master vengono inviati come messaggi XML dal sistema ERP centrale per i sistemi di negozio. i sistemi di negozio inviano le variazioni delle rimanenze, gli ordini e le vendite ai sistemi centrali. Questo è completamente basato PTP, in quanto i dati master è unico per ogni negozio.

-usage come un backbone di messaggistica centrale, sia direttamente per i sistemi che sono in grado di fare la messaggistica, o tramite alcune funzionalità adattatore per il database, file, sistemi SAP o HTTP. Qui il sistema di messaggistica costruisce la base per il nostro ESB.