Compensation de transaction et support des activités métier

Une activité métier est un ensemble de tâches liées les unes aux autres de manière à aboutir à un résultat convenu. Contrairement aux transactions atomiques, les activités telles que l'envoi de messages électroniques peuvent s'avérer difficiles voire impossibles à annuler automatiquement et, par conséquent, exigent un processus de compensation en cas d'erreur. La prise en charge de l'activité métier de WebSphere Application Server offre cette fonction de compensation par le biais des portées d'activités métier.

Quand utiliser le support des activités métier

Utilisez le support des activités métier lorsqu'une de vos applications nécessite une compensation. Une application nécessite une compensation si ses opérations ne peuvent pas être annulées automatiquement. En règle générale, ce scénario est dû à l'une des raisons suivantes :
  • L'application utilise plusieurs ressources non XA (architecture étendue).
  • L'application utilise plusieurs transactions atomiques, par exemple, des beans enterprise ayant Nouvel adaptateur requis pour réglage dans le champ Transaction dans le descripteur de déploiement de la transaction du conteneur.
  • L'application ne s'exécute pas sous une transaction globale.
Le schéma suivant représente une application de services Web simple utilisant le support des activités métier. Les services d'Enseigne, d'Entrepôt de données et de Fabrication sont exécutés dans des environnements autres que WebSphere Application Server. Le service d'Enseigne appelle le service de Fournisseur s'exécutant sous WebSphere Application Server qui délègue les tâches auprès des services d'Entrepôt de données et de Fabrication. L'implémentation du service de Fournisseur contient un bean session sans état, qui appelle d'autres beans session sans état qui sont associés aux services d'Entrepôt de données et de Fabrication, et qui réalisent un travail pouvant être compensé. Ces autres beans possèdent chacun un gestionnaire de compensation ; un élément de logique qui est associé à un composant d'application au cours de la phase d'exécution et qui s'acquitte de l'activité de compensation comme le renvoi d'un courrier électronique.
Voir le texte descriptif.

Conception d'applications

Les contextes de l'activité métier sont propagés avec les messages de l'application et peuvent par conséquent être répartis entre les composants d'application qui ne se trouvent pas dans le même serveur. Contrairement aux contextes de transaction atomique, les contextes de l'activité métier sont propagés à la fois sur les messages réponse d'appel et sur les messages unidirectionnels asynchrones. Un composant d'application fonctionnant sous une portée d'activité métier doit s'assurer que tout travail asynchrone qu'il démarre est terminé avant que le traitement du composant lui-même ne le soit. Une application qui démarre un travail asynchrone en utilisant un modèle de type fire-and-forget ne doit pas utiliser des portées d'activité métier, car cette application ne dispose d'aucun moyen pour détecter si ce traitement asynchrone est terminé.

Seuls les beans enterprise ayant des transactions gérées par conteneur peuvent utiliser les fonctions d'activité métier. Les beans enterprise qui exploitent les portées d'activité métier peuvent offrir des interfaces de service Web, mais peuvent également proposer des interfaces Java™ bean enterprise locales ou distantes. Le contexte d'activité métier est propagé dans les messages de services Web en utilisant l'élément standard et interopérable Web Services Business Activity (WS-BA) CoordinationContext. WebSphere Application Server peut également propager le contexte d'activité métier sur des appels RMI vers des beans enterprise lorsque les services Web ne sont pas utilisés. Cette forme de contexte n'est cependant pas interopérable avec les environnements autres que WebSphere Application Server. Il se peut que vous souhaitiez utiliser ce scénario lorsqu'une application interne à votre entreprise requiert une compensation. Si vous souhaitez utiliser une compensation d'activité métier dans un environnement hétérogène, exposez vos composants d'application comme des services Web.

Les contextes d'activité métier peuvent être propagés au-delà des pare-feux et à l'extérieur du domaine WebSphere Application Server. La topologie que vous utilisez pour réaliser cette propagation peut affecter la haute disponibilité et le comportement d'affinité de la transaction d'activité métier.

Développement et déploiement d'applications

WebSphere Application Server propose un modèle de programmation pour la création de portées d'activité métier et pour l'association de gestionnaires de compensation à ces portées d'activité métier. WebSphere Application Server offre également une interface de programmation d'applications pour spécifier les données de compensation, et pour vérifier ou altérer le statut d'une activité métier. Pour utiliser le support des activités métier, vous devez définir convenablement certains descripteurs de déploiement d'applications, fournir une classe de gestionnaires de compensation le cas échéant et activer le support des activités métier sur tout serveur exécutant l'application.
Remarque : Les applications ne peuvent exploiter le support des activités métier que si vous les déployez sur un serveur WebSphere Application Server Version 6.1 ou supérieure. Les applications ne peuvent pas utiliser la prise en charge de l'activité métier si vous les déployez sur un cluster regroupant des serveurs WebSphere Application Server Version 6.0.x.

Portées d'activité métier

