Implementieren Sie einen anpassbaren ESB mit Java

Stellen Sie sich ein Unternehmen vor, in dem Sie heterogene Anwendungen haben, die möglicherweise von verschiedenen Teams bereitgestellt werden und miteinander interagieren müssen, aber die folgenden Einschränkungen aufweisen:

  • Jede Anwendung wird nicht unbedingt mit derselben Technologie erstellt und kommuniziert möglicherweise nicht mit den anderen über ihren nativen Aufrufmechanismus, z. B. eine J2EE-Anwendung und eine .Net-Anwendung.
  • Vorzugsweise sollte jede Anwendung ihre Anforderungen nicht in das Format umwandeln, das von der Zielanwendung verstanden wird. Darüber hinaus verfügt das Unternehmen über viele Anwendungen, die die Zielanwendung verwenden.
  • Servicekomponenten sollten einen für sie natürlichen Aufruf- oder Anforderungsmechanismus verwenden. Beispielsweise kann eine vorhandene J2EE-Anwendung Anforderungen nur über den Java Message Service (JMS) entgegennehmen.
  • Das Unternehmen bewegt sich in Richtung einer Architektur, in der sich eine Anwendung nur mit dem einen befasst, was es weiß und zweitens, was es als Parameter übergeben soll, wenn es die Dienste einer anderen Anwendung innerhalb des Unternehmens erhalten möchte.

Für andere Einschränkungen ist möglicherweise eine Infrastruktur erforderlich, mit der heterogene Anwendungen nahtlos integriert werden können, ohne das Design zu ändern. Ein Enterprise Service Bus (ESB) ist eine Möglichkeit, eine solche Enterprise-Integrationsarchitektur zu realisieren.

Obwohl jedes Unternehmen seinen ESB wahrscheinlich auf seine eigene Art und Weise erstellen wird, ist es wichtig, die Flexibilität zu berücksichtigen, wenn die Definition eines ESB in Betracht gezogen wird. Es gibt keinen festen Ansatz, um einen zu bauen. Die Idee ist eine Konnektivitätsschicht, die die Interaktionen zwischen Dienstkonsumenten und Dienstanbietern optimiert und auf ereignis-, nachrichten- oder dienstorientierte Kontexte reagieren kann.

Dieser Artikel beschreibt einen Ansatz zum Erstellen eines erweiterbaren Java-basierten ESB, der die häufigsten funktionalen ESB-Anforderungen unterstützt.

Gemeinsame ESB-Anforderungen

Die allgemeinen Anforderungen eines ESB sind auch seine am häufigsten verwendeten Merkmale:

  1. Routing: Der ESB sollte einen effizienten und flexiblen Routing-Mechanismus bieten.
  2. Transformation: Eine Dienstkomponente sollte das Anforderungsformat des Zieldienstes, den sie möglicherweise aufruft, nicht kennen müssen. Basierend auf dem Anforderer und dem Ziel sollte der ESB in der Lage sein, die entsprechende Transformation auf die Anforderung anzuwenden, damit das Ziel sie verstehen kann.
  3. Multiprotokoll-Transport: Eine ESB-Implementierung, die nur JMS oder nur Webdienste kommuniziert, ist nicht von großem Wert. Es sollte erweiterbar genug sein, um je nach Unternehmensanforderungen mehrere Nachrichtenprotokolle zu unterstützen.
  4. Sicherheit: Bei Bedarf sollte der ESB die Authentifizierung und Autorisierung für den Zugriff auf verschiedene Dienstkomponenten erzwingen.

Abbildung 1 zeigt die wichtigsten Architekturkomponenten eines ESB. Es hat drei breite Fächer:

  1. Empfänger: Ein ESB stellt verschiedene Schnittstellen bereit, damit die Clientanwendungen Nachrichten an den ESB senden können. Beispielsweise könnte ein Servlet die HTTP-Anforderungen für den ESB empfangen. Gleichzeitig kann eine MDB (Message Driven Bean) ein JMS-Ziel abhören, an das Clientanwendungen Nachrichten senden können.
  2. Kern: Dies ist der Hauptteil der ESB-Implementierung. Es übernimmt das Routing und die Transformation und wendet Sicherheit an. In der Regel besteht es aus einer MDB, die eingehende Anforderungen empfängt und dann basierend auf dem Nachrichtenkontext die entsprechende Transformation, das entsprechende Routing und die entsprechende Sicherheit anwendet. Details zu Routing-, Transport-, Transformations- und Sicherheitsinformationen können in einem XML-Dokument angegeben werden (wird in Kürze erläutert).
  3. Dispatcher: Alle ausgehenden Transportabfertiger fallen unter diesen Teil des ESB. Sie können einen beliebigen Transport-Handler (E-Mail, Fax, FTP usw.) an den ESB anschließen.

Alle diese ESB-Teile werden durch ein XML-Dokument zusammengeklebt, in dem alle Routen aufgeführt sind, auf denen der ESB arbeitet. Die verschiedenen Transporthandler, Transformatoren und Wiederholungsrichtlinien sowie ihre Verbindung zu verschiedenen Routen sind alle über dieses XML-Dokument miteinander verbunden.

ESBConfiguration.xml

