Quando utilizzare Java e Message Broker?

Question

Sono uno sviluppatore nel mio ufficio in cui lo sviluppo SOA è ai massimi livelli. Usiamo IBM MQ, IBM Message Broker e Java/J2EE Technologies.

Sono stato attualmente inserito in un progetto in cui Message Broker viene utilizzato per sviluppare un middleware che interagisce tra due applicazioni. Non sono del tutto sicuro che Message Broker sia l'opzione giusta per questo tipo di progetto, dal momento che Java può fare lo stesso lavoro in un modo molto efficiente, il che mi ha spinto a cercare in Internet i vantaggi nell'utilizzare i due.

Ho letto in diversi siti che Message Broker viene utilizzato per trasformare, instradare e migliorare i messaggi, questo può essere fatto utilizzando java in modo efficiente. Quindi questo mi ha portato a questa domanda "Quando utilizzare Java e quando utilizzare Message Broker per lo sviluppo?" Sarebbe bello se qualcuno potesse aiutarmi con i vantaggi di usare i due.

-RDJ

Answer 1

Mi pare di capire che si sta cercando, ad esempio, implementare la funzionalità del core java invece di andare con un messaggio pronto Broker e simili tecnologie SOA correlati. Il mio suggerimento è - non reinventare la ruota. Il punto è che, anche se provi a farlo, alla fine dovrai affrontare gli stessi problemi tecnici e portare a una soluzione simile. Perché non concentrarsi sulla logica aziendale invece di cercare di sviluppare un equivalente di qualcosa che è già lì che è probabilmente più testato e affidabile.

Answer 2

I broker di messaggi consentono ad es. le operazioni le persone per monitorare tutte le integrazioni in un unico luogo. Inoltre, se un formato di dati cambia, può essere banale determinare quali integrazioni sono interessate dalla modifica.

Ogni singola integrazione potrebbe probabilmente essere implementata in Java (o in qualsiasi altra lingua, se è per questo), ma si finirebbe con una serie di integrazioni point-to-point, che è uno dei problemi dei broker di messaggi prova a risolvere.

Se dovessi progettare una soluzione di trasformazione/instradamento generalizzata in Java, dovresti progettare un broker di messaggi :) Che sarebbe interessante, ma non proprio necessario, visto che molti broker di messaggi commerciali e open source sono già disponibili .

Answer 3

Da un punto di vista più pratico, il broker di messaggi Websphere offre un modo per integrare le applicazioni non java (C, COBOL, PHP, VB ...) che è spesso difficile da eseguire con java.

Inoltre, Java non è particolarmente adatto per elaborare XML. Sia ESQL che XSLT sono veicoli molto migliori per la trasformazione xml di Java.

Il broker di messaggi Webshpere è anche in grado di gestire la messaggistica al di fuori dei limiti di JMS (può anche fare JMS).

Si potrebbe guardare Websphere ESB che è un po 'come un'implementazione Java del broker di messaggi. Questo prodotto si aspetta che le applicazioni esterne non java si adattino al mondo Java, quindi ha meno capacità di integrazione, ma penso che le persone java troveranno comodo lavorare con.

Answer 4

La messaggistica viene in genere utilizzata quando si dispone di integrazione di applicazioni eterogenee e può essere utilizzata in sostituzione di RPC in particolare quando è asincrona. Viene anche utilizzato per allentare l'accoppiamento tra le applicazioni e come la spina dorsale di un'architettura basata sugli eventi. Usare il messaggio per migliorare la scalabilità delle applicazioni è molto comune. In alcuni casi viene utilizzato per i sistemi che non sono sempre disponibili ma garantiscono di soddisfare la richiesta quando diventano disponibili. Inoltre è usato per sistemi che hanno più di un consumatore per richiesta.

Answer 5

Websphere Message Broker è un ESB mentre Java invece è un linguaggio di programmazione. Esistono ESB che usano Java come linguaggio di implementazione come Axis, Fuse ma sono abbastanza potenti da analizzare XML, orchestrare servizi, integrarsi con i sistemi mainframe. Progettazione e sviluppo di servizi Web in Message Broker è facile e user-friendly. ESQL come indicato correttamente out è potente per la trasformazione e l'elaborazione XML è il linguaggio di implementazione utilizzato in Message Broker. Ancora una volta, l'integrazione con MQ, HTTP, nodi file è perfetta ed efficiente in MB.

Answer 6

prima cosa da capire è che la Java API per Broker si trova sulla cima del C-API e non ti dà pieno accesso a tutte le funzionalità disponibili.

In secondo luogo la sua brutta, io non lo uso per semplici trasformazioni di mappatura, e, naturalmente, in questi giorni c'è il mapper visivo pure.

Detto questo è ancora utile in circostanze particolari. Un esempio in cui l'ho usato è stato quello di unire un po 'di contenuto del messaggio. Fondamentalmente lo scenario è stato ricevuto Msg1 contenente 2000+ elementi e quindi ottenere un messaggio corrispondente Msg2 contenente 2000+ elementi che ha fornito ulteriori dettagli.

Quindi in ESQL ci si riduce a iniziare con Msg1.element [1] e quindi si esegue la scansione di Msg2 per una corrispondenza, per ottimizzare è possibile eliminare elementi da Msg2 man mano che si esauriscono. Tuttavia è stato terribilmente costoso in termini di CPU, soprattutto una volta che le cose hanno iniziato a salire da 2000+ a 5000+. E ci è voluto molto tempo, oltre 5 minuti per messaggi davvero grandi.

L'alternativa era usare il nodo di calcolo Java e caricare il contenuto del secondo messaggio in un oggetto Java albero, questo riduce il tempo di elaborazione per circa 3 secondi.

Quindi, se si sta solo facendo trasformazione evitare del nodo di calcolo Java. Se tuttavia si sta facendo qualcosa di più complesso e/o di utilizzo intensivo della CPU, si può provare a provare il nodo di elaborazione Java.