Transactions, pare-feux, haute disponibilité et noeuds intermédiaires des services Web

Vous pouvez configurer votre système pour activer la propagation des contextes de messages à travers des pare-feux ou hors du domaine de WebSphere Application Server pour des transactions atomiques et des activités métier de services Web. Avec ces configurations, vous pouvez distribuer des applications de services Web qui utilisent des transactions atomiques ou des activités métier dans des systèmes disparates. La topologie que vous utilisez peut avoir un impact sur la haute disponibilité et le comportement d'affinité des transactions.

Les transactions de services Web (WS-AT ou WS-BA) peuvent utiliser toutes les fonctionnalités transactionnelles à haute disponibilité. Ceci comprend la récupération d'un serveur par un autre serveur actif du même cluster et le réacheminement des messages de protocole vers le serveur homologue pour exécuter les travaux du serveur défaillant. Pour activer la haute disponibilité des transactions de services Web, voir la rubrique dédiée à la configuration des propriétés des transactions pour la reprise homologue. Pour obtenir des informations générales sur la haute disponibilité et la reprise homologue dans WebSphere Application Server, voir la rubrique dédiée à la haute disponibilité des transactions.

Lorsque des transactions de service Web sont distribuées entre les applications dans différents serveurs ou clusters ou sur des systèmes qui ne sont pas des systèmes WebSphere Application Server, vous devez prendre en compte l'affinité de routage de transaction des demandes de service Web, ainsi que l'impact de la haute disponibilité du service de transaction sur WebSphere Application Server. Si un client distant envoie une série de demandes transactionnelles à un service cible déployé dans un cluster, le but recherché est en général que la première demande établisse une affinité transactionnelle entre l'application client et le serveur cible, de façon à ce que les demandes suivantes de la même transaction soient envoyées au même serveur cible. Lorsque la transaction se termine, les messages du protocole de transaction sont aussi envoyés à ce même serveur cible, sauf en cas de reprise en ligne de la haute disponibilité de la transaction et pas avant cette reprise.

Les topologies suivantes sont à votre disposition :
Connexion directe

Utilisez cette topologie pour les configurations autres qu'en cluster. Aucun noeud intermédiaire n'existe dans cette topologie. Le client communique directement avec le WebSphere Application Server qui héberge le service cible. Cette topologie prend en charge l'affinité et la haute disponibilité des transactions, mais seulement lorsque le client s'exécute sur un serveur WebSphere Application Server Version 6.0.2 ou supérieure, dans la même cellule administrative que celle du service cible.

Serveur proxy WebSphere Application Server

Utilisez cette topologie lorsque le client ne fait pas partie de la même cellule administrative que celle du service cible, et que vous avez besoin de l'affinité et de la haute disponibilité des transactions. Dans cette topologie, le client communique avec un serveur proxy pour IBM® WebSphere Application Server qui achemine de façon dynamique les demandes du client et les messages de protocole des transactions de services Web vers le serveur approprié dans un cluster WebSphere Application Server. Le serveur proxy est configuré dans la même cellule administrative que celle du service cible.

Eviter les incidents Eviter les incidents: WebSphere Application Server ne prend pas en charge le routeur On Demand pour ce scénario. Le serveur proxy de WebSphere Application Server seulement peut servir de proxy pour les noeuds finaux des transactions de services Web.gotcha

Il assure l'acheminement de l'affinité et de la haute disponibilité des transactions en périphérie de la cellule administrative. Comme pour toute configuration de proxy HTTP, vous devez fournir des informations sur l'URL du noeud final HTTP, c'est-à-dire que vous devez configurer le préfixe de l'URL du serveur HTTP pour le module de service Web cible.

De plus, vous devez configurer le serveur proxy pour les transactions de services Web afin de distribuer les messages de protocole des transactions de services Web au produit WebSphere Application Server approprié. Pour cela, configurez le préfixe du proxy HTTP du service de transaction décrit dans la rubrique dédiée à l'activation de WebSphere Application Server pour utiliser un noeud intermédiaire pour les transactions de services Web.

Le client du service Web envoie des messages, via un pare-feu, au serveur proxy pour WebSphere dans la zone démilitarisée. Le serveur proxy transmet ensuite le message à un serveur qui se trouve dans le cluster WebSphere Application Server.
Serveur HTTP, tel qu'IBM HTTP Server

Utilisez cette topologie lorsque le client n'a pas besoin d'acheminer l'affinité et la haute disponibilité des transactions, par exemple parce que le service cible est déployé sur un serveur qui n'est pas en cluster.

