Sollten Sie mit JMS gehen?

Die verteilte Systementwicklung nimmt rasant zu, da Softwareentwickler Systeme entwickeln, die mit den ständig steigenden Anforderungen des E-Business Schritt halten müssen. Noch nie war der Entwurf und die Implementierung einer Nachrichtenverarbeitungsschicht in einem verteilten System so komplex wie heute. Dies ist hauptsächlich auf die dramatische Zunahme der potenziellen Funktionalität zurückzuführen, die durch Standards wie Java Message Service (JMS) ermöglicht wird, die die Technologien vieler Anbieter in einem einzigen System verbinden. Darüber hinaus hat die Verbreitung des Internets zu neuen, expansiven Benutzerbasen geführt und mehrere Protokolle für die Kommunikation innerhalb eines verteilten Systems zur Verfügung gestellt. Zu diesen Protokollen gehören CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distributed Component Object Model) und Java RMI (Remote Method Invocation).

Die natürliche Entwicklung dieser Protokolle hat zur Einführung der nachrichtenorientierten Middleware (MOM) geführt, die eine lockerere Kopplung innerhalb verteilter Systeme ermöglicht, indem Übersetzung, Sicherheit und die zugrunde liegenden Kommunikationsprotokolle von Clients und Servern abstrahiert werden. Zu den Middleware-Lösungen gehören SOAP (Simple Object Access Protocol) und JMS. Seit den Anfängen von COBOL (Common Business Oriented Language) gibt es eine proprietäre Transaktionsverarbeitung auf mittlerer Ebene, die jedoch aufgrund der Einschränkungen der frühen Messaging-Technologien nicht sehr komplex war.

Mit dem Aufkommen von Standards wie JMS können Entwickler nun zahlreiche Technologien verbinden. Entwurfsentscheidungen für verteilte Systeme sind schwieriger und ihre Auswirkungen auf die Datenintegrität und -verteilung sind entscheidend für den Erfolg oder Misserfolg des Systems.

Eine allgegenwärtige und stillschweigende Annahme ist, dass die Einführung von Technologie ein Aktivposten ist, während ihre Verbindlichkeiten häufig ignoriert werden. Die Nichtberücksichtigung der Verbindlichkeiten führt häufig zu einem System, das entweder unnötig kompliziert und / oder überentwickelt ist. Ein grundlegendes Verständnis von JMS und seinen inhärenten Eigenschaften (systemunabhängige Eigenschaften), gefolgt von einer sorgfältigen Analyse in Bezug auf bestimmte Szenarien mit verteilten Systemen, kann zeigen, wie gut JMS Systemanforderungen lösen kann, anstatt bestehende Probleme zu ändern oder sogar neue einzuführen.

JMS-Übersicht

JMS, das 1999 von Sun Microsystems als Teil der Java 2 Platform Enterprise Edition (J2EE) -Spezifikation eingeführt wurde, ist eine Reihe von Standards, die die Grundlagen für eine Middleware-Schicht für die Nachrichtenverarbeitung beschreiben. Mit JMS können Systeme synchron oder asynchron über Punkt-zu-Punkt- und Publish-Subscribe-Modelle kommunizieren. Heutzutage bieten mehrere Anbieter JMS-Implementierungen wie BEA Systems, Hewlett-Packard, IBM, Macromedia und Oracle an, sodass JMS mit Technologien mehrerer Anbieter interagieren kann.

Abbildung 1 zeigt ein einfaches JMS-basiertes System mit einer ausgehenden Warteschlange, die mit Nachrichten gefüllt ist, die von Clients verarbeitet werden sollen, und einer eingehenden Warteschlange, in der die Clientverarbeitungsergebnisse zum Einfügen in eine Datenbank erfasst werden.

Wie oben erwähnt, ermöglicht MOM (wie JMS) eine lockerere Kopplung innerhalb verteilter Systeme, indem Übersetzung, Sicherheit und die zugrunde liegenden Kommunikationsprotokolle von den Clients und Servern abstrahiert werden. Eine der Hauptvorteile der Nachrichtenverarbeitungsschicht besteht darin, dass sich die Implementierung des Clients oder des Servers aufgrund der Einführung dieser Abstraktionsschicht manchmal radikal ändern kann, ohne andere Systemkomponenten zu beeinträchtigen.

Zwei spezifische Szenarien

In diesem Abschnitt stelle ich zwei verteilte Systeme vor, die potenzielle Kandidaten für JMS sind, und erkläre die Ziele jedes Systems und warum die Systeme JMS-Kandidaten sind.

