Im Moment verwende ich RMI oder Hessian-Bibliothek , um zwischen meinem Server und meinen Kunden zu kommunizieren (über eine LinkedBlockingQueue). Jetzt lese ich über JMS , das auch in diesem Bereich verwendet werden könnte. Ist das richtig? Wenn ja, würde es Ihnen etwas ausmachen, mir eine einfache Liste von Vorteilen / Nachteilen zu geben, weil es ein ziemlich kompliziertes und "vollblütiges Unternehmen" zu sein scheint.
Was sind die Vorteile? Und was ist mit der Leistung im Vergleich zu RMI + Queue? Könnte JMS RMI + Queue schlagen?
PS: Ich weiß, es gibt ähnliche Fragen , aber ich möchte JMS mit RMI + Queue verglichen haben.
Ein vereinfachter Vergleich wäre (nicht speziell zu JMS, eher wie Vergleich gegen MQ im Allgemeinen) ...
Automatischer Wiederholungsversuch
Wenn Sie ein Client sind, der eine RMI auf einem Server ausführt, und aus irgendeinem Grund, dass RMI fehlschlägt, müssen Sie es erneut versuchen. Wenn Sie JMS verwenden und Sie der Client sind, senden Sie einfach die JMS-Nachricht. Wenn der Server nicht erreichbar ist, wird Ihre Nachricht gespeichert und dann zugestellt, wenn der Server wieder verfügbar ist.
Persistente Warteschlange
Da Sie eine LinkedBlockingQueue verwenden, können Sie entweder eine beschränkte Warteschlange oder eine unbegrenzte Warteschlange im Speicher haben. Erstere wird beginnen, Threads abzufangen, sobald die Warteschlange voll ist, und wird schließlich unter hoher Last ausfallen. Das spätere würde schließlich OutOfMemoryError werfen. Wenn Sie jedoch JMS verwenden, kann es automatisch damit beginnen, Nachrichten an "persistenten Speicher" zu "persistieren". Normalerweise ist "persistenter Speicher" die DB, die normalerweise viel mehr Kapazität hat als die In-Memory-Warteschlange. Natürlich geht der Inhalt der In-Memory-Warteschlange verloren, wenn der Server ausfällt usw., während in JMS eine dauerhafte Nachricht / dauerhafte Nachricht gewählt werden kann, die ein solches Ereignis überlebt. Dies ermöglicht Ihnen auch das Clustering, was auch für Enterprise-Programme sehr wichtig ist ...
Abstraktion Sie werden eine standardisierte API verwenden (ok, Sie haben auch Protokolle in RMI, aber wenn Sie möchten, dass Nachrichten weitergeleitet werden, bietet MQ viel mehr Abstraktion auf höherer Ebene als RMI + In-Memory Queue). Das bedeutet, dass Sie zukünftige Implementierungen von JMS verwenden können. Vielleicht etwas, das keine Datenbank benötigt, um Haltbarkeit und Persistenz zu bieten, skalierbarer als die heutige Implementierung usw. Oder vielleicht können Sie dieselbe Nachricht an einen völlig anderen Dienst senden, weil die Stabilisierung. Grundsätzlich könnte die höhere Abstraktion Ihnen Flexibilität geben, die die RMI + In-Memory-Queue nicht bietet.
Vor einiger Zeit habe ich mit einer großen Firma zusammengearbeitet, die ihr internes Framework nutzen wollte, um unsere Sachen zu integrieren. Zu dieser Zeit verwendeten wir kein MQ. Wir haben sie gebeten, unser eigenes asynchrones Protokoll basierend auf RMI zu verwenden. Vertrauen Sie mir, wir haben diese Entscheidung sehr, sehr, sehr bedauert ...
Die anderen Antworten decken viele Aspekte von JMS ab, aber ich denke, dass ein sehr wichtiger Punkt mehr Nachdruck erfordert, nämlich die Tatsache, dass JMS mehrere gleichzeitige Verbraucher in einer abgewickelten Weise unterstützt . Das ist für mich die Killer-Funktion .
Wenn wir von JMS Skalierbarkeit sprechen, sprechen wir jedoch davon: die Fähigkeit der App. Server zum Hinzufügen / Entfernen von Consumer / Producer, um die Last zu verwalten.
Weitere Vorteile von JMS sind Dienstqualität und Management, z.B. Redelivery Versuch, tote Nachrichtenwarteschlange, Überwachung usw.
Wenn Sie das nicht wirklich brauchen, könnte eine etwas einfachere Lösung funktionieren. Sie können auch eine andere Antwort von mir sehen, wo ich eine ähnliche Frage behandle: Warum JMS für asynchrone Lösung wählen?
Was verwenden Sie für den "Queue" Teil Ihrer Lösung? Ihr eigener Code?
JMS ist nur eine API über dem Warteschlangensystem eines Anbieters, aber eines, das die Remoting-Aspekte beinhaltet. Aus der Clientperspektive einfach eine Nachricht in eine Warteschlange (oder ein Thema, wenn Sie Pub Sub) tun, und vergessen Sie es. Die Infrastruktur liefert es an die Listener.
Ich sehe viel von der Stärke von JMS, die von der Qualität der Implementierung der Warteschlangeninfrastruktur kommt, und nicht von der API selbst, das ist ziemlich einfach.
Einfache RMI skaliert nicht gut oder behandelt Zuverlässigkeitsprobleme. Ein gutes Warteschlangensystem kann sowohl skalierbar als auch ausfallsicher sein.
Ich denke, es ist fair zu sagen, dass JMS und der Rest von Java EE dafür sorgen sollen, dass Ihre Anwendung Enterprise-Qualität erhält. Anfangs dachte ich, Java EE Overall sei komplex, obwohl ich dachte, JMS sei einer der einfacheren Ecken. Heute bin ich mir nicht sicher, ob es einfacher ist, RMI + zu schreiben, als mit JMS zu arbeiten.
Möglicherweise besteht ein wesentlicher Unterschied darin, dass die Verwendung von JMS ziemlich genau voraussetzt, dass Sie über eine Infrastruktur wie einen App Server verfügen.
JMS ist transaktional, kann mit Datenbanktransaktionen koordiniert werden.
JMS entkoppelt die Produzenten und die Konsumenten, was bedeutet, dass sie nicht gleichzeitig laufen müssen.
JMS ist eine garantierte Zustellung, was bedeutet, dass die Nachrichten im Falle eines Fehlers garantiert ankommen. (Abhängig vom Fehlertyp kann Clustering erforderlich sein.)
JMS kann synchrone, asynchrone Point-to-Point- und Publish / Subscribe-Funktionen ausführen.
Die meisten JMS-Implementierungen verwenden ein Warteschlangensystem, das mit anderen Sprachen, Betriebssystemen, arbeiten kann.
'Automatischer Wiederholungsversuch Wenn Sie ein Client sind, der eine RMI auf einem Server ausführt, und aus irgendeinem Grund, dass RMI fehlschlägt, müssen Sie es erneut versuchen. Wenn Sie JMS verwenden und Sie der Client sind, senden Sie einfach die JMS-Nachricht. Wenn der Server nicht erreichbar ist, wird Ihre Nachricht gespeichert und dann zugestellt, wenn der Server wieder verfügbar ist. "
Ich denke, die Antwort ist irreführend. Es ist belastbar in dem Sinne, dass Nachrichten, die an ein Ziel gesendet werden, für das sie keine Verbraucher sind, gespeichert werden, bis ein Verbraucher für diese Nachricht oder diese Nachricht abläuft. Dies setzt voraus, dass der JMS-Broker funktionsfähig ist.
Wenn Sie versuchen, eine Nachricht an einen Broker zu senden, der nicht erreichbar ist, sollten Sie eine JMSException erhalten, und in diesem Fall sind Ihre Clientnachrichten möglicherweise verloren, sofern Ihre Anwendung keine Vorbehalte hat, sie selbst zu speichern und es erneut zu versuchen. In diesem Sinne verhält sich ein Client für einen JMS-Server genauso wie der Client für einen RMI-Server. Sie werden immer noch die Nachricht verlieren, wenn dieser Server ausgefallen ist.