Las recomendaciones siguientes muestran cómo diseñar los servicios de
WebSphere
Studio Application Developer Integration Edition para asegurarse de que se migrarán correctamente al nuevo modelo de
programación:
- Intente utilizar la actividad Asignar en todas las
operaciones posibles (en lugar del servicio de transformador, que sólo es necesario cuando
se precisa una transformación avanzada). Debe utilizar este procedimiento porque es necesario
construir componentes intermedios para que un módulo SCA invoque un servicio de transformador. Además, no hay soporte de herramientas especiales en
WebSphere
Integration Developer para los servicios de transformador creados en 5.1 (debe utilizar el editor
WSDL o XML para modificar el XSLT incorporado en el archivo WSDL si necesita cambiar el
comportamiento del servicio de transformador.)
- Especifique un componente por mensaje WSDL igual que por la especificación de interoperatividad
de servicios Web (WS-I) y el estilo preferido en 6.0.
- Utilice el estilo de literal de documentos WSDL ya que es el estilo preferido en 6.0.
- Asegúrese de dar un nombre a todos los tipos complejos y de que cada tipo complejo
pueda identificarse de forma exclusiva por su espacio de nombres destino y su nombre. A
continuación se muestra el modo recomendado de definir tipos complejos y elementos de ese
tipo (definición del tipo complejo seguida de una definición de elemento que la utiliza):
<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>
El ejemplo siguiente representa un tipo complejo anónimo que debe
evitarse, ya que puede provocar problemas cuando se serializa un SDO en XML (elemento que
contiene una definición de tipo complejo anónimo):<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 publica un servicio
para consumidores externos, genere el código de despliegue del servicio utilizando los servicios Web de
IBM
(en lugar de emplear Apache SOAP/HTTP) ya que los servicios Web de
IBM
reciben soporte directo en 6.0 y los servicios Web de Apache no.
- Hay dos modos de organizar los archivos WSDL y XSD en 5.1 para minimizar la cantidad de
reorganización necesaria durante la migración. En 6.0, los artefactos compartidos como, por
ejemplo, archivos WSDL y XSD deben localizarse en proyectos de integración empresarial
(módulos y bibliotecas de integración empresarial) para que un servicio de
integración empresarial les haga referencia:
- Guarde todos los archivos WSDL compartidos por varios proyectos de servicio en un proyecto
Java
al que los proyectos de servicio puedan hacer referencia. Durante la migración a 6.0 creará una biblioteca de
Integración empresarial nueva con el mismo nombre que el proyecto
Java
compartido de 5.1.
Copie todos los artefactos del proyecto Java compartido 5.1 en la biblioteca para que
el asistente para la migración pueda resolverlos cuando migre los proyectos de servicio
que utilizan esos artefactos
- Guarde una copia local de todos los archivos WSDL/XSD a los que hace referencia un
proyecto de servicio en el propio proyecto de servicio. Los proyectos de servicio de
WebSphere
Studio Application Developer Integration Edition se migrarán a un módulo de integración empresarial en
WebSphere
Integration Developer y un módulo no puede tener dependencias sobre otros módulos (un proyecto de servicio con
dependencias sobre otro proyecto de servicio para compartir archivos WSDL o XSD no se migrará correctamente).
- Evite utilizar la API de mensajería genérica (Generic MDB) del coreógrafo de procesos de
negocio (BPC) ya que no se proporcionará en 6.0. En 6.0 no habrá disponible una interfaz
MDB de enlace tardío.
- Utilice la API de EJB genérica Business Process Choreographer en lugar de invocar los
beans de sesión
generados que son específicos de una versión determinada de un proceso. Estos beans de sesión no se generarán
en V6.0.0.0.
- Si tiene un proceso de negocio con varias respuestas para la misma operación, asegúrese de que
si cualquiera de ellas tiene valores de cliente, todas las respuestas para esa operación tengan los
mismos valores de cliente ya que en 6.0 solo se da soporte un conjunto de valores de cliente por
respuesta de operación.
- Diseñe fragmentos de código Java BPEL según las directrices siguientes:
- Evite enviar parámetros WSIFMessage a clases Java personalizadas;
intente no depender del formato de datos WSIFMessage en la medida de lo posible.
- Evite utilizar las API de metadatos WSIF si es posible.
- Evite declarar variables locales en fragmentos de código
Java
de BPEL que tengan el mismo nombre que las variables BPEL. En 6.0 las variables BPEL son directamente
accesibles en los fragmentos de código por lo que las variables locales con el mismo nombre pueden
crear un conflicto.
- En lo posible, evite crear servicios
Java
o EJB de arriba abajo ya que el esqueleto Java/EJB que se genera a partir de los mensajes/tipos de puerto de WSDL
dependerá de las clases WSIF (por ejemplo: WSIFFormatPartImpl). En su lugar, cree primero las interfaces Java/EJB y
genere un servicio alrededor de la clase
Java
o el EJB (procedimiento de abajo arriba.)
- Evite crear o utilizar interfaces WSDL que hagan referencia al tipo soapenc:Array porque este
tipo de interfaz no está soportado de forma nativa en el modelo de programación SCA
- Evite crear tipos de mensajes cuyo elemento de alto nivel sea un tipo de matriz (el atributo
maxOccurs es mayor que uno) porque este tipo de interfaz no está soportado de forma nativa en el
modelos de programación SCA.
- Defina las interfaces WSDL de forma precisa; en lo posible, evite complexTypes de XSD que
tengan referencias al tipo xsd:anyType.
- Para cualquier WSDL y
los XSD que genere a partir de un bean EJB o
Java,
asegúrese de que el espacio de nombres destino sea exclusivo (el nombre de clase y de paquete
Java
están representados por el espacio de nombres destino) para evitar colisiones al migrar a
WebSphere
Process Server V6. En WebSphere Process
Server V6, no se permiten dos definiciones WSDL/XSD diferentes que tengan el mismo nombre
y el mismo espacio de nombres destino. Esta situación se produce con frecuencia cuando se utilizan el asistente
Servicio Web o el mandato Java2WSDL sin especificar explícitamente el espacio de nombres destino (éste será exclusivo
con respecto al nombre de paquete del bean EJB o
Java,
pero no con respecto a la propia clase, por lo que se producirán problemas cuando se genere un servicio Web para dos o
más beans EJB o
Java
en el mismo paquete). La solución consiste en especificar un paquete personalizado para
la correlación de espacio de nombres en el asistente Servicio Web o utilizar la opción de
línea de mandatos -namespace de Java2WSDL
para asegurarse de que el espacio de nombres de los archivos generados sea exclusivo para
la clase dada.
- Utilice espacios de nombres exclusivos para cada archivo WSDL siempre que sea
posible. Existen limitaciones con respecto a la importación de dos archivos WSDL diferentes con el mismo espacio de
nombres de acuerdo con la especificación WSDL 1.1, y en
WebSphere
Integration Developer 6.0 estas limitaciones deben cumplirse estrictamente.