Macht Terracotta JMS zu einer unnötigen Schicht?

Question

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, die 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 parallele Strukturen erstellen oder sie als separate, möglicherweise entfernte Objekte behandeln?

Answer 1

Eine Nachrichtenwarteschlange ist im Wesentlichen nur Queue Datenstruktur, die einige ausgefallene Optionen hat. Wenn Ihr Projekt wie die meisten anderen Projekte ist, sind Sie nicht mit irgendwelche der JMS-Funktionen, die JMS anders als alle alten Queue Implementierung machen, vor allem seit Terracotta Umgang mit Persistenz und Verteilung.

JMS fügt Ihrer Anwendung wahrscheinlich nur Komplexität hinzu, und JMS ist ziemlich gut darin. 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.

Answer 2

Ein Kollege von mir verwendet Mule, mit dem Sie Warteschlangen definieren können, die intra- oder inter-JVM-Warteschlangen sein können.

Ich stimme zu krosenwald: es ist nicht klar, was JMS würde in Ihrem Fall hinzufügen, es sei denn, es gibt einen allgemeinen Plan, entweder von Terracotta (oder zumindest die Option) zu entfernen.

Answer 3

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.

Während ich prinzipiell stimme, dass das Hinzufügen von JMS jetzt eine unnötige Komplexität für Sie sein könnte, haben wir festgestellt, dass, während glatt, der verteilte Cache ist nicht die beste Implementierung eines Messaging-Mechanismus. Während dieselben sematics erzeugt werden können, verursachen einige kleine Details Probleme (wie Load-Balancing für Verbraucher, die eine zusätzliche Synronisierung mit einem verteilten Cache erfordern, aber natürlich mit JMS funktioniert.)

Wenn Sie Ihre zukünftigen Anwendungsfälle denken erfordern mehr Pub-Sub-Semantik mit Persistenz etc, möchten Sie vielleicht anfangen, über JMS nachzudenken. 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)?