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.
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).
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.
- Utilisez la topologie Connexion directe pour les configurations sans cluster.
- Utilisez la topologie Serveur HTTP, tel qu'IBM HTTP Server 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 n'accèdent à aucune information avec état localisée sur un serveur spécifique.
- Utilisez la topologie Serveur proxy pour IBM WebSphere Application Server ou Serveur HTTP avec un Proxy Server for IBM WebSphere Application Server, lorsque les références de noeud final désignent des services :
- qui sont déployés dans un cluster dont la charge de travail est pondérée ;
- qui, le cas échéant, accèdent à des informations avec état localisée sur un serveur spécifique ;
- qui, le cas échéant, font l'objet d'une reprise en ligne dans une configuration à haute disponibilité.
Le serveur HTTP doté d'une topologie Proxy Server for IBM WebSphere Application Server est utile lorsque le serveur HTTP proprement dit ne comporte aucune fonctionnalité intégrée pour le routage avec affinité vers des noeuds finaux WS-Addressing.
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.


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é.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- 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.
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.

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.
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.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- 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.
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.