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.