Prise en charge de Web Services Business Activity sur le serveur d'applications
Avec le support Web Services Business Activity (WS-BA) sur le serveur d'applications, les services Web de différents systèmes peuvent coordonner les activités plus largement couplées que des transactions atomiques. De telles activités peuvent être difficiles voire impossibles à annuler de façon atomique, et nécessitent de ce fait un processus de compensation en cas d'erreur.
- WS-BA est un type de coordination spécifique qui définit les protocoles des activités métier. 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
Outre la prise en charge du protocole d'interopérabilité WS-BA, le serveur d'applications propose une interface de programmation pour créer des activités métier et des gestionnaires de compensation. Grâce à cette interface de programmation, vous pouvez définir des données de compensation et vérifier ou altérer le statut de l'activité métier.
Vous pouvez également utiliser cette fonction de compensation avec des applications qui ne sont pas des services Web, à condition que ces applications impliquent des communications entre serveurs WebSphere Application Server uniquement. Pour de plus amples informations, consultez les rubriques connexes.
Vous pouvez configurer les règles pour le protocole WS-BA. Vous pouvez indiquer si un client propage, et si un serveur reçoit, un contexte WS-BA. Pour vous assurer qu'un client envoie toujours un contexte WS-BA 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-BusinessActivity doit être Obligatoire. Si vous savez que le client appelle toujours des noeuds finaux éloignés qui incluent l'attribut BAAtomicOutcomeAssertion du type de règle WS-BusinessActivity, 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-BusinessActivity, 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-BusinessActivity doit être Obligatoire.
Pour vous assurer qu'un client ou un fournisseur n'utilise jamais un contexte WS-BusinessActivity, 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-BusinessActivity 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é.
Développement d'applications
Aucune tâche de développement spécifique n'est requise pour que des applications de services Web tirent parti de WS-BA.
Pour les applications JAX-RPC, les composants EJB (Enterprise JavaBeans) configurés pour s'exécuter sous une portée BusinessActivity propagent automatiquement cette portée lorsqu'ils effectuent une demande sortante de services Web JAX-RPC. La phase d'exécution JAX-RPC prend en charge WS-BA 1.0.
Pour les applications JAX-WS, activez le support WS-BA 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-BA. La phase d'exécution JAX-WS prend en charge WS-BA 1.0, WS-BA 1.1, WS-BA 1.2 et l'assertion WS-Policy pour WS-BA.
Lorsque la phase 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-BA 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é.
- Si un client ne tient pas compte de la règle du fournisseur, le client n'envoie ni contexte WS-AT (Web Service Atomic Transaction), ni WS-BA. Ce comportement équivaut à un paramètre de configuration de règle WS-Transaction défini à Jamais.
- Si un 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 configuration 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ègles WS-Transaction défini à Jamais.
Assertions de règle WS-Transaction
Si vous configurez les règles du protocole WS-BusinessActivity pour un fournisseur, ceci 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 utilisée pour décrire les exigences de compensation d'un client ou d'un fournisseur qui utilise WS-BusinessActivity est BAAtomicOutcomeAssertion. Si le type de règle WS-Transaction comporte un paramètre WS-BusinessActivity 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-BusinessActivity BAAtomicOutcomeAssertion indique qu'un noeud final doit être appelé avec un contexte WS-BA 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/wsba/2006/06"
xmlns:wsat10="http://schemas.xmlsoap.org/ws/2004/10/wsba"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:Policy wsu:Id="BAPolicy">
<wsp:ExactlyOne>
<wsat11:BAAtomicOutcomeAssertion />
<wsat10:BAAtomicOutcomeAssertion />
<!-- omitted assertions -->
</wsp:ExactlyOne />
</wsp:Policy>
<!-- omitted elements -->
<wsdl:binding name="BankBinding" type="tns:BankPortType">
<!-- omitted elements -->
<wsdl:operation name="TransferFunds">
<wsp:PolicyReference URI="#BAPolicy" wsdl:required="true"/>
<!-- omitted elements -->
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>