As práticas a seguir mostram como projetar serviços do WebSphere Studio Application Developer
Integration Edition para assegurar que eles sejam migrados com êxito
para o novo modelo de programação:
- Tente utilizar a atividade de Designação onde for possível
(em oposição ao serviço de transformador que é requerido apenas quando é necessária
uma transformação avançada). Você deve utilizar essa prática porque o componente intermediário deve ser construído para que o módulo SCA chame um serviço de transformador. Adicionalmente, não há nenhum suporte de ferramenta especial no WebSphere Integration
Developer para os serviços de transformador criados na 5.1 (você deve utilizar o editor WSDL ou XML para modificar o XSLT incorporado no arquivo WSDL se precisar alterar o comportamento do serviço de transformador).
- Especifique uma parte por mensagem WSDL utilizando a especificação WS-I (Web Services Interoperability)
e o estilo preferido da 6.0.
- Utilize o estilo WSDL doc-literal pois este é o estilo preferido na 6.0.
- Certifique-se de que
todos os tipos complexos tenham recebido um nome e que cada tipo complexo possa ser identificado exclusivamente
por seu espaço de nomes e nome de destino. A seguir é mostrada a maneira recomendada para definir tipos complexos e elementos desse tipo (definição de tipo complexo
seguida por uma definição de elemento que a 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>
O exemplo a seguir é um tipo complexo anônimo que deve ser evitado, pois pode causar problemas quando um SDO for serializado para
XML (elemento contendo uma definição de tipo complexo anônima):<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>
- Se estiver publicando um serviço para consumidores externos, gere o código de implementação do serviço
utilizando os IBM
Web Services (em oposição ao Apache SOAP/HTTP) porque os IBM Web Services são diretamente suportados
na 6.0 e os Apache Web Services não são.
- Existem duas maneiras de organizar arquivos WSDL e XSD na 5.1 para minimizar
a quantidade de reorganização que deve ser feita durante a migração. Na 6.0, os artefatos
compartilhados, como arquivos WSDL e XSD, devem ser localizados em projetos do BI
(módulos e bibliotecas do Business Integration) para serem referidos
por um serviço do BI:
- Mantenha todos os arquivos WSDL compartilhados por mais de um projeto de serviço em um projeto Java
ao qual os projetos de serviço podem fazer referência. Durante a migração para a 6.0, você criará uma nova Biblioteca do Business Integration com o mesmo nome do projeto Java compartilhado pela 5.1.
Copie todos os artefatos do projeto Java 5.1 compartilhado para a biblioteca para que o assistente
de migração possa resolver os artefatos quando ele migrar os projetos de serviços
que utilizam esses artefatos
- Mantenha uma cópia local de todos os arquivos WSDL/XSD aos quais um projeto de serviço se refere
no próprio projeto de serviço. Os projetos de serviço do WebSphere Studio Application Developer
Integration Edition serão migrados para um Módulo do Business Integration
no WebSphere Integration
Developer e um módulo não pode ter dependências de outros módulos (um projeto de serviço
com dependências de outro projeto de serviço em relação ao compartilhamento
de arquivos WSDL ou XSD não será migrado corretamente).
- Evite utilizar a API do Sistema de Mensagens Genérico (MDBs Genéricos) do Business Process Choreographer,
pois ela não será fornecida na 6.0. Uma ligação posterior de oferta da interface MDB
não estará disponível na 6.0.
- Utilize a API de EJB Genérico do Business Process Choreographer em oposição à chamada de beans de sessão gerados
específicos de uma determinada versão de um processo. Esses beans de sessão não serão gerados na V6.0.0.0.
- Se você tiver um processo de negócios com várias respostas para a mesma operação, certifique-se de que se qualquer uma delas tiver configurações do cliente e que todas as respostas para essa operação tiverem as mesmas configurações do cliente que a 6.0, apenas um conjunto de configurações do cliente será suportado por resposta de operação.
- Projete snippets Java de BPEL de acordo com as seguintes instruções:
- Evite enviar parâmetros WSIFMessage para quaisquer classes Java customizadas
- tente não depender do formato de dados de WSIFMessage, se possível.
- Evite utilizar as APIs de metadados do WSIF, se possível.
- Evite declarar variáveis locais em snippets Java do BPEL que têm o mesmo nome das variáveis BPEL. Na 6.0, as variáveis BPEL estão diretamente acessíveis nos snippets, portanto, as variáveis locais com o mesmo nome poderão criar um conflito.
- Evite criar serviços EJB ou Java de cima para baixo onde possível, porque a estrutura
Java/EJB gerada a partir de PortTypes/Mensagens WSDL
será dependente de classes WSIF (por exemplo, WSIFFormatPartImpl). Em vez disso, crie primeiro as interfaces Java/EJB e gere um serviço em torno da classe/EJB Java (abordagem de baixo para cima).
- Evite criar ou utilizar interfaces WSDL que façam referência ao tipo soapenc:Array, porque esse tipo de interface não é suportado de forma nativa no modelo de programação SCA.
- Evite criar tipos de mensagens cujo elemento de alto nível seja um tipo de matriz (atributo maxOccurs é maior que um), porque esse tipo de interface não é suportado de forma nativa no modelo de programação SCA.
- Defina suas interfaces WSDL precisamente - evite, onde possível, complexTypes de XSD que tenham referências ao tipo xsd:anyType.
- Para quaisquer WSDL e XSDs gerados a partir de um EJB ou Java bean, certifique-se
de que o espaço de nomes de destino seja exclusivo (o nome da classe e o nome do pacote Java são representados pelo espaço de nomes
de destino) para evitar conflitos durante a migração para o WebSphere Process Server V6. No WebSphere Process
Server V6, duas diferentes definições de WSDL/XSD que possuem o mesmo nome
e espaço de nomes de destino não são permitidas. Esta situação geralmente ocorre quando o assistente de Serviço da Web
ou o comando Java2WSDL é utilizado sem especificar o espaço de nomes de destino explicitamente
(o espaço de nomes de destino será exclusivo para o nome do pacote
do EJB ou Java bean, mas não para a própria classe, portanto,
ocorrerão problemas quando um serviço da Web for gerado para dois ou mais EJB
ou Java beans
no mesmo pacote). A solução é especificar um mapeamento de pacote customizado para espaço de nomes
no assistente de Serviço da Web ou utilizar a opção da linha de comandos -namespace Java2WSDL
para assegurar que o espaço de nomes dos arquivos gerados seja exclusivo
para a classe especificada.
- Utilize espaços de nomes exclusivos para cada arquivo WSDL sempre que possível. Existem limitações
na importação de dois arquivos WSDL diferentes com o mesmo espaço de nomes, de acordo
com a especificação WSDL 1.1 e, no WebSphere Integration Developer 6.0,
estas limitações são estritamente aplicadas.