1.0 Introduction
2.0 Spécifications et logiciels pris en charge
3.0 Modifications par rapport à la version précédente
4.0 Problèmes connus
4.1 Explorateur de services Web
4.2 Le serveur de surveillance TCP/IP ne fonctionne pas sous Linux
4.3 Registre UDDI privé
4.4 Interopérabilité avec l'environnement d'exécution IBM SOAP
4.5 Génération d'un document WSDL à partir d'un fichier DADX
4.6 Générateur JSP d'outils Web
4.7 Scénario Hospital
4.8 Utilisation d'Universal Test Client
4.9 Plusieurs sorties admises dans certains cas avec les services Web DADX
4.10 Préférence du pilote JDBC à utiliser sous Linux uniquement
4.11 Nécessité de mettre à jour les fichiers exemple DAD si XML extender n'est pas installé dans le répertoire par défaut
4.12 Remarques relatives aux services Web DADX
4.13 Affichage incorrect des boîtes de dialogue de l'explorateur si Mozilla et Netscape sont en cours d'exécution
4.14 Support de génération DADX
4.15 Erreurs WSDL après importation d'un fichier de services Web de la version 4.0.x
4.16 Problèmes lors de l'utilisation de Linux avec GTK
4.17 Utilisation du serveur Tomcat avec l'environnement d'exécution AXIS
4.18 Problèmes lors de l'utilisation de la ligne de commande de services Web
4.19 Création de service Web sans serveur existant
4.20 Génération d'une application exemple de services Web
4.21 Importation de fichiers WSDL avec l'authentification de base HTTP
4.22 Problèmes lors de l'utilisation de l'environnement d'exécution WebSphere v5.0.2
4.23 Configuration d'un groupe DADX avec des informations de source de données
4.24 Chargement du releveur de coordonnées client à l'aide d'Universal Test Client
4.25 Préférences des ressources non observées
4.26 Problèmes lors de l'utilisation de l'environnement d'exécution
Apache Axis 1.0
4.27 La compilation du fichier JSP exemple de service Web n'a pas abouti
4.28 Erreur lorsque l'hôte local n'est pas défini
4.29 Restrictions permanentes lors de l'utilisation de l'environnement d'exécution IBM SOAP
4.30 Le client et le service Web utilisent des environnements d'exécution différents
4.31 Sélection de Terminer dans l'assistant de client de service Web
4.32 Aide-mémoire de 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é.
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 :
- l'environnement d'exécution des services Web IBM WebSphere v5.0.2,
- les environnements d'exécution IBM SOAP version 2.2 et version 2.3 et
- l'environnement d'exécution Apache Axis 1.0.
Si vous lancez l'environnement de test WORF en dehors de l'espace de travail à l'aide de Mozilla, il recommandé d'utiliser au minimum la version 1.3.1 du navigateur. Les fichiers de description et les données générées après l'appel d'un service Web risquent de ne pas s'afficher correctement si vous utilisez une version antérieure du navigateur Mozilla.
L'environnement d'exécution DADX requiert DB2 7.2 fixpack 6 ou version ultérieure ou DB2 8.1 ou version ultérieure.
Les fonctions suivantes ont été ajoutées dans les outils de services Web de la version 5.1 :
- Prise en charge de l'environnement d'exécution des services Web IBM WebSphere v5.0.2. Il s'agit de l'environnement d'exécution de services Web IBM stratégique qui prend en charge JSR-109 et JAX-RPC.
- Prise en charge de l'environnement d'exécution Apache Axis 1.0. Cet environnement d'exécution prend en charge JAX-RPC et s'adresse aux utilisateurs qui préfèrent développer pour la plateforme Apache Axis ouverte.
- Fournissez un outil de ligne de commande de 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 et d'annuler la publication d'entreprises et de services dans des registres UDDI.
- Intégration complète de l'explorateur WSDL dans l'explorateur de services Web.
- Prise en charge des outils d'assemblage d'application de services Web, tels que :
- Editeur de services Web et éditeur client de services Web permettant d'éditer les descripteurs de déploiement JSR-109 et IBM WebSphere v5.0.2
- Action de menu en incrustation permettant d'appeler la fonction EndpointEnabler
- Action de menu en incrustation permettant d'appeler la fonction WebServiceDeploy
- Aide à l'utilisateur dans le processus de création de services Web compatibles WS-I avec les préférences. L'utilisateur peut choisir que les services Web requièrent, suggèrent ou ignorent la compatibilité WS-I lors de la création de services Web.
- Génération et consommation de documents de référence de services Web WSIL par proxy.
- Activation de l'utilisateur pour mise à jour des descripteurs de déploiement WebSphere v5.0.2 avec des configurations de sécurité exemple.
- Prise en charge de SOAP sur JMS en tant que transport des messages SOAP lors de la création de services Web à partir de beans EJB.
- Prise en charge de catégories UDDI définies par l'utilisateur.
- Prise en charge de la validation de service Web. Lorsque cette préférence est définie, l'outil confirme le fait qu'une application d'entreprise et/ou les modules de cette dernière sont compatibles avec un ensemble de règles, ce qui prouve la compatibilité avec JSR-109.
- 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 l'explorateur de services Web 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 comporte les procédures permettant de vérifier les services Web publiés en supprimant ceux auxquels il n'est pas possible d'accéder ou qui ne sont plus opérationnels. 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 l'explorateur de services Web est effacé. Cet incident se produit uniquement dans le registre d'entités UDDI SAP.
- Lorsque vous tentez de publier une entreprise, un service ou une interface de service vers le registre UDDI XMethods, vous obtenez un message d'erreur signalant un incident d'établissement de liaison SSL. Il s'agit d'un problème connu qu'IBM et XMethods tentent de résoudre.
Le serveur de surveillance TCP/IP ne fonctionne pas sous Linux. Toute tentative d'insertion d'un serveur de surveillance entre un service Web et un client de service Web (par exemple, les fichiers JSP de l'exemple de service Web, les fichiers JSP du bean Java des outils Web et Universal Test Client) a une incidence sur les communications établies entre le client et le service. Le client se bloque lors de la première réponse du service. Pour corriger cette erreur dans les pages JSP ou Universal Test Client,fermez tous les navigateurs, lancez un nouveau navigateur en dehors de WebSphere Studio et entrez l'URL appropriée pour l'exemple de pages JSP générées ou Universal Test Client.
Pour contrôler le trafic SOAP sous Linux, vous pouvez utiliser un autre outil de surveillance, tel que le tunnel TCP/IP fourni avec l'environnement d'exécution Apache SOAP, disponible à l'adresse http://ws.apache.org/soap/index.html.tool. Lancez cet outil et appelez une opération du client du service Web. Le trafic demande/réponse doit apparaître dans le tunnel. Toutefois, le client peut s'interrompre. Arrêtez le tunnel. Le client se débloque et l'opération peut s'exécuter. Relancez le tunnel avant d'effectuer l'appel suivant.
- Les vérifications du serveur d'informations du registre UDDI privé sont visibles pour toutes les activités du registre. Une activité peut voir des vérifications du serveur d'informations associées à l'activité elle-même (par exemple, la clé de l'activité ne correspond jamais aux clés source ou aux clés cible des vérifications du serveur d'informations).
- Lorsque le registre UDDI de test est configuré avec le dorsal de base de données Cloudscape, les méthodes de recherche par nom UDDI effectuent par défaut des recherches prenant en compte la distinction maj/min. Cela est contraire à la spécification UDDI et constitue une restriction.
- Le registre UDDI privé doit être configuré avec le dorsal Cloudscape uniquement dans le but d'effectuer des tests de base (en d'autres termes, ce dorsal ne doit pas être utilisé dans des conditions de production car l'exécution d'actions telles que des demandes complexes est source d'erreurs). Pour plus d'informations sur le registre UDDI privé, reportez-vous à la documentation Network Deployment dans l'InfoCenter de WAS V5.
- Après la création ou la mise à jour d'un registre UDDI de test d'unité de type Cloudscape sous Linux, vous pouvez obtenir un avertissement rouge dans la console de serveur qui indique :
Cloudscape (instance <uuid>) is attempting to boot the database <UDDI DB location> even though Cloudscape (instance <uuid>) may still be active. Only one instance of Cloudscape should boot a database at a time. Severe and non-recoverable corruption can result and may have already occurred.
Cet avertissement peut être ignoré. Vous pouvez obtenir plus de détails en consultant le site suivant :
http://www-1.ibm.com/support/docview.wss?rs=636&context=SSCVRP&q=&uid=swg21051601&loc=en_US&cs=utf-8&lang=en+en
- Lors de l'utilisation de l'environnement 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 de l'environnement d'exécution IBM SOAP, l'assistant 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 règles d'inclusion des propriétés xsi:type ne sont pas les mêmes pour tous les modules d'exécution de services Web proposés par des fournisseurs tiers. 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 dans le cadre des scénarios ascendants bean Java/EJB et des 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 conforme aux 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 nom) ou non qualifié.
L'assistant de services Web WSAD suit ces règles pour effectuer un choix entre des noms d'élément qualifiés et non qualifiés :
- 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 de 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 de 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.
- Lorsque vous commencez avec un bean service qui renvoie un tableau contenant des éléments Map ou Hashtable et que l'option de "mappage en fonction des éléments" est activée, le proxy SOAP généré mappe de manière incorrecte le type de retour vers un élément 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.
- Pour améliorer l'interopérabilité avec les services Web de Microsoft, le module d'exécution DADX a été mis à jour pour permettre la génération de services Web utilisant un 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>
Le pilote DB2 db2java.zip doit être ajouté au chemin d'accès aux classes WebSphere ws.ext.dirs. Pour ajouter db2java.zip, procédez comme suit :
- Accédez à la perspective Serveur (Fenêtre > Ouvrir la perspective > Serveur).
- Dans la sous-fenêtre Configuration de serveur, développez Serveur.
- Cliquez deux fois sur WebSphere v.4.0 Test Environment. L'éditeur d'instance s'affiche.
- Dans l'éditeur d'instance, cliquez sur l'onglet Chemins d'accès, puis cliquez sur Ajouter des fichiers JAR externes dans la section Chemin d'accès aux classes propre à WebSphere (ws.ext.dirs) pour ajouter /home/db2inst1/sqllib/java12/db2java.zip au chemin WebSphere.
- Sélectionnez Fichier > Sauvegarder (nom du fichier) pour sauvegarder les modifications, puis quittez l'éditeur d'instance.
Pour connaître les mises à jour apportées à la documentation du scénario Hospital, accédez à la page WebSphere Developer Domain et cliquez sur Library.
Lors du lancement d'Unviversal Test Client à 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.La solution est la suivante :
- 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.
Les fichiers DAD se trouvant dans le répertoire répertoire_installation_WS\wstools\eclipse\plugins\com.ibm.etools.webservice_<version>\samples\DADX_examples doivent être modifiés afin de refléter votre configuration système particulière.
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 machines Linux sur lesquelles l'emplacement est généralement /usr/IBMdb2xml.
- Il est possible que les modifications apportées dans la page Propriétés du groupe DADX du service Web ne soient pas prises en compte immédiatement. Il est donc recommandé de modifier les propriétés du groupe DADX à l'aide de l'assistant de configuration du groupe DADX.
- Après avoir modifié et validé un fichier DADX, il est possible qu'un message s'affiche dans la vue Tâches pour vous inviter à recompiler le projet. Dans ce cas, cliquez à l'aide du bouton droit de la souris et sélectionnez Recompiler un projet. Vous pouvez être amené à effectuer cette opération une seconde fois pour supprimer le message de la vue Tâches.
Il est possible que les boîtes de dialogue de l'explorateur de services Web ne s'affichent pas correctement si Mozilla et Netscape sont simultanément en cours d'exécution. Les boîtes de dialogue en incrustation comprennent les boîtes de dialogue Parcourir les documents WSDL et Parcourir la catégorie. Pour résoudre ce problème, utilisez soit Mozilla soit Netscape mais n'exécutez pas ces deux programmes simultanément.
Bien que les fonctions définies par l'utilisateur soient répertoriées dans l'assistant Générer DADX, il n'est pas possible de générer de fichier DADX à partir de ces fonctions. La génération DADX peut uniquement être effectuée à partir de fichiers DAD, de procédures mémorisées et d'instructions SQL. La sélection d'une fonction UDF entraîne la génération d'un fichier squelette DADX simple.
Si vous avez importé un fichier de services Web à partir de la version 4.0, les messages d'erreur suivants peuvent s'afficher :
Erreur La section 'result' comporte une valeur 'anyElement' non valide 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 La section 'response' comporte une valeur non valide 'findPatientResponse' définies pour son élément. Les déclarations d'élément doivent désigner des valeurs valides définies dans un schéma.La solution est la suivante :
- Supprimez les fichiers WSDL.
- Générez à nouveau vos services Web en exécutant une nouvelle fois l'assistant de services Web.
- Lors de l'exécution de WebSphere Studio sous Linux avec GTk, l'assistant de création de service Web associe toujours par défaut le type de service Web à "service Web de squelette de bean Java" quelque soit la sélection dans le plan de travail. L'utilisateur doit remplacer la valeur par défaut et sélectionner le type de service Web désiré.
- Le problème se produit sous Linux avec les serveurs Tomcat 4.1 et 4.0 sur lesquels l'application Web est installée avec Axis. Si le serveur a été démarré et qu'un redémarrage est demandé dans l'assistant de services Web, l'assistant peut se bloquer car Axis empêche le serveur Tomcat de s'arrêter.
Cette situation peut être évitée en arrêtant le serveur avant de démarrer l'assistant de services Web et en désélectionnant la case à cocher "Exécuter sur le serveur" dans la page de l'assistant qui génère le test de l'application de service Web.
- Option FileNStoPkg : L'option -fileNStoPkg pour WSDL2WebService ne fonctionne pas actuellement dans la ligne de commande. Utilisez l'option -NStoPkg et entrez chaque mappage dans la ligne de commande. Vous pouvez également utiliser l'assistant de service Web si le mappage espace de nom vers 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) qui est généré ne se compile pas.
- Descripteur de déploiement client et fichiers WSDL : Après l'exécution de Bean2WebService, d'EJB2WebService et de WSDL2WebService, les descripteurs de déploiement côté client (webservicesclient.xml, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et the _mapping.xml) se trouvent dans client-side/META-INF. Si l'utilisateur a l'intention de créer une application client gérée, il doit suivre la procédure ci-après.
- Pour exécuter le client géré sous la forme d'un EJB ou d'un client d'application J2EE, l'utilisateur doit mettre en forme tous les descripteurs de déploiement sous META-INF de l'archive et copier le fichier wsdl à partir du service (sous WEB-INF/wsdl si le service se trouve dans un conteneur Web ou META-INF/wsdl si le service se trouve dans un conteneur EJB) vers le répertoire META-INF/wsdl du projet client.
- Pour exécuter le client géré dans le conteneur Web, l'utilisateur doit mettre en forme tous les descripteurs de déploiement dans 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 dit également être copié du service dans WEB-INF/wsdl. L'utilisateur doit également éditer manuellement le fichier webservicesclient.xml (à l'aide d'un éditeur de texte ou d'un éditeur xml dans WebSphere Studio) en remplaçant chaque occurrence de META-INF en WEB-INF.
Nom de classe comportant des traits de soulignement : Lors de la création de service Web à partir de bean Java ou d'EJB, si le nom de la classe ou du bean de service comporte un trait de soulignement et que le caractère suivant est en minuscule (par exemple test.Simple_bean), le service ne peut pas démarrer sur le serveur WebSphere Application Server. La solution consiste à utiliser un nom de bean de service ne comportant pas de trait de soulignement ou à utiliser une lettre majuscule après le trait de soulignement (par exemple, test.Simple_Bean).
- Lorsque vous suivez le scénario de création de service Web sans serveur Web existant dans l'espace de travail et que vous sélectionnez le bouton Précédent au niveau de la troisième page, le bouton Suivant sera désactivé. La solution consiste à sélectionner le bouton Annuler dans l'assistant et de redémarrer ce dernier. Pour éviter ce problème, créez le serveur et la configuration avant de démarrer le scénario de service Web et évitez de sélectionner le bouton Précédent lorsque vous vous trouvez dans la troisième page lorsqu'il n'existe aucun serveur Web.
- Lorsqu'un utilisateur clique à l'aide du bouton droit sur un fichier Java du plan de travail, une action de menu en incrustation Générer un modèle d'application sous le menu Services Web génère des fichiers JSP de services Web pour un proxy IBM SOAP. Pour générer des fichiers JSP exemple de services Web pour les autres environnements d'exécution de services Web (IBM WebSphere 5.0.2 et Apache Axis 1.0), cliquez à l'aide du bouton droit de la souris sur un fichier WSDL et choisissez l'action de menu en incrustation Générer un client sous le menu Services Web. Lorsque vous suivez cet assistant, sélectionnez Tester le proxy généré
Lors de la génération de squelettes ou de clients à partit d'un fichier WSDL comportant des importations relatives et qui protégé par l'authentification de base HTTP, l'utilisateur voit 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 entrés. Le problème est dû au fait que l'ID utilisateur et le mot de passe permettent d'extraire uniquement le fichier WSDL d'origine et non les fichiers importés par ce dernier.
Pour résoudre ce problème, l'utilisateur peut tout d'abord télécharger le fichier WSDL et tous les fichiers importés par ce dernier dans le plan de travail puis générer un squelette ou un client à partir du fichier WSDL téléchargé.
- Aucune prise en charge de WSDL : L'ajout de WSDL à l'URL de point d'extrémité d'un service Web déployé sur WebSphere v5.0.2, en cours d'exécution dans l'environnement de test ou dans l'environnement du serveur distant pour obtenir le fichier WSDL pour le service Web déployé n'est pas 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 Jaba et dans le répertoire ejbModule/META-INF/wsdl du projet EJB pour le service Web EJB. Si le service WSDL à partir d'un projet Web est requis, l'utilisateur peut effectuer une référence à la copie du fichier WSDL se trouvant dans le répertoire WebContent/wsdl du projet Web ou créer son propre emplacement sous WebContent et servir le fichier WSDL à partir du projet Web.
- Fichier JAR ou plusieurs dossiers source : Lors de la création d'un service Web à partir d'un bean Java ou d'un EJB, des fichiers qui ne sont pas nécessaires peuvent être générés dans le module s'il existe plus d'un dossier source dans le projet Web ou si les beans se trouvent dans un fichier JAR d'utilitaire d'un fichier EAR. Etant donné que ces fichiers de signature existent déjà dans le module (soit dans le fichier JAR d'utilitaire ou dans un autre dossier source), il est nécessaire de les supprimer pour que la compilation du projet et que le service Web fonctionnent correctement. L'autre solution consiste à fusionner le dossier source dans un autre dossier ou de copier les beans du fichier JAR d'utilitaire dans le dossier source.
- Tableau non pris en charge dans un service RPC/littéral : Lors de la création d'un service RPC/littéral, la signature de méthode ne peut pas contenir de tableau. Si elle en contient, le service ne peut pas être appelé avec le code client généré. Il n'existe actuellement pas de solution pour cette situation. Essayez d'utiliser le service document/littéral ou RPC/codé si possible.
- Surcharge de méthodes non prise en charge dans le service document/littéral : La surcharge de 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/littéral. Il n'existe actuellement pas de solution pour cette situation. Essayez d'utiliser le service RPC/littéral ou RPC/codé si possible.
- Importation WSDL : L'instruction d'importation WSDL ne peut avoir que des URL absolues ou des URL relatives dans le même répertoire. Par exemple, l'importation relative au format suivant n'est pas prise en charge :
<import namespace="http://someNamespace/" location="../someFile.wsdl"/>- Elément de liaison avant l'élément portType : Vous obtenez le message d'erreur "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 du proxy client ou du squelette à partir d'un fichier WSDL contenant l'élément de liaison avant l'élément portType.
- Eléments abstraits : Lors de la génération de squelettes à partir d'un fichier WSDL avec des opérations qui utilisent des types ou des éléments abstraits, la compilation des JavaBeans générés n'aboutira pas.
- Types sans mappages JAX-RPC par défaut : Lors de la génération de squelettes à partir d'un fichier WSDL avec des opérations comportant les paramètres inout des types n'ayant pas de mappages JAX-RPC par défaut, la compilation du bean généré n'aboutira pas. Le problème est dû au fait que lorsqu'un élément javax.xml.soap.SOAPElement est créé à partir de l'élément javax.xml.soap.SOAPFactory, il émet une exception javax.xml.soap.SOAPException. Le bean d'implémentation n'intercepte ou n'émet pas à nouveau cette exception, c'est pourquoi la compilation n'a pas lieu.
- Même type de schéma pour l'entrée et la sortie : Lors de la génération de squelettes à partir d'un fichier WSDL qui utilise le même type de schéma XML pour les messages d'entrée et de sortie et les messages d'erreur, les artefacts générés ne fonctionnent pas à l'exécution. Pour éviter ce problème, ne partagez pas les définitions de type de schéma XML entre les messages d'entrée et de sortie et les messages d'erreur.
- Référence d'é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 d'élément XSD avec des valeurs minOccurs et maxOccurs définies par l'utilisateur (<element ref="..." minOccurs="0" maxOccurs="unbounded"/>). L'utilisation de tels éléments provoque un exception java.util.MissingResourceException au démarrage du serveur.
- API différentes dans le bean émis et dans le bean service : Si les beans générés par l'émetteur ont des API différentes que le bean service lors de la création d'un serveur Web à partir d'un bean Java ou d'un EJB, des erreurs d'exécution du type suivant peuvent se produire :
La méthode n'est pas définie.
Impossible de trouver une opération Java correspondante.
Voici quelques exemples de beans service ayant des API différentes des beans générés :
- beans avec des zones publiques,
- zones booléennes avec une méthode nommée getBooleanValue et non isBooleanValue,
- nom de méthode en lettres majuscules
Littéral de document avec retour à la ligne activé : Lors de la création d'un service Web ascendant à l'aide du document de littéral, par défaut l'option de retour à la ligne est activée. Vous pouvez vous trouver face à un problème d'interopérabilité si vous avez plus d'une entrée avec différents types ou aucun type. La solution consiste à utiliser le service RPC/littéral. Bean Java dont le nom est en lettres minuscules ou comporte un trait de soulignement : Lorsque vous créez un service Web à partir d'un bean Java dont le nom de fichier est en lettres minuscules ou comporte un trait de soulignement suivi d'une minuscule, vous obtenez une erreur du type suivant :
Erreur lors de la génération des fichiers Java et des descripteurs de déploiement à partir du fichier WSDL avec les détails de l'exception IOException getOutputStream().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.WsnInitialContextFactoryDe plus, il est nécessaire d'ajouter les éléments ci-dessous au fichier web.xml du projet contenant le groupe DADX. (En supposant que le nom JNDI de la source de données est 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 nom de la classe du bean Java du projet de service Web est identique au nom de la classe SEI du projet Web client, Universal Test Client ne peut pas pré-charger la classe du releveur de coordonnées client générée par l'environnement d'exécution WebSphere v5.0.2 ou Axis. Pour éviter ce problème, procédez comme suit :
- Supprimez le projet Web client de l'espace de travail
- Cliquez à l'aide du bouton droit de la souris sur le projet Web client et cliquez sur "Supprimer".
- Situez le fichier application.xml dans le projet EAR et cliquez deux fois sur le fichier afin d'ouvrir l'éditeur de descripteur de déploiement d'applications. Sélectionnez le module de projet Web et cliquez sur "Supprimer". Fermez l'éditeur et sauvegardez les modifications.
- Créez le projet Web client sous un EAR différent dans lequel nom du projet EAR doit précéder dans l'ordre alphabétique le nom du projet EAR de service. Par exemple, si le nom du projet EAR de service est "DefaultEAR", appelez le nouveau projet EAR "ClientEAR".
- Exécutez à nouveau l'assistant de service Web.
Les préférences de remplacement de fichier, de création de dossier et de réservation de fichier automatique ne sont pas observées lors de la création de services Web à l'aide de l'environnement d'exécution WebSphere v5.0.2 et Axis. La création de dossier est toujours autorisée et la réservation automatique de fichier n'est jamais activée.
Lors de l'utilisation de l'environnement d'exécution WebSphere v5.0.2, le fichier WSDL, les artefacts de déploiement et SEI (sérialiseurs et désérialiseurs) sont toujours remplacés. Les artefacts de développement (bean service, beans de type complexe, classe holder et helper) ne sont jamais remplacées. Toutefois, l'utilisateur obtient un message d'avertissement relatif aux descripteurs de déploiement s'ils existent. L'utilisateur peut cliquer sur OK pour remplacer les descripteurs de déploiement et poursuivre le scénario ou cliquer sur Annuler pour éviter que les descripteurs ne soient remplacés.
Lors de l'utilisation de l'environnement d'exécution Apache Axis 1.0, les émetteurs Axis régénèrent à chaque fois tous les fichiers Java serveur/client, deploy.wsdd et undeploy.wsdd. Le scénario de génération de WSDL2Java pour le service génère uniquement le fichier d'implémentation du squelette s'il n'existe pas déjà. Si cette implémentation existe déjà, elle ne sera pas remplacée.
La création de services Web à l'aide de l'environnement d'exécution Apache Axis 1.0 utilise les émetteurs Java2WSDL et WSDL2Java fournis dans Axis 1.0. Le support pour le service document/littéral et document/littéral (encapsulé) est problématique dans Axis 1.0, c'est pourquoi l'utilisateur doit utiliser RPC/codé lors de la création de services Web à l'aide de l'environnement d'exécution Apache Axis 1.0.
Lors de la définition de mappage personnalisé entre un package et un espace de noms, si un package et un espace de noms par défaut incorrects apparaissent dans la table une fois que vous avez cliqué sur le bouton Ajouter, vous devez remplacer ces valeurs par défaut et entrer votre propre mappage de package et d'espace de noms.
Lors de la génération de squelettes de services Web ou de proxy à partir d'un fichier WSDL qui utilise le même nom pour un élément <service> et pour un élément <port>, n'utilisez pas de fichiers JSP exemple en tant que client test. Les fichiers JSP exemple générés contiennent des erreurs et leur compilation n'aboutira pas. Une tentative d'exécution de fichiers JSP exemple sur le serveur génère une erreur 500 dans le navigateur indiquant que les fichiers JSP exemple ne peuvent être chargés et des exceptions sur la console du serveur indiquant que le conteneur de servlet n'a pas pu compiler les fichiers JSP exemple.
L'assistant de création des services Web peut échouer lors de la génération du fichier WSDL si le nom d'hôte "localhost" n'est pas défini sur le système. Le démarrage d'Universal Test Client peut également échouer si "localhost" n'est pas défini.
Sous Windows, l'entrée suivante doivent être définie dans le fichier [UNITE-INSTALLATION]\WINNT\system32\drivers\etc\hosts :
127.0.0.1 localhost
Sous Linux, l'entrée suivante doit être définie dans le fichier /etc/hosts :
127.0.0.1 localhost
L'environnement d'exécution IBM SOAP doit être utilisé principalement pour des raisons de compatibilité amont. Il est fortement recommandé d'utiliser l'assistant de services Web avec l'environnement d'exécution pour toutes les opérations de production. Lors de l'utilisation de l'assistant de services Web avec l'environnement d'exécution IBM SOAP, l'utilisateur peut se trouver confronté aux restrictions 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é, que vous tentez d'utiliser la classe Serializer ou Deserializer du contexte d'exécution SOAP (c'est-à-dire les classes du package org.apache.soap.encoding.soapenc) et que vous recevez l'erreur La classe Serializer/Deserializer sélectionnée ne peut pas être chargée à partir de ce projet, il est probable que le fichier soap.jar ne figure pas dans le chemin de compilation du projet Web. Pour corriger cette erreur, fermez l'assistant, utilisez la boîte de dialogue des propriétés du projet Web pour ajouter répertoire_installation_WS\wstools\eclipse\plugins\com.ibm.etools.webservice\runtime\soap.jar au chemin de compilation du projet Web, puis tentez d'utiliser à nouveau 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.
- Lorsque vous créez un service Web à partir d'une classe Java dont l'interface contient un type Java abstrait, la page Mappages Java vers XML de service Web peut définir la zone de désérialiseur du type abstrait à 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 Service Web en cours ne prennent 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 dans 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 utilisant d'autres beans Java avec des propriétés de type Vector, Hashtable ou Map, le fichier XSD est généré avec un élément complexTypes contenant les types "Vector" et"Map" de l'espace-nom "http://xml.apache.org/xml-soap". Etant donné qu'il n'existe pas actuellement de schéma pour cet espace-nom, le valideur XSD génère des erreurs et des avertissements comparables à ceux indiqués ci-après.
Ces erreurs et ces avertissements n'ont pas d'incidence sur le traitement du fichier WSDL et XSD effectué par les assistants de services Web. Les types "Map" et "Vector" sont correctement mappés à leurs homologues Java. Notez que les outils d'autres fournisseurs risquent de ne pas traiter correctement les fichiers carhttp://xml.apache.org/xml-soap n'est pas un espace-nom reconnu par les spécifications WSDL 1.1 ou SOAP 1.1. Pour améliorer l'interopérabilité, vous pouvez envisager d'adapter les classes de collection Java à des tableaux ou des beans, puis de générer 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 xsi:base64Binary à partir de l'espace nom soapenc (http://www.w3.org/2001/XMLSchema), le contexte d'exécution du service Web utilise en fin de compte le xsi:base64 à partir de l'espace nom soapenc (http://schemas.xmlsoap.org/soap/encoding/). En général, ces deux types sont interchangeables. Toutefois, il est possible que la différence entre le type figurant dans le message et celui figurant dans le schéma provoque le rejet du message lors de certaines exécutions de 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 de 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"
- Lorsque vous générez des proxy Java et des squelettes Java à partir de WSDL, vous avez désormais la possibilité de mapper les types intrinsèques XSL boolean, byte, short, int, long, float et double vers les types d'encapsuleur "java.lang" (java.lang.Integer, par exemple) plutôt que vers les primitives Java (int, par exemple). 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'encapsuleur "java.lang", ouvrez Fenêtres -> Préférences -> Services Web -> Génération du code et cochez la case "Mapper les types de données XML simples vers les classes d'encapsuleur java.lang".
- Lorsque vous définissez un mappage personnalisé entre un type Java et un type XSD dans le cadre d'un scénario ascendant, le programme indique automatiquement le nom complet du type Java dans la zone de la classe du bean. Cette zone ne peut pas être modifiée. Lorsque vous effectuez un mappage personnalisé pour un tableau Java, le nom de la classe du bean se présente sous la forme d'un tableau, par exemple, "java.lang.String[]" et elle est transmise telle quelle aux fichiers des descripteurs de déploiement ".isd" et "dds.xml". Cette forme de nom de classe n'est pas traitée correctement par l'environnement d'exécution SOAP et entraîne la consignation d'une erreur comparable à celle indiquée ci-après.
Deployment error in SOAP service http://tempuri.org/webservice.AddressBook: class name java.lang.String[] could not be resolved: java.lang.String[]
Vous ne pouvez donc pas définir de mappage personnalisé pour le sérialiseur d'un tableau Java du côté du service. Pour corriger en partie cette erreur, vous pouvez ne pas indiquer de valeur dans la zone de la classe sérialiseur pour le mappage personnalisé. Cette opération permet d'éviter de générer un nom de classe dans le descripteur de déploiement et assure le fonctionnement du service. La classe Deserializer et le mappage personnalisé du déséraliseur ne sont pas concernés par cette erreur et cette procédure.
- Remarques 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 choisi 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. Il convient cependant de ne pas déployer ce fichier dds.xml sur un autre serveur utilisant Xerces 2.x (XML4J 4.x) ou version suivante (tel que WebSphere Application Server V5). Cette opération générerait une erreur d'analyse Xerces similaire lors du chargement du fichier dds.xml sur le serveur. Il convient de générer à nouveau le fichier dds.xml en suivant le scénario du service Web et en sélectionnant le type de serveur approprié. Cette opération génère un fichier dds.xml adapté à ce type de serveur.
De plus, si vous tentez de déployer le service Web à partir de ce fichier ISD, une erreur d'analyse Xerces similaire est générée. 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"/>
- S le fait d'appeler un service Web créé à partir d'un bean Java ou EJB génère une exception SOAPException, associée à targetException, comme dans le cas suivant :
"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 proviennent de WebSphere version 4.0 et ne correspondent pas précisément 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 du serveur est ouverte dans un éditeur, l'assistant du service Web ne pourra pas démarrer le serveur car le projet Web du service Web n'a pas été ajouté à la configuration du 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 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 en tant qu'environnement d'exécution de service et Apache Axis 1.0 en tant qu'environnement d'exécution client, vous pouvez obtenir l'erreur suivante :
Fichier WSDL non trouvé
Pour éviter ce problème, créez tout d'abord le service Web sans choisir de générer un proxy. Créez ensuite un client de service Web à partir du fichier WSDL généré.
Lors de l'utilisation de l'assistant de client de service Web, si l'utilisateur clique sur le bouton Terminer dans la page Configuration d'environnement client, il obtient l'erreur :
"null" n'a pas de solution
La solution consiste à cliquer sur le bouton Suivant de cette page et de la page suivante puis de sélectionner Terminer.
Dans l'aide-mémoire de création, de test et de validation d'un service Web compatible WS-I et dans l'aide-mémoire de création d'un service Web à partir d'un fichier WSDL, si vous utilisez le fichier HelloService.wsdl à partir du répertoire install_wsad/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_5.1/examples, modifiez l'emplacement de port du service en fonction de l'environnement d'exécution de la manière suivante :
Pour IBM Soap :
location="http://hotelocal:9080/HelloWorldSample/servlet/rpcrouter"
Pour l'environnement d'exécution Apache Axis ou WebSphere 5.0.2 :
location="http://hotelocal:9080/HelloWorldSample/services/Hello_Port"
Si vous importez votre propre fichier wsdl, assurez-vous que l'emplacement est défini correctement en fonction de l'environnement d'exécution sélectionné.
Retour au fichier Readme principal
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.