Méthodes recommandées pour le processus de migration de l'artefact source

Il existe un certain nombre de méthodes recommandées pour le processus de migration de l'artefact source de WebSphere Studio Application Developer Integration Edition.

Les pratiques suivantes montrent comment concevoir des services de WebSphere Studio Application Developer Integration Edition pour assurer leur migration vers le nouveau modèle de programmation :
  • Essayez d'utiliser l'activité Affecter autant que possible (par opposition au service de conversion qui est nécessaire uniquement lorsqu'une transformation avancée est requise). Vous devez utiliser cette méthode car un composant intermédiaire doit être créé pour que le module SCA appelle un service de transformateur. De plus, il n'existe pas de prise en charge de l'outil spécifique dans WebSphere Integration Developer pour les services de transformateur créés avec la version 5.1 (vous devez utiliser l'éditeur WSDL ou XML pour modifier le XSLT intégré dans le fichier WSDL si vous devez changer le comportement du service de transformateur).
  • Spécifiez une partie par message WSDL et par spécification d'interopérabilité de services Web (WS-I), ainsi que le style préféré de la version 6.0.
  • Utilisez le style doc-literal WSDL car il s'agit du style préféré dans la version 6.0.
  • Vérifiez que chaque type complexe dispose d'un nom et qu'il peut être identifié de façon unique par son nom et son espace de nom cible. La méthode recommandée pour définir les types complexes et des éléments correspondants est la suivante (définition du type complexe suivie d'une définition d'élément utilisant ce type) :
    <schema
    attributeFormDefault="qualified"
        elementFormDefault="unqualified"
        targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com" 
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
    
    <complexType name="Duration">
    	 <all>
    				<element name="hours" type="int"/>
    				<element name="minutes" type="int"/>
    				<element name="days" type="int"/> 
    	 </all>
     		</complexType>
     	<element name="DurationElement" type="tns:Duration"/>
    </schema>
    L'exemple suivant montre un type complexe anonyme à éviter, car il peut provoquer des incidents lorsqu'un SDO est sérialisé en XML (élément contenant une définition de type complexe anonyme) :
     <schema
    attributeFormDefault="qualified"
        elementFormDefault="unqualified"
        targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com" 
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
    <element name="DurationElement">
     		<complexType>
    	  <all>
    				<element name="hours" type="int"/>
    				<element name="minutes" type="int"/>
    				<element name="days" type="int"/>
    
       			</all>
      		</complexType>
     	</element>
    </schema>
  • Si vous publiez un service pour des clients externes, générez un code de déploiement de service à l'aide des services Web IBM (par opposition à Apache SOAP/HTTP) car les services Web IBM sont directement pris en charge dans V6.0, contrairement aux services Web Apache.
  • Il existe deux façons d'organiser des fichiers WSDL et XSD dans la version 5.1 pour réduire la réorganisation que vous devez effectuer pendant la migration. Dans la version 6.0, les artefacts partagés comme les fichiers WSDL et XSD doivent être situés dans les projets BI (modules Business Integration et Bibliothèques) afin d'être référencés par un service BI :
    • Conservez tous les fichiers WSDL partagés par plusieurs projets de service dans un projet Java que les projets de service peuvent référencer. Lors de la migration vers la version 6.0, vous créerez une bibliothèque Business Integration avec le même nom que le projet Java 5.1 partagé. Copiez tous les artefacts du projet Java 5.1 partagé vers la bibliothèque de sorte que l'Assistant de migration puisse résoudre les artefacts lorsqu'il migre les projets de service utilisant ces artefacts.
    • Conservez une copie locale de tous les fichiers WSDL/XSD qu'un projet de service référence dans le projet de service lui-même. Les projets de service WebSphere Studio Application Developer Integration Edition seront migrés vers un module Business Integration dans WebSphere Integration Developer. Un module ne peut pas avoir de dépendance sur d'autres modules (un projet de service ayant des dépendances sur un autre projet de service pour le partage des fichiers WSDL ou XSD ne migrera pas correctement).
  • Evitez d'utiliser l'API de messagerie générique (Generic MDBs) de Business Process Choreographer (BPC) car elle n'est pas fournie dans la version 6.0. Une interface MDB offrant une connexion tardive n'est pas disponible dans la version 6.0.
  • Utilisez l'API EJB générique de Business Process Choreographer par opposition à l'appel des beans de session générés spécifiques à une version particulière d'un processus. Ces beans de session ne seront pas générés dans la version 6.0.0.0.
  • Si vous possédez un processus métier avec plusieurs réponses pour la même opération, assurez-vous que si l'une d'elles a des paramètres client, toutes les réponses pour cette opération ont les mêmes paramètres client, étant donné que dans la version 6.0, un seul ensemble de paramètres client par réponse d'opération est pris en charge.
  • Concevez les fragments Java BPEL selon les directives suivantes :
    • Evitez l'envoi de paramètres WSIFMessage à toute classe Java personnalisée. Essayez de ne pas dépendre du format de données WSIFMessage dès que cela est possible.
    • Evitez, si possible, l'utilisation d'API métadonnées WSIF.
  • Evitez de déclarer des variables locales dans des fragments Java BPEL portant le même nom que les variables BPEL. Etant donné que dans la version 6.0, les variables BPEL sont directement accessibles dans les fragments, des variables locales portant le même nom peuvent entraîner des conflits.
  • Dans la mesure du possible, évitez de créer des services EJB ou Java descendants car le squelette Java/EJB généré à partir des messages et des types de port WSDL dépendra des classes WSIF (par exemple : WSIFFormatPartImpl). Créez d'abord les interfaces Java/EJB et créez un service autour de la classe Java ou de l'EJB (approche ascendante).
  • Evitez de créer ou d'utiliser des interfaces WSDL qui référencent le type soapenc:Array, dans la mesure où ce type d'interface n'est pas pris en charge en mode natif dans le modèle de programmation SCA.
  • Evitez de créer des types de message dont l'élément de niveau supérieur est un type de tableau (l'attribut maxOccurs est supérieur à un), dans la mesure où ce type d'interface n'est pas pris en charge en mode natif dans le modèle de programmation SCA.
  • Définissez les interfaces WSDL de manière précise (dans la mesure du possible, évitez les types complexes XSD qui référencent le type xsd:anyType).
  • Pour tout WSDL et XSD généré à partir d'un EJB ou d'un bean Java, vérifiez que l'espace de nom cible est unique (le nom du package et celui de la classe Java sont représentés par l'espace de nom cible) afin d'éviter des conflits lors de la migration vers WebSphere Process Server V6. WebSphere Process Server V6 ne permet pas à deux définitions WSDL/XSD différentes d'avoir le même nom et le même espace de nom cible. Cette situation se produit fréquemment si l'Assistant de service Web ou la commande Java2WSDL est utilisé sans indication explicite de l'espace de nom cible. L'espace de nom cible est unique pour le nom de package de l'EJB ou du bean Java, mais pas pour la classe elle-même. Des incidents peuvent donc survenir lorsqu'un service Web est généré pour plusieurs EJB ou beans Java d'un même package. La solution consiste à définir un package personnalisé pour le mappage de l'espace de nom dans l'Assistant de service Web. Vous pouvez aussi utiliser l'option de ligne de commande Java2WSDL -namespace pour vous assurer que l'espace de nom des fichiers générés correspond uniquement à la classe concernée.
  • Si possible, utilisez un espace de nom unique pour chaque fichier WSDL. Les restrictions de la spécification WSDL 1.1 concernant l'importation de deux fichiers WSDL différents ayant le même espace de nom sont mises en oeuvre de façon très stricte dans WebSphere Integration Developer 6.0.
Tâches associées
Vérification de la migration de l'artefact source
Traitement des problèmes de migration des artefacts source
Référence associée
Restrictions du processus de migration (pour la migration des artefacts source)

Commentaires
(C) Copyright IBM Corporation 2005. Tous droits réservés.