1.0 Introduction
2.0 Spécifications et logiciels pris en charge
3.0 Modifications par rapport à la version précédente
4.0 Limitations
4.1 Impossible d'exécuter l'exemple de gestion de la chaîne logistique globale
5.0 Problèmes connus
5.1 Explorateur de services Web
5.2 Interopérabilité avec le contexte d'exécution IBM SOAP
5.3 Génération d'un document WSDL à partir d'un fichier DADX
5.4 Générateur JSP d'outils Web
5.5 Utilisation du client de test universel
5.6 Plusieurs sorties autorisées dans certains cas avec les services Web DADX
5.7 La préférence de pilote JDBC ne doit être utilisée que sur Linux
5.8 Nécessité de mettre à jour les fichiers exemple DAD si XML extender n'est pas installé dans le répertoire par défaut
5.9 Problèmes liés aux services Web DADX
5.10 Prise en charge de la génération DADX
5.11 Erreurs WSDL à l'issue de l'importation d'un fichier de services Web à partir de la version 4.0.x
5.12 Incidents lors de l'utilisation de la ligne de commande des services Web
5.13 Création d'un service Web sans serveur existant
5.14 Génération d'un exemple d'application de services Web
5.15 Importation de fichiers WSDL avec l'authentification HTTP de base
5.16 Incidents lors de l'utilisation de l'environnement d'exécution WebSphere v5.0.2
5.17 Configuration d'un groupe DADX avec des informations relatives à la source de données
5.18 Chargement d'un releveur de coordonnées de client à l'aide du client de test universel
5.19 Préférences des ressources non respectées
5.20 Incidents lors de l'utilisation du contexte d'exécution Apache Axis 1.0
5.21 Echec de la compilation de l'exemple de fichier JSP de service Web
5.22 Incident avec la ligne de commande des services Web lorsque la langue allemande est utilisée
5.23 Erreur lorsque localhost n'est pas défini
5.24 Limitations permanentes lors de l'utilisation du contexte d'exécution IBM SOAP
5.25 Le service Web et le client utilisent des contextes d'exécution différents
5.26 Cliquer sur Fin dans l'assistant Client
de services Web
5.27 Aide-mémoire des services Web
La fonction des outils des services Web permet de rechercher, créer et publier des services Web de bean Java, DADX, de bean enterprise et des services Web d'URL. Ce fichier Readme décrit les problèmes et restrictions connus, ainsi que les solutions associées aux fonctions des outils des services Web suivants :
- Génération d'un document WSDL à partir d'un bean Java, d'un document DADX, d'un bean enterprise, d'un fichier ISD et d'un URL.
- Génération d'un proxy ou d'un squelette Java à partir d'un document WSDL.
- Création et déploiement d'un service Web à partir d'un bean Java, DADX, d'un bean enterprise ou d'un URL.
- Recherche et publication des services Web.
- Génération d'un exemple d'application Web à partir d'un proxy Java.
- Problèmes d'interopérabilité.
L'explorateur de services Web prend en charge les navigateurs Web suivants :
- Microsoft Internet Explorer 6.0 ou supérieur
- Mozilla 1.2.1 ou supérieur
Cette version des outils des services Web génère du code conforme aux spécifications suivantes :
- Simple Object Access Protocol (SOAP) Version 1.1
- Universal Description, Discovery, and Integration (UDDI) Version 2.0
- Web Services Definition Language (WSDL) Version 1.1
- Web Services Inspection Language (WSIL) Version 1.0
Cette version des outils des services Web prend en charge ce qui suit :
- le contexte d'exécution des services Web d'IBM WebSphere v5.0.2
- les environnements d'exécution IBM SOAP version 2.2 et version 2.3
- le contexte d'exécution Apache Axis 1.0
Si vous lancez l'environnement de test WORF en dehors du plan de travail à l'aide de Mozilla, une version de Mozilla 1.3.1 au moins est recommandée. La sortie de l'appel de votre service Web et les fichiers de description peuvent ne pas être rendus correctement dans les versions précédentes du navigateur Mozilla.
Le contexte d'exécution DADX nécessite DB2 7.2 Fix Pack 6 ou supérieur, ou DB2 8.1 ou une version supérieure.
Les fonctions suivantes sont nouvelles dans les outils des services Web de la version 5.1 :
- Prise en charge du contexte d'exécution des services Web IBM WebSphere v5.0.2. Il s'agit du contexte d'exécution stratégique des services Web IBM qui supporte JSR-109 et JAX-RPC.
- Prise en charge du contexte d'exécution Apache Axis 1.0. Ce contexte d'exécution supporte JAX-RPC et il est destiné aux utilisateurs qui préfèrent développer pour la plateforme ouverte Apache Axis.
- Fourniture d'un outil de ligne de commande des services Web qui permet à l'utilisateur de créer des services Web à partir d'un bean Java, d'un EJB ou d'un fichier WSDL, et de publier des entités et des services ou de supprimer leur publication dans les registres UDDI.
- Explorateur WSDL pleinement intégré à l'explorateur de services Web.
- Fourniture d'outils d'assemblage d'applications de services Web, avec notamment :
- Web Services Editor et Web Services Client Editor pour éditer les descripteurs de déploiement JSR-109 et IBM WebSphere v5.0.2.
- Action en incrustation pour appeler la fonction EndpointEnabler.
- Action en incrustation pour appeler la fonction WebServiceDeploy.
- Assiste l'utilisateur dans le processus de création de services Web compatibles WS-I à travers les préférences. L'utilisateur peut déterminer si l'assistant de création de services Web va exiger, suggérer ou ignorer la compatibilité WS-I lors de la création de services Web.
- Génération et utilisation de documents de référence de services Web WSIL par proxy.
- Permet à l'utilisateur de mettre à jour les descripteurs de déploiement WebSphere v5.0.2 avec des exemples de configuration de sécurité.
- Prise en charge de SOAP sur JMS comme transport pour les messages SOAP lors de la création de services Web à partir d'EJB.
- Prise en charge de catégories UDDI définies par l'utilisateur.
- Prise en charge de la validation des services Web. Lorsque cette préférence est définie, l'outil valide le fait qu'une Enterprise Application et/ou les modules qu'elle contient sont conformes à un ensemble de règles établissant leur conformité avec JSR-109.
L'exemple de gestion de la chaîne logistique globale ne fonctionne pas sur WAS Express.
- Si vous utilisez l'explorateur de services Web à l'aide du registre UDDI privé, le formulaire Gérer les vérifications du serveur d'informations d'un noeud d'entreprise n'est pas chargé dans les cas suivants :
- Vous n'êtes pas connecté au noeud du registre contenant le noeud d'entreprise.
- Vous êtes connecté au noeud du registre contenant le noeud d'entreprise, mais ce dernier n'appartient pas à l'ID utilisateur et mot de passe utilisés pour la connexion au registre.
- Vous ne pourrez pas utiliser ce dernier pour réaliser des opérations d'interrogation et de publication par le biais d'un registre UDDI configuré en vue d'une authentification de base. Il peut s'agir d'un registre privé qui est déployé sur un serveur pour lequel l'authentification de base est activée. Les registres publics (IBM, Microsoft, SAP, NTT et XMethods) ne sont pas concernés.
- Lorsqu'une recherche avancée est utilisée dans Web Services Explorer pour rechercher des entités dans un registre UDDI privé WAS configuré avec un backend Cloudscape et qu'une ou plusieurs interfaces de services supplémentaires sont indiquées en tant que paramètres, la recherche échoue et le message suivant s'affiche dans la fenêtre d'état :
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: Could not list all service providers. ------------------------------------------------------------------------------ Nested exception is:E_fatalError (10500) Serious technical error has occurred while processing the request. : Fault code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) Serious technical error has occurred while processing the request.
- Le registre XMethods a des procédures en place pour vérifier les services Web publiés en supprimant ceux qui ne sont pas accessibles ou qui ne fonctionnent pas. Pour éviter la suppression d'un service Web publié, assurez-vous que les références d'URL figurant dans les fichiers WSDL sont accessibles sur internet.
Le registre d'entités UDDI SAP renvoie une erreur E_fatalError pour une demande de recherche d'entité par catégorie, dans laquelle findQualifier a la valeur "combineCategoryBags" (tModelKey a la valeur UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2). Le message d'erreur suivant s'affichera dans la fenêtre d'état. Cet incident se produit uniquement dans le registre d'entités UDDI SAP.
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: Could not list all service providers. ------------------------------------------------------------------------------ Nested exception is:A serious technical error has occurred while processing the request. : Fault code=Client Fault string=UDDI Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=A serious technical error has occurred while processing the request. at com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626) at FindBusWithQualifier.main(FindBusWithQualifier.java:35)
- Les états générés par la fonction de vérification du serveur d'informations renvoyés par le registre d'entités UDDI SAP ne contiennent aucun statut. Lorsque des états sont renvoyés par SAP, le contenu de la colonne d'état de la fonction de vérification du serveur d'informations figurant dans le formulaire Gérer les vérifications du serveur d'informations de Web Services Explorer est effacé. Cet incident se produit uniquement dans le registre d'entités UDDI SAP.
- Lors de la tentative de publication d'une entreprise, d'un service ou d'une interface de services dans le registre UDDI XMethods, vous obtenez un message d'erreur concernant un "échec d'établissement de liaison SSL". Il s'agit d'un incident connu faisant actuellement l'objet de recherches chez IBM et XMethods.
- Lors de l'utilisation du contexte d'exécution IBM SOAP, la génération de WSDL avec des paramètres complexes peut générer des erreurs lors de l'utilisation d'outils Microsoft qui utilisent des ressources WSDL. Les outils Microsoft ne gèrent pas correctement les instructions include XSD et il peut s'avérer nécessaire d'intégrer les schémas XSD dans le document WSDL généré. Pour cela, sélectionnez
Fenêtres > Préférences > Services Web > Génération du code > Utiliser le schéma avec lignes d'entrée.Lors de l'utilisation du contexte d'exécution IBM SOAP, l'assistant de création de services Web est désormais configuré pour prendre en charge intégralement la génération de mappages à base d'éléments, en plus des mappages à base de types standard, si la case "Activer le mappage à base d'éléments" est cochée. A partir du menu principal WSAD, cette case à cocher est disponible dans la page des préférences suivante :
Fenêtres > Préférences > Services Web > Génération du code.Si cette préférence n'est pas activée, (configuration par défaut), le module d'exécution Apache/IBM SOAP peut ne pas interagir avec les modules d'exécution de services Web d'autres fournisseurs qui envoient des messages dont les éléments n'ont pas les propriétés "xsi:type". Les modules d'exécution de service Web d'autres fournisseurs suivent différentes règles sur l'inclusion des propriétés xsi:type. Dans certains cas, ces propriétés sont toujours inclues. Dans d'autres cas, elles ne le sont jamais. Il arrive également que certains modules d'exécution offrent un choix de configuration. Les propriétés xsi:types sont parfois omises pour certains types d'éléments, tels que les tableaux.
L'erreur qui se produit le plus fréquemment dans le module d'exécution IBM/Apache SOAP est la suivante :
targetException=java.lang.IllegalArgumentException: No Deserializer found to deserialize a ':MyElement' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.
Lorsque cette option est activée, les mappages à base d'éléments sont générés dans :
- le fichier du descripteur de déploiement pour les scénarios bean Java/EJB ascendants et les scénarios de squelette WSDL
- le proxy dans le cadre des scénarios client.
Les mappages à base d'éléments se présentent de la manière suivante :
<isd:map
encodingStyle="encoding style"
xmlns:x="un-espace-nom"
qname="x:un-nom-local"
xml2JavaClassName="un-nom-de-classe-de-désérialiseur"/>Un mappage à base d'éléments est généré pour :
- Chaque partie définie dans chaque entrée wsdl:message.
- Chaque partie définie dans chaque sortie wsdl:message, dans le cadre des scénarios de squelette et de proxy uniquement.
- Chaque élément racine ou local faisant partie de chaque type complexe référencé par des sections du fichier WSDL
L'assistant de services Web WSAD se fonde sur les spécifications SOAP et XSD pour déterminer si le nom d'un élément dans le mappage à base d'éléments doit être qualifié (c'est-à-dire comporter un espace de nom) ou non qualifié.
L'utilisation de noms qualifiés ou non qualifiés dans les services Web WSAD est régie par ces règles :
- Les noms de partie dans WSDL sont non qualifiés.
- Les éléments racine dans XSD entraînent l'utilisation de noms qualifiés.
- Les éléments locaux dans XSD entraînent l'utilisation de noms non qualifiés si le schéma indique elementFormDefault="unqualified", ce qui correspond également à la valeur par défaut lorsque le schéma ne comporte pas d'attribut elementFormDefault.
- Les éléments locaux dans XSD entraînent l'utilisation de noms qualifiés si le schéma indique elementFormDefault="qualified".
On constate que certains modules d'exécution génèrent des éléments non qualifiés dans les messages SOAP en dépit du fait qu'un schéma spécifie l'utilisation d'éléments qualifiés par le biais de l'attribut "elementFormDefault" du schéma XSD. Dans ce cas de figure, vous pouvez être amené à modifier manuellement le schéma WSDL ou XSD d'un service en affectant la valeur "unqualified" à l'attribut elementFormDefault.
Exemple de mappage à base d'éléments où les noms sont non qualifiés (sans indication d'espace nom) :
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Exemple de mappage à base d'éléments où les noms sont qualifiés (avec indication de l'espace nom) :
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="http://www.ibm.com/"
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Un seul mappage à base d'éléments est généré pour chaque nom d'élément. Ainsi, si le schéma utilise plusieurs fois le même nom d'élément avec des types différents, un seul de ces éléments est sélectionné, de manière aléatoire, pour servir de base au mappage à base d'éléments. Les autres éléments du même nom mais de types différents ne sont pas désérialisés. Cette règle s'applique si le schéma utilise le même nom pour un élément et une partie WSDL.
- En cas de commencement par un bean de service renvoyant un tableau de mappage ou un tableau de table de hachage et que l'option "mappage à base d'éléments" est activée, le proxy SOAP généré mappera à tort le type de retour vers une java.lang.String[]. Une exception ClassCastException se produit lors de l'exécution. Pour éviter ce problème, exécutez l'assistant de client de service Web avec l'élément WSDL nouvellement créé et générez à nouveau le proxy SOAP dans le projet client.
- Afin d'améliorer l'interopérabilité avec les services Web de Microsoft, la phase d'exécution DADX a été mise à jour de façon à ce qu'ils puissent générer des services Web de style de document. Pour activer cette fonction, utilisez l'assistant de configuration DADX pour ouvrir la page de propriétés du groupe DADX devant être utilisé. Au bas de la page de propriétés, vérifiez que la zone d'entrée "Utilisation du style de document" a la valeur true.
- La génération d'un proxy Java pour les opérations d'appel DADX comportant plusieurs paramètres de sortie n'est pas prise en charge.
- Lors de la création d'un service Web DADX, le message "IWAB0177E Error generating WSDL from a DADX file." peut apparaître. Dans la plupart des cas, ce message indique des erreurs de base de données ; vous devez consulter le journal de la console du serveur pour obtenir plus de détails sur l'erreur. Vérifiez également les points suivants :
- Les fichiers DAD (*.dad) doivent se trouver dans le répertoire du groupe DADX. C'est ainsi que l'environnement d'exécution WORF recherche les fichiers DAD.
- Si vous tentez de générer un fichier DAD à partir d'un fichier de mappage de RDB vers XML (.rmx), vérifiez que le fichier DAD se trouve bien dans le même dossier que le fichier DADX.
- Le schéma DADX n'utilise plus la balise de document WSDL pour la documentation. Cette balise fait maintenant partie du schéma DADX. Cela peut entraîner des erreurs de validation pour les anciens fichiers DADX n'ayant pas été soumis au processus de migration visant à autoriser l'utilisation du schéma mis à jour. Par exemple, si l'ancien fichier DADX contient les données XML suivantes :
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Provides queries for part order information at myco.com.
</wsdl:documentation>la nouvelle entrée du document doit être la suivante :
<documentation>
Provides queries for part order information at myco.com.
</documentation>
Lors du lancement du client de test universel à partir de l'assistant de services Web, l'URL du fournisseur JNDI correspond au port 2809, utilisé par défaut par WebSphere v5. Si vous utilisez un serveur WebSphere v4 ou si vous avez modifié le numéro de port, vous ne pourrez plus effectuer de recherches dans le répertoire JNDI. Si vous tentez d'accéder à ce répertoire, l'erreur suivante se produit :
IWAD0403E Impossible de construire l'arborescence JNDI : Interception de CORBA.COMM_FAILURE lors de la résolution du paramètre reference=WsnNameService initial.Pour remédier à cette situation :
- Cliquez deux fois sur le serveur utilisé. Les propriétés du serveur s'affichent.
- Sélectionnez l'onglet des ports.
- Copiez le port d'amorçage Orb.
- Ouvrez la fenêtre des propriétés JNDI dans le client de test universel.
- Collez le port d'amorçage dans la zone d'entrée de l'URL du fournisseur.
Généralement, nos outils ne prennent pas en charge plusieurs sorties dans un service Web. Toutefois, dans le cas de services Web DADX, plusieurs sorties sont admises si la valeur true est affectée à la propriété d'utilisation du groupe de styles de document. Dans ce cas, lorsque la valeur true est attribuée à style de document, plusieurs sorties sont associées dans un seul document XML.
Une nouvelle catégorie de préférences de services Web (Fenêtre > Préférences > Services Web) appelée Pilotes JDBC a été ajoutée. Bien que cette préférence soit disponible sur toutes les plateformes, elle est conçue pour être utilisée uniquement sous Linux. Sous Linux, il peut être difficile de déterminer l'emplacement du fichier JAR contenant les pilotes JDBC. C'est pourquoi, cette page de préférences a été ajouté afin que vous puissiez indiquer le fichier JAR à utiliser. Généralement, seul le code de validation DADX utilise ces informations relatives au fichier JAR.
The DAD files located in the WSinstall_dir\wstools\eclipse\plugins\com.ibm.etools.webservice_<version>\samples\DADX_examples directory may need to be modified to reflect your particular system configuration.
Au début du fichier, se trouve une ligne similaire à la ligne suivante :
<!DOCTYPE DAD SYSTEM "c:\dxx\dtd\dad.dtd">
Si XML extender a été chargé dans un autre répertoire que c:\dxx, alors cette chaîne doit être mise à jour afin de correspondre à l'emplacement réel. Cette remarque s'applique également aux machine Linux sur lesquelles l'emplacement est généralement /usr/IBMdb2xml.
- Les modifications apportées dans la page Propriétés du groupe DADX du service Web de l'assistant de services Web peuvent ne pas prendre effet immédiatement. Par conséquent, nous recommandons d'effectuer les modifications des propriétés de groupe DADX à l'aide de l'assistant de configuration de groupe DADX.
- Après avoir édité et validé un fichier DADX, il se peut qu'un message apparaisse dans la vue des tâches et indique que le projet doit être recompilé. Dans ce cas, cliquez à l'aide du bouton droit de la souris sur le projet concerné, puis cliquez sur Recompiler un projet. Vous devrez peut-être répéter l'opération afin de supprimer le message de la vue des tâches.
Bien que les fonctions définies par l'utilisateur soient énumérées dans l'assistant de génération DADX, il n'existe actuellement pas de prise en charge de la génération de DADX à partir des fonctions définies par l'utilisateur. La prise en charge existante est limitée à la génération DADX à partir de fichiers DAD, de procédures stockées et d'instructions SQL. La sélection d'une fonction UDF générera un simple fichier squelette DADX.
Si vous avez importé un fichier de services Web à partir de 4.0.x, les messages d'erreur suivants peuvent être émis :
Erreur Le composant 'result' comporte une valeur incorrecte 'anyElement' définie pour son type. Les déclarations de type doivent désigner des valeurs valides définies dans un schéma.
Erreur Le composant 'return' comporte une valeur incorrecte 'findPatientResult' définie pour son élément. Les déclarations d'élément doivent désigner des valeurs valides définies dans un schéma.
Erreur Le composant 'response' comporte une valeur incorrecte 'findPatientResponse' définie pour son élément. Les déclarations d'élément doivent désigner des valeurs valides définies dans un schéma.Pour remédier à cette situation :
- Supprimez les fichiers WSDL.
- Régénérez vos services Web en lançant de nouveau l'assistant de services Web.
- Option FileNStoPkg : L'option -fileNStoPkg pour WSDL2WebService dans la ligne de commande ne fonctionne pas actuellement. Veuillez utiliser -NStoPkg et supprimer chaque mappage de la ligne de commande. Une autre possibilité consiste à utiliser l'assistant de création de services Web si le mappage de l'espace de nom vers le package est requis.
- Répertoire avec espace : Evitez d'exécuter WSDL2WebService à partir d'un répertoire dont le nom contient un espace. Sinon, le fichier compile.bat (ou compile.sh sous Linux) généré ne peut pas être compilé.
- Descripteurs de déploiement client et fichiers WSDL : Après l'exécution de Bean2WebService, EJB2WebService, WSDL2WebService, les descripteurs de déploiement côté client (webservicesclient.xml, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et _mapping.xml) se trouvent dans le répertoire client-side/META-INF. Si l'utilisateur a l'intention de créer une application client gérée, il doit suivre les procédures suivantes :
- Pour exécuter le client géré sous la forme d'un client d'application EJB ou J2EE, l'utilisateur doit mettre en forme tous les descripteurs de déploiement dans le répertoire META-INF de l'archive et en plus copier le fichier wsdl du côté serveur (situé dans le répertoire WEB-INF/wsdl si le service se trouve dans le conteneur Web, ou dans META-INF/wsdl si le service se trouve dans le conteneur EJB) dans le répertoire META-INF/wsdl du projet de client.
- Pour exécuter le client géré à l'intérieur du conteneur Web, l'utilisateur doit mettre en forme tous les descripteurs de déploiement dans le répertoire WEB-INF de l'archive client (généralement sous la forme d'un fichier WAR ou d'un projet Web dans WebSphere Studio). Le fichier WSDL doit également être copié depuis le côté service vers le répertoire WEB-INF/wsdl. L'utilisateur doit aussi éditer webservicesclient.xml manuellement (à l'aide d'un éditeur de texte ou, si dans WebSphere Studio, à l'aide de l'éditeur xml) en remplaçant chaque occurrence de META-INF par WEB-INF.
Nom de classe avec trait de soulignement : Lors de la création d'un service Web à partir d'un bean Java ou d'un EJB, si le nom de classe du bean de service contient un trait de soulignement et si le caractère suivant est en minuscule (par exemple, test.Simple_bean), le service ne peut pas être démarré sur WebSphere Application Server. La solution consiste soit à utiliser un nom de bean de service sans trait de soulignement, soit à utiliser une majuscule après le trait de soulignement (par exemple, test.Simple_Bean).
- Lors de l'exécution d'un scénario de création de services Web sans serveur Web existant dans l'espace de travail, l'activation du bouton Précédent de la troisième page entraîne la désactivation du bouton Suivant. La solution consiste à annuler à partir de l'assistant et à relancer l'assistant. Pour éviter cet incident, créez le serveur et la configuration avant de lancer le scénario de création de service Web ou évitez de cliquer sur le bouton Précédent de la troisième page lorsqu'il n'existe pas de serveur Web existant.
- Lorsqu'un utilisateur clique avec le bouton droit de la souris sur un fichier Java dans le plan de travail, l'action en incrustation Génération du modèle d'application du menu Services Web génère des modèles de JSP de services Web pour un proxy IBM SOAP. Pour générer des modèles JSP de services Web pour d'autres contextes d'exécution de services Web (IBM WebSphere 5.0.2 et Apache Axis 1.0), cliquez avec le bouton droit de la souris sur un fichier WSDL et sélectionnez l'action en incrustation Générer un client dans le menu Services Web. Lors de l'exécution de cet assistant, sélectionnez Tester le proxy généré
Lors de la génération de squelettes ou de clients à partir d'un fichier WSDL contenant des importations relatives et protégé par l'authentification HTTP de base, l'utilisateur voit s'afficher un message d'erreur indiquant que le fichier WSDL ne peut pas être résolu, même si l'ID utilisateur et le mot de passe corrects sont spécifiés. L'incident est dû au fait que l'ID utilisateur et le mot de passe ne sont utilisés que pour extraire le fichier WSDL d'origine, mais pas les fichiers qu'il importe.
Pour résoudre cet incident, l'utilisateur peut dans un premier temps télécharger dans le plan de travail le fichier WSDL et tous les fichiers qu'il importe, puis générer un squelette ou un client à partir du fichier WSDL téléchargé.
- Pas de prise en charge de WSDL : L'ajout de WSDL à l'URL de noeud final d'un service Web déployé vers le serveur WebSphere v5.0.2, s'exécutant dans l'environnement de test ou dans l'environnement de serveur distant, afin d'obtenir le fichier WSDL pour le service Web déployé n'est pas pris en charge. Le fichier WSDL généré se trouve dans le répertoire WebContent/WEB-INF/wsdl du projet Web pour le service Web de bean Java et dans le répertoire ejbModule/META-INF/wsdl du projet EJB pour le service Web d'EJB. Si la prise en charge de WSDL à partir d'un projet Web est requise, l'utilisateur peut soit faire référence à la copie du fichier WSDL située dans le répertoire WebContent/wsdl du projet Web, soit créer son propre emplacement dans le répertoire WebContent et prendre en charge le WSDL à partir du projet Web.
- Utilisation d'un fichier JAR d'utilitaire ou existence de plusieurs dossiers source : Lors de la création d'un service Web à partir d'un bean Java ou d'un EJB, des fichiers inutiles peuvent être générés dans le module si le projet Web utilise plusieurs dossiers source ou si les beans se trouvent dans un fichier JAR d'utilitaire dans le fichier EAR. Etant donné que ces fichiers générés existent déjà dans le module (soit dans le fichier JAR d'utilitaire, soit dans un autre dossier source), ils doivent être supprimés pour que le projet puisse être compilé et pour que le service Web fonctionne correctement. L'autre solution consiste à fusionner les dossiers source en un seul ou à copier les beans à partir du JAR d'utilitaire vers le dossier source.
- Tableau non pris en charge dans RPC/literal : Lors de la création d'un service RPC/literal, la signature de la méthode ne peut pas contenir de tableau. Si elle contient un tableau, le service ne peut pas être appelé à l'aide du code client généré. Il n'existe actuellement aucune solution pour cet incident. Essayez d'utiliser document/literal ou RPC/encoded si possible.
- La surcharge des méthodes n'est pas prise en charge dans document/literal : La surcharge des méthodes (même nom de méthode, différents paramètres d'entrée) n'est pas prise en charge lors de la création d'un service document/literal. Il n'existe actuellement aucune solution pour cet incident. Essayez d'utiliser RPC/literal ou RPC/encoded si possible.
- Importation WSDL : Une instruction d'importation WSDL ne peut contenir que des URL absolues ou des URL relatives dans le même répertoire. Par exemple, l'importation relative sous la forme suivante n'est pas prise en charge :
<import namespace="http://someNamespace/" location="../someFile.wsdl"/>- L'élément de liaison avant l'élément portType : Vous obtiendrez un message "Error in generating Java files and deployment descriptors from WSDL file (detail: duplicate operation name)" (Erreur lors de la génération des fichiers Java et des descripteurs de déploiement à partir du fichier WSDL (détail : nom d'opération en double)) lors de la génération d'un client proxy ou d'un squelette à partir d'un fichier WSDL contenant un élément de liaison avant un élément portType.
- Eléments abstraits : Lors de la génération de squelettes à partir d'un fichier WSDL avec une opération utilisant des éléments ou des types abstraits, les JavaBeans générés ne peuvent pas être compilés.
- Types sans mappage JAX-RPC par défaut : Lors de la génération de squelettes à partir d'un fichier WSDL avec des opérations contenant des paramètres d'entrée de types qui ne possèdent pas de mappages JAX-RPC par défaut, le bean de mise en oeuvre généré ne peut pas être compilé. L'incident est lié au fait que lorsque javax.xml.soap.SOAPElement est créé à partir de javax.xml.soap.SOAPFactory, il émet une exception javax.xml.soap.SOAPException. Le bean de mise en oeuvre n'intercepte pas ni ne réémet cette exception, et par conséquent, il ne peut pas être compilé.
- Même type de schéma pour les entrées et les sorties : Lors de la génération de squelettes à partir d'un fichier WSDL qui utilise le même type de schéma XML pour ses messages d'entrée/sortie et ses messages d'erreur, les éléments générés ne fonctionnent pas lors de l'exécution. Pour résoudre ce problème, ne partagez pas les définitions de type de schéma XML entre les messages d'entrée/sortie et les messages d'erreur.
- Références à l'élément XSD avec minOccurs et maxOccurs : Lors de la génération de squelettes à partir d'un fichier WSDL, n'utilisez pas de références à l'élément XSD avec les valeurs minOccurs et maxOccurs spécifiées par l'utilisateur (<element ref="..." minOccurs="0" maxOccurs="unbounded"/>). L'utilisation de ce type d'élément entraîne une exception java.util.MissingResourceException au démarrage du serveur.
- Bean émis utilisant des API différentes de celles du bean de service : Si les beans générés par l'émetteur possèdent des API différentes de celles du bean de service lors de la création d'un service Web à partir d'un bean Java ou d'un EJB, vous pouvez rencontrer une erreur d'exécution du type suivant :
La méthode n'est pas définie.
Impossible de trouver une opération Java correspondante.
Voici des exemples de bean de service possédant des API différentes de celles des beans générés :
- beans avec zones publiques
- zones booléennes dont la méthode getter est nommée getBooleanValue au lieu de isBooleanValue,
- nom de méthodes en majuscules
Document/literal (document/literal) avec option de renvoi à la ligne activée : Lors de la création d'un service Web ascendant à l'aide de document/literal, l'option de renvoi à la ligne est activée par défaut. Vous pouvez rencontrer un problème d'interopérabilité si vous avez plusieurs entrées de types différents ou aucune entrée. La solution consiste à utiliser RPC/literal. Bean Java avec nom en minuscules ou contenant un trait de soulignement : Lorsque vous créez un service Web à partir d'un bean Java dont le nom de fichier est en minuscules ou contient un trait de soulignement suivi d'une minuscule, vous obtenez l'erreur suivante :
Error in generating Java files and deployment descriptors from WSDL file with details of getOutputStream() IOException. (Erreur lors de la génération des fichiers Java et des descripteurs de déploiement à partir du fichier WSDL (détail : getOutputStream() IOException)Configuration de sécurité différente : Ne générez pas de services Web avec des configurations de sécurité différentes dans le même module/projet. Utilisez des projets séparés pour chaque service Web.
Si le serveur WebSphere Application Server V5.0 est utilisé pour héberger un service Web DADX, alors le fichier group.properties du groupe DADX doit utiliser la propriété initialContextFactory suivante :
initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactoryAussi, les éléments suivants doivent être ajoutés au fichier web.xml du projet contenant le groupe DADX. (En supposant que le nom JNDI de la source de données soit jdbc/hospital.)
<resource-ref id="ResourceRef_1058550453092">
<res-ref-name>jdbc/hospital</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Lorsque le client de test universel ne parvient pas à précharger la classe de releveur de coordonnées générée par le contexte d'exécution WebSphere v5.0.2 ou Axis, cela est dû au fait que le nom de la classe de bean Java du projet WEB du service est le même que le nom de la classe SEI du projet Web client. Pour résoudre cet incident, procédez comme suit :
- Supprimez le projet Web client de l'espace de travail.
- Cliquez avec le bouton droit de la souris sur le projet Web client, puis cliquez sur "Supprimer".
- Recherchez l'application.xml dans le projet EAR et cliquez deux fois sur ce fichier pour ouvrir l'éditeur de descripteur de déploiement d'application. Sélectionnez le module de projet Web client et cliquez sur "Supprimer". Fermez l'éditeur et enregistrez les modifications.
- Créez le projet Web client dans un fichier EAR différent, le nom du projet EAR devant être alphabétiquement avant le nom du projet EAR du service. Par exemple, si le nom du projet EAR du service est "DefaultEAR", créez le nouveau projet EAR en le nommant "ClientEAR".
- Réexécutez l'assistant de création de services Web.
Les préférences de remplacement de fichier, de création de dossiers et de vérification automatique des fichiers ne sont pas respectées lors de la création de services Web à l'aide du contexte d'exécution WebSphere v5.0.2 et Axis. La création de dossiers est toujours autorisée et la vérification automatique des fichiers n'est jamais activée.
Lorsque vous utilisez le contexte d'exécution WebSphere v5.0.2, le fichier WSDL, SEI et les artefacts de déploiement (sérialiseurs et désérialiseurs) sont toujours remplacés. Les artefacts de développement (bean de service, beans de types complexes, collecteur et classe auxiliaire) ne sont jamais remplacés. Toutefois, l'utilisateur obtient un message d'avertissement concernant le remplacement des descripteurs de déploiement s'ils existent. L'utilisateur peut sélectionner OK pour remplacer les descripteurs de déploiement et poursuivre le scénario, ou Annuler pour empêcher le remplacement des descripteurs de déploiement.
Lorsque vous utilisez le contexte d'exécution Apache Axis 1.0, les émetteurs d'Axis régénèrent à chaque fois tous les fichiers Java serveur/client, deploy.wsdd et undeploy.wsdd. WSDL2Java pour le scénario de génération de service ne génère le fichier d'implémentation du squelette que s'il n'existe pas. Si cette implémentation existe déjà, elle n'est pas remplacée.
La création de services Web à l'aide du contexte d'exécution Apache Axis 1.0 dépend des émetteurs Java2WSDL et WSDL2Java fournis dans Axis 1.0. La prise en charge de document/literal et de document/literal (avec renvoi à la ligne) est problématique dans Axis 1.0 ; par conséquent, l'utilisateur doit utiliser RPC/encoded lors de la création de services Web à l'aide du contexte d'exécution Apache Axis 1.0.
Lors de la définition d'un mappage personnalisé entre le package et l'espace de nom, un package et espace de nom par défaut incorrects s'affichent dans le tableau lorsque vous cliquez sur le bouton Ajouter. L'utilisateur doit remplacer ces valeurs par défaut et entrer son propre mappage de package vers un espace de nom.
Lors de la génération de squelettes ou de proxy de services Web à partir d'un fichier WSDL qui utilise le même nom pour l'un de ses éléments <service> et l'un de ses éléments <port>, n'utilisez pas les fichiers exemples JSP comme client de test. Les fichiers exemples JSP générés contiennent des erreurs et ne peuvent pas être compilés. Toute tentative d'exécution des fichiers exemples JSP sur le serveur entraînera une ERREUR 500 dans le navigateur indiquant que les fichiers exemples JSP ne peuvent pas être chargés, et des exceptions dans la console du serveur indiquant que le conteneur de servlet n'a pas pu compiler les fichiers exemples JSP.
Lors de l'exécution de l'outil de ligne de commande sous Windows en allemand, certains caractères s'affichent en tant que "?" dans la sortie de l'invite de commande. Il est probable que ce caractère corresponde au tréma (Umlaut) allemand.
L'assistant de création de service Web peut échouer lors de la génération de WSDL si le nom d'hôte "localhost" n'est pas défini sur l'ordinateur. Il se peut également que le client de test universel ne parvienne pas à se lancer si "localhost" n'est pas défini.
Sous Windows, l'entrée suivante doit être présente dans le fichier [INSTALL-DRIVE]\WINNT\system32\drivers\etc\hosts :
127.0.0.1 localhost
Sous Linux, l'entrée suivante dans être présente dans le fichier /etc/hosts :
127.0.0.1 localhost
Le contexte d'exécution IBM SOAP doit être utilisé principalement pour des raisons de compatibilité amont. Il est vivement conseillé d'utiliser l'assistant de création de services Web avec le contexte d'exécution IBM WebSphere 5.0.2 pour tous les besoins relatifs à la production. Lorsque vous utilisez l'assistant de création de services Web avec le contexte d'exécution IBM SOAP, l'utilisateur peut rencontrer les limitations permanentes suivantes :
- Génération d'un document WSDL à partir d'un bean Java
- char et java.lang.Character requièrent l'entrée de mappages personnalisés dans la mesure où il n'existe aucun mappage par défaut de char ou de java.lang.Character vers WSDL XSD.
- Les types d'encapsuleurs primitifs java.lang.Boolean, java.lang.Byte, java.lang.Short, java.lang.Integer, java.lang.Long, java.lang.Float etjava.lang.Double ne peuvent pas coexister avec leurs types primitifs individuels correspondants boolean, byte, short, int, long, float et double sur tous les paramètres d'entrée d'un bean de service. Par exemple, un bean de service dans lequel java.lang.Integer et int apparaissent à n'importe quel endroit comme types de paramètre d'entrée ne peut pas être transformé en service Web complet. Lorsque vous essayez d'utiliser l'assistant de service Web pour créer un service Web à partir de ce type de bean service, un message d'avertissement s'affiche sauf si les méthodes contenant les types primitifs ou les types d'encapsuleur ne sont pas sélectionnées dans la page Méthodes de bean Java de services Web de l'assistant. Toutefois, vous devez vous assurer que ces méthodes ne sont pas sélectionnées lorsque vous affichez la page Méthodes de bean Java de services Web pour la première fois. Le retour à cette page et le fait de désélectionner les méthodes une fois que l'avertissement affiché peut générer des services Web incomplets. Dans ce cas, il est nécessaire de redémarrer l'assistant afin d'effectuer les sélections de méthode correctes au premier affichage de la page Méthodes de bean Java de services Web.
- Les tableaux multidimensionnels ne sont pas pris en charge. En java, on peut aussi insérer des beans Java entre les dimensions. Par exemple, au lieu de MyType[][], la forme MyArray[] serait correcte, où MyArray a une propriété de type MyType[]
- Une méthode constituée d'une liste d'arguments en entrée et contenant une combinaison d'éléments DOM et de types de bean simple requiert l'entrée d'un ou plusieurs mappages personnalisés. La spécification Web Services Definition Language (WSDL) Version 1.1 prend en charge un style d'encodage pour tous les éléments en entrée (paramètres). L'environnement d'exécution Simple Object Access Protocol (SOAP) version 2.2 ne prend pas en charge le mappage par défaut de l'élément DOM vers l'encodage SOAP pour les types primitifs et les beans dont l'encodage est de type XML littéral.
- Lorsque vous configurez un mappage personnalisé, si vous essayez d'utiliser la classe de sérialiseur ou de désérialiseur de la phase d'exécution SOAP (c'est-à-dire, les classes du package org.apache.soap.encoding.soapenc) et recevez l'erreur "la classe du sérialiseur/désérialiseur sélectionné ne peut pas être chargée à partir de ce projet", le soap.jar ne se trouve probablement pas sur le chemin de compilation de votre projet Web. Pour résoudre ce problème, annulez l'assistant, utilisez la boîte de dialogue des propriétés de projet Web pour ajouter rép_install_WS\wstools\eclipse\plugins\com.ibm.etools.webservice\runtime\soap.jar au chemin de compilation du projet Web, puis réessayez de lancer l'assistant de service Web.
- Le mappage personnalisé n'est pas pris en charge pour les types complexes imbriqués. Bien que les types imbriqués s'affichent dans la page de mappage de l'assistant, les mappages personnalisés sont ignorés pour ces types.
- Lors de la création d'un service Web à partir d'un classe Java dont l'interface contient un type Java abstrait, la page se service Web de mappages Java vers XML peut définir à tort le champ du désérialiseur pour le type abrégé en tant que org.apache.soap.encoding.soapenc.BeanSerializer. Cela provoque une erreur lors de l'exécution étant donné que le code de désérialiseur de la classe BeanSerializer n'est plus à même de construire une instance de type abstrait. Pour éviter cela, choisissez au besoin l'option Mappage personnalisé pour le type et indiquez dans la zone du désérialiseur le nom d'une classe écrite pour désérialiser le type abstrait.
- Les outils de service Web ne prennent actuellement pas en charge la création de services Web à partir de beans Java contenant des classes internes imbriquées (c'est-à-dire, des classes internes définies au sein d'une classe de niveau supérieur). La solution consiste à déplacer les classes internes dans des classes de niveau supérieur dans des fichiers Java distincts.
- Lors de la création d'un service Web à partir d'un bean Java qui utilise d'autres beans Java avec des propriétés de type Vector (vecteur), Hashtable (table de hachage) ou Map (mappage), XSD sera généré avec des complexTypes contenant les types "Vector" et "Map" à partir de l'espace nom "http://xml.apache.org/xml-soap". Etant donné qu'il n'existe actuellement pas de schéma pour cet espace nom, le valideur XSD produira des erreurs et des avertissements similaires aux suivants :
Ces erreurs et avertissements n'empêchent pas le traitement correct de WSDL et de XSD par les assistants de services Web. Les types "Map" et "Vector" seront correctement mappés à leurs homologues Java. Notez que les autres fournisseurs peuvent avoir des difficultés à traiter WSDL ou XSD contenant ces types car http://xml.apache.org/xml-soap n'est pas un nom d'espace reconnu par les spécifications WSDL 1.1 ou SOAP 1.1. Afin d'améliorer l'interopérabilité, envisagez d'adapter les classes de collection Java aux tableaux et beans, puis à compiler les services Web à partir des adaptateurs.
- Error src-resolve: Cannot resolve the name 'xsd2:Vector' to a(n) type definition component.
- Warning src-import.0: Failed to read imported schema document 'null'.
- Génération d'artefacts Java à partir d'un document WSDL
- La prise en charge est limitée à un élément part par élément input ou output. Plusieurs éléments parts logiques dans un message d'entrée ou de sortie ne sont pas pris en charge. Le premier élément part est traité et les autres sont ignorés.
- Lorsque vous générez des squelettes ou des proxy de service Web à partir d'un langage WSDL qui utilise le type base64Binary à partir de l'espace de nom xsd (http://www.w3.org/2001/XMLSchema), le contexte d'exécution du service Web utilise effectivement le xsi:type base64 à partir de l'espace nom soapenc (http://schemas.xmlsoap.org/soap/encoding/). En général, les deux types peuvent être librement interchangés. Toutefois, il est possible que la différence entre le type dans le message et le type dans le schéma provoque le rejet du message par certaines exécutions du protocole SOAP. Dans ce cas, vous pouvez créer un sérialiseur manuellement, qui sera similaire au Base64Serializer d'Apache SOAP mais qui écrira du xsd:base64binary au lieu de soapenc:base64.
- Les squelettes de bean Java ne peuvent pas être compilés s'ils sont créés à partir de documents WSDL contenant des noms d'opération et de partie qui ne correspondent pas à des identifiants Java valides. Les noms d'opération et de partie WSDL doivent être des identifiants Java valides pour permettre la création de squelettes de bean Java.
- Les assistants des services Web utilisent par défaut les URI "http" lors de la génération de WSDL ; cependant, certains documents WSDL provenant d'autres outils peuvent faire appel occasionnellement aux URI d'un service Web, d'une action SOAP ou d'un espace nom cible qui emploient des schémas autres que "http", tels que "urn". Lorsque vous générez des proxy ou des squelettes, à partir de WSDL, qui contiennent des URI non http, les assistants des services Web peuvent mapper ces URI vers le package Java "com.example" plutôt que vers un package plus significatif. Dans certains cas, les assistants de services Web ne peuvent pas gérer entièrement ces URI et génèrent l'erreur "IWAB0234E Une interne interne s'est produite"
- Lors de la génération de proxy Java et de squelettes Java à partir de WSDL, vous disposez désormais de la possibilité de mapper les types XSD intrinsèques boolean, byte, short, int, long, float et double au types encapsuleurs "java.lang" (par exemple, java.lang.Integer) à la place des primitives Java (par exemple, int). Par défaut, les assistants de services Web effectuent le mappage vers les primitives Java. Pour que les assistants effectuent le mappage vers les classes d'encapsulation "java.lang", sélectionnez Fenêtres -> Préférences -> Services Web -> Génération de code, puis cochez "Mapper les types de données XML simples vers les classes d'encapsuleur java.lang wrapper."
- Lors de la spécification d'un mappage personnalisé à partir d'un type Java vers un type XSD au cours de la création d'un service Web à partir d'un bean Java ou d'un EJB, le champ de la classe de bean est automatiquement défini sur le nom complet du type Java et ne peut pas être modifié. Lors du mappage personnalisé d'un tableau Java, le nom de la classe de bean sera sous forme de tableau, par exemple, "java.lang.String[]", et sera émise en tant que telle dans les fichiers de descripteur de déploiement ".isd" et "dds.xml". Cette forme de nom de classe n'est pas traitée correctement par le module d'exécution SOAP et entraînera une erreur du type suivant :
Deployment error in SOAP service http://tempuri.org/webservice.AddressBook: class name java.lang.String[] could not be resolved: java.lang.String[] (Erreur de déploiement dans le service SOAP http://tempuri.org/webservice.AddressBook : le nom de classe java.lang.String[] n'a pas pu être résolu : java.lang.String[])
Par conséquent, il n'est pas possible d'effectuer un mappage personnalisé du sérialiseur pour un tableau Java du côté service. Une solution palliative partielle consiste à laisser le champ de classe de sérialiseur vide pour le mappage personnalisé. Cela supprime la génération du nom de classe de tableau dans le descripteur de déploiement et permet au service de fonctionner. Notez que ce problème et cette solution palliative ne s'appliquent pas à la classe du désérialiseur, ni à la possibilité d'effectuer un mappage personnalisé vers le désérialiseur.
- Observations relatives à l'exécution
- Si vous sélectionnez la préférence de génération de code des services Web "Activer le mappage à base d'éléments" et choisissez d'effectuer le déploiement sur un serveur WebSphere Application Server V4, l'entrée suivante risque d'être générée dans les fichiers ISD et dds.xml :
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:some-name"
xml2JavaClassName="some-serializer"/>L'éditeur XML peut marquer l'erreur suivante :
The value of the attribute "xmlns:x" is invalid. Prefixed namespace bindings may not be empty.
Cela n'a aucune incidence sur le serveur WebSphere Application Server V4. Toutefois, n'essayez pas de déployer ce dds.xml vers un autre serveur utilisant Xerces version 2.x (XML4J 4.x) ou supérieure tel que WebSphere Application Server V5). Vous obtiendriez une erreur d'analyse Xerces similaire lorsque le serveur charge le fichier dds.xml. Vous devez régénerer dds.xml en suivant le scénario de service Web et en sélectionnant le type de serveur correct. Cette opération génère un fichier dds.xml adapté à ce type de serveur.
De plus, une erreur d'analyse Xerces serait générée lors de la tentative de déploiement de service Web à partir de ce fichier ISD. La solution consiste à modifier manuellement le fichier au format suivant :
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
qname="some-name"
xml2JavaClassName="some-serializer"/>
- Lorsque vous appelez un service Web créé à partir d'un bean Java ou d'un EJB, si vous obtenez une SOAPException avec une targetException telle que :
"java.lang.IllegalArgumentException: Impossible d'instancier ..."
l'erreur peut être due au fait que la méthode exposée en tant que service Web contient un bean Java pour lequel aucun constructeur public par défaut n'est défini en tant que paramètre et/ou type de retour. Un constructeur public par défaut doit être défini pour autoriser la construction de l'objet par le module d'exécution SOAP dans le cadre du processus de désérialisation.- Les fichiers de sécurité, cl-ver-config.xml et sv-ver-config.xml, actuellement déployés dans le projet Web sont les fichiers de WebSphere version 4.0 et ne correspondent pas exactement aux DTD. Ils peuvent cependant être exécutés à la fois sous WebSphere version 4.0 et WebSphere version 5.0 malgré les erreurs de validation indiquant que "xmlns:ds" ou "xmlns:SOAP-SEC" doit être déclaré.
- Si la configuration de serveur est ouverte dans un éditeur, il se peut que l'assistant de service Web ne parvienne pas à lancer le serveur en raison du fait que le projet de service Web n'aura pas été ajouté à la configuration de serveur. La solution consiste à fermer l'éditeur de configuration du serveur.
- Services Web ISD
- Une fois les données du mappage personnalisé entrées, lors de la création de services Web Java ou de services Web d'EJB, elles sont stockées dans le fichier ISD (excepté l'URL du fichier XSD). Ces informations sont extraites lors de la création de services Web à partir de ce fichier ISD. Par conséquent, lors de la création de services Web à partir d'un fichier ISD, dans la page Mappages Java vers XML de service Web de l'assistant, vous devez compléter L'URL de l'emplacement XSD manuellement.
Si vous créez un service Web à partir d'un bean Java ou d'un EJB, en choisissant IBM SOAP comme contexte d'exécution du service et Apache Axis 1.0 comme contexte d'exécution du client, vous pouvez obtenir l'erreur suivante :
WSDL Not found (WSDL introuvable)
Pour éviter cet incident, créez d'abord le service Web sans choisir de générer un proxy. Créez ensuite un client de services Web à partir du fichier WSDL généré.
Lors de l'exécution de l'assistant Client de services Web, si l'utilisateur clique sur Fin dans la page de configuration de l'environnement du client, il obtient l'erreur suivante :
"null" is not resolvable (Impossible de résoudre "null")
La solution consiste à cliquer sur Suivant dans cette page et dans la page suivante, puis de cliquer sur Fin.
Dans l'aide-mémoire relatif à la création, au test et à la validation d'un service Web compatible WS-I et dans l'aide-mémoire relatif à la création d'un service Web à partir d'un fichier WSDL, si vous utilisez le fichier HelloService.wsdl du répertoire wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_5.1/examples, veuillez modifier l'emplacement du port du service en fonction du contexte d'exécution, comme suit :
Pour IBM Soap :
location="http://localhost:9080/HelloWorldSample/servlet/rpcrouter"
Pour Apache Axis ou WebSphere 5.0.2 :
location="http://localhost:9080/HelloWorldSample/services/Hello_Port"
Si vous importez votre propre fichier WSDL, veuillez vous assurer que l'emplacement est défini correctement en fonction du contexte d'exécution sélectionné, comme mentionné plus haut.
Retour au fichier Readme principal
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.