Übersicht über Web Services Atomic Transaction
Die Unterstützung von Web Services Atomic Transaction (WS-AT) im Anwendungsserver stelt transaktionsorientierte Servicequalität für die Web-Service-Umgebung bereit. Verteilte Web-Service-Anwendungen und die Ressourcen, die sie verwenden, können an verteilten globalen Transaktionen beteiligt sein. WS-AT wird jetzt in Liberty unterstützt.
Web-Service-Protokolle sind Standardmittel für die Definition von Web-Service-Anwendungen. Die Anwendungen können diese Protokolle für einen vom verwendeten Produkt, von der verwendeten Plattform oder von der verwendeten Programmiersprache unabhängigen Betrieb verwenden. Die WS-AT-Unterstützung ist eine Implementierung der folgenden Spezifikationen im Anwendungsserver. Diese Spezifikationen definieren einen Satz von Web-Services, mit denen sich Web-Service-Anwendungen an globalen Transaktionen beteiligen können, die in der heterogenen Web-Service-Umgebung verteilt werden.
- WS-AT ist ein bestimmter Koordinationstyp, der Protokolle für atomare Transaktionen definiert. Liberty kann nur die Spezifikation Web Services Atomic Transaction Version 1.2 verwenden.
- Web Services Coordination (WS-COOR) gibt einen Koordinationskontext (CoordinationContext) und einen Registrierungsservice an, mit dem sich teilnehmende Web-Services für die Beteiligung in Protokollen registrieren können, die von bestimmten Koordinationstypen bereitgestellt werden. Liberty kann nur die Spezifikation Web Services Coordination Version 1.2 verwenden.
Die WS-AT-Unterstützung ist ein Interoperabilitätsprotokoll, das keine neuen Programmierschnittstellen für die Transaktionsunterstützung einführt. Die Abgrenzung globaler Transaktionen erfolgt durch die Standardverwendung von Unternehmensanwendungen der JTA-Schnittstelle "UserTransaction". Wenn eine Anwendungskomponente, die unter einen globalen Transaktion ausgeführt wird, eine Web-Service-Anforderung ausführt, wird implizit ein WS-AT-Koordinationskontext (CoordinationContext) an die Ziel-Web-Services weitergegeben, sofern die entsprechenden Anwendungsimplementierungsdeskriptoren festgelegt wurden. Informationen hierzu finden Sie im Artikel zur Konfiguration transaktionsorientierter Implementierungsattribute.
Wenn der Anwendungsserver das System ist, das den Zielendpunkt für eine Web-Service-Anforderung mit einem WS-AT-Koordinationskontext hostet, erstellt der Anwendungsserver automatisch eine untergeordnete JTA-Transaktion in der Ziellaufzeitumgebung, die zum Transaktionskontext wird, unter dem die Web-Service-Zielanwendung ausgeführt wird.
Die folgende Abbildung zeigt einen Transaktionskontext, der von zwei Anwendungsservern für eine Web-Service-Anforderung mit einem WS-AT-Koordinationskontext gemeinsam genutzt wird.

Wenn Sie das Feature WS-AT aktivieren und die Transaktion auf der Clientseite in Liberty starten, werden standardmäßig alle in der Clienttransaktion enthaltenen Web-Service-Operationen der globalen Transaktion hinzugefügt. Wenn Sie aber Code außerhalb des Geltungsbereichs der aktuellen globalen Transaktion ausführen möchten, verwenden Sie den UOWManager mit dem Typ UOWSynchronizationRegistry.UOW_TYPE_LOCAL_TRANSACTION. Dies hat zur Folge, dass die globale Transaktion um dieses Code-Snippet aus- und fortgesetzt wird.
Ist das Feature WS-AT aktiviert? | Sind Transaktionen vorhanden? | Sind Richtlinienzusicherungen in WSDL vorhanden? | Sind globale WS-AT-Transaktionen aktiviert? |
---|---|---|---|
Nein | Nein | Nein | Nein |
Nein | Nein | Ja | Nein, Liberty löst eine Ausnahme aus |
Nein | Ja | Nein | Nein |
Nein | Ja | Ja | Nein, Liberty löst eine Ausnahme aus |
Ja | Nein | Nein | Nein |
Ja | Nein | Ja (wsp: Optional="false") | Nein, Liberty löst eine Ausnahme aus |
Ja (wsp: Optional="true") | Nein | ||
Ja | Ja | Nein | Ja |
Ja | Ja | Ja | Ja |
Ist das Feature WS-AT aktiviert? | Ist ein Koordinationskontext im SOAP-Header vorhanden? | Sind Richtlinienzusicherungen in WSDL vorhanden? | Sind globale WS-AT-Transaktionen aktiviert? |
---|---|---|---|
Nein | Nein | Nein | Nein |
Nein | Nein | Ja | Nein |
Nein | Ja | Nein | Nein, Liberty löst eine Ausnahme aus |
Nein | Ja | Ja | Nein, Liberty löst eine Ausnahme aus |
Ja | Nein | Nein | Nein |
Ja | Nein | Ja (wsp: Optional="false") | Nein, Liberty löst eine Ausnahme aus |
Ja (wsp: Optional="true") | Nein | ||
Ja | Ja | Nein | Ja |
Ja | Ja | Ja | Ja |
Anwendungsdesign
WS-AT ist ein zweiphasiges Festschreibungstransaktionsprotokoll, das nur für kurzlebige Transaktionen geeignet ist.
WS-AT ist am besten für die Verteilung von Transaktionskontext auf Web-Services geeignet, die in einem einzigen Unternehmen implementiert sind. Nur Anforderung/Antwort-Nachrichtenaustauschmuster übertragen Transaktionskontext, weil der Ersteller (Anwendung oder Container) einer Transaktion sicher sein muss, dass alle Geschäftstasks, die unter dieser Transaktion ausgeführt werden, abgeschlossen sind, bevor der Abschluss der Transaktion angefordert wird. Von einer unidirektionalen Anforderung aufgerufene Web-Services werden nicht unter der Transaktion des anfordenden Clients ausgeführt.
Die Auswirkungen von Servicefehlern bei WS-AT-Transaktionen ähneln den Auswirkungen von EJB-Anwendungsausnahmen (Java™) bei Transaktionen, die in der EJB-Spezifikation beschrieben sind. Wenn ein Service, der unter einer WS-AT-Transaktion eines Anforderers ausgeführt wird, einen Fehler zurückgibt, markiert der Anwendungsserver die Transaktion nicht automatisch als "rollback-only". Der Ausnahmehandler des Anforderers wählt aus, ob die Transaktion fortgesetzt werden kann und ob die Transaktion als "rollback-only" markiert werden soll. Wenn der Anforderer im Anwendungsserver ausgeführt wird, können die Standard-JTA- oder Standard-EJB-APIs zum Markieren der Transaktion als "rollback-only" verwendet werden. Die Servicekomponente, die den Fehler generiert, markiert die Transaktion möglicherweise selbst als "rollback-only", bevor sie den Fehler zurückgibt. Wenn die Implementierung der Servicekomponente eine Systemausnahme feststellt, erlaubt sie ihrem Container gewöhnlich die Ausnahme zu bearbeiten. Anwendungsserver-Container markieren empfangenen Transaktionskontext automatisch als "rollback-only", wenn eine Systemausnahme bearbeitet wird, die von einer Serviceimplementierung generiert wurde.