Dans cette topologie, le client communique avec un serveur HTTP qui achemine systématiquement les demandes du client et les messages de protocole des transactions de services Web à un serveur WebSphere Application Server spécifique. Comme pour toute configuration de proxy HTTP, vous devez fournir des informations sur l'URL du noeud final HTTP, c'est-à-dire que vous devez configurer le préfixe de l'URL du serveur HTTP pour le module de service Web cible. Vous devez aussi habituellement configurer le serveur HTTP pour les transactions de services Web, afin qu'il envoie les messages de protocole des transactions de services Web au serveur WebSphere Application Server approprié. Pour cela, configurez le préfixe du proxy HTTP du service de transaction décrit dans la rubrique dédiée à l'activation de WebSphere Application Server pour utiliser un noeud intermédiaire pour les transactions de services Web.

Le serveur HTTP ne peut pas offrir d'affinité ou de haute disponibilité pour les transactions. Toutefois, l'intégrité transactionnelle est assurée car le processus de reprise se produit après le redémarrage du serveur défaillant.
Remarque : Vous pouvez toujours activer la haute disponibilité sur WebSphere Application Server. Les clients autres que WebSphere Application Server qui accèdent à ce serveur via un serveur HTTP ne peuvent pas disposer d'une haute disponibilité des transactions, contrairement aux autres clients accédant au même serveur. Quand le client est sur WebSphere Application Server, la haute disponibilité est cependant disponible si le serveur qui agit comme client peut adresser les messages de protocole de transaction directement au serveur d'applications sans que le proxy HTTP route ces messages de protocole. Dans cas cas particulier, vous ne devez pas indiquer le préfixe du proxy HTTP du service de transaction.
Le client du service Web communique, via un pare-feu, avec le serveur HTTP dans la zone démilitarisée. La configuration du serveur HTTP détermine le point de destination du message dans WebSphere Application Server.

Il peut exister un serveur HTTP qui soit un proxy inverse pour tous les messages reçus, dont les messages des protocoles de transaction. Si vous souhaitez les fonctions de haute disponibilité et de gestion de la charge de travail d'un serveur proxy pour IBM WebSphere Application Server, créez un serveur proxy pour IBM WebSphere Application Server et configurez le serveur HTTP pour qu'il route toutes les requêtes vers le serveur proxy, comme dans le scénario suivant :

Serveur HTTP en conjonction avec un serveur proxy pour IBM WebSphere Application Server

Utilisez cette topologie lorsque le client ne fait pas partie de la même cellule administrative que celle du service cible, et que vous avez besoin de l'affinité et de la haute disponibilité des transactions. La topologie est similaire à celle du serveur proxy pour IBM WebSphere Application Server, mais elle prend en charge l'utilisation de tout serveur HTTP comme proxy inverse externe.

Dans cette topologie, le client communique avec un serveur HTTP que vous configurez, via l'acheminement des demandes d'un module d'extension vers un serveur proxy, de façon à ce qu'il transmette les demandes du client et les messages de protocole des transactions de services Web à un serveur proxy pour IBM WebSphere Application Server. Le proxy achemine ensuite de façon dynamique les demandes au serveur approprié dans WebSphere Application Server. Le serveur proxy est configuré dans la même cellule administrative que celle du service cible.

Il assure l'acheminement de l'affinité et de la haute disponibilité des transactions en périphérie de la cellule administrative. Comme pour toute configuration de proxy HTTP, vous devez fournir des informations sur l'URL du noeud final HTTP, c'est-à-dire que vous devez configurer le préfixe de l'URL du serveur HTTP pour le module de service Web cible.

Vous devez aussi configurer le serveur HTTP et le serveur proxy pour les transactions de services Web, afin qu'ils envoient les messages de protocole des transactions de services Web au serveur WebSphere Application Server approprié. Pour cela, configurez le préfixe du proxy HTTP du service de transaction décrit dans la rubrique dédiée à l'activation de WebSphere Application Server pour utiliser un noeud intermédiaire pour les transactions de services Web.

Le client du service Web communique, via un pare-feu, avec le serveur HTTP dans la zone démilitarisée. Le serveur HTTP réachemine toutes les demandes au serveur proxy pour IBM WebSphere Application Server, qui les achemine de façon dynamique vers le serveur correct dans WebSphere Application Server.

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_routing
Nom du fichier : cjta_routing.html