Transaktionskompensation und BA-Unterstützung

Eine Geschäftsaktivität (BA) ist eine Gruppe von Tasks, die miteinander verknüpft werden, um ein abgestimmtes Ergebnis zu erzielen. Im Gegensatz zu atomaren Transaktionen sind Aktivitäten, wie z. B. das Senden einer E-Mail, atomar schwer oder gar nicht zurückzusetzen und erfordern im Falle eines Fehlschlags einen Kompensationsprozess. Die Unterstützung von Geschäftsaktivitäten in WebSphere Application Server ermöglicht diese Kompensation über BA-Bereiche.

Wann die BA-Unterstützung verwendet werden soll

Verwenden Sie die BA-Unterstützung, wenn Sie eine Anwendung haben, die Kompensation erfordert. Eine Anwendung erfordert Kompensation, wenn ihre Operationen nicht atomar zurückgesetzt werden können. Normalerweise hat dieses Szenario einen der folgenden Gründe:
  • Die Anwendung verwendet mehrere Nicht-XA-Ressourcen (Extended Architecture).
  • Die Anwendung verwendet mehrere atomare Transaktionen, z. B. Enterprise-Beans, die die Einstellung Erfordert neue(n) für das Feld Transaktion im Implementierungsdeskriptor für Containertransaktionen verwenden.
  • Die Anwendung wird nicht unter einer globalen Transaktion ausgeführt.
Das folgende Diagramm zeigt eine einfache Web-Service-Anwendung, die die BA-Unterstützung verwendet. Der Retailer Service (Einzelhändler), der Warehouse Service (Warenlager) und der Manufacturing Service (Fertigung) werden in Nicht-WAS-Umgebungen ausgeführt. Der Retailer Service ruft den Supplier Service (Lieferant) auf, der unter WebSphere Application Server ausgeführt wird und Tasks an den Warehouse Service und den Manufacturing Service delegiert. Die Implementierung des Supplier Service enthält eine Stateless-Session-Bean, die alle anderen Stateless-Session-Beans, die dem Warehouse Service und dem Manufacturing Service zugeordnet sind, aufruft und kompensierbare Arbeitsvorgänge ausführt. Diese anderen Session-Beans haben jede einen Kompensationshandler. Dabei handelt es sich um ein Logikelement, das einer Anwendungskomponente zur Laufzeit zugeordnet wird und eine Kompensationsaktivität ausführt, z. B. das erneute Senden einer E-Mail.
Siehe beschreibenden Text.

Anwendungsdesign

BA-Kontexte werden mit Anwendungsnachrichten weitergegeben und können daher zwischen Anwendungskomponenten, die sich nicht auf demselben Server befinden, verteilt werden. Im Gegensatz zu atomaren Transaktionskontexten werden BA-Kontexte sowohl in synchronen (blockierenden) Aufruf-Antwort-Nachrichten als auch in asynchronen Einwegnachrichten weitergegeben. Eine Anwendungskomponente, die unter einem BA-Bereich ausgeführt wird, ist dafür zuständig, dass alle asynchrone Aufgaben, die sie einleitet, beendet werden, bevor die Verarbeitung der Komponente selbst beendet wird. Eine Anwendung, die asynchrone Verarbeitungsvorgänge mit einem Nachrichtenmuster des Typs Fire-and-Forget einleitet, darf keine BA-Bereiche verwenden, da solche Anwendungen nicht in der Lage sind, zu erkennen, wann die asynchrone Verarbeitung beendet ist.

Nur Enterprise-Beans, die containergesteuerte Transaktionen haben, können die BA-Funktionen verwenden. Enterprise-Beans, die BA-Bereiche ausnutzen, können Web-Service-Schnittstellen, aber auch standardmäßig verwendete Local- oder Remote-Java™-Schnittstellen für Enterprise-Beans bereitstellen. Der BA-Kontext wird in Web-Service-Nachrichten mit einem interoperablen WSBA-Standardelement (Web Services Business Activity, WS-BA), CoordinationContext, weitergegeben. WebSphere Application Server kann BA-Kontext auch über RMI-Aufrufe an Enterprise-Beans weitergeben, wenn Web-Services nicht verwendet werden, aber dieses Kontextformat ist mit Umgebungen ohne WebSphere Application Server nicht kompatibel. Sie können dieses homogene Szenario verwenden, wenn Sie Kompensation für eine geschäftsinterne Anwendung benötigen. Wenn Sie eine BA-Kompensation in einer heterogenen Umgebung verwenden möchten, müssen Sie Ihre Anwendungskomponenten als Web-Services bereitstellen.

