Adressage des services Web : pare-feux et noeuds intermédiaires

La prise en charge de l'adressage des services Web (WS-Addressing) dans ce produit permet de créer des références de noeud final qui peuvent être réparties entre les pare-feux et les noeuds intermédiaires.

Grâce à la prise en charge de WS-Addressing, vous pouvez générer automatiquement des références de noeud final qui représentent des noeuds finaux sur le noeud sur lequel les références sont générées. Ces références de noeud final contiennent les informations d'adresse appropriées, basées sur l'URL configurée pour le noeud final et sur toute configuration proxy valide pour le serveur qui héberge le noeud final. Les messages destinés à la référence de noeud final à partir du client sont acheminés vers le noeud final via le(s) noeud(s) intermédiaire(s) approprié(s), comme décrit dans les scénarios de topologie ci-dessous.

Si vous utilisez l'API propriété d'IBM pour créer la référence de noeud final, la topologie de votre système peut également affecter le type de référence de noeud final généré par le modèle de programmation WS-Addressing. Par exemple, si vous utilisez la méthode EndpointReferenceManager.createEndpointReference(QName serviceName, String endpointName) pour créer une référence de noeud final dans un environnement à clusters, la référence de noeud final représente par défaut un noeud final dont la charge de travail est pondérée dans le cluster dans lequel le noeud final a été créé, conformément aux topologies appropriées dans les sections qui suivent. Ce comportement fournit donc une amélioration des performances de l'application.
Remarque : Si le composant d'application demandeur s'exécute dans le cadre d'une transaction ou dans une session HTTP, des contraintes d'affinité risquent de s'appliquer à la pondération de charge de travail des noeuds finaux.

[AIX Solaris HP-UX Linux Windows][IBM i]Vous pouvez également utiliser l'API propriété d'IBM pour créer une référence de noeud final représentant un service qui ne doit pas faire l'objet d'une pondération de charge de travail, par exemple, car l'état en mémoire est maintenu. Un service utilisant un bean session avec état constitue un exemple de service reposant sur l'affinité de routage avec une instance de serveur spécifique. Pour créer une référence de noeud final à un service de ce type, utilisez la méthode EndpointReferenceManager.createEndpointReference(QName serviceName, String endpointName, java.rmi.Remote statefulSessionBean).

[AIX Solaris HP-UX Linux Windows][IBM i]Si vous activez la fonction de haute disponibilité pour les beans session avec état et que vous créez la référence de noeud final à l'aide de cette méthode, la référence de noeud final reste valide même en cas de reprise en ligne du bean session avec état, à condition que la demande provienne d'un client WebSphere Application Server version 6.1 ou ultérieure, ou qu'elle soit acheminée par un Proxy Server for IBM® WebSphere Application Server dans la même cellule d'administration, comme décrit dans les scénarios de topologie ci-dessous.

Pour les références de point de contact désignant des services qui n'accèdent pas aux informations avec état localisées sur un serveur spécifique, tous les scénarios de topologie ci-dessous sont applicables.

Connexion directe

Utilisez cette topologie pour les configurations sans cluster.

Cette topologie ne contient aucun noeud intermédiaire. Le client communique directement avec le serveur qui héberge le noeud final cible. Dans cette topologie, les API WS-Addressing génèrent automatiquement l'adresse de référence de noeud final appropriée, en fonction de l'URL configurée pour le module de service Web. Ce scénario est illustré dans le diagramme ci-dessous.
Le client de service web envoie directement des messages au serveur WebSphere Application Server qui héberge le noeud final cible.
Vous pouvez également utiliser cette topologie lorsque des références de noeud final créées à l'aide de l'API propriété d'IBM désignent des services déployés dans un cluster dont la charge de travail est pondérée. Cependant, les messages destinés à la référence de noeud final ne font l'objet d'une pondération de charge de travail que si le client ciblant la référence de noeud final est un client WebSphere Application Server version 6.1 ou ultérieure, qui existe dans la même cellule d'administration que le noeud final, comme illustré dans le diagramme ci-dessous.
Le client WebSphere Application Server client utilise sa pondération de charge de travail et la logique de routage à haute disponibilité pour acheminer des messages vers le noeud final cible qui est hébergé dans un cluster WebSphere Application Server. Le client et le serveur résident dans la même cellule d'administration.

Les références de noeud final créées à l'aide de l'API JAX-WS standard n'ont pas une charge de travail pondérée.

Serveur proxy pour IBM WebSphere Application Server

Utilisez cette topologie lorsque les références de noeud final désignent des services déployés dans un cluster dont la charge de travail est pondérée, qui accèdent, le cas échéant, à des informations avec état localisées sur un serveur spécifique et qui, éventuellement, font l'objet d'une reprise en ligne dans une configuration à haute disponibilité.

