Messaging, Warteschlangen und ESBs - ich weiß, wo ich sein möchte, aber nicht wie ich dahin komme

Question

Um es kurz zu machen: Ich arbeite an einem Projekt, bei dem wir eine große Webanwendung aus den üblichen Gründen neu schreiben. Das Hauptziel des Neuschreibens besteht darin, diese große einzelne Anwendung, die auf einem einzelnen Server ausgeführt wird, in viele kleinere entkoppelte Anwendungen zu trennen, die auf vielen Servern ausgeführt werden können.

Ok hier ist, was würde ich gerne:

ich HTTP möchte den Haupttransportmechanismus sein. Wenn eine Anwendung beispielsweise wurde das CMS aktualisiert wird es den Broker über http kontaktieren und sagen "I've changed", dann wird der Broker eine 200 OK"thanks I got the message" zu sagen, zurückschicken.

Der Broker wird dann auf der Liste der anderen Anwendungen nach CMS-Änderungen suchen und die Nachricht an die URL übergeben, die die Anwendung verlassen hat, als sie dem Broker mitgeteilt hat, dass sie die Nachricht hören möchte.

Die anderen Anwendungen geben 200 OK zurück, wenn sie die Nachricht empfangen, wenn der Broker die Nachricht nicht speichert und sie in die Warteschlange stellt, wenn jemand das nächste Mal versucht, diese Anwendung zu kontaktieren.

Das Problem ist, ich weiß nicht einmal, wo ich anfangen soll oder was ich tun muss, damit es geschieht. Ich habe bei XMPP suchen, ActiveMQ, RabbitMQ, Mule ESB usw. und sehen kann ich das nächste Jahr gehen im Kreis mit diesem Zeug verbringen.

Könnte jemand irgendeinen Rat von der persönlichen Erfahrung anbieten, wie ich ziemlich vermeiden möchte, Lektionen auf die harte Art zu lernen.

Answer 1

Ich habe mit JMS Messaging in verschiedenen Softwaresystemen seit etwa 2003 gearbeitet. Ich habe eine Web-App, wo die Clients effektiv JMS-Themen-Abonnenten sind. Durch den bloßen Akt des Veröffentlichens einer Nachricht in einem Thema wird die Nachricht servergeschoben an alle teilnehmenden Web-Clients verbreitet.

Der Webclient ist Flex-basiert. Unsere Middle-Tier-Stack besteht aus:

• Java 6
• Tomcat 6
• BlazeDS
• Frühlings-Rahmen
• ActiveMQ (JMS Message Broker)

BlazeDS hat die Fähigkeit zu als Brücke zu JMS konfiguriert werden. Es ist ein Tomcat-Servlet, das auf Flex-Client-Remoting-Aufrufe reagiert, aber auch Nachrichten an die Clients senden kann, wenn neue Nachrichten in dem JMS-Thema angezeigt werden, für das es konfiguriert ist.

BlazeDS implementiert das Comet-Muster für die serverseitige Nachricht Push tun:

Asynchronous HTTP and Comet architectures An introduction to asynchronous, non-blocking HTTP programming

Farata System hat angekündigt, dass sie BlazeDS geändert haben mit dem Jetty Fortsetzung Ansatz zur Umsetzung des Comet-Musters zu arbeiten.Dies ermöglicht die Skalierung auf Tausende von Comet-Verbindungen für einen einzelnen physischen Server.

Farata Systems Achieves Performance Breakthrough with Adobe BlazeDS

Wir für Adobe warten Unterstützung von Servlets zu implementieren 3.0 in BlazeDS sich als im Grunde sind wir ziemlich vermählt mit Tomcat und Spring in Kombination.

Der Schlüssel zur Technik des massiv skalierbaren Comet-Musters besteht darin, Java NIO-HTTP-Listener in Verbindung mit einem Thread-Pool zu verwenden (z. B. die Executor-Klasse in der Java 5 Concurrency-Bibliothek). Das Servlet 3.0 ist ein asynchrones ereignisgesteuertes Modell für Servlets, die mit einem solchen HTTP-Listener verknüpft werden können. Tausende (Zahlen wie 10.000 bis 20.000) gleichzeitige Comet-Verbindungen können dann gegen einen einzelnen physischen Server aufrechterhalten werden.