La portée d'activité métier est celle d'une unité de travail WebSphere Application Server principale : une transaction globale, une session d'activité ou un LTC (local transaction containment). Une portée d'activité métier n'est pas une nouvelle unité de travail. Il s'agit d'un attribut d'une unité de travail principale existante. Par conséquent, une relation un à un existe entre une portée d'activité métier et une unité de travail.

Dans un déploiement WS-BA, l'unité de travail doit être gérée par conteneur.
  • L'unité de travail peut être un bean enterprise CMT (transaction gérée par conteneur) qui crée une transaction globale.
  • L'unité de travail peut être un confinement des transactions locales(LTC) dans lequel le conteneur est responsable du début et de la fin des transactions locales des gestionnaires de ressources (RMLT). Autrement dit, dans les attributs du descripteur de déploiement transactionnel, l'attribut Resolver des transactions locales doit avoir la valeur ContainerAtBoundary. Pour pouvoir utiliser WS-BA, vous ne devez pas attribuer la valeur Application à l'attribut Resolver.
Toute unité de travail principale peut être associée à une portée d'activité métier. Si un composant fonctionnant sous une unité de travail associée à une portée d'activité métier appelle un autre composant, cette requête propage la portée d'activité métier ; tout travail réalisé par le nouveau composant est associé à la même portée d'activité métier que le composant appelant. Le composant appelé peut créer une nouvelle unité de travail, par exemple si le paramètre Transaction d'un bean enterprise est Nouvel adaptateur requis, ou s'il fonctionne sous la même unité de travail que le composant appelant. Si une nouvelle unité de travail est démarrée, alors une nouvelle portée d'activité métier est créée et lui est associée. La nouvelle portée d'activité métier est un enfant de la portée d'activité métier associée à l'unité de travail appelante. Dans le schéma suivant, EJB1a s'exécutant sous UOW1 appelle deux composants : EJB1b qui s'exécute également sous UOW1, et EJB2 qui crée une nouvelle unité de travail, UOW2. Le bean enterprise EJB1b, appelle un autre bean enterprise, EJB3, qui crée une nouvelle unité de travail, UOW3. Du fait que chaque nouvelle unité de travail est créée par un composant appelant dont l'unité de travail est déjà associée à la portée d'activité métier BAScope1, les nouvelles unités de travail sont associées à de nouvelles portées d'activité métier internes, BAScope2 et BAScope3.
Voir le texte de la description.

Les portées d'activité métier internes doivent être terminées avant que les portées d'activité métier externes ne le soient. Les portées d'activité métier, par exemple BAScope2, sont associées à la portée d'activité métier externe, dans ce cas, BAScope1. Chaque portée d'activité métier est invitée à se fermer si son unité de travail ne se termine pas correctement, ou à compenser si les unités de travail associées rencontrent un incident. Si BAScope2 se termine avec succès, tout gestionnaire de compensation appartenant à BAScope2 est déplacé vers BAScope1, et est invité à agir de la même manière que BAScope1 : soit compenser, soit se fermer. Si BAScope2 échoue, les gestionnaires de compensation sont compensés automatiquement, et aucun élément n'est déplacé vers BAScope1 externe. Lorsqu'une portée d'activité métier interne échoue, en raison d'une défaillance de l'unité de travail à laquelle elle est associée, une exception de serveur d'applications est transmise au composant d'application appelant, en cours d'exécution sur l'unité de travail externe.

Par exemple, si l'unité de travail interne échoue, elle peut émettre une exception TransactionRolledBackException. Si l'application appelante peut faire face à l'exception, par exemple en contactant à nouveau le composant appelé ou en appelant un autre composant, alors l'unité de travail appelante et la portée d'activité métier qui lui est associée peuvent se terminer correctement bien que la portée d'activité métier interne ait échoué. Si la conception de l'application exige que l'unité de travail appelante échoue et que les portées d'activité métier qui lui sont associées soient compensées, le composant d'application appelante doit alors faire échouer son unité de travail, par exemple en autorisant la gestion par son conteneur de n'importe quelle exception système émise par l'unité de travail défaillante.

Une fois la portée de l'activité métier externe terminée, son succès ou son échec détermine l'orientation de l'exécution (fermer ou compenser) de tous les gestionnaires de compensation actifs appartenant à la portée de l'activité métier externe, y compris celle qui est remontée grâce au bon déroulement des portées des activités métier internes. Si la portée de l'activité métier externe se termine avec succès, elle invite tous les gestionnaires de compensation actifs à se fermer. Dans le cas contraire, elle invite tous les gestionnaires de compensation actifs à compenser.

