Implémentation de clients de services Web JAX-WS statiques
Vous pouvez développer des clients de services Web statiques sur la base de la spécification Java™ EE (Java Platform, Enterprise Edition) et du modèle de programmation JAX-WS (Java API for XML-Based Web Services).
Avant de commencer

Pourquoi et quand exécuter cette tâche
- Développement de clients de services Web reposant sur le modèle de programmation JAX-WS
Les clients de services Web ayant accès à des services Web JAX-WS et qui peuvent les appeler sont développés sur la base de la spécification des services Web pour Java EE (Java Platform, Enterprise Edition). Le serveur d'applications prend en charge les clients EJB (Enterprise JavaBeans), les clients d'applications Java EE, les fichiers JSP (JavaServer Pages) et les servlets fondés sur le modèle de programmation JAX-WS. Les clients de services Web s'appuyant sur la spécification JAX-RPC peuvent appeler les services Web de type JAX-WS si le fichier WSDL est compatible avec le profil de base WS-I.
Le modèle de programmation de client JAX-WS prend en charge l'API client Dispatch et l'API client de Dynamic Proxy. L'API client Dispatch est un modèle de programmation client dynamique alors que le modèle de programmation de client statique de JAX-WS correspond au client Dynamic Proxy. Les clients Dispatch et Dynamic Proxy permettent l'appel synchrone et asynchrone des services Web JAX-WS.
Le client de proxy dynamique appelle un service Web reposant sur une interface SEI fournie. Les instances Dynamic Proxy JAX-WS optimisent la fonction Dynamic Proxy dans Java SE Runtime Environment 6 (JRE). Vous devez commencer avec un client WSDL si vous développez un client statique.
En revanche, l'API client Dispatch, javax.xml.ws.Dispatch, est un client XML orienté message destiné aux développeurs XML avancés qui préfèrent utiliser les blocs de construction XML. L'API Dispatch peut envoyer des données en mode PAYLOAD ou MESSAGE. En mode PAYLOAD, le client Dispatch n'est responsable que de la fourniture du contenu de l'élément soap:Body et JAX-WS inclut la charge dans un élément soap:Envelope. En mode MESSAGE, le client Dispatch est chargé de fournir la totalité de l'enveloppe SOAP. Vous n'avez pas besoin d'un fichier WSDL si vous développez un client dynamique.
Pour développer des clients de services Web reposant sur le modèle de programmation JAX-WS, vous devez déterminer le modèle client qui correspond le mieux aux besoins de votre application de service Web. Si vous souhaitez que le client de services Web appelle le service en fonction des interfaces SEI avec un proxy dynamique, utilisez l'API Dynamic Proxy pour développer un client de service Web statique. Une fois les proxy créés, l'application client peut appeler les méthodes sur ces proxy, comme une implémentation standard des interfaces SEI. Si vous souhaitez utiliser directement XML et non une abstraction Java et utiliser la structure de messages ou la structure de charge de messages, utilisez l'API Dispatch pour développer un client de service Web dynamique. Consultez la section Implémentation des clients de services Web dynamiques pour en savoir plus sur le développement de ces clients.
Effectuez cette tâche pour développer un client de services Web statique avec un fichier WSDL.
Pour appeler les services Web de manière asynchrone à l'aide d'un client JAX-WS statique ou dynamique, déterminez si vous implémentez le modèle d'interrogation ou de rappel. Pour plus de détails sur l'implémentation de l'interrogation ou du rappel asynchrone pour les clients de service Web, consultez les informations relatives à l'appel de services Web JAX-WS. Le modèle de programmation JAX-WS pour le client et le service utilise des annotations pour représenter les mêmes informations fournies dans la liaison client JAX-RPC de manière non spécifique à un fournisseur.
- Clients de services Web JAX-WS gérés et non gérés
Le serveur d'applications prend en charge des clients de services web gérés et non gérés lors de l'utilisation du modèle de programmation JAX-WS :
- Clients gérés
Les clients de services Web pour Java EE sont définis par la spécification JSR 109 (Java Requirements) et sont des clients gérés car ils s'exécutent dans un conteneur Java EE. Ces clients sont livrés sous forme de fichiers EAR et ils contiennent des composants qui servent de demandeurs de service. Ces composants peuvent être une application client Java EE, un composant web comme un servlet, une page JSP (JavaServer Pages) ou un EJB (Enterprise JavaBeans) de session. Les clients gérés de services Web utilisent des API JSR 109 et des informations de déploiement pour rechercher et appeler un service Web.
Pour les clients gérés, vous pouvez utiliser l'interface JNDI (Java Naming and Directory Interface) pour rechercher un service ou utiliser des annotations pour injecter des instances d'un service ou d'un port JAX-WS. Consultez la documentation de la sécurité des services Web de jeton UserName, de la sécurité des services Web de signature numérique et de la sécurité des Services Web de jeton LTPA. Le code suivant est un exemple de recherche de contexte compatible JSR 109 :
InitialContext ctx = new InitialContext(); FredsBankService service =(FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService"); FredsBank fredsBank = service.getFredsBankPort(); long balance = fredsBank.getBalance();
Vous pouvez aussi utiliser l'annotation @WebServiceRef ou @Resource pour déclarer des clients gérés. La syntaxe de ces annotations entraîne la liaison du type spécifié par l'annotation dans l'espace de nom JNDI. Si les annotations sont utilisées dans une zone ou une méthode, une instance de service ou de port JAX-WS est également injectée. Vous pouvez utiliser ces annotations au lieu de déclarer des entrées service-ref dans le descripteur de déploiement client. Vous pouvez toujours utiliser le descripteur de déploiement de client pour déclarer des clients gérés JAX-WS, similaires aux clients gérés JAX-RPC. Vous pouvez également utiliser le descripteur de déploiement pour remplacer et augmenter les informations spécifiées par les annotations @WebServiceRef et @Resource. Utilisez l'annotation @WebServiceRef pour lier et injecter une instance de service ou de port JAX-WS. L'annotation @Resource ne peut être utilisée que pour lier et injecter une instance de service JAX-WS. L'utilisation de l'une de ces annotations pour déclarer des clients gérés JAX-WS est prise en charge uniquement dans certains types de classe. Certains de ces types de classe incluent des classes d'implémentation de noeud final JAX-WS, des classes de gestionnaire JAX-WS, des classes de bean enterprise et des classes de servlet.
L'exemple suivant utilise l'annotation @WebServiceRef pour obtenir une instance de FredsBank :
Dans la classe, il n'est désormais plus nécessaire d'initialiser la zone fredsBank. Cette zone peut être utilisée immédiatement :@WebServiceRef(name=”service/FredsBankPort”, value=FredsBankService.class) FredsBank fredsBank;
long balance = fredsBank.getBalance();
Vous pouvez également utiliser l'annotation @WebServiceRef pour obtenir des instances de classes de service JAX-WS :@WebServiceRef(name=”service/FredsBankService”) FredsBankService service;
Dans la classe, il n'est désormais plus nécessaire d'initialiser la zone fredsBank. Cette zone peut être utilisée immédiatement :FredsBank fredsBank = service.getFredsBankPort(); long balance = fredsBank.getBalance();
Outre l'annotation @WebServiceRef, vous pouvez utiliser l'annotation @Resource pour obtenir une instance de classes de services JAX-WS, par exemple :@Resource(name=”service/FredsBankService”, type=FredsBankService.class) FredsBankService service;
Comme avec l'annotation @WebServiceRef, vous pouvez désormais utiliser la zone service sans instanciation, par exemple :FredsBank fredsBank = service.getFredsBankPort(); long balance = fredsBank.getBalance();
Vous pouvez utiliser les annotations @Resource et @WebServiceRef sur une classe. Dans ce cas, JNDI doit être utilisé pour rechercher le service ou le port JAX-WS, par exemple :@WebServiceRef(name=”service/FredsBankService”, type=FredsBankService”) public class J2EEClientExample { … … public static void main(String[] args) { … … InitialContext ctx = new InitialContext(); FredsBankService service =(FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService"); FredsBank fredsBank = service.getFredsBankPort(); long balance = fredsBank.getBalance(); } … }
Pour plus d'informations sur l'utilisation des annotations @WebServiceRef et @Resource, consultez les spécifications pour JSR-109, JSR-224, JSR-250 et Java EE 5 (Java Platform Enterprise Edition 5).
Comme indiqué précédemment, lors de l'utilisation d'annotations ou de l'interface JNDI pour obtenir des instances de services et de ports JAX-WS, n'instanciez pas les objets renvoyés. L'instanciation peut produire une instance client non gérée. L'exemple suivant illustre un cas d'utilisation non appropriée :@WebServiceRef(name=”service/FredsBankService”) FredsBankService service; service = new FredsBankService(); // le client devient non géré.
Pour les clients gérés JAX-WS déclarés par l'annotation @WebServiceRef ou @Resource et pour les clients déclarés à l'aide d'entrées service-ref dans le descripteur de déploiement client, utilisez la console d'administration pour fournir l'URL du noeud final utilisé par le client. L'URL spécifiée remplace l'URL du noeud final dans le document WSDL utilisé par le client. Pour plus d'informations sur cette URL de noeud final, consultez la documentation relative à la configuration des liaisons de client de services Web.
- Clients non gérés
Les clients Java SE 6 (Java Platform, Standard Edition) appelant les services Web par le biais de l'exécution de JAX-WS et ne s'exécutant pas dans un conteneur Java EE sont appelés clients non gérés. Un client de services Web non géré est un client Java autonome capable d'inspecter directement un fichier WSDL et d'adresser des appels au service Web à l'aide d'API JAX-WS. Ces clients sont livrés sous la forme de fichiers JAR qui ne contiennent aucune information de déploiement.
- Clients gérés
En commençant par WebSphere Application Server version 7.0 et ultérieure, les modules d'application Java EE 5 (modules d'application Web version 2.5 ou ultérieure ou les modules EJB version 3.0 ou ultérieure) sont analysés pour connaître les annotations permettant d'identifier les services et clients JAX-WS. Toutefois, les modules d'application antérieurs à Java EE 5 (modules d'application Web version 2.4 ou antérieure, ou modules EJB version 2.1 ou antérieure) ne font pas l'objet d'une analyse des annotations JAX-WS, par défaut, pour des raisons de performance. Dans la version 6.1 de Feature Pack for Web Services, le comportement par défaut consiste à analyser les modules d'application Web antérieurs à Java EE 5 pour identifier les services JAX-WS et à rechercher dans les modules d'application Web antérieurs à Java EE 5 et dans les modules EJB des clients de service au cours de l'installation de l'application. Dans la mesure où le comportement par défaut de WebSphere Application Server version 7.0 et ultérieure consiste à ne pas rechercher les annotations dans les modules antérieurs à Java EE 5 au cours de l'installation de l'application ou du démarrage du serveur, si vous souhaitez conserver la compatibilité antérieure avec le module de fonctions, vous devez configurer soit la propriété UseWSFEP61ScanPolicy dans l'élément META-INF/MANIFEST.MF d'un fichier WAR ou d'un module EJB, soit définir la propriété personnalisée de machine virtuelle Java, com.ibm.websphere.webservices.UseWSFEP61ScanPolicy, sur les serveurs pour en demander l'analyse pendant l'installation de l'application et le démarrage du serveur. Pour en savoir plus sur l'analyse des annotations, voir les informations relatives aux annotations JAX-WS.
Procédure
Résultats
Vous avez créé et testé une application client de services Web.
Que faire ensuite
Après avoir développé un client d'application de services Web, et lorsque le client est lié de façon statique, le point de contact de service utilisé par l'implémentation est celui identifié dans le fichier WSDL que vous avez utilisé lors de la procédure de développement. Vous pouvez modifier le point de contact de service pendant ou après l'installation de l'application de services Web. Pour les clients gérés, vous pouvez modifier le noeud final à l'aide de la console d'administration ou de l'outil de scriptage wsadmin. Pour les clients de services Web JAX-WS non gérés, vous pouvez modifier le noeud final à partir de l'application client.
Vous pouvez, en option, personnaliser les services Web en implémentant les extensions de votre client de services Web. Certains exemples de ces extensions impliquent l'envoi ou la réception de valeurs dans des en-têtes SOAP, l'envoi et la réception d'en-têtes de transport HTTP ou JMS (Java Message Service). Pour en savoir plus sur ces extensions, lisez les rubriques sur l'implémentation d'extensions aux clients de services Web.