JAX-RPC - candidat non valide pour l'outil de conversion JAX-RPC

Cette règle marque l'utilisation de fichiers de configuration et de packages spécifiques à JAX-RPC. Elle marque également toute utilisation de la balise jaxrpc-mapping-file dans les fichiers de mappage XML. Le tableau suivant répertorie les packages Java, les fichiers de configuration et les fichiers de mappage XML concernés par cette règle :

Lots	Fichiers de configuration	Fichiers de mappage XML
javax.xml.rpc javax.xml.rpc.encoding javax.xml.rpc.handler javax.xml.rpc.handler.soap javax.xml.rpc.holders javax.xml.rpc.server javax.xml.rpc.soap	ibm-webservices-ext.xmi ibm-webservices-bnd.xmi ibm-webservicesclient-ext.xmi ibm-webservicesclient-bnd.xmi ws-security.xml	webservices.xml web.xml Fichier ejb-jar.xml ibm-webservicesclient-bnd.xmi application.xml

Cette règle exécute la validation à partir de l'outil de conversion JAX-RPC et a déterminé qu'aucun service Web JAX-RPC dans cette analyse n'est un bon candidat pour la conversion binaire en JAX-WS à l'aide de l'outil de conversion JAX-RPC.

L'API Java pour le RPC basé sur XML (JAX-RPC) n'est pas prise en charge dans Liberty ou Liberty Core. Cette technologie est obsolète dans WebSphere Application Server Traditional version 9.0 et pourrait être retirée dans une version ultérieure. Si votre application utilise JAX-RPC, le chemin de migration stratégique consiste à utiliser JAX-WS, mais voici les alternatives :

• Option 1 : Migrer manuellement les services Web JAX-RPC vers les services Web JAX-WS
• Option 2 : Utilisation du moteur Apache Axis 1 JAX-RPC dans Liberty
• Option 3 : Utilisation de WebSphere Application Server Traditional avec son moteur JAX-RPC natif

Le tableau suivant compare les quatre options en fonction de facteurs susceptibles d'affecter votre projet.

Critères de projet	Option 1 Migration manuelle des services web JAX-RPC vers des services web JAX-WS	Option 2 Utilisation du moteur Apache Axis 1 JAX-RPC dans Liberty	Option 3 Utilisation de WebSphere Application Server Traditional avec son moteur JAX-RPC natif
Solution prise en charge	Oui JAX-WS est pris en charge en tant que fonctionnalité configurable sur toutes les éditions de Liberty excepté Liberty Core.	Non Axis 1 n'est pas pris en charge.	Oui JAX-RPC est pris en charge sur WebSphere Application Server Traditional.
Solution stratégique	Oui JAX-WS est stratégique pour toutes les éditions de Liberty excepté Liberty Core.	Non Axis 1 n'est plus en cours de développement.	Non JAX-RPC est obsolète dans WebSphere Application Server Traditional et pourrait être retirée dans une version ultérieure.
Complexité d'implémentation	Elevé Cette option peut s'avérer complexe pour un grand nombre de services Web et de clients JAX-RPC. Faute d'utiliser l'outil de conversion JAX-RPC pour porter les services JAX-RPC vers JAX-WS, de nombreux changements dans la base de code seront nécessaires.	Faible Si l'application utilise déjà Axis 1, cette option n'est pas complexe. Sinon, cette option est de complexité moyenne.	Moyen La migration des services Web JAX-RPC vers un autre moteur préserve une grande partie de la base du code.
Fonctionnalités avancées	Oui JAX-WS offre un grand nombre de fonctions avancées, telles Annotations, JAXB Binding et SOAP 1.2.	Non JAX-RPC ne dispose pas de la plupart des fonctions avancées de JAX-WS.	Non JAX-RPC ne dispose pas de la plupart des fonctions avancées de JAX-WS.
Conformité à la spécification	Oui	Oui Même si JAX-RPC est toujours mentionné dans la spécification Java EE, il est obsolète avec Java EE 6.	Oui Même si JAX-RPC est toujours mentionné dans la spécification Java EE, il est obsolète avec Java EE 6.
Recommandation	Utilisez cette option si vous n'avez que quelques services web JAX-RPC à convertir et que l'application ne répond pas aux exigences de l'outil de conversion JAX-RPC.	Utilisez cette option si vos services Web JAX-RPC s'exécutent déjà sur Axis 1.	Utilisez cette option si vos services Web JAX-RPC sont déjà exécutés sur WebSphere Application Server Traditional, ou si de nombreux services Web JAX-RPC n'exécutent pas encore Axis 1.