Ce comportement de compensation est résumé dans le tableau suivant.
Tableau 1. Comportement de compensation pour une seule portée d'activité métier. Le tableau répertorie les combinaisons possibles de réussites et d'échecs pour les portées d'activité métier internes et externes ainsi que le comportement de compensation associé à chaque combinaison.
Portée de l'activité métier interne Portée de l'activité métier externe Comportement de compensation
Aboutit Aboutit Tous les gestionnaires de compensation appartenant à la portée de l'activité métier interne attendent que l'unité de travail externe prenne fin. Si l'unité de travail externe aboutit, l'activité métier externe invite tous les gestionnaires de compensation à se fermer.
Echoue Aboutit Tout gestionnaire de compensation actif appartenant à la portée de l'activité métier interne est compensé. Une exception est émise à destination de l'unité de travail externe ; si cette exception est interceptée, lorsque l'unité de travail externe aboutit, la portée de l'activité métier externe invite tous les gestionnaires de compensation actifs restants à se fermer.
Echoue Echoue Tout gestionnaire de compensation actif appartenant à la portée de l'activité métier interne est compensé. Une exception est émise à destination de l'unité de travail externe ; si cette exception n'est pas interceptée, la portée de l'activité métier externe échoue. Si la portée de l'activité métier externe échoue, que ce soit en raison d'une exception non gérée ou pour quelque raison que ce soit, tous les gestionnaires de compensation actifs restants sont compensés.
Aboutit Echoue Tous les gestionnaires de compensation appartenant à la portée de l'activité métier interne attendent que l'unité de travail externe prenne fin. Lorsque l'unité de travail externe échoue, la portée de l'activité métier externe invite tous les gestionnaires de compensation à compenser.

Lorsqu'une unité de travail et une portée d'activité métier associée aboutissent, la portée de l'activité métier aboutit toujours dans le même sens que l'unité de travail à laquelle est associée. La seule manière d'influencer le sens de la portée de l'activité métier est d'influencer l'unité de travail à laquelle elle est associée. Pour ce faire, utilisez la méthode setCompensateOnly de l'interface de programme d'application de l'activité métier.

Un gestionnaire de compensation enregistré dans une unité de travail transactionnelle peut être à l'origine inactif, en fonction de la méthode appelée depuis l'interface de programme d'application de l'activité métier. Les gestionnaires inactifs dans cette situation deviennent actifs lorsque l'unité de travail dans laquelle ce gestionnaire est déclaré se termine avec succès. Un gestionnaire de compensation enregistré en dehors d'une unité de travail transactionnelle devient toujours actif immédiatement. Pour plus d'informations, voir la rubrique relative à l'interface des activités métier.

Chaque portée d'activité métier du schéma représente une activité métier. Par exemple, l'activité métier externe s'exécutant sous BAScope1 peut être un scénario de réservation pour les vacances, BAScope2 étant une activité de réservation de billet d'avion et BAScope3 une réservation de chambre d'hôtel. En cas d'échec de la réservation du vol ou de l'hôtel, la réservation globale par défaut échoue également. De même, si la réservation du vol échoue, vous pouvez demander à l'application de tenter de réserver un vol en utilisant un autre composant représentant une compagnie aérienne différente. En cas d'échec de la réservation globale, l'application peut utiliser des gestionnaires de compensation pour annuler toutes les réservations de vols et d'hôtels effectuées avec succès.

Utilisation de portées d'activité métier par des composants d'applications

Par défaut, les composants d'applications n'utilisent pas les portées d'activité métier. Vous utilisez les outils d'assemblage de WebSphere Application Server pour définir l'utilisation d'une portée d'activité métier et pour identifier toute classe de gestionnaire de compensation pour le composant :
Configuration par défaut
En présence d'un contexte d'activité métier dans une requête reçue par un composant sans configuration de portée d'activité métier, le contexte est stocké par le conteneur, mais il n'est jamais utilisé pendant la portée de la méthode du composant cible. Aucune nouvelle portée d'activité métier n'est créée. Si le composant cible appelle un autre composant, le contexte d'activité métier est propagé et peut être utilisé par d'autres composants de compensation.
Exécutez les méthodes bean enterprise sous une portée d'activité métier
Tout contexte d'activité métier présent dans une requête entrante est reçu par le conteneur et mis à disposition du composant cible. Si une nouvelle unité de travail est créée pour la méthode cible, par exemple du fait que le paramètre Transaction de la méthode bean enterprise est réglé sur Nouvel adaptateur requis, la portée d'activité métier reçue devient une portée d'activité métier externe pour une nouvelle activité métier. Si l'unité de travail est propagée depuis le composant appelant et utilisée par cette méthode, la portée d'activité métier reçue est alors utilisée par la méthode. Si une aucune portée d'activité métier n'est présente dans l'appel, une nouvelle portée d'activité métier est créée et utilisée par la méthode.
Pour créer une portée d'activité métier lorsqu'un bean enterprise est appelé, vous devez configurer le bean enterprise de manière à exécuter des méthodes bean enterprise sous une portée d'activité métier. Vous devez également configurer les descripteurs de déploiement pour la méthode appelée, pour définir la création d'une nouvelle unité de travail au moment de l'appel. Pour plus d'informations, voir la rubrique relative à la création d'une application utilisant la prise en charge WS-BA.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjta_wsbascope
Nom du fichier : cjta_wsbascope.html