Muster - Übersicht

IBM® SOA Policy Pattern leitet MQ-JMS-Nachrichten in Abhängigkeit von den Daten in den Richtliniendokumenten weiter, die von einer Service-Registry abgerufen werden.

IBM SOA Policy Pattern for Red Hat Enterprise Linux V2.0 stellt die IPAS-Hardware (IBM PureApplication System) bzw. IBM Workload Deployer (IWD) bereit und verwaltet diese, um die folgenden Features bereitzustellen, die als Teil des Musters vorkonfiguriert sind:

Welche Szenarios ermöglicht dieses Muster?

MQ-JMS-Anwendungen senden Nachrichten an die JMS-Eingabewarteschlange für dieses Muster; diese Nachrichten werden an eine andere MQ-JMS-Warteschlange gesendet, in Abhängigkeit davon, welche Richtlinie dieser Eingabenachricht entspricht. Das Muster verwendet JMS-Headerdaten, um zu entscheiden, welche Richtlinien gültig sind, und bewertet diese Richtlinien anschließend, um festzustellen, wohin die Nachricht weitegeleitet wird. Zur Bestätigung, dass die Nachricht weitergeleitet wurde, wird eine Rückantwort an die sendende JMS-Anwendung gesendet. Daraus ergibt sich, dass das Muster viele JMS-Anwendungen gleichzeitig unterstützen kann, wobei für jede ihre eigenen, durch eine Reihe von Richtlinien ausdrückten, Routing-Regeln gelten.

Richtlinien geben den Plan in Uhrzeiten eines Tages und in Tagen der Woche usw. an, um Nachrichten an unterschiedliche Endpunktziele weiterzuleiten. Dieses Muster unterstützt keine anderen Bedingungen oder Aktionen. Das Muster arbeitet mit dem Standard 'WS-MediationPolicy', um festzulegen, wie und wann Nachrichten weitergeleitet werden. Der Namensbereich für diesen Standard ist http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation. Die Domäne Web Services Mediation Policy 1.0 definiert eine Reihe von Richtlinienzusicherungen für die Beschreibung von Mediationsanforderungen für einen Service.

Jede Richtlinie ist Teil des SOA-Richtlinienlebenszyklus. Angewendete Richtlinien müssen die Governance-Zustände 'Genehmigt', 'Veraltet' oder 'Außer Kraft gesetzt' aufweisen. Weitere Informationen finden Sie in Richtlinienverwendung in IBM SOA Policy Pattern.

Was umfasst das Muster?

IBM SOA Policy Pattern ist ein Beispiel eines Musters eines virtuellen Systems. Das Muster eines virtuellen Systems besteht aus einer Sammlung von Teilen. Jedes Teil ist das Image eines virtuellen Betriebssystems mit einer installierten IBM Software, die auf der Grundlage von Musterparametern konfiguriert wurde, die während des Bereitstellungsprozesses angegeben wurden.

Dieses Muster stellt drei Teile bereit:
  • Ein Image mit WebSphere Message Broker V8.0.0.1 und WebSphere MQ V7.0.1.8.
  • Ein Image mit WebSphere Service Registry and Repository V8.0 und WebSphereApplication Server V8.0.
  • Ein Image mit DB2 Enterprise Edition V9.7.5 (zur Unterstützung von WSRR).
Wenn die IBM PureApplication System-Hardware oder der IBM Workload Deployer-Benutzer eine Instanz von IBM SOA Policy Pattern erstellt, um eine vorkonfigurierte ESB bereitzustellen, werden aus diesen Teilen drei Images erstellt. In der folgenden Abbildung wird diese Konfiguration veranschaulicht:
Abbildung 1. IBM SOA Policy Pattern - ÜbersichtEin Diagramm, das die Konfiguration darstellt, die im oberen Abschnitt erläutert wird.
Für die Erstellung dieser Konfiguration führt der Benutzer die folgenden Komponenten aus:
  1. Einen WebSphere MQ-Warteschlangenmanager für die Bereitstellung von JMS-Services und damit JMS-Programme eine Verbindung zu dem Muster herstellen können.
  2. Ein vorkonfigurierter WebSphere Message Broker für das Routing zwischen JMS-Zielen.
  3. Eine vorkonfigurierte WSRR-Instanz für die Definition und Verwaltung der Richtlinien, die das Routing steuern.
  4. Eine DB2-Instanz zur Unterstützung von WSRR.
  5. Die browserbasierte Benutzerschnittstelle von IBM Workload Deployer oder IBM PureApplication System für die Implementierung des Musters.
  6. Die browserbasierte Benutzerschnittstelle von Business Space für die Erstellung und Verwaltung von Richtlinien.

In welche anderen Anwendungen ist eine Integration möglich?

Sie können Ihre eigenen Richtliniendokumente in WSRR laden; diese Richtlinien definieren ihre eigenen JMS-Endpunktziele. Bei der Erstkonfiguration wird die Registry mit zwei Beispielrichtlinien geladen, die zwei Beispielendpunkte verwenden. Die in IBM SOA Policy Pattern enthaltene WebSphere Message Broker-Konfiguration stellt einen Nachrichtenfluss bereit, der JMS-Nachrichten aus einer Eingabewarteschlange liest und auf der Grundlage der aus der Registry abgerufenen Richtlinien die Nachrichten an Ausgabewarteschlangen weiterleitet.

IBM SOA Policy Pattern enthält einen JMS-Provider, aber keine JMS-Anwendungen; daher müssen Sie Ihre vorhandenen MQ-JMS-Anwendungen zur Vervollständigung der Lösung hinzufügen. JMS-Ziele werden über standardmäßige WebSphere MQ-Prozeduren definiert. Sie können sich aussuchen, wie Ihre MQ-JMS-Anwendungen eine Verbindung zur Steuerung der Art der Nachrichtentopologie herstellen werden, die erstellt werden soll; mithilfe von MQ-Clientbindungen ist eine ferne Verbindung zu einem einzelnen Warteschlangenmanager möglich, der von diesem Muster gehostet wird, oder sie können verteilte MQ-Messagingverfahren anwenden, um Nachrichten aus einem vorhandenen fernen Warteschlangenmanager in den Musterwarteschlangenmanager einzuspeisen.

Wie wird das Nachrichtenrouting gesteuert?

Wenn das Muster instanziiert worden ist, wird das Routing-Verhalten von einem Richtlinienadministrator gesteuert, der Business Space (das mit WSRR bereitgestellt wird) für die Definition und Verwaltung von Richtlinien verwendet, die die Routing-Anforderungen erfüllen. Für jede Richtlinie muss ein JMS-Ziel vorhanden sein; daher muss ein Messagingadministrator sicherstellen, dass jeder in einer Richtlinie definierte JMS-Endpunkt ebenfalls im Messagingsubsystem vorhanden ist. Weitere Informationen finden Sie in Mit der implementierten Instanz arbeiten.


Informationen Informationen

Feedback


Timestamp icon Letzt aktualisiert: 16. Oktober 2012


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawmbwsrr.doc/topics/pattern_overview.htm