Prise en charge de Web Services Atomic Transaction sur le serveur d'applications
Le support de Web Services Atomic Transaction (WS-AT) dans le serveur d'applications apporte une qualité de service transactionnelle à l'environnement des services Web. Des applications de services Web répartis et les ressources qu'elles utilisent peuvent participer à des transactions globales réparties.
- WS-AT constitue un type de coordination spécifique qui définit des protocoles pour des transactions atomiques. Les spécifications sont les suivantes :
- WS-COOR (Web Services Coordination) désigne un contexte de coordination et un service d'enregistrement grâce auquel des services Web participants peuvent s'inscrire pour prendre part à des protocoles fournis par des types de coordination spécifiques. Les spécifications sont les suivantes :
- Web Services Coordination version 1.0
- Web Services Coordination Version 1.1
- Web Services Coordination Version 1.2
Le support WS-AT permet la prise en charge d'un protocole d'interopérabilité qui n'introduit aucune interface de programmation nouvelle pour le support des transactions. La démarcation de transaction globale est fournie par l'utilisation d'applications entreprise standard de l'interface JTA (Java™ Transaction API) UserTransaction. Si un composant d'application s'exécutant sous une transaction globale effectue une demande de services Web, le contexte de coordination WS-AT est envoyé de manière implicite au service Web cible, à condition que les descripteurs de déploiement d'application appropriés aient été définis, comme décrit dans la rubrique Configuration des attribut d'un déploiement transactionnel.
Si le serveur d'applications est le système d'hébergement du noeud final cible pour une demande de services Web qui inclut un contexte de coordination WS-AT, le serveur d'applications établit automatiquement une transaction JTA subordonnée dans l'environnement d'exécution cible, lequel devient le contexte transactionnel sous lequel l'application de service Web cible s'exécute.
La figure suivante montre un contexte de transaction partagé entre deux serveurs d'applications pour une demande de services Web contenant un contexte de coordination WS-AT.

