La première option de migration pour la connexion
SOAP/JMS de WebSphere
Studio Application Developer Integration Edition consiste à
rendre le service accessible à un client de services Web.
L'exportation avec liaison de services Web permet à un client
de services Web externe d'accéder à un composant SCA. Pour créer une exportation avec liaison de services Web, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface de service
pour laquelle une connexion (SOAP/JMS) de service Web
IBM
a été générée dans
WebSphere
Studio Application Developer Integration Edition :
- Cliquez avec le bouton droit de la souris sur le composant SCA dans
l'éditeur d'assemblage.
- Sélectionnez Exportation….
- Sélectionnez Liaison de service Web.
- Si le composant est associé à plusieurs interfaces, sélectionnez
celle(s) que vous souhaitez exporter avec ce type de connexion.
- Sélectionnez le transport SOAP/JMS.
- Une fois l'exportation de services Web créée,
sélectionnez-la dans l'éditeur d'assemblage et dans la vue
Propriétés, sélectionnez le volet Description.
Le nom de l'exportation et sa description sont répertoriés et peuvent
être modifiés si nécessaire.
- Enregistrez le diagramme de l'assemblage.
- Sélectionnez le panneau du contenu Connexion. Observez qu'un élément
connexion et service de type IBM Web Service WSDL a été directement
généré dans le dossier projet du module. Il est nommé composant-exporté
Export Nom Typeport WSDL Jms_Service.wsdl. Si vous examinez ce
fichier, vous trouverez que la connexion Document/Literal wrapped est
utilisée par défaut, puisqu'il s'agit du style préféré dans la
version 6.0. Il s'agit du WSDL que les clients des services Web IBM
utilisent pour appeler le service.
- Suivez les étapes suivantes pour générer une nouvelle liaison de services Web et un service si vous voulez préserver le code client :
- Copiez le fichier WSDL 5.1 dans le projet EJB 5.1 généré dans
ejbModule/META-INF/wsdl/nom_processus
métier/type_port_interface_processus métierJMS.wsdl vers
le projet de module Business Integration.
- Après avoir copié le fichier et recompilé le module, vous verrez
peut-être des messages d'erreur car les types de schéma XML, les
messages WSDL et les types de port WSDL utilisés par le service Web
sont dupliqués dans le fichier WSDL du service Web
IBM
dans la version 5.1. Pour régler ce problème, supprimez les
définitions en double du fichier WSDL du service ou de la liaison de services Web IBM et ajoutez à la place une importation WSDL
pour l'interface WSDL réelle. Remarque : Notez que quand
WebSphere
Studio Application Developer Integration Edition a généré le code de
déploiement du service Web
IBM,
les définitions de schéma ont aussi été modifiées dans certains cas. Cela peut causer des incohérences pour les clients existants qui
utilisent le service Web WSDL
IBM. Par exemple, l'attribut de schéma "elementFormDefault" a pris la
valeur "qualified" dans le schéma en ligne généré dans le fichier
WSDL de service Web
IBM
si la définition de schéma d'origine n'était pas qualifiée. L'erreur
suivante sera générée au cours de l'exécution : WSWS3047E: Erreur :
Impossible de désérialiser l'élément.
- Avec le bouton droit, cliquez sur le fichier WSDL que vous venez de
copier dans le module Business Integration et sélectionnez
Ouvrir avec puis Editeur
WSDL.
- Accédez à l'onglet Source. Supprimez tous les messages et types de port
définis dans ce fichier.
- Vous voyez maintenant l'erreur "Le type
de port '<TypePort' indiqué pour la connexion
'<Connexion>' n'est pas défini.
Pour régler ce problème, dans l'éditeur WSDL, dans l'onglet
Graphique, cliquez avec le bouton droit dans la section Imports et
sélectionnez Ajouter une importation.
- Dans la vue Propriétés de l'onglet Propriétés générales, cliquez sur
le bouton … situé à droite de la zone
Emplacement. Passez dans l'interface WSDL où résident le message
WSDL et les définitions des types de port puis cliquez sur
OK pour importer l'interface WSDL dans le
fichier WSDL de la connexion/du service.
- Enregistrez le fichier WSDL.
- Réactualisez/recompilez le projet. Passez dans Business Integration. Ouvrez le diagramme de l'assemblage du module dans Assembly Editor.
- Dans la vue de l'explorateur de projet, développez le module que vous
migrez puis développez la catégorie logique Ports de
service Web. Vous devez voir apparaître le port qui
existe dans le fichier WSDL de la connexion/du service. Faites-le
glisser dans l'éditeur d'assemblage.
- Choisissez de créer une exportation avec
liaison de services Web et sélectionnez le nom de port
approprié. Ceci va créer une exportation utilisant l'ancienne
liaison/service pour que les clients du service Web actuels ne
demandent pas de modification. Si vous sélectionnez l'exportation
que vous venez de créer dans Assembly Editor et que vous passez dans
la vue Propriétés, vous devez voir dans l'onglet Connexion que les
noms de service et le port 5.1 ont été entrés pour vous.
- Enregistrez toutes les modifications.
- Juste avant de déployer l'application, vous pouvez changer la
configuration du projet Web généré pour refléter l'adresse du service
version 5.1 (vous devez faire ces modifications chaque fois que vous
modifiez le module SCA qui cause la régénération de ce fichier). Si vous regardez la définition Service du fichier WSDL du
service Web
IBM
que vous réutilisez depuis la version 5.1, vous verrez l'adresse
de service codée dans le client 5.1
:<wsdlsoap:address
location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
- Pour que les artefacts du projet Web 6.0 généré utilisent cette
ancienne adresse de service, vous devez modifier le descripteur de
déploiement du projet Web généré. Ouvrez le descripteur de
déploiement dans WebSphere Integration
Developer et, dans l'onglet Servlets, ajoutez un autre mappage d'URL
proche du mappage d'URL existant pour cette exportation, avec le même
nom de servlet mais avec un autre modèle d'URL.
- Notez aussi que si vous devez modifier la racine
de contexte de ce projet Web pour qu'elle reflète la racine
de contexte de l'adresse de service d'origine (dans cet exemple, la
racine de contexte est "MyServiceWeb"), vous pouvez alors ouvrir
le descripteur de déploiement de l'application J2EE Enterprise
où réside ce projet Web et modifier la racine de contexte de ce
module Web pour refléter celle de l'ancienne adresse de service. Vous verrez peut-être
l'erreur suivante que vous pouvez ignorer : CHKJ3017E: Le
projet Web <nom_projet web> est mappé à une racine de contexte non
valide : <nouvelle racine de contexte> dans le projet EAR :
<nom_application>.