Die XML-Liste ESBConfiguration.xml, die unten angezeigt wird , gibt uns einen Eindruck von der Funktionsweise eines ESB. Die wichtigsten Elemente von Interesse ESBConfiguration.xmlsind die folgenden:

  1. Beans: Dieses Element enthält null oder mehr BeanElemente.
  2. Bean: Dieses Element definiert im Wesentlichen die Art und Weise, wie wir eine BeanKlasse erstellen und konfigurieren . Es hat die folgenden Attribute:
    • name: Eindeutiger Name, der verwendet werden kann, um auf diese Bean zu verweisen.
    • className: Vollqualifizierter Name der Bean-Klasse.
    Jede Bohne kann Propertyals Kinder null oder mehr Elemente haben. Jedes PropertyElement verfügt über ein Attribut name, das es identifiziert, und ein untergeordnetes Element vom Typ Value, das den Eigenschaftswert enthält. Diese Eigenschaften sind tatsächlich die JavaBeans-artigen Mitglieder der Klasse, die die Bean-Klasse konfigurieren können.
  3. RetryPolicies: Dieses Element enthält null oder mehr RetryPolicyuntergeordnete Elemente .
  4. RetryPolicy: Dieses Element definiert die Wiederholungsrichtlinie für eine bestimmte Route. Es hat ein Attribut name, mit dem darauf verwiesen werden kann. Es hat zwei untergeordnete Elemente mit dem Namen MaxRetriesund RetryInterval.
  5. Route: Das EsbConfigurationStammelement kann null oder mehr untergeordnete Elemente dieses Typs enthalten. Es stellt im Grunde eine Route für den ESB dar. Es hat die folgenden Attribute:
    • name: Eindeutiger Name, der verwendet werden kann, um auf diese Route zu verweisen.
    • retryPolicyRef: Verweis auf die Wiederholungsrichtlinie. Es sollte mit dem Attribut des RetryPolicyElements übereinstimmen name.
    • transformerRef: Verweis auf eine Bean, die den Transformator darstellt. Es sollte mit dem Attribut des BeanElements übereinstimmen name.
    Das RouteElement kann ein oder mehrere untergeordnete Elemente vom Typ haben TransportHandlerRef. Dieses untergeordnete Element verweist im Wesentlichen auf eine Bean, die einen geeigneten Transporthandler darstellt, der für diese Route verwendet werden soll, und auf den öffentlichen Methodennamen dieser Bean, die zum Senden der Nachricht aufgerufen werden soll. Optional kann das RouteElement ein untergeordnetes Element haben, das auf eine DeadLetterDestinationandere Route verweist, die ein Ziel mit toten Buchstaben darstellt.

Ein Beispiel für ein XML-Dokument wird EsbConfiguration.xmlunten angezeigt:

                              qcf-1   myCreditQueue     //www.tax.com/calc      file:///C:/temp/esb/transform/xsl/credit.xsl     file:///C:/temp/esb/transform/custom/configManager.properties      qcf-1   Redelivery.Queue     qcf-1   System.DL.Queue     qcf-1   System.Error.Queue     qcf-1   Redelivery.Request.Topic       10 100   10 500    

ESB-Verhalten

Das ESBConfiguration.xmlDokument bestimmt das Verhalten unseres ESB. Die EsbRouterMDB lädt dieses XML von einem Speicherort, der in ihrem Bereitstellungsdeskriptor angegeben ist. Die darin enthaltenen Informationen werden dann in einer Datenstruktur organisiert, die in Abbildung 2 dargestellt ist.

Der EsbRouterverwendet diese Informationen (über EsbConfigManager), um die geeignete Route, die gegebenenfalls anzuwendende Transformation, die Sicherheitsautorisierungsprüfung usw. zu entschlüsseln. Der wichtige zu beachtende Punkt ist die Art und Weise, wie die Abhängigkeitsinjektionstechnik zusammen mit der Vererbung verwendet wurde Entkoppeln verschiedener Funktionen (wie Multiprotokoll-Nachrichtentransport und Nachrichtentransformation) des ESB, wodurch dieser in hohem Maße erweiterbar und anpassbar ist.

Wie das Klassendiagramm zeigt, befinden sich im ESB-Design zwei wichtige Schnittstellen: TransformHandlerund TransportHandler. Mit ihnen können Sie eine bestimmte Transformations- und Transportimplementierung für weitergeleitete Nachrichten schreiben. Diese Implementierungsklassen können dann über BeanElemente in mit den Routen verbunden werden EsbConfiguration. Im Beispieldokument gibt EsbConfiguration.xmldie folgende Bean-Definition beispielsweise den Transporthandler an:

   myQCF   myCreditQueue   

Auf diesen Transporthandler kann dann in einem RouteKnoten verwiesen werden, indem ein untergeordnetes Element wie folgt eingefügt wird TransportHandler:

Hinweis
Der in diesem Artikel beschriebene Ansatz verwendet Java-Schnittstellen zum Definieren der Transport- und Transformationshandler. Daher müsste jeder neue Handler die erforderliche Schnittstelle implementieren, was aufdringlich erscheinen könnte. Sie können die EsbConfigManagerVerwendung von Dependency Injection zum Aufrufen einer beliebigen Methode einer Implementierungsklasse leicht ändern , sodass keine Schnittstelle implementiert werden muss. Da aber die EsbRouterimmer passiert javax.jms.MessageBeispiel muss der Handler Implementierungsklasse die Art verwenden javax.jms.Messagesowieso.