Migration manuelle des services web JAX-RPC vers des services web JAX-WS

Pour plus d'informations sur la migration des applications de JAX-RPC vers JAX-WS, voir Scénarios de migration des services Web : JAX-RPC vers JAX-WS et JAXB dans la documentation en ligne.

Pour plus d'informations sur les différences entre JAX-RPC et JAX-WS, voir Modèle de déploiement d'application JAX-WS.

Utilisation du moteur Apache Axis 1 JAX-RPC dans Liberty

Si vous utilisez déjà Axis 1, pour l'utiliser dans Liberty, vous devez inclure les bibliothèques Axis 1 dans le chemin de classe Liberty.

Si vous utilisez un JAX-RPC embarqué, vous pouvez convertir vos services web pour utiliser Axis 1. La procédure suivante explique comment faire migrer un service web de Red Hat JBoss vers Axis 1.

1. Téléchargez les bibliothèques Axis 1.0 à partir du site Web d'Apache.
   Remarque : Axis 2.0 utilise JAX-WS et ne prend pas en charge les services Web JAX-RPC.
2. Incluez les bibliothèques Axis dans le chemin d'accès aux classes. Vous pouvez inclure les bibliothèques dans le chemin d'accès aux classes du serveur ou dans le répertoire WEB-INF/lib de l'application.
3. Supprimez du fichier web.xml la référence au service Web.
4. Ajoutez les servlets d'administration Axis au fichier web.xml. Pour des exemples du fichier web.xml, voir Installation avancée : ajout d'Axis à votre propre application Web sur le site Web d'Apache.
5. Régénérez les services Web à partir du fichier WSDL en utilisant la commande suivante :

      java -cp <AXIS LIBRARIES> org.apache.axis.wsdl.WSDL2Java -t    java -cp <AXIS LIBRARIES> org.apache.axis.wsdl.WSDL2Java -t -s -o <Output directory> <WSDL file>

   Pour plus d'informations sur cette commande, voir Référence WSDL2Java sur le site Web d'Apache.

6. Créez un descripteur de déploiement Axis en créant un fichier XML nommé server-config.wsdd dans le répertoire WEB-INF.

   Pour plus d'informations sur les éléments de configuration WSDD, voir Référence de déploiement (WSDD) sur le site Web d'Apache.

7. Modifiez le code client en fonction du nouvel environnement. Etant donné que le serveur n'est pas utilisé en tant que conteneur, les références JNDI ne peuvent pas être utilisées. Les références JNDI doivent être supprimées et être remplacées par des références directes à l'URL.

   Par exemple, la méthode suivante inclut une recherche JNDI :

   
   public DemoType getService() throws Exception {
   
   javax.naming.InitialContext ctx = new javax.naming.InitialContext();
   
   DemoService service = (DemoService)ctx.lookup("java:comp/env/service/Demo");
   
   return service.getDemoService();
   }

   La recherche doit être remplacée :

   private com.ibm.demo.webservices.server.DemoType getService() throws Exception {
   
   com.ibm.demo.webservices.server.DemoService_ServiceLocator service = new com.ibm.demo.webservices.server.DemoService_ServiceLocator();
   
   com.ibm.demo.webservices.server.DemoType demoType = service.getDemoService();
   
   return demoType;
   
   }

Utilisation de WebSphere Application Server Traditional avec son moteur JAX-RPC

Si vous souhaitez utiliser le moteur WebSphere Application Server JAX-RPC, vous devez utiliser WebSphere Application Server Traditional. Liberty ne prend pas en charge JAX-RPC. Si vous souhaitez utiliser Liberty, vous devez sélectionner l'une des autres options.

Configuration uniquement

Si des fichiers de configuration JAX-RPC sont détectés, mais qu'il n'y aucune utilisation détectée de JAX-RPC Java API pour cette application, les fichiers de configuration peuvent venir d'une utilisation antérieure de la technologie JAX-RPC qui n'est plus nécessaire. Les configurations non utilisées peuvent être retirées.