Dans cette topologie, les API WS-Addressing génèrent automatiquement l'adresse de référence de noeud final appropriée, en fonction du préfixe d'URL du Proxy Server for IBM WebSphere Application Server configuré pour le module de service web cible. Vous devez fournir des informations d'URL de noeud final HTTP, en d'autre termes, configurer le préfixe d'URL HTTP pour chaque déploiement de chaque application. Le client peut exister hors de la cellule d'administration qui contient le serveur proxy et le serveur cible. Le client communique avec le serveur proxy qui achemine de façon dynamique les demandes du client vers le serveur approprié du cluster.
Le client du service web envoie des messages, via un pare-feu, à Proxy Server for IBM WebSphere Application Server. Le serveur proxy utilise ensuite sa pondération de charge de travail et la logique de routage à haute disponibilité pour acheminer des messages vers le noeud final d'un serveur du cluster. Le serveur proxy et le serveur cible résident dans la même cellule d'administration.
[AIX Solaris HP-UX Linux Windows][IBM i]Si le proxy ciblé par la référence de noeud final est un Proxy Server for IBM WebSphere Application Server version 6.1 ou ultérieure, qui existe dans la même cellule d'administration que le noeud final, les messages destinés à une référence de noeud final dont la charge de travail est pondérée font l'objet d'une pondération de charge de travail, basée sur le cluster. Pour les références de noeud final créées à l'aide de l'API propriété d'IBM, le comportement suivant s'applique également :
  • Si la référence de noeud final représente un bean session avec état, les demandes adressées à la référence du noeud final conservent l'affinité au serveur et l'instance du bean session avec état.
  • Si la référence de noeud final représente un bean session avec état hautement disponible, la référence du noeud final reste valide si le bean session avec état est défaillant sur un autre serveur.
Les références de noeud final créées à l'aide de l'API JAX-WS standard n'ont pas d'affinité de serveur, ni de haute disponibilité.

[z/OS]Si le proxy ciblé par la référence de noeud final est un Proxy Server for IBM WebSphere Application Server version 6.1 ou ultérieure, qui existe dans la même cellule d'administration que le noeud final, les messages destinés à une référence de noeud final dont la charge de travail est pondérée font l'objet d'une pondération de charge de travail, basée sur le cluster.

Serveur HTTP, tel qu'IBM HTTP Server

Utilisez cette topologie lorsque les références de point de contact désignent des services qui sont déployés dans un cluster dont la charge de travail est pondérée et qui n'accèdent à aucune information avec état localisée sur un serveur spécifique.

Dans cette topologie, l'API WS-Addressing IBM génère automatiquement l'adresse de référence de noeud final appropriée, en fonction du préfixe d'URL du serveur HTTP configuré pour le module de service web cible. Vous devez fournir des informations d'URL de noeud final HTTP, en d'autre termes, configurer le préfixe d'URL HTTP pour chaque déploiement de chaque application. Le client communique avec le serveur HTTP qui achemine les demandes du client vers un serveur spécifique en fonction de la configuration de serveur HTTP.
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.

[AIX Solaris HP-UX Linux Windows][IBM i]Ne déployez pas dans cette topologie une référence de point de contact représentant un bean session avec état, car le serveur HTTP ne conservera pas l'affinité avec ce bean session avec état et répartira ses demandes sur les serveurs disponibles.

[AIX Solaris HP-UX Linux Windows][IBM i]Pour maintenir l'affinité et la haute disponibilité du bean session avec état des références de noeud final créées à l'aide de l'API propriété d'IBM, utilisez un Proxy Server for IBM WebSphere Application Server en plus de votre serveur HTTP, comme décrit dans la topologie ci-dessous.

Serveur HTTP avec un Proxy Server for IBM WebSphere Application Server

Utilisez cette topologie lorsque les références de point de contact désignent des services qui sont déployés dans un cluster dont la charge de travail est pondérée, qui accèdent, le cas échéant, à des informations avec état localisées sur un serveur spécifique et qui, le cas échéant, font l'objet d'une reprise en ligne dans une configuration à haute disponibilité. 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, l'API WS-Addressing génère automatiquement l'adresse de référence de noeud final appropriée, en fonction du préfixe d'URL du serveur HTTP qui est configuré pour le module de service web cible. Vous devez fournir des informations d'URL de noeud final HTTP, en d'autre termes, configurer le préfixe d'URL HTTP pour chaque déploiement de chaque application.

Le client communique avec le serveur HTTP que vous configurez en acheminant des demandes d'un plug-in vers un serveur proxy, afin de transmettre les demandes du client à un IBM WebSphere Application Server . Le proxy achemine ensuite de façon dynamique les demandes vers le serveur approprié.
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 le cluster WebSphere Application Server. Le serveur proxy et le serveur cible résident dans la même cellule d'administration.
[AIX Solaris HP-UX Linux Windows][IBM i]Si le proxy ciblé par la référence de noeud final est un Proxy Server for IBM WebSphere Application Server version 6.1 ou ultérieure, et qu'il existe dans la même cellule d'administration que le noeud final, les messages destinés à une référence de noeud final dont la charge de travail est pondérée font l'objet d'une pondération de charge de travail, basée sur le cluster. Pour les références de noeud final créées à l'aide de l'API propriété d'IBM, le comportement suivant s'applique également :
  • Si la référence de noeud final représente un bean session avec état, les demandes adressées à la référence du noeud final conservent l'affinité au serveur et l'instance du bean session avec état.
  • Si la référence de noeud final représente un bean session avec état hautement disponible, la référence du noeud final reste valide si le bean session avec état est défaillant sur un autre serveur.
Les références de noeud final créées à l'aide de l'API JAX-WS standard n'ont pas d'affinité de serveur, ni de haute disponibilité.

[z/OS]Si le proxy ciblé par la référence de noeud final est un Proxy Server for IBM WebSphere Application Server version 6.1 ou ultérieure, et qu'il existe dans la même cellule d'administration que le noeud final, les messages destinés à une référence de noeud final dont la charge de travail est pondérée font l'objet d'une pondération de charge de travail, basée sur le cluster.


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=cwbs_wsa_eprs
Nom du fichier : cwbs_wsa_eprs.html