Clients de services Web et configuration de règles à l'aide de la règle du fournisseur de services
Si un fournisseur de services publie sa règle dans son WSDL (Web Services Description Language), la configuration des règles d'un client de services WebSphere Application Server peut être exécutée de manière dynamique, en fonction des règles prises en charge par son fournisseur de services.
Le fournisseur de services doit publier sa règle au format WS-PolicyAttachment dans son WSDL et le client doit pouvoir prendre en charge les règles du fournisseur. Le client peut baser la configuration de sa règle entièrement sur la règle du fournisseur, ou seulement en partie avec des restrictions définies par la configuration de l'ensemble de règles du client.
Un client acquiert la règle du fournisseur à l'aide d'une requête HTTP GET ou du protocole d'échange de métadonnées de services Web (WS-MetadataExchange) pour obtenir le WSDL du fournisseur. Vous pouvez configurer comment le client obtient la règle du fournisseur et le noeud final sur lequel la règle est acquise à l'aide de la console d'administration ou des commandes wsadmin. Si vous utilisez le protocole WS-MetadataExchange pour obtenir la règle du fournisseur, vous avez alors l'avantage de pouvoir sécuriser les demandes WS-MetadataExchange GetMetadata à l'aide d'un ensemble de règles système adaptées.
Si les règles du fournisseur utilisent des WSDL à plusieurs parties, vous pouvez utiliser une requête HTTP GET pour obtenir ces règles mais vous ne pouvez pas utiliser le protocole WS-MetadataExchange. Pour plus d'informations sur les WSDL à plusieurs parties, consultez la rubrique relative à WSDL.
La règle côté client d'applications Web est calculée et mise en cache en tant que configuration d'exécution. Cette règle calculée est connue la règle effective et est utilisée pour les demandes ultérieures de services Web sortantes au noeud final ou à l'opération pour lequel le calcul a été effectué. La configuration de l'ensemble de règles d'origine du client ne change pas.
Pour un service spécifique, la configuration de règle dynamique a lieu une seule fois, par défaut, et il est supposé que cette configuration est la même pour tous les noeuds finals qui mettent en oeuvre un service, car ils ont le même WSDL. Les calculs de règle basés sur ce WSDL sont mis en cache dans l'exécution client (ils ne persistent pas) et sont partagés avec chaque service cible.
Dans un environnement en clusters, ceci signifie que le client n'obtient pas de nouveau la règle du fournisseur pour chaque instance de noeud final d'un service Web.
Dans WebSphere Application Server version 8.0 et versions ultérieures, une référence de service peut être configurée pour l'utilisation d'un autre document WSDL que celui configuré pour le service client. Par défaut, les références de service héritent leur ensemble de règles et leur configuration WS-Policy de leur service parent, mais, si vous le souhaitez, l'ensemble de règles et la configuration WS-Policy peuvent être remplacés. Pour plus de détails, voir Utilisation de WS-Policy pour échanger des règles dans un format standard.
Si une configuration de règle différente est nécessaire pour chaque implémentation de noeud final, vous devez créer un port pour chacun des noeuds finals. Ensuite, vous pouvez spécifier une configuration de règle différente pour chaque noeud final.
Les règles de transport, telles que HTTP, SSL et JMS, ne peuvent pas être exprimées dans le format WS-PolicyAttachment, ainsi le client ne peut pas acquérir les règles de transport du fournisseur de services. Si le client requiert des règles de transport, vous devez les configurer au cours de la configuration de l'ensemble de règles du client.
Dans le cas d'une demande HTTP GET, lorsque celle-ci cible l'emplacement du noeud final, la demande utilise les mêmes règles de transport HTTP et SSL que la demande d'application. Lorsque la cible de la demande HTTP GET est un noeud final différent, un ensemble de règles système peut aussi être associé pour définir des règles de transport HTTP et SSL différentes.
Dans le cas d'une demande WS-MetadataExchange GetMetadata, la configuration WS-Security de l'ensemble de règles système spécifié est utilisée. Les propriétés de transport HTTP sont héritées de l'application.
Un client configuré pour utiliser SAML (Security Assertion Markup Language) peut utiliser la configuration de règles dynamique. Toutefois, le client doit être configuré pour utiliser les liaisons générales.
Règles d'administration dans un registre
Un client peut obtenir la configuration des règles d'un fournisseur de service Web à partir d'un registre tel que WSRR (WebSphere Service Registry and Repository) à l'aide d'une requête HTTP GET.
Le WSDL des règles du fournisseur de services, les règles correspondantes et les annexes des règles sont stockés dans un registre tel que WSRR. Ces règles doivent contenir leur configuration au format WS-PolicyAttachments. Le client doit pouvoir prendre en charge les règles du fournisseur.
Le registre doit permettre l'utilisation des requêtes HTTP GET pour publier le WSDL qui contient les annexes WS-Policy, par exemple WSRR version 6.2 ou ultérieure.
Vous pouvez appliquer la règle du fournisseur que le client a obtenue d'un registre au niveau du service ou de la référence de service mais pas au niveau de l'application.
S'il existe une connexion sécurisée entre le client et le registre, vous devez vérifiez la sécurité entre le serveur d'applications et le serveur du registre.
Si le registre demande une authentification, vous devez aussi configurer des règles pour authentifier les demandes de service sortantes vers le registre. Par défaut, les données d'identification HTTP et HTTPS sont utilisées à la fois pour le registre et le noeud final du service Web. Il est donc conseillé de sécuriser toutes les données d'identification d'autorisation et de vérifier que ces données d'identification ne sont pas envoyées à un noeud final non autorisé. Un ensemble de règles système peut aussi être associé pour définir des règles de transport HTTP et SSL différentes.
Héritage de règles
La règle du fournisseur peut être associée au niveau du service ou de l'application. Des noeuds finals ou des opérations héritent la configuration de leurs règles du service adapté.
Calcul de règle
- Si vous spécifiez uniquement une règle de fournisseur, la règle calculée est basée sur toutes les règles que le client WebSphere Application Server prend en charge, croisées avec la règle du fournisseur. En effet, le fournisseur détermine la règle, tant que le client peut la prendre en charge. Cette configuration de règles est disponible si le point de portée (opération du noeud final) auquel la règle du fournisseur est rattachée n'est pas lié à un ensemble de règles du client et n'hérite pas une liaison d'ensemble de règles de points de portée parent.
- Lorsque vous spécifiez une règle de client et de fournisseur, la règle calculée est basée sur la règle acceptable pour le client, croisée par la règle du fournisseur. En effet, la règle est conforme à l'ensemble des règles client, mais peut être davantage restreinte par les règles dictées par le fournisseur. La règle qui est acceptable pour le client est définie par l'ensemble de règles qui est relié au point de portée du client ou dont le point de portée du client hérite d'un point de portée parent. Cette configuration de règles est disponible si le point de portée (opération du noeud final) auquel la règle du fournisseur est rattachée est lié à un ensemble de règles du client ou hérite une liaison d'ensemble de règles de points de portée parent.
Le langage WS-Policy fournit un moyen d'exprimer plusieurs choix de règle, ainsi le calcul de règles peut aboutir à plusieurs résultats. Par exemple, le fournisseur de services peut prendre en charge WS-ReliableMessaging 1.0 et WS-ReliableMessaging 1.1. Si le client prend également en charge les deux versions, il peut utiliser l'une ou l'autre version dans ses demandes de services Web envoyées au fournisseur. Dans ce cas, si plusieurs versions de spécifications sont acceptables pour le client et le fournisseur, la règle effective est calculée à l'aide de la version la plus récente.
Croisement de règles sur le client Dispatch JAX-WS
- Le client se conforme à la règle du fournisseur destinée à l'opération uniquement si cette règle est identique pour toutes les opérations fournies par le service (sur le plan sémantique et syntaxique).
- Si la règle du fournisseur n'est pas identique pour toutes les opérations fournies par le service, le client renvoie une exception JAX-WS WebserviceException avec la cause WSPolicyException (CWPOL0106E) et un message d'erreur approprié.
- Si les opérations ne comportent aucune règle, le client utilise la règle de fournisseur effective pour le noeud final de service.
Régénération de la règle du fournisseur détenue par le client
La règle du fournisseur que le client détient pour un service est régénérée la première fois que le service Web est appelé après le chargement de l'application. Ensuite, la règle du fournisseur est actualisée lors que l'application redémarre ou lorsque vous appelez de manière explicite une mise à jour de la règle du fournisseur. Une fois les règles du fournisseur régénérées, les règles effectives sont recalculées.
Vous pouvez appeler une mise à jour de la règle du fournisseur dans le code de l'application. Ceci peut être utile si un appel JAX-WS échoue. Dans le traitement de l'exception, vous pouvez forcer une tentative avec une règle régénérée. Vous pouvez définir la propriété suivante (disponible dans la classe WSPConstants de l'API) sur le proxy client JAX-WS, puis réexécuter la demande JAX-WS : com.ibm.websphere.wspolicy.refreshProviderPolicy.
Si la propriété com.ibm.websphere.wspolicy.refreshProviderPolicy est définie, la règle du fournisseur détenue par le client pour un service est régénérée et la règle effective est recalculée à la demande suivante. Une fois la régénération et le recalcul terminés, la valeur de propriété com.ibm.websphere.wspolicy.refreshProviderPolicy est annulée.
L'exemple ci-dessous de code pour un client Dispatch montre l'identification d'une exception qui peut être résolue par la régénération de la règle du fournisseur, suivie de l'appel de régénération.
try
{
dispatch.invoke(params);
}
catch (javax.xml.ws.WebServiceException e)
{
Throwable cause = e.getCause();
if ((cause instanceof NullPolicyException) || (cause instanceof PolicyException) )
{
// L'exception peut être due au fait que la règle du fournisseur n'est pas à jour.
//
// Il y a également un message sur la console qui commence par les caractères CWPOL,
// qui aide à déchiffrer et à déboguer la cause de l'erreur.
// Ce message est également disponible avec
// String nlsedMessage = cause.getMessage();
Map<String, Object> requestContext = dispatch.getRequestContext();
requestContext.put(WSPConstants.REFRESH_PROVIDER_POLICY, Boolean.TRUE);
// La méthode suivante peut entraîner une autre exception d'appel jax-ws.
// La règle peut encore en être la cause, au quel cas un message s'affiche sur la
// console.
dispatch.invoke(params);
}
// Pour toutes les autres exceptions, utiliser le traitement d'exception normal pour
// l'application. Dans ce cas, présumer qu'il n'y a pas d'autres exceptions et relancer
// l'exception initiale. N'oubliez pas que WebServiceException peut être causé par une
// WSPolicyAdministrationException. Dans ce cas, un message s'affiche sur la
// console, mais le fait de forcer une régénération dans l'application ne résout pas le problème.
throw e;
}