Szenario 1

Der erste Kandidat ist ein verteiltes Codierungssystem (in Abbildung 2 dargestellt). Dieses System verfügt über eine Reihe von N Clients, die Codierungsaufträge von einem zentralen Datenbankserver abrufen. Die Clients führen dann die eigentliche Umwandlung (Codierung) vom digitalen Master in codierte Dateien aus und melden abschließend ihren Nachbearbeitungsstatus (z. B. Erfolg / Misserfolg) an den zentralen Datenbankserver zurück.

Die Arten der Codierung (z. B. Text, Audio oder Video) oder Transformationen (z. B. .pdfzu .xml, .wavzu .mp3, .avizu .qt) spielen keine Rolle. Es ist wichtig zu verstehen, dass die Codierung CPU-intensiv ist und eine verteilte Verarbeitung auf mehrere Clients erfordert, um skaliert zu werden.

Auf einen Blick ist dieses System ein potenzieller JMS-Kandidat, weil:

  • Die Verarbeitung muss verteilt werden, da sie extrem prozessorintensiv (CPU) ist
  • Unter dem Gesichtspunkt der Systemleistung kann es problematisch sein, mehrere Clients direkt mit einem einzelnen Datenbankserver zu verbinden

Szenario 2

Das zweite JMS-Kandidatensystem ist ein globales Registrierungssystem für ein Internetportal. Die globale Registrierung verarbeitet Anforderungen für die Erstellung neuer Benutzer (Registrierung), die Anmeldung und die Authentifizierung.

Spezifische Registrierungsinformationen (z. B. Name, Adresse, bevorzugte Farbe) und Benutzerauthentifizierungsmethoden (z. B. serverseitige Benutzerobjekte, HTTP-Cookies) sind unwichtig. Es ist jedoch wichtig, dass dieses System für Millionen von Benutzern skaliert werden kann und dass Nutzungsmuster schwer, wenn nicht unmöglich vorherzusagen sind. (Während eines im Fernsehen übertragenen ESPN-Weltcup-Spiels sagt der Ansager: "Melden Sie sich an und stimmen Sie in unserer Online-Umfrage ab. Wir werden die Ergebnisse am Ende der Show präsentieren." Plötzlich melden sich 500.000 Benutzer innerhalb von drei Minuten an Intervall 3 Minuten = 180 Sekunden; 500.000 Benutzeranmeldungen / 180 Sekunden = 2.778 Benutzeranmeldungen / Sek.)

Dieses System ist aus folgenden Gründen ein potenzieller JMS-Kandidat:

  • Das System muss verteilt werden, um das Transaktionsvolumen zu skalieren
  • Transaktionen sind atomar (z. B. Login), daher sind sie zustandslos und daher Kandidaten für die Verteilung

Die beiden Systeme sind architektonisch gleich. Mehrere Clientcomputer extrahieren Daten von einem zentralen Datenbankserver (möglicherweise auf M schreibgeschützte Datenbankserver repliziert ), führen eine Logik auf dem Client aus und melden den Status dann an den zentralen Datenbankserver zurück. Ein System liefert verschlüsselte Dateien über UNC / FTP an ein Dateisystem. Der andere liefert HTML-Inhalte über HTTP an Webbrowser. Beide Systeme sind verteilt.

Dies ist so weit, wie viele Ingenieure ihre Analysen durchführen, bevor sie JMS anwenden. Im Rest dieses Artikels erkläre ich, dass, obwohl diese Systeme viele Merkmale gemeinsam haben, die Angemessenheit von JMS klarer und unterschiedlicher wird, wenn wir die Anforderungen jedes Systems untersuchen, einschließlich Systemleistung, Datenverteilung und Skalierbarkeit.

Systemanalyse: Integrieren oder nicht integrieren