Obwohl wir in unserem Fall die Adobe Flex-Technologie verwenden, um Webclients zu ereignisgesteuerten Messaging-Abonnenten zu machen, könnte dies auch für jede generische AJAX-Webanwendung erfolgen. In AJAX-Kreisen wird die Technik der serverseitigen Nachrichtenübertragung oft als Reverse AJAX bezeichnet. Sie haben vielleicht bemerkt, dass der Komet ein Wortspiel ist, wie im Gegenstück zu Ajax (beide Haushaltsreiniger). Das Schöne für uns ist jedoch, dass wir nur unsere Stücke miteinander verbinden, und dann gehen wir los. Generische AJAX Web-Coder werden viel Programmierarbeit haben. (Sogar eine generische Web-App könnte mit BlazeDS spielen, aber sie würde für das AMF-Marshalling, das BlazeDS zu bieten hat, keine Verwendung haben.)

Schließlich arbeiten Adobe und SpringSource zusammen, um eine reibungslosere of-the-Box-Integration von BlazeDS in Verbindung mit dem Frühlings-Framework:

Adobe Collaborates with SpringSource for Enhanced Integration Between Flash and SpringSource Platforms

Answer 2

Zunächst einmal, keine Sorge über ESBs. Die Situation, die Sie beschrieben haben, liegt innerhalb der Grenzen einer einfachen nachrichtenorientierten Middleware. Sie brauchen nur dann einen ESB, wenn Sie Mediationen, inhaltsbasiertes Routing, Protokollumwandlungen durchführen. Dinge, wo die Middleware macht die auf die Nachricht, oben auf Routing an den richtigen Ort.

Wenn Sie eine Vielzahl von Zielanwendungen haben, die miteinander sprechen müssen - und es klingt wie Sie - haben Sie Recht, dass Messaging über eine Sprache agnostic Protokoll (wie XMPP, STOMP oder HTTP) ist eine nette Sache Lösung. Es bedeutet im Grunde, dass Sie nicht viele Java-Daemons schreiben und ausführen müssen, um Nachrichten in Ihre bevorzugte Version von JMS zu übersetzen.

STOMP wird zunehmend von Nachrichtenbrokern unterstützt, insbesondere von Open-Source-Nachrichten, und es gibt eine Reihe verschiedener Clientbibliotheken. Es handelt sich um ein leichtgewichtiges Protokoll, das speziell für die Nachrichtenübertragung entwickelt wurde, so dass Sie ein umfangreicheres Feature-Set als bei HTTP erhalten.

Für mich XMPP ein bisschen eine schwache Option ist, wie es ist nicht so gut auf der Serverseite unterstützt, obwohl es Spaß ist in der Lage sein, Ihren Broker IM :)

Wenn Sie auf HTTP gesetzt sind, ist sehr gut, und ich habe seine Universal Message Service - im Grunde eine Webapp-Wrapper um JMS Destinationen persönlich verwendet. Es bietet eine REST-ful Schnittstelle mit einem ähnlichen Satz von Verben wie STOMP bietet.

Answer 3

Sie sprechen wirklich über veröffentlichen und abonnieren Sie mit gesicherter Lieferung. Die meisten MOM-Software sollte Ihren Anwendungsfall leicht unterstützen.

Answer 4

Wie jemand bereits gesagt hat, was Sie beschreiben, ist im Grunde das Publisher/Subscribe-Modell. Dies wird sehr einfach mit einem ESB oder einer Nachrichtenwarteschlange erreicht.Ich habe einige Erfahrungen mit RabbitMQ gemacht. Es ist sehr gut. Nichts geht verloren und es geht sehr gut mit dem Publish-Subscribe-Modell um. Ich habe in der Vergangenheit die Strecke auf kleinen Systemen hinuntergegangen, um meinen eigenen Nachrichtenmakler mit einem maßgeschneiderten Protokoll über HTTP zu entwickeln. Ich würde dies nicht raten, Grund zu sein ist, dass, während Sie anfangen, es zu entwickeln, Sie darüber nachdenken, wie Sie es erweitern können.