BA-Kontexte können über Firewalls hinweg und außerhalb der Domäne von WebSphere Application Server weitergegeben werden. Die Topologie, die Sie verwenden, um diese Weitergabe zu realisieren, kann das Hochverfügbarkeits- und Affinitätsverhalten der BA-Transaktion beeinflussen.

Anwendungsentwicklung und -implementierung

WebSphere Application Server stellt ein Programmierungsmodell für die Erstellung von BA-Bereichen und die Zuordnung von Kompensationshandlern zu diesen BA-Bereichen bereit. WebSphere Application Server stellt auch eine Anwendungsprogrammierschnittstelle bereit, mit der Sie Kompensationsdaten angeben und den Status einer Geschäftsaktivität überprüfen oder ändern können. Zum Verwenden der BA-Unterstützung müssen Sie bestimmte Implementierungsdeskriptoren von Anwendungen entsprechend konfigurieren und die BA-Unterstützung auf allen Servern, auf denen die Anwendung ausgeführt wird, aktivieren.
Anmerkung: Anwendungen können die BA-Unterstützung nur ausnutzen, wenn Sie sie auf einem WebSphere Application Server der Version 6.1 oder höher implementieren. Anwendungen können die BA-Unterstützung nicht nutzen, wenn Sie sie in einem Cluster mit Servern von WebSphere Application Server Version 6.0.x implementieren.

BA-Bereiche

Der Geltungsbereich einer Geschäftsaktivität entspricht dem einer Basisarbeitseinheit von WebSphere Application Server: eine globale Transaktion, eine Aktivitätssitzung oder ein lokaler Transaktionseinschluss (Local Transaction Containment, LTC). Ein BA-Bereich ist keine neue Arbeitseinheit, er stellt ein Attribut einer vorhandenen Basisarbeitseinheit dar. Daher besteht eine Eins-zu-eins-Beziehung zwischen einem BA-Bereich und einer Arbeitseinheit.

In einer WS-BA-Implementierung muss die UOW containergesteuert sein:
  • Die UOW kann eine CMT-Enterprise-Bean (Container-managed Transaction, containergesteuerte Transaktion), die eine globale Transaktion erstellt.
  • Die UOW kann ein lokaler Transaktionseinschluss sein, bei dem der Container für das Starten und Beenden lokaler Transaktionen des Ressourcenmanagers zuständig ist. Das heißt, dass das Attribut "Resolver" für lokalen Transaktionen in den transaktionsorientierten Attributen im Implementierungsdeskriptor auf "ContainerAtBoundary" gesetzt werden muss. Wenn Sie WS-BA verwenden möchten, dürfen Sie das Attribut "Resolver" nicht auf "Application" setzen.
Jeder Basisarbeitseinheit kann ein BA-Bereich zugeordnet sein. Wenn eine Komponente, die unter einer Arbeitseinheit ausgeführt wird, die einem BA-Bereich zugeordnet ist, eine andere Komponente aufruft, wird bei dieser Anforderung der BA-Bereich weitergegeben. Alle Arbeitsanforderungen, die von der neuen Komponente ausgeführt werden, werden demselben BA-Bereich zugeordnet wie die aufrufende Komponente. Die aufgerufene Komponente kann eine neue Arbeitseinheit erstellen, z. B., wenn eine Enterprise-Bean für Transaktion die Option Erfordert neue(n) verwendet, oder unter derselben Arbeitseinheit ausgeführt werden wie die aufrufende Komponente. Wenn eine neue Arbeitseinheit gestartet wird, wird ein neuer BA-Bereich erstellt und der neuen Arbeitseinheit zugeordnet. Der neu erstellte BA-Bereich ist dem BA-Bereich, der der aufrufenden Arbeitseinheit zugeordnet ist, untergeordnet. Im folgenden Diagramm ruft EJB1a, die unter UOW1 ausgeführt wird, zwei Komponenten auf: EJB1b, die auch unter UOW1 ausgeführt wird, und EJB2, die eine neue Arbeitseinheit erstellt, UOW2. Die Enterprise-Bean EJB1b ruft eine andere Enterprise-Bean auf, EJB3, die wiederum eine neue Arbeitseinheit, UOW3, erstellt. Da jede neue Arbeitseinheit von einer aufrufenden Komponente erstellt wird, deren Arbeitseinheit bereits eine Zuordnung zu BA-Bereich BAScope1 hat, werden die neu erstellten Arbeitseinheiten neuen inneren BA-Bereichen, BAScope2 und BAScope3, zugeordnet.
Siehe Beschreibung im Text.