![[z/OS]](../images/ngzos.gif)
Vous pouvez configurer les règles pour le protocole WS-AT. Vous pouvez indiquer si un client propage, et si un serveur reçoit, un contexte WS-AT. Pour vous assurer qu'un client envoie toujours un contexte WS-AT lorsqu'il effectue une demande de service sortant, vous devez associer un ensemble de règles au client, cet ensemble devant inclure le type de règle WS-Transaction dont le paramètre WS-AtomicTransaction doit être Obligatoire. Si vous savez que le client appelle toujours des noeuds finaux éloignés qui incluent l'attribut ATAssertion du type de règle WS-AtomicTransaction, vous pouvez également configurer le client pour appliquer la configuration WS-Policy du fournisseur de sorte que le client adopte automatiquement la règle obligatoire du fournisseur.
Pour vous assurer que les demandes qu'un fournisseur de services Web reçoit incluent un contexte WS-AtomicTransaction, vous devez associer un ensemble de règles au fournisseur, cet ensemble devant inclure le type de règle WS-Transaction dont le paramètre WS-AtomicTransaction doit être Obligatoire.
Pour vous assurer qu'un client ou un fournisseur n'utilise jamais un contexte WS-AtomicTransaction, vous devez associer un ensemble de règles au client ou au fournisseur, cet ensemble de règles incluant le type de stratégie WS-Transaction dont le paramètre WS-AtomicTransaction doit être Jamais. Vous pouvez utiliser cette configuration pour les environnements dans lesquels vous ne souhaitez pas de demandes de services Web pour créer une cohésion entre un client et un fournisseur, par exemple dans le cas de demandes entre entreprises.
Si aucun ensemble de règles n'est associé à un client ou à un fournisseur, ou si le type de règle WS-Transaction n'est pas inclus dans l'ensemble de règles, le comportement WS-Transaction par défaut est utilisé.
Restrictions du support WS-AT
Dans cette version du serveur d'applications, les contextes WS-AT ne peuvent pas être démarrés à partir d'un processus client non remédiable.
Les requêtes effectuées pour la même transaction
WS-AT qui sont envoyées à un cluster de serveurs ne sont pas systématiquement affectées au même membre du cluster.
Dans de tels cas, le travail pour une transaction peut être géré par plusieurs membres d'un cluster. Si une tâche transactionnelle traitée par plusieurs membres du cluster fait appel à une même ressource transactionnelle, un blocage risque de se produire.
Conception d'applications
WS-AT est un protocole de transaction de validation en deux phases adapté uniquement aux transactions de courte durée.
Une transaction atomique coordonne des gestionnaires de ressources qui isolent des mises à jour transactionnelles en suspendant des verrous transactionnels sur des ressources. Ainsi est-il en général déconseillé de répartir des transactions WS-AT entre plusieurs domaines d'entreprise. Les transactions entre entreprises requièrent en général une sémantique moins stricte que la validation à deux phases ; dans ce cas, elle peut répondre davantage à l'utilisation d'une transaction métier de compensation, dans le cadre d'un processus BPEL (Business Process Execution Language) ou en utilisant WS-BA (Web Services Business Activity).
WS-AT s'avère plus approprié pour la répartition de contextes de transactions entre plusieurs services Web déployés au sein d'une seule entreprise. Seuls les modèles d'échange de messages demande-réponse incluent des contextes de transactions, car l'émetteur (application ou conteneur) d'une transaction doit s'assurer que toutes les tâches métier exécutées sous cette transaction ont pris fin avant de demander l'achèvement d'une transaction. Les services Web appelés par une demande unidirectionnelle ne s'exécutent jamais sous la transaction du client demandeur.
L'effet des incidents de service sur les transactions WS-AT est similaire à celui des exceptions d'application EJB (Enterprise JavaBeans) sur les transactions, comme décrit dans la spécification EJB. Si un service qui s'exécute sous la transaction WS-AT d'un demandeur renvoie une erreur, le serveur d'applications ne marque pas automatiquement la transaction en annulation seule. Le gestionnaire d'exceptions du demandeur décide si la transaction peut se poursuivre et si elle doit être marquée pour annulation seulement. Si le demandeur s'exécute sur le serveur d'applications, les API JTA ou EJB standard peuvent être utilisées pour marquer la transaction en annulation seule. Le composant de service qui génère l'erreur peut, lui-même, marquer la transaction pour annulation seulement avant de renvoyer l'erreur. Si l'implémentation du composant de service rencontre une exception système, elle autorise généralement le conteneur à gérer l'exception. Les conteneurs du serveur d'applications ne marquent automatiquement un contexte de transaction reçu pour annulation seule que s'il s'agit d'une exception système générée par une implémentation de service.
Développement d'applications
Il n'existe pas de tâche de développement spécifique requise pour que que des applications de services Web tirent parti de WS-AT.
Pour les applications JAX-RPC, certains descripteurs de déploiement doivent être définis correctement, comme expliqué dans la rubrique Configuration des attributs d'un déploiement transactionnel. L'environnement d'exécution JAX-RPC prend en charge WS-AT 1.0.
Pour les applications JAX-WS, activez le support WS-AT en créant un ensemble de règles, en ajoutant le type de stratégie WS-Transaction, en le configurant (facultatif) et en associant ce type à l'application ou au client qui participera à la communication WS-AT. L'environnement d'exécution JAX-WS prend en charge WS-AT 1.0, WS-AT 1.1, WS-AT 1.2 et l'assertion WS-Policy pour WS-AT.
Lorsque l'environnement d'exécution JAX-WS reçoit une demande entrante, les niveaux de spécification WS-Transaction 1.0, 1.1 et 1.2 sont pris en charge. Lorsqu'une demande JAX-WS sortante est envoyée, un seul niveau de spécification peut être utilisé. Si des assertions WS-Transaction WS-Policy sont disponibles, soit à partir du langage SWDL (Web Services Description Language) du service Web cible, soit à partir du type de règle WS-Transaction du client, le niveau de spécification applicable au service Web cible et au client est utilisé. Par exemple, si l'environnement d'hébergement du service Web cible ne prend en charge que WS-Transaction 1.0, WS-AT 1.0 est utilisé. Si les deux niveaux de spécification sont applicables, ou si aucune assertion WS-Transaction WS-Policy n'est disponible, le niveau de spécification WS-Transaction défini dans les paramètres du service de transaction est utilisé.
- Pour un client, si le client ne tient pas compte de la règle du fournisseur, le client n'envoie ni contexte WS-AT, ni WS-BA (Web Services Business Activity). Ce comportement équivaut à un paramètre de règle WS-Transaction défini à Jamais.
- Pour un client, si le client tient compte de la règle du fournisseur, le client envoie un contexte WS-AT ou WS-BA si la règle du fournisseur inclut des assertions WS-AT ou WS-BA. Ce comportement équivaut à un paramètre de règle WS-Transaction défini à Supporte.
- Un serveur ne reçoit aucun contexte WS-AT ou WS-BA. Ce comportement équivaut à un paramètre de configuration de règle WS-Transaction défini à Jamais.
Les développeurs d'applications n'ont pas besoin d'enregistrer des participants WS-AT de façon explicite. L'environnement d'exécution du serveur d'applications se charge de l'enregistrement des participants WS-AT, comme pour XAResources dans la transaction JTA à laquelle la transaction WS-AT est fédérée. Au terme de l'exécution de la transaction, tous les participants WS-AT et XAResources sont coordonnés de façon atomique par le service de transaction du serveur d'applications.
Si une transaction JTA est active sur l'unité d'exécution lorsqu'une demande d'application de services Web est effectuée, la transaction est propagée sur la demande de services Web et réalisée dans l'environnement cible. Ce processus est similaire à la répartition d'un contexte de transaction sur IIOP, comme décrit dans la spécification EJB. Tout travail transactionnel effectué dans l'environnement cible est intégré à la même transaction globale.
Assertions de règle WS-Transaction
Si vous configurez les règles du protocole WS-Transaction pour un fournisseur, cette configuration affecte les assertions incluses dans n'importe quel WSDL généré pour le service Web auquel le type de règle est associé. L'assertion WS-Policy est utilisée pour décrire les exigences transactionnelles d'un client ou d'un fournisseur qui utilise WS-AtomicTransaction est ATAssertion. Si le type de règle WS-Transaction comporte un paramètre WS-AtomicTransaction défini à Obligatoire ou Supporte, une assertion de règle est incluse dans le WSDL.
Le serveur d'applications peut également analyser, comprendre et appliquer de telles assertions se trouvant dans le WSDL qu'il analyse.
L'exemple suivant illustre le WSDL où WS-AtomicTransaction ATAssertion indique qu'un noeud final doit être appelé avec un contexte WS-AT inclus dans le message de la demande et que le contexte peut être au format WS-Transaction 1.0 ou 1.1. Il existe deux espaces de nom et deux vérifications : un pour chaque niveau de spécification WS-Transaction, utilisant l'opérateur WS-Policy ExactlyOne pour montrer que le client doit choisir le niveau de spécification à utiliser.
<wsdl:definitions targetNamespace="bank.example.com"
xmlns:tns="bank.example.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsat11="http://docs.oasis-open.org/ws-tx/wsat/2006/06"
xmlns:wsat10="http://schemas.xmlsoap.org/ws/2004/10/wsat"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:Policy wsu:Id="ATPolicy">
<wsp:ExactlyOne>
<wsat11:ATAssertion />
<wsat10:ATAssertion />
<!-- omitted assertions -->
</wsp:ExactlyOne />
</wsp:Policy>
<!-- omitted elements -->
<wsdl:binding name="BankBinding" type="tns:BankPortType">
<!-- omitted elements -->
<wsdl:operation name="TransferFunds">
<wsp:PolicyReference URI="#ATPolicy" wsdl:required="true"/>
<!-- omitted elements -->
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>