Wann verwende ich Java und Message Broker?

Question

Ich bin ein Entwickler in meinem Büro, wo SOA-Entwicklung auf dem Höhepunkt ist. Wir verwenden IBM MQ, IBM Message Broker und Java/J2EE-Technologien.

Ich wurde im Moment in Projekt eingefügt, wo Message Broker verwendet wird, um eine Middleware zu entwickeln, die zwischen zwei Anwendungen interagiert. Ich bin mir nicht ganz sicher, ob Message Broker die richtige Option für ein solches Projekt ist, da Java die gleiche Arbeit auf eine sehr effiziente Art und Weise erledigen kann, was dazu führte, dass ich im Internet nach Vorteilen suchte.

Ich lese in verschiedenen Websites, dass Message Broker verwendet wird, um Nachrichten zu transformieren, zu routen und zu verbessern, dies kann sehr gut mit Java effizient durchgeführt werden. Das führte mich zu der Frage "Wann sollte Java verwendet werden und wann sollte Message Broker für die Entwicklung verwendet werden?" Es wäre toll, wenn mir jemand mit den Vorteilen der beiden helfen könnte.

-RDJ

Answer 1

Wie ich verstehe Sie versuchen, zum Beispiel Java, die Funktionalität in Kern implementieren, anstatt mit einem bereit Message Broker und ähnliche SOA bezogenen Technologien gehen. Mein Vorschlag ist - erfinden Sie das Rad nicht neu. Der Punkt ist, selbst wenn Sie dies versuchen, werden Sie schließlich mit denselben technischen Problemen konfrontiert sein und zu einer ähnlichen Lösung führen. Warum nicht auf Geschäftslogik konzentrieren, anstatt zu versuchen, ein Äquivalent von etwas zu entwickeln, das bereits vorhanden ist, das wahrscheinlich mehr getestet und vertrauenswürdig ist.

Answer 2

Nachrichtenbroker ermöglichen z.B. operations people, um alle Integrationen an einem Ort zu überwachen. Wenn sich ein Datenformat ändert, kann es außerdem trivial sein zu bestimmen, welche Integrationen von der Änderung betroffen sind.

Jede einzelne Integration könnte wahrscheinlich in Java (oder einer anderen Sprache, was das betrifft) umgesetzt werden, aber Sie würden am Ende aber mit einem Bündel von Punkt-zu-Punkt-Integrationen, die eines der Probleme Nachrichtenvermittler sind Versuche es zu lösen.

Wenn Sie eine generalisierte Transformation/Routing-Lösung in Java entwerfen würden, würden Sie einen Nachrichtenbroker entwerfen :) Das wäre interessant, aber nicht wirklich notwendig, da viele kommerzielle und Open Source-Nachrichtenbroker bereits verfügbar sind .

Answer 3

Von einem praktischeren Standpunkt bietet websphere message broker eine Möglichkeit, non-Java-Anwendungen (C, COBOL, PHP, VB ...) zu integrieren, die mit Java oft schwer zu erreichen sind.

Auch Java eignet sich nicht besonders gut für die Verarbeitung von XML. Sowohl ESQL als auch XSLT sind viel bessere Vehikel für die XML-Transformation als Java.

Webshpere Message Broker ist auch in der Lage, mit Messaging außerhalb der Beschränkungen von JMS zu handeln (es kann auch JMS tun).

Sie können Websphere ESB betrachten, die eine Art Java-Implementierung des Nachrichtenbrokers ist. Dieses Produkt erwartet, dass externe Nicht-Java-Anwendungen sich an die Java-Welt anpassen, so dass es weniger Integrationsfähigkeit hat, aber ich denke, dass Java-Leute es bequem finden werden, damit zu arbeiten.

Answer 4

Messaging wird normalerweise verwendet, wenn Sie über eine heterogene Anwendungsintegration verfügen und als Ersatz für RPC verwendet werden können, insbesondere wenn es asynchron ist. Es wird auch verwendet, um die Kopplung zwischen Anwendungen und als Rückgrat einer ereignisgesteuerten Architektur zu lösen. Die Verwendung von Nachrichten zur Verbesserung der Skalierbarkeit von Anwendungen ist sehr verbreitet. In einigen Fällen wird es für die Systeme verwendet, die nicht immer verfügbar sind, aber garantieren, die Anfrage zu erfüllen, sobald sie verfügbar sind. Es wird auch für Systeme verwendet, die mehr als einen Verbraucher pro Anfrage haben.

Answer 5

Websphere Message Broker ist ein ESB, wohingegen Java eine Programmiersprache ist. Es gibt ESBs, die Java als ihre Implementierungssprache wie Axis, Fuse verwenden, aber sie sind leistungsfähig genug, um XML zu analysieren, Dienste zu orchestrieren, mit Mainframe-Systemen zu integrieren. Webservice-Design und -Entwicklung in Message Broker ist einfach und benutzerfreundlich out ist für die XML-Transformation leistungsfähig und die Verarbeitung ist die Implementierungssprache, die in Message Broker verwendet wird. Auch hier ist die Integration mit MQ-, HTTP-, File-Knoten nahtlos und effizient in MB.

Answer 6

Das erste, was zu verstehen ist, dass die Java-API für Broker auf der C-API sitzt und Ihnen nicht den vollen Zugriff auf alle verfügbaren Funktionen bietet.

Zweitens ist es hässlich, ich würde es nicht für einfache Mapping-Transformationen verwenden, und natürlich gibt es heutzutage auch den visuellen Mapper.

Das sagte, dass es immer noch unter besonderen Umständen nützlich ist. Ein Beispiel, bei dem ich es verwendet habe, war, einen Nachrichteninhalt zusammenzuführen. Im Grunde wurde das Szenario Msg1 mit 2000+ Elementen empfangen und dann eine entsprechende Nachricht Msg2 mit 2000+ Elementen erhalten, die zusätzliche Details lieferte.

In ESQL müssen Sie also nur mit Msg1.element [1] beginnen und dann Msg2 für eine Übereinstimmung scannen, um zu optimieren, können Sie Elemente aus Msg2 löschen, wenn sie aufgebraucht sind. Dennoch war es in Bezug auf die CPUs horrend teuer, vor allem, als die Dinge von 2000+ auf 5000+ zu skalieren begannen. Und es dauerte lange, über 5 Minuten für wirklich große Nachrichten.

Die Alternative bestand darin, den Java-Rechenknoten zu verwenden und den Inhalt der zweiten Nachricht in ein Java-Tree-Objekt zu laden, wodurch sich die Verarbeitungszeit auf ungefähr 3 Sekunden verringerte.

Wenn Sie also nur die Transformation durchführen, vermeiden Sie den Java-Rechenknoten. Wenn Sie jedoch etwas Komplexeres und/oder CPU-intensives tun, dann geben Sie dem Java-Rechenknoten sicher einen Versuch.