Die inneren BA-Bereiche müssen vor den äußeren BA-Bereichen beendet sein. Die inneren BA-Bereiche, z. B. BAScope2, haben eine Zuordnung zum äußeren BA-Bereich, in diesem Fall BAScope1. Jeder BA-Bereich wird geschlossen, wenn er die zugeordnete Arbeitseinheit erfolgreich beendet hat, oder kompensiert, wenn die zugeordnete Arbeitseinheit fehlschlägt. Wenn BAScope2 erfolgreich beendet wird, werden alle aktiven Kompensationshandler, deren Eigner BAScope2 ist, nach BAScope1 verschoben und auf dieselbe Weise gesteuert: Kompensieren oder Schließen. Wenn BAScope2 fehlschlägt, werden die aktiven Kompensationshandler automatisch kompensiert, und es werden keine Daten in den äußeren BA-Bereich BAScope1 verschoben. Wenn ein innerer BA-Bereich fehlschlägt, wird eine Ausnahmebedingung für den Anwendungsserver an die aufrufende Anwendungskomponente ausgegeben, die in der äußeren Arbeitseinheit ausgeführt wird.

Wenn z. B. die innere Arbeitseinheit fehlschlägt, kann sie eine Ausnahmebedingung des Typs TransactionRolledBackException auslösen. Kann die aufrufende Anwendung die Ausnahmebedingung beheben, z. B. indem sie die aufgerufene Komponente wiederholt oder eine andere Komponente aufruft, können die aufrufende Arbeitseinheit und der ihr zugeordnete BA-Bereich erfolgreich beendet werden, auch wenn der innere BA-Bereich fehlschlägt. Wenn das Anwendungsdesign vorsieht, dass die aufrufende Arbeitseinheit fehlschlägt und der ihr zugeordnete BA-Bereich kompensiert wird, muss die aufrufende Anwendungskomponente ihre Arbeitseinheit fehlschlagen lassen, z. B. indem sie zulässt, dass alle Systemausnahmen der fehlgeschlagenen Arbeitseinheit von ihrem Container bearbeitet werden.

Wenn der äußere BA-Bereich beendet ist, bestimmt Erfolg bzw. Fehlschlag die Richtung (Schließen oder Kompensieren) für die Beendigung aller aktiven Kompensationshandler, deren Eigner der äußere BA-Bereich ist, einschließlich der Handler, die durch erfolgreiche Beendigung innerer BA-Bereiche hochgestuft wurden. Wenn der äußere BA-Bereich fehlerfrei beendet wird, veranlasst er, dass alle aktiven Kompensationshandler geschlossen werden. Schlägt der äußer BA-Bereich fehl, veranlasst er, dass alle aktiven Kompensationshandler kompensiert werden.

Dieses Kompensationsverhalten ist in der folgenden Tabelle zusammengefasst.
Tabelle 1. Kompensationsverhalten für einen einzelnen BA-Bereich . Die Tabelle listet die möglichen Kombinationen zu Erfolg und Fehlerschlägen für die inneren und äußeren BA-Bereiche sowie das jeder Kombination zugeordnete Kompensationsverhalten.
Innerer BA-Bereich Äußerer BA-Bereich Kompensationsverhalten
Erfolg Erfolg Alle Kompensationshandler, deren Eigner der innere BA-Bereich ist, warten darauf, dass die äußere Arbeitseinheit beendet wird. Wenn die äußere Arbeitseinheit fehlerfrei beendet wird, veranlasst der äußere BA-Bereich, dass alle Kompensationshandler geschlossen werden.
Fehlschlag Erfolg Alle aktiven Kompensationshandler, deren Eigner der innere BA-Bereich ist, werden kompensiert. Eine Ausnahmebedingung wird an die äußere Arbeitseinheit abgesetzt. Wird diese Ausnahmebedingung abgefangen, wenn die äußere Arbeitseinheit fehlerlos beendet wird, veranlasst der äußere BA-Bereich, dass alle verbleibenden aktiven Kompensationshandler geschlossen werden.
Fehlschlag Fehlschlag Alle aktiven Kompensationshandler, deren Eigner der innere BA-Bereich ist, werden kompensiert. Eine Ausnahmebedingung wird an die äußere Arbeitseinheit abgesetzt. Wenn diese Ausnahmebedingung nicht abgefangen wird, schlägt der äußere BA-Bereich fehl. Wenn der äußere BA-Bereich aufgrund der nicht behandelten Ausnahmebedingung oder aus einem anderen Grund fehlschlägt, werden alle verbleibenden aktiven Kompensationshandler kompensiert.
Erfolg Fehlschlag Alle Kompensationshandler, deren Eigner der innere BA-Bereich ist, warten darauf, dass die äußere Arbeitseinheit beendet wird. Wenn die äußere Arbeitseinheit fehlerfrei beendet wird, veranlasst der äußere BA-Bereich, dass alle Kompensationshandler kompensiert werden.