JMS hat intrinsische, systemunabhängige Eigenschaften. Einige dieser Eigenschaften (Vorzeichen mit +, Nachteile mit -), die für beide Systeme gelten, umfassen:

  • (+) JMS ist eine Reihe von Standards, die von Implementierungen mehrerer Anbieter erstellt wurden. Daher vermeiden Sie das gefürchtete Problem der Lieferantenbindung .
  • (+) JMS ermöglicht die Abstraktion (über eine generische API) zwischen Client und Server. Sie können ein Datenbankschema oder eine Plattform ändern, ohne die Anwendungsschicht zu ändern (implizit sind hier andere potenzielle Systemänderungen enthalten, die durch die Messaging-Schicht voneinander isoliert sind).
  • (+) / (-) JMS kann einer Systemskalierung helfen (ein Profi). Der Nachteil ist, dass jedes System, das mit JMS skaliert, ohne JMS skalieren kann.
  • (-) JMS ist kompliziert. Es ist eine völlig neue Ebene mit neuen Servern. Software-Rollout-Management, Serverüberwachung und Sicherheit sind nur einige der nicht trivialen Probleme, die mit einem JMS-Rollout verbunden sind. Kosten sollten ebenfalls berücksichtigt werden.
  • (-) Anbieter interpretieren und implementieren Standards nicht immer genau gleich, sodass Unterschiede zwischen verschiedenen Implementierungen bestehen.
  • (-) Mit JMS benötigen Sie mehr Systemprüfungen. Sie führen nicht nur eine neue Ebene ein, sondern auch eine asynchrone Datenverteilung und -bestätigung, die die zusätzliche Komplexität einer asynchronen Benachrichtigung mit sich bringt.
  • (-) Keine Nachrichtenberichterstellungs- / Aktualisierungs- / Überwachungswarteschlangen ohne benutzerdefinierte Software.

JMS hat auch systemabhängige Eigenschaften. Die Angemessenheit von JMS hängt davon ab, wie gut diese Eigenschaften dem Problem entsprechen, das Sie lösen möchten. Einige dieser Eigenschaften und ihre Beziehung zu den beiden interessierenden Systemen folgen:

Caching

Caching ist eine wichtige Überlegung für die Kapazitätsplanung in einem verteilten System. JMS verfügt über viele Funktionen, die die Verwendung als Caching-Technologie ermöglichen (hauptsächlich verteilte, synchrone oder asynchrone Funktionen sowie Datenaustausch als Objekte in Nachrichten). Daher kann eine vorhandene JMS-Installation bei Bedarf als Caching-Infrastruktur genutzt werden.

Wenn Sie das Codierungssystem in Betracht ziehen, ist das Caching im Allgemeinen nicht hilfreich, um die Gesamtsystemleistung zu steigern, da die meisten Dateiumwandlungen einmal ausgeführt werden und auf eine Hosting-Einrichtung oder ein SAN (Storage Area Network) verschoben werden und es nur geringe inhaltliche Überschneidungen zwischen Kunden gibt. Die globale Registrierung ist ein Hauptkandidat für einen Benutzerinformations-Cache, da sich Benutzer normalerweise anmelden, durchsuchen und sich dann abmelden. Durch die Anmeldung wird der Cache-Eintrag eines Benutzers erstellt, und dieses Objekt bietet eine nachfolgende Benutzerauthentifizierung, während sich der Benutzer auf der Site befindet.

Bearbeitungsauftrag

Innerhalb des globalen Registrierungssystems gibt es keine Planung und / oder Bestellung für die Transaktionsverarbeitung. Pseudozufällige Benutzer betreten das System beim Anmelden in pseudozufälligen Intervallen, durchsuchen Inhalte (und werden daher authentifiziert, wenn sie auf eingeschränkte Inhalte und / oder Anwendungen zugreifen) und melden sich dann ab.

Innerhalb des Codierungssystems wird die Verarbeitung angeordnet. Inhaltsstapel werden je nach Verfügbarkeit des Wechselspeichers (z. B. DLT Solutions oder Network Appliance-Speicher) zur Bereitstellung in Gruppen zusammengefasst. Der Inhalt wird erst geliefert, wenn der Stapel vollständig ist. Daher müssen die Stapel in der richtigen Reihenfolge ausgeführt werden (obwohl Transformationen innerhalb eines Stapels möglicherweise ungeordnet sein können). Die Implementierung von Prioritätswarteschlangen in JMS zur Beibehaltung der Verarbeitungsreihenfolge ist möglich, die Beibehaltung dieser Reihenfolge von Nachrichtenstapeln zwischen mehreren JMS-Servern und mehreren Warteschlangen wird jedoch recht kompliziert. Ein relationaler Datenbankserver mit Unterstützung für Transaktionen ist eine geeignetere Technologie zur Verwaltung dieses Workflows.

Sicherheit

Sicherheit ist nicht Teil der JMS-Spezifikation. Das Sicherheitsproblem wird bei einer JMS-basierten Implementierung nicht unbedingt geändert (wenn Sie vor JMS eine Sicherheitsanforderung haben, haben Sie nach JMS eine ähnliche Sicherheitsanforderung). In diesem Wissen ist es wichtig zu verstehen, wie sich JMS auf die vorhandene Infrastruktursicherheit auswirkt.

