Wir schreiben gerade eine Anwendung, für die die IT bereits Hardware gekauft hat. Ihr Ansatz bestand darin, große Hardware zu kaufen, auf der wir sie bereitstellen würden. Um mehr Verarbeitung hinzuzufügen, planen sie zusätzliche Server mit identischer Software hinzuzufügen. Um diesem Design gerecht zu werden, verwenden wir Terracotta, um mehrere JVMs wie ein großes JVM zu betreiben. Unabhängig davon, ob dies ein weiser Weg ist (was ich immer noch nicht überzeugt bin), das ist die Situation, mit der ich es zu tun habe.
Wie auch immer, wir haben einen Teil der Anwendung, der eine standardmäßige Producer / Consumer Type Queue verwendet. Mit Terracotta können wir eine einzige Warteschlange erstellen, die mit mehreren JVMs funktioniert. Das ist ziemlich glatt und es funktioniert gut.
Aber jetzt finden wir zusätzliche Möglichkeiten, asynchrone Prozesse auszuführen. Um unsere gesamte Warteschlangenlogik konsistenter zu gestalten, ziehen wir in Erwägung, JMS zu verwenden, um die allgemeine Logik zu abstrahieren. Da wir JMS nicht als ferne Warteschlange verwenden werden (zumindest in absehbarer Zeit), frage ich mich, ob JMS einfach unnötige Komplexität hinzufügt.
Irgendwelche Vorschläge oder Gedanken? Sollten wir weiterhin Warteschlangen als konkurrierende Strukturen erstellen oder sie als separate, möglicherweise entfernte Objekte behandeln?
Eine Nachrichtenwarteschlange ist im Wesentlichen nur eine Warteschlangen-Datenstruktur, die einige ausgefallene Optionen hat. Wenn Ihr Projekt wie die meisten anderen Projekte ist, verwenden Sie keine JMS-Funktionen, die JMS anders als alle anderen Queue Implementierung, besonders seit Terracotta mit Persistenz und Verteilung umgeht.
JMS fügt Ihrer Anwendung wahrscheinlich nur Komplexität hinzu, und JMS ist damit ziemlich gut. Wie alle unnötigen Treiber der Komplexität, loswerden. Wenn Sie JMS aus einem oder mehreren Gründen verwenden möchten, tun Sie es dann.
Ein Kollege von mir verwendet Mule , mit dem Sie Warteschlangen definieren können, die intra- oder inkorporiert sein können Inter-JVM-Warteschlangen.
Ich stimme mit krosenwald überein: Es ist nicht klar, was JMS in Ihrem Fall hinzufügen würde, es sei denn, es gibt einen allgemeinen Plan, entweder von Terracotta wegzugehen (oder zumindest die Option dazu zu haben) / p>
Ich habe Terracotta nicht verwendet, aber wir verwenden ein sehr ähnliches verteiltes Caching-Produkt. Unsere Architektur klingt auch ähnlich wie das, was Sie haben. Hersteller und Verbraucher sitzen im selben Cache und teilen Daten über das Caching-Subsystem.
Obwohl ich dem Prinzipal zustimme, dass das Hinzufügen von JMS jetzt eine unnötige Kompliziertheit für Sie sein könnte, haben wir festgestellt, dass der verteilte Cache zwar glatt, aber nicht die beste Implementierung eines Nachrichtenmechanismus ist. Während die gleichen sematics erzeugt werden können, verursachen einige kleine Details Probleme (wie Load-Balancing für Konsumenten, die eine zusätzliche Synronisierung mit einem verteilten Cache benötigen, aber natürlich mit JMS funktioniert.)
Wenn Sie der Meinung sind, dass Ihre zukünftigen Anwendungsfälle mehr Pub-Sub-Semantik mit Persistenz usw. erfordern, sollten Sie sich Gedanken über JMS machen. Bedenken Sie auch die Trennung von Bedenken. Sie verwenden Terrakotta, um Daten zu verteilen (wozu es bestimmt ist). Werden Sie es auch verwenden, um Steueranweisungen zu verteilen (was mit messaing Semantik besser gemacht wird)?
Tags und Links java concurrency jms terracotta