JMS-Zieladressen, die Nachrichten an einen JMS-Empfangsknoten senden oder Nachrichten von einem JMSSendeknoten empfangen, können als Teil einer globalen Nachrichtenfluss-Transaktion der Synchronisationspunktsteuerung unterliegen.
In de folgenden Abbildung werden Nachrichten aus einem Thema von einem JMSEmpfangsknoten empfangen und an die JMS-Warteschlange eines JMSSendeknotens ausgegeben. Die Knoten werden mit einem JMS-Provider verbunden und unterhalten eine Sitzung mit diesem. Jeder Empfangsknoten im Nachrichtenfluss kann den externen Koordinator der Synchronisationspunktsteuerung darüber informieren, wann ein Nachrichtenfluss beginnt und endet, und ob Ressourcen, die von dem Fluss betroffen sind, festgeschrieben oder zurückgesetzt werden sollen.
IMAGE HERE
Der Koordinator der Synchronisationspunkt sendet XA/Open-kompatible Anforderungen an alle teilnehmenden Ressourcenmanager zu deren Vorbereitung, und anschließend werden Änderungen festgeschrieben oder zurückgesetzt. Ressourcenmanager wie beispielsweise WebSphere MQ, DB2 und alle XA-kompatiblen JMS-Provider können an einer globalen Transaktion mitwirken. Als externer Koordinator der Synchronisationspunktsteuerung fungiert auf verteilten Plattformen WebSphere MQ und unter z/OS RRS (Resource Recovery Services).
Der JMSEmpfangsknoten und der JMSSendeknoten können nur an einer globalen Transaktion mitwirken, wenn der JMS-Provider, mit dem sie sich verbinden, die XA/Open-Schnittstelle über die JMS-Klasse XAResource unterstützt. Der WebSphere MQ Java Client ist beispielsweise ein solcher JMS-Provider.
Während des Starts des WebSphere MQ-Warteschlangenmanagers des Brokers wird eine erste Fehlerbehebungsmaßnahme durchgeführt, um sicherzustellen, dass alle unbestätigten Transaktionen aufgelöst werden, bevor die Nachrichtenflüsse des Brokers mit der Verarbeitung neuer Eingaben beginnen. Unbestätigte Transaktionen können auftreten, wenn ein Ressourcenmanager nicht auf einen Aufruf des Synchronisationspunktmanagers zur Festschreibung oder Rücksetzung von Ressourcen antwortet. Ein JMS-Provider, der an globalen Brokertransaktionen mitwirkt, wird während des Starts des Broker-WS-Managers in diese Fehlerbehebungsmaßnahme aufgenommen.
Die Switch-Datei leitet XA/Open-Transaktionsaufrufe vom Koordinator der Synchronisationspunktsteuerung an den JMS-Provider weiter. Auf diese Weise wird sichergestellt, dass die JMS-Ressourcen, die an der Transaktion mitwirken, bezüglich der Synchronisation mit anderen Ressourcenmanagern in derselben Transaktion koordiniert werden können.
XAResourceManager: Name=WBIWMQJMS SwitchFile=/<Installationspfad>/lib/JMSSwitch.so XAOpenString=<Ausgangskontextfactory>, <Position der JNDI-Bindungen>, <LDAP-Principal>, <LDAP-Berechtigungsnachweise>, <Name der Wiederherstellungs-Verbindungsfactory> ThreadOfControl=THREADDabei ist
<Installationspfad> die Position der WebSphere Broker-Installation. Dieser Wert ist obligatorisch. Die in XAOpenString übergebenen Parameter sind durch Kommas getrennt und positionsgebunden. Fehlende optionale Parameter müssen durch ein Komma dargestellt werden, wenn weiter hinten in der Zeichenfolge sonstige Parameter angegeben werden.
<Ausgangskontext> ist die ID für die Ausgangskontext-Factory für den JMS-Provider. Dieser Wert ist obligatorisch.
<Position der> ist entweder der Dateipfad zur Datei .bindings (ohne Angabe des Dateinamens selbst) oder der Pfad des LDAP-Verzeichnisses der von JNDI verwalteten Objekte, die zur Erstellung einer Ausgangskontext-Factory für die JMS-Verbindung verwendet werden kann. Die Abschnitte zum JMSEmpfangs- oder JMSSendeknoten enthalten detaillierte Informationen zur Erstellung der von JNDI verwalteten Objekte. Dieser Wert ist obligatorisch.
<LDAP-Principal> ist ein optionaler Parameter zur Angabe des Principals (Benutzer-ID), der erforderlich sein kann, wenn eine LDAP-Datenbank zum Speichern der von JNDI verwalteten Objekte verwendet wird.
<LDAP-Berechtigungsnachweise> ist ein optionaler Parameter zur Angabe der Berechtigungsnachweise (Kennwort), die erforderlich sein können, wenn eine LDAP-Datenbank zum Speichern der von JNDI verwalteten Objekte verwendet wird. Dieser Parameter ist durch ein Kennwort geschützt.
<Wiederherstellungs-Factory> ist ein optionaler Parameter zur Angabe des Namens eines Wartenschlangenverbindungsfactory-Objekts in den von JNDI verwalteten Objekten zur Wiederherstellung, wenn der vom Standard abweichende Name erforderlich ist.
Sie müssen für jeden zu verwendenden JMS-Provider eine Zeilengruppe in der ".ini"-Datei des Warteschlangenmanagers des Brokers angeben. Das bedeutet, es sollte eine Zeilengruppe für jeden neuen JMS-Provider vorhanden sein, die von jedem JMSEmpfangs- oder JMSSendeknoten in einem Nachrichtenfluss angegeben werden kann, der auf diesem Broker ausgeführt wird.
Die Werte für 'Ausgangskontextfactory' und 'Position der JNDI-Bindungen' in der Zeilengruppe müssen den Werten entsprechen, die in den JMSEmpfangs- oder JMSSendeknoten in den Nachrichtenflüssen angegeben sind.
Auf ähnliche Weise gilt, dass alle LDAP-Parameter denen entsprechen müssen, die für diesen Broker mit dem Befehl 'mqsicreatebroker' oder 'mqsichangebroker' angegeben werden.
Der Name der Wiederherstellungsfactory muss dem Namen einer Wartenschlangenverbindungsfactory entsprechen, die in den von JNDI verwalteten Objekten erstellt wurde. Wird kein Wert angegeben, wird eine Standardwertfactory mit der Bezeichnung "recoveryQCF" verwendet. In jedem Fall muss es sich bei diesem Wert um ein zuvor erstelltes, von JNDI verwaltetes Objekt handeln. Beispiel:
XAOpenString=com.sun.jndi.fscontext.RefFSContextFactory, /u/myJndiFileLocation, , , myRecoveryQCFNameWenn für die LDAP-Parameter keine Angabe erfolgt, zur Wiederherstellung jedoch eine benutzerdefinierte Wartenschlangenverbindungsfactory angegeben wird.
Es sind dieselben Informationen erforderlich, werden jedoch mit dem Snap-in 'WebSphere MQ Services' konfiguriert, um die Details zur Registry hinzuzufügen. In diesem Fall heißt die Switch-Datei JMSSwitch.dll. Weitere Informationen zur Aktualisierung der Datei 'qm.ini' finden Sie im Handbuch 'WebSphere MQ System Administration Guide'. In diesem Fall sollte ein zusätzlicher “Zeilengruppen”-Eintrag namens XACloseString den Werten entsprechen, die für die Zeichenfolge XAOPenString angegeben werden.
In WebSphere Event Broker wird derzeit nur IBM WebSphere MQ Java Client als JMS-Provider unterstützt. Der einzige derzeit für den Client unterstützte Transportmodus ist der Modus BIND. Es sind keine weiteren Konfigurationsschritte erforderlich.
Der standardmäßige JMS-Provider für diese Implementierung ist WebSphere MQ. Wenn jedoch eine Transaktionskoordination erforderlich ist, kann jeder JMS-Provider verwendet werden, vorausgesetzt, er entspricht der Spezifikation JMS 1.1 und unterstützt über die JMS-Sitzung die JMS-API 'XAResource'.
Wenn der Nachrichtenentwickler jedoch einen nicht XA-kompatiblen Provider angegeben hat, wird nur der Nicht-Transaktionsmodus unterstützt, und der Nachrichtenentwickler muss auch die erweiterte Eigenschaft Transaktionsmodus für alle JMSEmpfangs- und JMSSendeknoten auf no setzen.