Je mehr Technologie Sie verwenden, desto anfälliger wird Ihr System im Allgemeinen für Hacker und Sicherheitsverletzungen. Da der globale Registrierungsanwendungsserver mit dem Internet verbunden ist, werden Sicherheitslücken, die in der JMS-Implementierung Ihrer Anbieter entdeckt und in Internet-Newsgroups veröffentlicht wurden, schnell zu Sicherheitsrisiken für Ihre Website. Da es sich bei JMS um eine generische API handelt, ist es anfälliger für Sicherheitsverletzungen als ein proprietäres System, das eine unveröffentlichte API verwendet.

Während Sie Ihre vorhandene Firewall- und IP-basierte Netzwerksicherheit nutzen können, um Ihre Back-End-Anwendungs- und Datenbankserver (sprich: nicht mit dem Web verbunden - Wortspiel beabsichtigt) vor Sicherheitsverletzungen zu schützen, besteht ein erhebliches Sicherheitsrisiko, das durch das Offenlegen von JMS-Anwendungsservern entsteht direkt ins Internet.

Das Codierungssystem befindet sich im Allgemeinen im selben Netzwerk (auch in einem vom Internet isolierten Netzwerk). Die Netzwerktopographie dieses Systems, die sich auf JMS bezieht und diese Topographie nutzt, um Sicherheit zu bieten, ist also nicht inhärent (es gibt weitaus weniger Sicherheitsanforderungen für das Codierungssystem, da es nicht mit dem Internet verbunden ist).

Skalierbarkeit

Da das globale Registrierungssystem den Launen einer großen und launisch klickenden Benutzerbasis unterliegt, rechtfertigen die Skalierbarkeitsanforderungen des Systems JMS. JMS hilft nicht nur bei der Skalierung des Systems, sondern stellt auch Transaktionen in die Warteschlange, obwohl es nicht sehr hilfreich ist, wenn Benutzeranforderungen das System überfluten.

Da das verteilte Codierungssystem den Datenverkehr sorgfältig reguliert hat (da es sich vermutlich um ein in sich geschlossenes System handelt), sind die Anforderungen an die Skalierbarkeit des Systems nicht so hoch. Bei der verteilten Codierung können Sie Ihre O[100]Clients direkt mit Ihrer Datenbank verbinden und deren Datenverkehr drosseln, um den Codierungsdurchsatz mit der Leistung des Datenbankservers in Einklang zu bringen.

Performance

Die Einführung eines einzelnen JMS-Servers kann Leistungsprobleme ändern, anstatt sie zu lösen. Aus diesem Grund sollte ein JMS-System mit mehreren JMS-Servern (und daher mehreren Warteschlangen) entworfen werden. Abbildung 4 zeigt, warum Leistungsprobleme geändert anstatt gelöst werden. Es zeigt die Verarbeitungsschichten, die ein generischer Datenserver benötigt, um auf Clientverbindungsanforderungen zu antworten:

Der Datenaustausch zwischen Client und Server besteht aus zwei Teilen, unabhängig davon, ob es sich um einen Client-zu-Datenbank- oder einen Client-zu-JMS-Server handelt:

  1. Datenzugriff
  2. Thread- und Socket-Verwaltung, Pooling und Caching

Ein JMS und ein Datenbankserver sehen genau gleich aus (Abbildung 4). Sie übernehmen Socket-Verbindungen, Thread-Verwaltung und den Zugriff auf die Serverdaten.

Mit nur einem JMS-Server werden potenzielle Leistungsprobleme einfach vom Datenbankserver zum JMS-Server übertragen. Zusätzlich zu möglichen Leistungseinbußen im Zusammenhang mit der Kontextumschaltung auf Ihrem Datenbankserver sind Leistungsprobleme aufgrund von JVM-Leistungsproblemen auf Ihrem JMS-Server jetzt möglicherweise größer.

Ein einzelner JMS-Server erhöht die Komplexität Ihres Systems erheblich und kann auch zu Leistungsproblemen führen, die mit der Verbindung mehrerer Clients zu einem einzelnen Server verbunden sind. Die Auswirkungen mehrerer JMS-Server auf Ihr Systemdesign und Ihren Datenfluss können den Unterschied zwischen einem erfolgreichen oder fehlgeschlagenen System-Rollout ausmachen.

Zusammenfassend lässt sich sagen, dass Funktionen im Vergleich zu potenziellen JMS-Auswirkungen folgendermaßen aussehen:

Funktionen im Vergleich zu JMS-Auswirkungen