Wenn eine Arbeitseinheit mit einem zugeordneten BA-Bereich beendet wird, wird der BA-Bereich in derselben Richtung beendet wie die Arbeitseinheit, der er zugeordnet ist. Der einzige Weg, die Richtung des BA-Bereichs zu beeinflussen, darin, die Arbeitseinheit, der er zugeordnet ist, zu beeinflussen. Dazu können Sie die Methode setCompensateOnly der BA-API verwenden.

Ein Kompensationshandler, der in einer transaktionsorientierten Arbeitseinheit registriert ist, kann anfangs inaktiv sein, je nach der Methode, die von der BA-API aufgerufen wird. Inaktive Handler in dieser Situation werden aktiv, wenn die Arbeitseinheit, in der dieser Handler deklariert wird, erfolgreich beendet wird. Ein Kompensationshandler, der außerhalb einer transaktionsorientierten Arbeitseinheit registriert wird, wird sofort aktiv. Weitere Informationen finden Sie im Artikel zur API für Geschäftsaktivitäten.

Jeder BA-Bereich im Diagramm repräsentiert eine Geschäftsaktivität. Beispielsweise kann die äußere Geschäftsaktivität, die unter BAScope1 ausgeführt wird, ein Szenario "Urlaubsbuchung" sein, wobei BAScope2 die Aktivität "Flugbuchung" und BAScope3 die Aktivität "Hotelbuchung" ist. Wenn entweder die Flug- oder die Hotelbuchung fehlschlägt, schlägt auch die gesamte Urlaubsbuchung fehl. Wenn andererseits die Flugbuchung fehlschlägt, kann die Anwendung versuchen, einen Flug mit einer anderen Komponente zu buchen, die für eine andere Fluglinie steht. Wenn die gesamte Urlaubsbuchung fehlschlägt, kann die Anwendung Kompensationshandler verwenden, um alle Flüge oder Hotels, die bereits erfolgreich gebucht wurden, zu stornieren.

Verwendung von BA-Bereichen durch Anwendungskomponenten

Anwendungskomponenten verwenden standardmäßig keine BA-Bereiche. Sie verwenden die Assembliertools von WebSphere Application Server, um die Verwendung eines BA-Bereichs anzugeben und Kompensationshandlerklassen für die Komponente zu identifizieren:
Standardkonfiguration
Wenn ein BA-Kontext sich in einer Anforderung befindet, die von einer Komponente ohne Konfiguration des BA-Bereichs empfangen wird, wird der Kontext vom Container gespeichert, jedoch nie im Methodenbereich der Zielkomponente verwendet. Es wird kein neuer BA-Bereich erstellt. Wenn die Zielkomponente eine andere Komponente aufruft, wird der gespeicherte BA-Kontext weitergeleitet und kann von anderen kompensierenden Komponenten verwendet werden.
Enterprise-Bean-Methoden unter einem BA-Bereich ausführen
Ein BA-Kontext in der eingehenden Anforderung wird vom Container empfangen und der Zielkomponente zur Verfügung gestellt. Wenn eine neue Arbeitseinheit für die Zielmethode erstellt wird, z. B., weil die Enterprise-Bean-Methode die Option Erfordert neue(n) für Transaktion verwendet, wird der empfangene BA-Bereich für eine neu erstellte Geschäftsaktivität zu einem äußeren BA-Bereich. Wenn die Arbeitseinheit der aufrufenden Komponente weitergeleitet und von der Methode verwendet wird, wird der empfangene BA-Bereich von der Methode verwendet. Wenn im Aufruf kein BA-Bereich vorhanden ist, wird ein neuer BA-Bereich erstellt und von der Methode verwendet.
Soll ein BA-Bereich erstellt werden, wenn eine Enterprise-Bean aufgerufen wird, müssen Sie die Enterprise-Bean so konfigurieren, dass sie Enterprise-Bean-Methoden unter einem BA-Bereich ausführt. Sie müssen auch die Implementierungsdeskriptoren für die aufzurufende Methode konfigurieren, um die Erstellung einer neuen Arbeitseinheit bei Aufruf zu definieren. Einzelheiten finden Sie im Artikel zum Erstellen einer Anwendung, die die WS-BA-Unterstützung verwendet.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjta_wsbascope
Dateiname:cjta_wsbascope.html