RabbitMQ ist in Erlang entwickelt, aber es hat Java, Net, Python usw. Clients, die sehr leicht darin einhaken können. Ich habe die .NET- und Python-Clients verwendet, es funktioniert gut. Ich habe es für Erlangs Ruf gewählt, solide Systeme zu entwickeln, die mehrere Dinge gleichzeitig bewältigen können, sehr gut. Ich würde sie Threads nennen, aber ich denke, dass es schlauer ist als nur Threads, ich denke, ich erinnere mich an das Murmeln des Actor Model und der Postfächer, von denen ich mich erinnere, dass sie ziemlich ordentlich waren.

Ich war in einer ähnlichen Position wie Sie, aber mit sehr schlechten Erfahrungen anderer Messaging-Systeme (Biztalk et al.), Die zu Anstand waren, die Sie in eine Lösung gebunden. Wenn Sie die Nachrichten getrennt von den Transport- und Liefermechanismen aufbewahren können, können Sie Ihr System nach Herzenslust entwickeln. Ich benutzte JSON am Ende, da die Paketgrößen klein sind. Sie können alles verwenden, was Sie möchten, einige entscheiden sich für SOAP-Nachrichten, aber ich finde, dass diese für die meisten Sachen viel zu schwer sind, obwohl Sie XSD-Schemas schön an Außenstehende weitergeben können, damit sie Systeme entwickeln können, die mit Ihren interagieren System in der Zukunft.

http://www.rabbitmq.com/tutorials/tutorial-three-java.html, dies ist ein Link zum Tutorial zum Publish/Subscribe-Modell und wie Sie es mithilfe eines Nachrichtenwarteschlangensystems erreichen würden. Es ist für RabbitMQ, aber um ehrlich zu sein, es wird mit ESB und jedem anderen Messaging-Queue-System da draußen arbeiten.

Answer 5

ESB (Enterprise Serial Bus) - Bedenken Sie dies, wenn Ihre Anwendung viel Interaktion mit zwei oder mehr externen/separaten Anwendungen hat, in denen diese nicht in einem ähnlichen Datenformat kommunizieren. Bsp .: Einige Systeme können Objekte, XML, JSON, SMTP, TCP/IP, HTTP, HTTPS usw. akzeptieren.

ESB hat viele Funktionen wie: Routing, Adressierung, Messaging-Stile, Transportprotokolle, Service-Messaging-Modell.

Betrachten Sie das Warteschlangensystem, wenn die Producer-Consumer-Anwendungen dem gleichen Typ von Datenformat folgen.

Webdienste (SOAP/REST) ​​sind am besten, wenn eine Anwendung die andere Anwendung benötigt, um den Arbeitsablauf zu vervollständigen. Verwenden Sie Warteschlangen, wenn die Anwendung eine asynchrone Datenübertragung benötigt.

Answer 6

Wie schon früher gesagt wurde, scheint mir ein aktueller Fall mit einem ESB eine Fliege mit einem Hammer zu zerschlagen.

Die ESB-Software selbst ist zeitaufwändig und muss gewartet werden. Wenn Sie zu einer Open-Source-Lösung wechseln, ist dies möglicherweise zeitaufwändiger als die Verwendung einer lizenzierten Lösung (IBM, ORACLE, ...).

Natürlich würde ein ESB die Arbeit machen, und es wäre wirklich einfach, eine Lösung zu entwickeln, aber die Einrichtung eines ESB wäre viel schwieriger als die Lösung selbst.

Wenn Ihr Problem auf den Fall beschränkt ist beschrieben, würde ich sehr empfehlen Ihnen eine einfache Architektur über OpenMQ (oder ähnlich) zu bauen, und es durch JMS