IBM WebSphere WebSphere Integration Developer
Versão 6.1
Migration Guide
Version 6 Release 1
Comunicado
Antes de utilizar essas informações e o produto suportado por
elas, leia as informações em Avisos.
Esta edição aplica-se à versão 6, release 1, do WebSphere Integration Developer.
Copyright International Business Machines Corporation 2005, 2007. Todos os direitos reservados.
Capítulo 1. Migrando para o WebSphere Integration Developer
O WebSphere Integration
Developer Versão 6.1 fornece as ferramentas necessárias para migrar seu ambiente existente.
Nota: Os projetos
WebSphere
Integration Developer 6.0.2 e 6.1 não podem ser utilizados no WebSphere Integration Developer 6.0.1.
Uma vez feito o upgrade do
WebSphere
Integration Developer 6.0.2 ou 6.1, você não retornar os projetos
para o WebSphere Integration Developer 6.0.1.x.
O suporte também não está disponível para um usuário de 6.0.2 ou 6.1
que marca seu código em um repositório ou exporta projetos e então
compartilha-os com um usuário do WebSphere Integration
Developer 6.0.1.
Os tópicos a seguir descrevem conceitos, informações de referência e instruções passo a passo
de migração para o WebSphere Integration Developer:
Capítulo 2. Migrando de versões anteriores do WebSphere Integration Developer
A migração de versões anteriores do
WebSphere
Integration Developer para WebSphere Integration
Developer 6.1 é suportada. Isso é referido como
migração de versão-para-versão.
A migração do
WebSphere
Integration Developer 6.1 preserva a estrutura básica de seu
aplicativo existente exigindo uma reconfiguração mínima.
Observe que o processo de versão-para-versão não tem um
assistente de migração associado a ele.
Os tópicos a seguir fornecem melhor orientação sobre o
processo de migração de versão-para-versão do
WebSphere Integration
Developer:
Considerações do Processo de Migração de Versão para Versão
Ao migrar de uma versão anterior do
WebSphere
Integration Developer para V6.1, grande parte da migração é feita por você. Entretanto,
há algumas considerações que requerem uma configuração manual
adicional.
As considerações a seguir destinam-se ajudar no processo de migração
de versão para versão:
- Adaptadores
- Aplicativos que utilizam um nível anterior de adaptador podem
ter uma migração mais rápida para o nível atual com um utilitário.
Para obter mais informações, consulte o tópico "Migrando para
aplicativos que utilizam níveis de adaptadores anterior" na seção
de link relacionado abaixo.
- Eventos CEI
- Os modelos de monitor do
WebSphere Integration
Developer 6.0.2 não podem ser criados recentemente mas podem
ser utilizados no WebSphere Integration
Developer 6.1 se eles já tiverem sido criados.
- Editor de Definição de Evento
- Esse editor é reprovado no WebSphere Integration Developer 6.1.
- XSD Federation
- O XSD Federation (ou seja, geração de inclusões xsd) foi removido
no WebSphere Integration
Developer 6.1. Portanto, apenas PIs antigos precisam ter
inclusões de xsd incluídos no PI. Isso acontece automaticamente
para PIs exportados no WebSphere Integration
Developer 6.0.2.x. Entretanto, para exportar PIs do 6.0.1.2, você
precisa explicitamente ativar a caixa de opção
Incluir arquivos derivados quando executar a
exportação.
- Primitivas do XSL Transformation
- No WebSphere Integration
Developer 6.1, a primitiva XSL Transformation tem um novo
editor de mapeamento XML.
Os mapas XML que foram construídos em uma versão anterior
precisam ser migrados para o novo formato para poderem ser
editados.
Para obter mais informações, consulte o tópico "Migrando uma
primitiva de XSL Transformation" na seção de link relacionado
abaixo.
Níveis de Versão de Desenvolvimento e Implementação
Sua decisão sobre qual nível de versão precisará em seu
ambiente dependerá dos níveis de versão com os quais seus
aplicativos foram desenvolvidos.
O WebSphere Process
Server 6.1 e o WebSphere Integration
Developer 6.1 são compatíveis com releases anteriores da seguinte maneira:
Nota: Para
sistemas i5/OS,
não há versões anteriores instaladas.
- A implementação do WebSphere Integration Developer 6.0.x.x (em que
6.0.x.x refere-se à 6.0.1.x ou à 6.0.2.x) para o WebSphere Process
Server 6.1 é suportada.
- Os aplicativos autorizados e gerados utilizando o WebSphere Integration Developer 6.0.x.x podem ser publicados nos servidores do WebSphere Process
Server 6.1.
- Os aplicativos autorizados, gerados e exportados do WebSphere Integration
Developer 6.0.x.x podem ser instalados nos servidores do WebSphere Process Server 6.1.
- A execução de artefatos do WebSphere Process Server 6.1 no WebSphere Process Server 6.0.x.xnão é suportada.
- Os aplicativos autorizados pelo WebSphere Integration Developer 6.1
não podem ser publicados nem instalados nos servidores do WebSphere Process Server 6.0.x.x (qualquer release anterior). Esses conteúdos não executarão corretamente no WebSphere Process
Server 6.0.x.x, e as alterações na geração de códigos farão com que os aplicativos não executem corretamente no WebSphere Process Server 6.0.x.x.
- Os aplicativos autorizados pelo WebSphere Integration Developer 6.0.x.x e gerados no WebSphere Integration
Developer 6.1 não podem ser publicados nem instalados nos servidores do WebSphere Process Server 6.0.x.x.
As alterações na geração de códigos farão com que os aplicativos não executem corretamente no WebSphere Process
Server 6.0.x.x.
- Os aplicativos gerados utilizando o serviceDeploy do servidor do WebSphere Process
Server 6.1 não podem ser instalados em um servidor do WebSphere Process Server 6.0.x.x.
As alterações na geração de códigos farão com que os aplicativos não executem corretamente no WebSphere Process
Server 6.0.x.x.
Capítulo 3. Migrando para o WebSphere Process Server do WebSphere InterChange
Server
A migração do WebSphere InterChange Server para o WebSphere Process Server é suportada através das funções a seguir no WebSphere Integration Developer.
Nota: Consulte as notas sobre o release para obter informações sobre limitações relacionadas à migração neste release do WebSphere Process Server.
- Migração automática de artefatos de origem por meio de ferramentas de migração que podem
ser chamadas a partir dos seguintes itens:
- O menu Arquivo -> Importar -> Business Integration do WebSphere Integration Developer
- A página de Boas-vindas do WebSphere Integration Developer
- O utilitário de linha de comandos reposMigrate
- Suporte nativo no tempo de execução de muitas APIs do WebSphere InterChange Server
- Suporte para a tecnologia atual do WebSphere Business Integration Adapter para que os adaptadores existentes sejam compatíveis com o WebSphere Process Server
Embora a migração de artefatos de origem seja suportada, são recomendados análise e teste
extensivos para determinar se os aplicativos resultantes funcionarão
conforme o esperado no WebSphere Process Server, ou se precisarão de
novo design pós-migração. Esta recomendação é baseada nas seguintes limitações
em paridade funcional entre o WebSphere InterChange Server e esta
versão do WebSphere Process Server. Não existe suporte nesta versão do WebSphere Process Server que seja equivalente
a estas funções do WebSphere InterChange
Server:
- Suporte a Grupo
- Implementação Rápida/Atualização Dinâmica
- Planejador - Pausar Operação
- Segurança - Auditoria
- RBAC de Granularidade Fina
- Os Descritores de Segurança não são migrados
Caminhos de Migração Suportados para o WebSphere InterChange Server
As ferramentas de migração
do WebSphere
Process Server suportam migração do
WebSphere
InterChange Server versões 4.2.2 ou posteriores.
Toda liberação do WebSphere InterChange
Server anterior à Versão 4.2.2 primeiro precisará migrar para a
versão 4.2.2 ou 4.3 antes de migrar para o
WebSphere Process Server.
Antes de migrar para o WebSphere Process Server do WebSphere InterChange
Server, primeiro, é necessário assegurar que você tenha preparado corretamente seu ambiente. O WebSphere Process
Server fornece as ferramentas necessárias para migrar do WebSphere InterChange Server.
Estas ferramentas de migração podem ser chamadas de:
- O menu Arquivo -> Importar -> Business Integration do WebSphere Integration Developer
- A página de Boas-vindas do WebSphere Integration Developer
A entrada para as ferramentas de migração é um arquivo jar de repositório exportado do WebSphere InterChange Server. Portanto, antes de acessar as ferramentas de migração por meio de qualquer uma destas
opções, primeiro é necessário:
- assegurar que você esteja executando uma versão do
WebSphere
InterChange Server que pode ser migrada para WebSphere Process Server. Consulte o tópico "Caminhos de Migração
Suportados para o WebSphere InterChange Server".
- exportar os artefatos de origem do WebSphere InterChange Server para um
arquivo jar do repositório utilizando o comando repos_copy do WebSphere InterChange Server
conforme descrito na documentação do WebSphere InterChange Server. O
assistente requer como entrada um arquivo JAR do repositório
WebSphere InterChange Server.
Esse arquivo JAR deve ser auto-contido com respeito a aplicativos
que estão sendo migrados.
Ou seja, todos os artefatos referidos por algum dos artefatos no
arquivo JAR também precisam estar contido no arquivo JAR.
Para assegurar que o arquivo JAR do repositório que será gerado é
auto-contido, execute o comando repos_copy com a opção
-vr antes de exportar o repositório do servidor (isso
valida o repositório).
Se o repositório for válido, então o repos_copy grava a
seguinte saída para o console: Validação bem-sucedida. Todas
as Dependências Resolvidas. Se o repositório não for
válido, então o comando repos_copy imprime uma lista de
dependências que precisam ser resolvidas.
Resolva as dependências antes de exportar o repositório.
Exporte os artefatos de repositório e crie o arquivo JAR do
repositório, utilizando o comando WebSphere InterChange Server repos_copy
com a opção -o (Consulte a documentação
WebSphere
InterChange Server 4.3 para obter mais detalhes, inclusive
como exportar componentes individuais.
Considerações para o Processo de Migração do WebSphere InterChange Server
As considerações a seguir destinam-se a ajudar no
desenvolvimento de artefatos de integração do WebSphere InterChange Server. Seguindo estas diretrizes, você pode
facilitar a migração de artefatos do WebSphere InterChange Server para
o WebSphere Process Server.
Essas recomendações destinam-se a serem utilizadas
somente como um guia.
Pode haver casos em que é necessário desviar-se dessas
orientações.
Neste casos, é necessário ter cuidado para limitar o escopo
do desvio para minimizar a quantidade de retrabalho requerido para migrar
os artefatos. Observe que as orientações destacadas aqui não são
todas recomendações gerais para o desenvolvimento de artefatos do
WebSphere InterChange
Server. Elas estão limitadas no escopo às considerações que podem afetar a facilidade
em que os artefatos podem ser migrados futuramente.
Considerações: Desenvolvimento Geral
Existem várias considerações que se aplicam amplamente
à maioria dos artefatos de integração. Em geral, os artefatos que alavancam os recursos fornecidos
pelas ferramentas e estão de acordo com os modelos de metadados aplicados
pelas ferramentas serão migrados de maneira mais uniforme.
Além disso, os artefatos com extensões importantes e dependências externas provavelmente
precisarão de mais intervenção manual durante a migração.
A lista a seguir resume as considerações para desenvolvimento geral de soluções baseadas no
WebSphere InterChange
Server para ajudar a facilitar a migração futura:
- Documentar o design do sistema e do componente
- Utilizar as ferramentas de desenvolvimento para editar artefatos de integração
- Alavancar sugestões para definir regras com as ferramentas e snippets Java
É importante para soluções de integração aderir ao modelo de
programação e arquitetura fornecido pelo WebSphere InterChange Server. Cada
componente de integração dentro do
WebSphere
InterChange Server desempenha uma função bem definida dentro da
arquitetura.
Os desvios significativos deste modelo o tornarão
mais desafiador para migrar o conteúdo para os artefatos
apropriados no WebSphere Process
Server.
Outra prática geral que melhorará o sucesso de futuros
projetos de migração é documentar o design do sistema.
Certifique-se de capturar a arquitetura e design
de integração, incluindo os requisitos de design funcional e de qualidade de serviço, as interdependências
de artefatos compartilhados entre projetos e também as decisões de
design que foram tomadas durante a implementação.
Isto ajudará na análise do sistema durante a migração e minimizará
os esforços de retrabalho.
Para criar, configurar e modificar definições de artefato, utilize
apenas a ferramenta de desenvolvimento fornecida.
Evite a manipulação manual de metadados de artefatos (por exemplo, a edição direta de arquivos XML), que
pode danificar o artefato para migração.
Siga essas diretrizes quando desenvolver o código
Java
dentro de modelo de colaboração, mapas, utilitários de código comum
e outros componentes:
- Utilize apenas APIs publicadas.
- Utilize o Activity Editor.
- Utilize adaptadores para acessar EISs.
- Evite dependências externas em trechos de código Java.
- Siga as práticas de desenvolvimento do J2EE para
portabilidade.
- Não efetuar spawn de encadeamentos ou utilizar primitivas de sincronização de encadeamento. Se tiver
que fazer isso, estas tarefas deverão ser convertidas para utilizar Beans Assíncronos durante a migração.
- Não fazer nenhuma E/S de disco utilizando java.io.* Utilizar JDBC para armazenar dados.
- Não execute as funções que podem ser reservadas a um contêiner
EJB, como E/S de soquete, carregamento de classe, bibliotecas nativas
de carregamento e assim em diante.
Se tiver que fazer isso,
estes snippets precisarão de conversão manual para utilizar as funções de contêiner
EJB durante a migração.
Utilize apenas APIs publicadas na documentação do produto
WebSphere
InterChange Server para os artefatos.
Estas tarefas estão descritas detalhadamente nos guias de desenvolvimento do WebSphere InterChange Server.
APIs de compatibilidade serão fornecidas no WebSphere Process
Server para APIs
WebSphere
InterChange Server publicadas. Embora o WebSphere InterChange
Server tenha muitas interfaces internas que você pode desejar
utilizar, essa prática é desencorajada porque essas interfaces não são
garantidas como suportadas futuramente.
Ao projetar a lógica de negócios e as regras de transformação
em mapas e modelo de colaboração, tente evitar bibliotecas de
utilitário de código comum desenvolvidas em campo, incluídas como um
arquivo Java archive
(*.jar) no caminho de classe do
WebSphere
InterChange Server, já que elas precisarão ser migradas manualmente.
Utilize a ferramenta do Activity Editor para a maior extensão
possível.
Isto assegurará que a lógica seja descrita por meio de metadados que podem ser mais
prontamente convertidos para os novos artefatos. Para operações que você deseja reutilizar
nas ferramentas, utilize o recurso "Minhas Coletas" do Activity Editor
sempre que possível.
Em quaisquer trechos de código
Java
que precise ser desenvolvido, o código ser o mais simples e atômico
possível.
O nível de sofisticação no código
Java
deve estar na ordem de script, envolvendo avaliações básicas,
operações e cálculos, formatação de dados, conversões de tipos, e
assim por diante.
Se for requerida uma lógica de aplicativo mais extensiva
ou sofisticada, será necessário utilizar os EJBs em execução
no WebSphere Application
Server para encapsular a lógica e utilizar chamadas de serviços da Web para chamá-la do WebSphere InterChange
Server. Utilize bibliotecas JDK padrão em vez de bibliotecas de terceiros ou externas
que precisariam ser migradas separadamente. Colete também toda a lógica relacionada
em um único trecho de código e evite utilizar lógica onde os contextos de conexão e de transação
estendem vários trechos de código. Com operações do banco de dados, por exemplo, o código relacionado
à obtenção de uma conexão, ao início e fim de uma transação e à liberação da conexão
deve estar em um trecho de código.
Em geral, certifique-se de que o código projetado
para interagir com um EIS (Enterprise Information
System) esteja colocado em adaptadores e não em mapas ou em gabaritos de colaboração.
Isso geralmente é uma prática recomendada para design de
arquitetura.
Além disso, isto ajudará a evitar
pré-requisitos para bibliotecas de terceiros e considerações relacionadas
no código, como gerenciamento de conexões e possíveis implementações de JNI (Java Native
Interface).
Torne o código o mais seguro possível utilizando
a manipulação de exceção apropriada. Torne também o código compatível para execução
em um ambiente do servidor de aplicativos J2EE, mesmo que ele esteja em execução
em um ambiente J2SE. Siga as práticas de desenvolvimento do J2EE,
como evitar variáveis estáticas, execução de spawn em encadeamentos
e E/S de disco. Ao mesmo tempo em que são boas práticas geralmente
recomendadas, elas podem melhorar a portabilidade.
Considerações: Utilitários de Código Comuns:
É recomendável evitar o desenvolvimento de bibliotecas de utilitário de código comum para utilização nos artefatos de integração no ambiente do WebSphere InterChange Server. Onde é necessária a reutilização de código nos artefatos de integração, é recomendável
alavancar o recurso "Minhas Coletas" da ferramenta Activity Editor.
Considere também a utilização de EJBs em execução no WebSphere Application Server para encapsular a lógica e utilizar chamadas de serviços da Web para chamá-la a partir do WebSphere InterChange
Server.
Embora seja possível que algumas bibliotecas de utilitários de código comuns sejam executadas apropriadamente no WebSphere Process Server, o usuário será responsável pela migração dos utilitários customizados.
Considerações: Conjuntos de Conexões com o Banco de Dados
Um conjunto de conexões do banco de dados do WebSphere InterChange
Server dentro de um mapa ou modelo de colaboração será finalizado
como um recurso JDBC padrão no
WebSphere Process Server. Entretanto,
o modo como as conexões e transações são gerenciadas pode ser
diferente entre o WebSphere InterChange
Server e o WebSphere Process
Server, portanto evite manter as transações do banco de dados ativas
através dos snippets Java.
Os conjuntos de conexão com o banco de dados definidos
pelo usuário são úteis dentro de mapas e modelos de
colaboração para consultas de dados simples e para instâncias
de gerenciamento de estado mais sofisticadas.
Um conjunto de conexões com o banco de dados no WebSphere InterChange Server será apresentado
como um recurso JDBC padrão no WebSphere Process Server e a função básica
será a mesma. Entretanto, o modo como as conexões e transações
são gerenciadas pode diferir.
Para maximizar a portabilidade futura, evite manter transações do banco de dados
ativas em nós de snippet Java em um gabarito ou mapa de colaboração.
Por exemplo, o código relacionado
à obtenção de uma conexão, ao início e fim de uma transação e à liberação da conexão
deve estar em um trecho de código.
Considerações: Objetos de Negócios
Para o desenvolvimento dos objetos de negócios, utilize
apenas as ferramentas fornecidas para configurar artefatos, utilize
os tipos de dados e comprimentos explícitos para atributos de dados
e utilize apenas as APIs documentadas.
Objetos de negócios dentro do
WebSphere
Process Server são baseados em SDOs (Service Data Objects). Os SDOs
utilizam atributos de dados fortemente caracterizados.
Para objetos de negócios no WebSphere InterChange
Server e adaptadores, os atributos de dados não são
fortemente caracterizados, e os usuários as vezes especificam
tipos de dados em cadeias para atributos de dados sem cadeia.
Para evitar problemas no WebSphere Process
Server, especifique explicitamente os tipos de dados.
Como os objetos de negócios dentro do
WebSphere
Process Server podem ser serializados em tempo de execução assim
como são transmitidos entre os componentes, é importante ser
explícito com os comprimentos exigidos para atributos de dados,
a fim de minimizar a utilização dos recursos do sistema.
Por isso, não utilize o comprimento máximo
de 255 caracteres para um atributo de cadeia, por exemplo. Além disso, não especifique
atributos de comprimento zero que, no momento, têm como padrão 255 caracteres.
Em vez disso, especifique o comprimento exato requerido para atributos.
As regras do XSD NCName se aplicam a nomes de atributo de
objeto de negócios no WebSphere Process
Server. Portanto, não utilize qualquer espaço ou ":" nos nomes para
atributos de objeto de negócios.
Os nomes de atributos de objeto de negócios
com espaços ou ":" são inválidos no WebSphere Process Server. Renomeie os atributos de
objeto de negócios antes da migração.
Se utilizar uma matriz em um objeto de negócios, você não pode
confiar na ordem da matriz quando indexar dentro da matriz em Mapas
e/ou Relacionamentos.
A construção migrada para dentro do
WebSphere
Process Server não garante a ordem de índice, particularmente
quando as entradas são excluídas.
É importante utilizar apenas a ferramenta do Business Object
Designer para editar definições de objeto de negócios, e utilizar
apenas as APIs publicadas para objetos de negócios dentro de artefatos
de integração.
Considerações: Modelos de Colaboração
Muitas das diretrizes que já foram descritas aplicam-se
ao desenvolvimento de modelos de colaboração.
Para assegurar que os processos sejam descritos apropriadamente com metadados, sempre utilize
a ferramenta Process Designer para a criação e modificação de gabaritos de colaboração
e evite editar os arquivos de metadados diretamente. Utilize a ferramenta Activity Editor
sempre que possível para aumentar a utilização de metadados para descrever a
lógica requerida.
Para minimizar a quantidade de retrabalho manual que pode ser requerido
na migração, utilize apenas as APIs documentadas em gabaritos de colaboração.
Evite utilizar variáveis estáticas. Em vez disso, utilize variáveis não estáticas e propriedades de colaboração para abordar os requisitos da lógica de negócios.
Evite utilizar qualificadores Java finais, transientes e nativos em snippets Java.
Não podem ser forçados em snippets do BPEL
Java
que são o resultado da migração dos Modelos de Colaboração.
Para maximizar a portabilidade futura, evite utilizar chamadas de
liberação de conexão explícitas e chaves de transação explícitas (ou
seja, confirmações explícitas e recuperações explícitas) para
Conjuntos de Conexão de Banco de Dados Definidos pelo Usuário.
Em vez disso, utilize a limpeza de conexão implícita gerenciada por contêiner
e o suporte a transações implícito. Além disso, evite manter conexões e transações do sistema ativas
em nós de snippet Java em um gabarito de colaboração.
Isto se aplica a qualquer conexão com um sistema externo, bem como conjuntos
de conexões com o banco de dados definidos pelo usuário. Operações
com um EIS externo devem ser gerenciadas dentro de um adaptador, e
o código relacionado à operação do banco de dados deve estar
contido dentro de um trecho de código.
Isto pode ser necessário em uma colaboração que,
quando apresentada como um componente do processo de negócios de BPEL, pode ser seletivamente
implementada como um fluxo que pode ser interrompido. Neste caso, o processo pode ser composto
de várias transações separadas, apenas com informações de estados e de variáveis globais
transmitidas entre as atividades.
O contexto para qualquer conexão do sistema ou transação relacionada que estendeu estas
transações de processos será perdido.
Dê nomes à propriedade do modelo de colaboração de acordo com as
convenções de nomenclatura do W3C XML NCName. O
WebSphere
Process Server aceita nomes conforme essas convenções.
Quaisquer caracteres desaprovados são inválidos nos nomes de
propriedade BPEL aos quais serão migrados.
Renomeie propriedades para remover todos os caracteres desaprovados antes
de migrar para evitar erros sintáticos no BPEL gerados pela migração.
Não faça referência a variáveis utilizando
"this." Por exemplo, em vez de "this.inputBusObj" utilize apenas "inputBusObj"
Utilize o escopo de nível de classe em variáveis em vez de variáveis com escopo definido pelo cenário.
O escopo de cenário não é transportado durante a migração.
Inicialize todas as variáveis declaradas em snippets
Java
com um valor padrão: "Object myObject = null;" por exemplo. Certifique-se
de que todas as variáveis sejam inicializadas durante a declaração
antes de migrar.
Certifique-se de que não haja instruções de importação
Java
nas seções modificáveis pelo usuário de seus modelos de
colaboração.
Na definição do modelo de colaboração, utilize os campos de
importação para especificar os pacotes
Java
para importar.
Não configure valores de objeto de negócios de entrada para serem
armazenados na variável triggeringBusObj.
Dentro do WebSphere InterChange
Server, o triggeringBusObj é de leitura e seus
valores não podem ser sobrescritos, assim os valores de objeto
de negócios de entrada não serão salvos.
Se o triggeringBusObj for utilizado como a
variável de recebimento para um objeto de negócios de entrada em uma
chamada de serviço de entrada, então após a migração o comportamento
da chamada de serviço de entrada será diferente: dentro do processo
BPEL, o valor de entrada da chamada de serviço de entrada
sobrescreverá o valor armazenado em triggeringBusObj.
Considerações: Mapas
Muitas das diretrizes já descritas para modelos de
colaboração também se aplicam a mapas.
Para assegurar que os mapas sejam descritos corretamente
com metadados, sempre utilize a ferramenta Map Designer para a criação e modificação de
mapas e evite editar os arquivos de metadados diretamente. Utilize a ferramenta Activity Editor
sempre que possível para aumentar a utilização de metadados para descrever a
lógica requerida.
Ao fazer referência a objetos de negócios filho em um mapa, utilize
um submapa para os objetos de negócios filho.
Evite utilizar o código Java como o "valor" em um SET, já que ele não é válido no WebSphere Process Server. Em vez disso, utilize constantes. Por exemplo, se o valor configurado for "xml version="
+ "1.0" + " encoding=" + "UTF-8", isto não será válido no WebSphere Process
Server. Em vez disso, altere-o para "xml version=1.0 encoding=UTF-8" antes da migração.
Para minimizar a quantidade de retrabalho manual necessário na
migração, utilize apenas as APIs documentadas dentro de mapas. Evite utilizar variáveis estáticas. Em
vez disso, utilize variáveis não-estáticas.
Evite o uso de qualificadores
Java
finais, temporários e nativos em código customizado de mapa.
Se utilizar uma matriz em um objeto de negócios, não confie na
ordem da matriz quando indexar dentro da matriz em mapas.
A construção migrada para dentro do
WebSphere
Process Server não garante a ordem de índice, particularmente quando
as entradas são excluídas.
Para maximizar a portabilidade futura, evite utilizar chamadas de
liberação de conexão explícitas e chaves de transação explícitas (ou
seja, confirmações explícitas e recuperações explícitas) para
Conjuntos de Conexão de Banco de Dados Definidos pelo Usuário.
Em vez disso, utilize a limpeza de conexão implícita gerenciada por contêiner
e o suporte a transações implícito. Também, evite manter conexões e
transações do sistema ativas em etapas de mapa customizado através
dos limites do nó de transformação.
Isto se aplica a qualquer conexão com um sistema externo, bem como conjuntos
de conexões com o banco de dados definidos pelo usuário. Operações
com um EIS externo devem ser gerenciadas dentro do adaptador, e
código relacionado a operação do banco de dados deve estar
contido em uma etapa customizada.
Não utilize classes internas em seus mapas.
O comando de migração (reposMigrate)
não migra classes internas e você receberá erros se seus mapas as
tiver.
Em um repositório do
WebSphere
InterChange, uma classe interna não pode ser definida em um nó e ser
referida por outros nós dentro do mesmo modelo de colaboração.
Em WebSphere Process
Server, uma classe interna definida em um componente BPEL não
pode ser utilizada por outro componente.
Devido a essa limitação, as classes internas não são
convertidas e devem ser tratadas manualmente.
As alterações recomendadas incluem pacote de código de
classe interna em uma biblioteca como uma classe externa, ou
remover a declaração de classe interna, resolvendo todos os
erros, e colocando o código conforme necessário por todo o BPEL.
Considerações: Relacionamentos
Para relacionamentos, lembre-se de que embora as definições de
relacionamentos poderão ser migradas para utilização no WebSphere Process
Server, o esquema da tabela de relacionamentos e os dados da instância podem ser reutilizados pelo WebSphere Process
Server e também compartilhados simultaneamente entre o WebSphere InterChange Server e o WebSphere Process
Server.
Para relacionamentos, utilize apenas a ferramenta fornecida para
configurar os componentes relacionados e utilize apenas as APIs
publicadas para relacionamentos dentro de artefatos de integração.
Utilize apenas a ferramenta de Relationship Designer para editar
definições de relacionamentos.
Além disso, permita que apenas o
WebSphere
InterChange Server configure os esquemas de relacionamentos, os
quais são gerados automaticamente através da implementação das
definições de relacionamentos.
Não altere o esquema da tabela de relacionamentos diretamente
com ferramentas de banco de dados ou scripts SQL.
Se você modificar manualmente dados da instância do relacionamento
dentro do esquema de tabela de relacionamento, certifique-se de
utilizar os recursos fornecidas pelo Relationship Manager.
Utilize apenas APIs publicadas para relacionamentos dentro de
artefatos de integração.
Considerações: Clientes de Estrutura de Acesso
Não desenvolva novos clientes adotando
as APIs da interface IDL CORBA. Isto não será suportado no WebSphere Process Server.
Considerações: Evitando colisões de banco de dados
Você pode evitar colisões do banco de dados planejando
eventos que ocorrem pelo menos a cada dois segundos.
Se um aplicativo migrado causar vários eventos ao mesmo tempo
para os componentes do WebSphere Business
Integration, podem ocorrer colisões de banco de dados ou conflitos.
Isso ocorre quando o WebSphere Process
Server Application Scheduler (AppScheduler) planeja vários
eventos para ocorrerem exatamente ao mesmo tempo.
Quando ocorre um conflito, o evento que o causou é retornado e
tentado novamente assim que possível.
Esse ciclo continua até que cada um dos encadeamentos que estão
tentando acessar o banco de dados consiga atualizá-lo com sucesso.
Por exemplo:
AppScheduler E com.ibm.wbiserver.scheduler.AppSchedulerMB process CWLWS0021E:
O método AppSchedulerMB.process gerou uma exceção.
WSRdbXaResour E DSRA0304E: ocorreu XAException. O conteúdo e
detalhes da XAException são:
A mensagem de Erro do DB2 é: Erro ao executar uma XAResource.end(), Server retornou
XA_RBDEADLOCK O código do Erro DB2 é: -4203
O DB2 SQLState está : nulo
Para evitar isso, planeje os eventos para ocorrerem distantes
entre si o suficiente para não ocorrer conflito.
Planeje os eventos para ocorrerem com pelo menos dois segundos
de distância entre si, entretanto, a quantidade de tempo que
você precisará pode variar de acordo com outros fatores em seu
ambiente que afetam o desempenho, como o tamanho do banco de
dados, hardware, velocidade da conexão e outros fatores.
Considerações: Pós-Migração
Quando os aplicativos forem migrados do WebSphere InterChange Server para oWebSphere Integration
Developer ou para o WebSphere Process
Server, uma atenção especial é necessária em algumas áreas para possibilitar que os aplicativos migrados funcionem no WebSphere Integration
Developer e no WebSphere Process
Server consistentemente com a função destinada devido às diferenças com a arquitetura do WebSphere InterChange
Server.
Para obter mais informações sobre as considerações de pós-migração, consulte Considerações pós-migração.
Migrando o WebSphere InterChange Server Utilizando o
Assistente de Migração
Você pode utilizar o Assistente de Migração do WebSphere Integration Developer para migrar seus artefatos
existentes do WebSphere InterChange Server.
Para utilizar o Assistente de Migração para migrar os artefatos do WebSphere InterChange Server, siga estas etapas:
- Chame o assistente selecionando
Arquivo (File) -> Importar (Import) -> Integração
de Negócios (Business Integration) -> WebSphere
InterChange Server JAR File e clique em
Avançar (Next):
OU você também pode abrir o assistente de
Migração a partir da página Bem-vindo (Welcome) clicando no ícone
Retornando Usuários (Returning Users)
para abrir a página
Retornando Usuários (Returning Users) (observe que você sempre pode retornar para a
página Bem-vindo (Welcome) clicando em
Ajuda (Help) -> Bem-vindo (Welcome)
):
Clique em
Migração (Migration) à esquerda da página Retornando
Usuários (Returning Users) para abrir a página de Migração (Migration). Na página Migração (Migration),
selecione a opção Migrar um repositório do WebSphere ICS (Migrate a WebSphere ICS repository)
.
- É aberto o Assistente de Migração (Migration). Digite o nome do arquivo de origem
no campo Seleção de Origem (Source selection) clicando no botão Procurar (Browse)
e navegando para o arquivo. Digite o nome da biblioteca no campo relevante.
Se a biblioteca compartilhada não existir no espaço de trabalho, ela
precisa ser criada clicando em Novo... (New...). Clique em Avançar (Next):
- É aberta a janela de Opções de Migração. Dela você pode aceitar
os padrões da migração ou selecionar uma caixa de opção para
alterar a opção:

A tabela a seguir destaca as
opções de migração disponíveis:
Opção |
Descrição |
Aviso em caso de erros de análise
Java (Warn in case of Java(TM) parsing errors) |
(Opcional)
Por padrão, a migração de um artefato individual irá falhar se
ocorrer um problema de conversão de Java. Se
essa opção for configurada, todos os problemas de conversão
Java
serão tratados como avisos apenas, e o artefato será migrado assim
que possível. |
Parar migração na primeira falha (Stop the migration on the first failure) |
(Opcional)
Por padrão, o assistente de Migração continuará o processo dos
artefatos restantes no arquivo JAR se ocorrer um erro durante o
processamento de um certo artefato.
Se essa opção estiver configurada, o processamento irá parar assim
que for detectado um erro.
O artefato com erro, e todos os artefatos subseqüentes, não
são processados. |
Usar o desembaraçamento de loop do modelo de colaboração (Use collaboration template loop unraveling) |
(Opcional)
Solicita que todos os loops presentes em um Modelo de Colaboração
sejam mantidos.
Se essa opção não estiver presente, o padrão é que a migração
utilize o desembaraçamento de loop. |
Ativar seqüenciamento de eventos (Enable event sequencing) |
(Opcional) Solicita que o Seqüenciamento de Eventos
seja ativado para todos os métodos de WSDL Assíncrono. Se essa opção
não estiver presente, o padrão é que a migração não ative
seqüenciamento de eventos em nenhum método WSDL. |
Usar modelo padrão (Use default template) |
(Opcional) Solicita que todos os modelos de editor de
montagem no diretório especificado sejam carregados e utilizados
para XML na conversão de Java. O
padrão para essa propriedade é apenas para o Standard Assembly Editor
Template v4.3.3 ser utilizado para XML na conversão Java. |
- Clique em Concluir (Finish).
Uma barra de progresso na parte inferior do diálogo de
migração indica o progresso da migração.
Uma vez concluído o processo de migração, o diálogo de migração
desaparece e a janela de Resultados da Migração é exibida.
Verificando a Migração do WebSphere InterChange Server
Se não forem relatados erros durante a migração do arquivo jar do WebSphere InterChange
Server, isto indica que a migração dos artefatos foi bem-sucedida. Se a migração não tiver sido concluída com êxito, será exibida uma lista de mensagens de erros, avisos e/ou informativas. Estas mensagens
podem ser utilizadas para verificar a migração do WebSphere InterChange
Server.
Nota: Devido à complexidade de migração do WebSphere InterChange
Server para o WebSphere Process
Server, é altamente recomendável desempenhar um teste extensivo dos aplicativos resultantes
em execução no WebSphere Process Server para assegurar que eles funcionem conforme
o esperado, antes de colocá-los em produção.
A página a seguir aparece se tiverem sido geradas mensagens de migração durante o processo de migração:
Na janela Resultados da Migração (Migration Results), é possível ver as mensagens de migração geradas durante o processo de migração. Selecionando uma mensagem da lista Mensagens (Message) superior, é possível localizar informações adicionais em relação a essa mensagem na janela Descrição de Mensagem (Message Description) inferior.
Para guardar todas as mensagens para futuras consultas, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização de tarefa e/ou clique no botão Salvar como... (Save as...) para salvar as mensagens em um arquivo de texto no sistema de arquivos.
Para ver a lista A Fazer gerada, clique em
Janela -> Mostrar
Visualização -> Outra... -> Geral -> Tarefas
e clique em OK.
A visualização de Tarefas é aberta com a lista de A Fazer gerada a
partir do processo de migração.
Trabalhando com Falhas de Migração do WebSphere InterChange Server
Se a migração do WebSphere InterChange Server falhar,
existem duas maneiras para lidar com as falhas.
Nota: Você pode preferir a primeira opção por estar, inicialmente,
mais familiarizado com o WebSphere InterChange Server. No entanto, à medida que se
torna mais experiente com o WebSphere Process Server e seus novos artefatos,
você pode optar por reparar os artefatos migrados no WebSphere Integration Developer.
- Se a natureza do erro permitir, será possível ajustar os artefatos do WebSphere InterChange
Server utilizando o conjunto de ferramentas do WebSphere InterChange Server e exportar o arquivo
jar outra vez e tentar novamente a migração.
- Você pode corrigir erros nos artefatos resultantes do WebSphere Process Server,
editando os artefatos no WebSphere Integration Developer.
Artefatos do WebSphere InterChange
Server Manipulados por Ferramentas de Migração
As ferramentas de migração podem migrar automaticamente alguns dos artefatos do WebSphere InterChange Server.
Os seguintes artefatos podem ser migrados:
- Objetos de Negócios se tornam objetos de negócios do WebSphere Process Server
- Mapas se tornam mapas do WebSphere Process Server
- Relacionamentos se tornam relacionamentos e funções do WebSphere Process Server
- Gabaritos de colaboração se tornam BPEL e WSDL do WebSphere Process Server
- Objetos de colaboração se tornam módulos do
WebSphere
Process Server contendo um limite de componente SCA para o Modelo de
Colaboração BPEL e toda a fiação SCA necessária
- Definições do conector se tornam módulos do
WebSphere
Process Server contendo importações e exportações SCA para
permitir a comunicação com Adaptadores de Legado, Artefato
Administrativo de Adaptador de Legado e toda a fiação SCA necessária.
As ferramentas de migração criarão um script Jython que pode ser utilizado com a ferramenta da linha de comandos wsadmin para configurar recursos no WebSphere Process Server para os artefatos/recursos do WebSphere InterChange Server a seguir:
- Conjuntos DBConnection
- Relacionamentos
- Entradas do Planejador
As ferramentas de migração não manipulam os seguintes artefatos do WebSphere InterChange Server:
- Artefatos de Avaliação de Desempenho
APIs do WebSphere InterChange Server Suportadas
Além das ferramentas de migração de artefato de origem do WebSphere InterChange Server fornecidas no
WebSphere Process Server e no WebSphere Integration
Developer, há também suporte para várias das APIs que são fornecidas no WebSphere InterChange
Server. As ferramentas de migração trabalham em conjunto com essas APIs do WebSphere InterChange
Server, preservando seu código de snippet customizado o máximo possível durante a migração.
Nota: Essas APIs são fornecidas apenas para suportar aplicativos do WebSphere InterChange Server migrados até que possam ser modificados para utilizar novas APIs do Process Server.
As APIs do WebSphere InterChange Server suportadas no Process Server são listadas abaixo. Essas APIs oferecem no WebSphere Process Server funções semelhantes às funções que oferecem no WebSphere InterChange Server. Consulte a documentação do WebSphere InterChange Server para obter uma descrição funcional dessas APIs.
CwBiDiEngine
AppSide_Connector/
- BiDiBOTransformation(BusinessObject, String, String, boolean):BusinessObj
- BiDiBusObjTransformation(BusObj, String, String, boolean):BusObj
- BiDiStringTransformation(String, String, String):String
JavaConnectorUtil
AppSide_Connector/
- INFRASTRUCTURE_MESSAGE_FILE
- CONNECTOR_MESSAGE_FILE
- XRD_WARNING
- XRD_TRACE
- XRD_INFO
- XRD_ERROR
- XRD_FATAL
- LEVEL1
- LEVEL2
- LEVEL3
- LEVEL4
- LEVEL5
- createBusinessObject(String):BusinesObjectInterface
- createBusinessObject(String, Locale):BusinesObjectInterface
- createBusinessObject(String, String):BusinesObjectInterface
- createContainer(String):CxObjectContainerInterface
- generateMsg(int, int, int, int, int, Vector):String
- generateMsg(int, int, int, int, Vector):String
- getBlankValue():String
- getEncoding():String
- getIgnoreValue():String
- getLocale():String
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
- isBlankValue(Object):boolean
- isIgnoreValue(Object):boolean
- isTraceEnabled(int):boolean
- logMsg(String)
- logMsg(String, int)
- traceWrite(int, String)
JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
BusObj
Collaboration/
- BusObj(DataObject)
- BusObj(String)
- BusObj(String, Locale)
- copy(BusObj)
- duplicate():BusObj
- equalKeys(BusObj):boolean
- equals(Object):boolean
- equalsShallow(BusObj):boolean
- exists(String):boolean
- get(int):Object
- get(String):Object
- getBoolean(String):boolean
- getBusObj(String):BusObj
- getBusObjArray(String):BusObjArray
- getCount(String):int
- getDouble(String):double
- getFloat(String):float
- getInt(String):int
- getKeys():String
- getLocale():java.util.Locale
- getLong(String):long
- getLongText(String):String
- getString(String):String
- getType():String
- getValues():String
- getVerb():String
- isBlank(String):boolean
- isKey(String):boolean
- isNull(String):boolean
- isRequired(String):boolean
- keysToString():String
- set(BusObj)
- set(int, Object)
- set(String, boolean)
- set(String, double)
- set(String, float)
- set(String, int)
- set(String, long)
- set(String, Object)
- set(String, String)
- setContent(BusObj)
- setDefaultAttrValues()
- setKeys(BusObj)
- setLocale(java.util.Locale)
- setVerb(String)
- setVerbWithCreate(String, String)
- setWithCreate(String, boolean)
- setWithCreate(String, BusObj)
- setWithCreate(String, BusObjArray)
- setWithCreate(String, double)
- setWithCreate(String, float)
- setWithCreate(String, int)
- setWithCreate(String, long):
- setWithCreate(String, Object)
- setWithCreate(String, String)
- toString():String
- validData(String, boolean):boolean
- validData(String, BusObj):boolean
- validData(String, BusObjArray):boolean
- validData(String, double):boolean
- validData(String, float):boolean
- validData(String, int):boolean
- validData(String, long):boolean
- validData(String, Object):boolean
- validData(String, String):boolean
BusObjArray
Collaboration/
- addElement(BusObj)
- duplicate():BusObjArray
- elementAt(int):BusObj
- equals(BusObjArray):boolean
- getElements():BusObj[]
- getLastIndex():int
- max(String):String
- maxBusObjArray(String):BusObjArray
- maxBusObjs(String):BusObj[]
- min(String):String
- minBusObjArray(String):BusObjArray
- minBusObjs(String):BusObj[]
- removeAllElements()
- removeElement(BusObj)
- removeElementAt(int)
- setElementAt(int, BusObj)
- size():int
- sum(String):double
- swap(int, int)
- toString():String
BaseDLM
DLM/
- BaseDLM(BaseMap)
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection
- getName():String
- getRelConnection(String):DtpConnection
- implicitDBTransactionBracketing():boolean
- isTraceEnabled(int):boolean
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- raiseException(RunTimeEntityException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- releaseRelConnection(boolean)
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
CwDBConnection
CwDBConnection/
CxCommon/
- beginTransaction()
- commit()
- executePreparedSQL(String)
- executePreparedSQL(String, Vector)
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- release()
- rollback()
CwDBConstants
CwDBConnection/
CxCommon/
- PARAM_IN - 0
- PARAM_INOUT - 1
- PARAM_OUT - 2
CwDBStoredProcedureParam
CwDBConnection/
CxCommon/
- CwDBStoredProcedureParam(int, Array)
- CwDBStoredProcedureParam(int, BigDecimal)
- CwDBStoredProcedureParam(int, boolean)
- CwDBStoredProcedureParam(int, Boolean)
- CwDBStoredProcedureParam(int, byte[])
- CwDBStoredProcedureParam(int, double)
- CwDBStoredProcedureParam(int, Double)
- CwDBStoredProcedureParam(int, float)
- CwDBStoredProcedureParam(int, Float)
- CwDBStoredProcedureParam(int, int)
- CwDBStoredProcedureParam(int, Integer)
- CwDBStoredProcedureParam(int, java.sql.Blob)
- CwDBStoredProcedureParam(int, java.sql.Clob)
- CwDBStoredProcedureParam(int, java.sql.Date)
- CwDBStoredProcedureParam(int, java.sql.Struct)
- CwDBStoredProcedureParam(int, java.sql.Time)
- CwDBStoredProcedureParam(int, java.sql.Timestamp)
- CwDBStoredProcedureParam(int, Long)
- CwDBStoredProcedureParam(int, String)
- CwDBStoredProcedureParam(int, String, Object)
- getParamType():int getValue():Object
DataHandler (Abstract Class)
DataHandlers/
crossworlds/
com/
- createHandler(String, String, String):DataHandler
- getBO(InputStream, Object):BusinessObjectInterface
- getBO(Object, BusinessObjectInterface, Object)
- getBO(Object, Object):BusinessObjectInterface
- getBO(Reader, BusinessObjectInterface, Object) (Abstract Method)
- getBO(Reader, Object):BusinessObjectInterface (Abstract Method)
- getBO(String, Object):BusinessObjectInterface
- getBOName(InputStream):String
- getBOName(Reader):String
- getBOName(String):String
- getBooleanOption(String):boolean
- getEncoding():String
- getLocale():Locale
- getOption(String):String
- getStreamFromBO(BusinessObjectInterface, Object):InputStream (Abstract
Method)
- getStringFromBO(BusinessObjectInterface, Object):String (Abstract Method)
- setConfigMOName(String)
- setEncoding(String)
- setLocale(Locale)
- setOption(String, String)
- traceWrite(String, int)
NameHandler (Abstract Class)
DataHandlers/
crossworlds/
com/
- getBOName(Reader, String):String) (Abstract Method)
ConfigurationException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
MalformedDataException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
NotImplementedException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
BusinessObjectInterface
CxCommon/
- clone():Object
- dump():String
- getAppText():String
- getAttrCount():int
- getAttrDesc(int):CxObjectAttr
- getAttrDesc(String):CxObjectAttr
- getAttribute(String):Object
- getAttributeIndex(String):int
- getAttributeType(int):int
- getAttributeType(String):int
- getAttrName(int):String
- getAttrValue(int):Object
- getAttrValue(String):Object
- getBusinessObjectVersion():String
- getDefaultAttrValue(int):String
- getDefaultAttrValue(String):String
- getLocale():String
- getName():String
- getParentBusinessObject():BusinessObjectInterface
- getVerb():String
- getVerbAppText(String):String
- isBlank(int):boolean
- isBlank(String):boolean
- isIgnore(int):boolean
- isIgnore(String):boolean
- isVerbSupported(String):boolean
- makeNewAttrObject(int):Object
- makeNewAttrObject(String):Object
- setAttributeWithCreate(String, Object)
- setAttrValue(int, Object)
- setAttrValue(String, Object)
- setDefaultAttrValues()
- setLocale(Locale)
- setLocale(String)
- setVerb(String)
CxObjectAttr
CxCommon/
- BOOLEAN
- BOOLSTRING
- DATE
- DATESTRING
- DOUBLE
- DOUBSTRING
- FLOAT
- FLTSTRING
- INTEGER
- INTSTRING
- INVALID_TYPE_NUM
- INVALID_TYPE_STRING
- LONGTEXT
- LONGTEXTSTRING
- MULTIPLECARDSTRING
- OBJECT
- SINGLECARDSTRING
- STRING
- STRSTRING
- equals(Object):boolean
- getAppText():String
- getCardinality():String
- getDefault():String
- getMaxLength():int
- getName():String
- getRelationType():String
- getTypeName():String
- getTypeNum():String
- hasCardinality(String):boolean
- hasName(String):boolean
- hasType(String):boolean
- isForeignKeyAttr():boolean
- isKeyAttr():boolean
- isMultipleCard():boolean
- isObjectType():boolean
- isRequiredAttr():boolean
- isType(Object):boolean
CxObjectContainerInterface
CxCommon/
- getBusinessObject(int):BusinessObjectInterface
- getObjectCount():int
- insertBusinessObject(BusinessObjectInterface)
- removeAllObjects()
- removeBusinessObjectAt(int)
- setBusinessObject(int, BusinessObjectInterface)
DtpConnection
Dtp/
CxCommon/
- beginTran()
- commit()
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- rollback()
DtpDataConversion
Dtp/
CxCommon/
- BOOL_TYPE - 4
- CANNOTCONVERT - 2
- DATE_TYPE - 5
- DOUBLE_TYPE - 3
- FLOAT_TYPE - 2
- INTEGER_TYPE - 0
- LONGTEXT_TYPE - 6
- OKTOCONVERT - 0
- POTENTIALDATALOSS - 1
- STRING_TYPE - 1
- UNKNOWN_TYPE - 999
- getType(double):int
- getType(float):int
- getType(int):int
- getType(Object):int
- isOKToConvert(int, int):int
- isOKToConvert(String, String):int
- toBoolean(boolean):Boolean
- toBoolean(Object):Boolean
- toDouble(double):Double
- toDouble(float):Double
- toDouble(int):Double
- toDouble(Object):Double
- toFloat(double):Float
- toFloat(float):Float
- toFloat(int):Float
- toFloat(Object):Float
- toInteger(double):Integer
- toInteger(float):Integer
- toInteger(int):Integer
- toInteger(Object):Integer
- toPrimitiveBoolean(Object):boolean
- toPrimitiveDouble(float):double
- toPrimitiveDouble(int):double
- toPrimitiveDouble(Object):double
- toPrimitiveFloat(double):float
- toPrimitiveFloat(int):float
- toPrimitiveFloat(Object):float
- toPrimitiveInt(double):int
- toPrimitiveInt(float):int
- toPrimitiveInt(Object):int
- toString(double):String
- toString(float):String
- toString(int):String
- toString(Object):String
DtpDate
Dtp/
CxCommon/
- DtpDate()
- DtpDate(long, boolean)
- DtpDate(String, String)
- DtpDate(String, String, String[], String[])
- addDays(int):DtpDate
- addMonths(int):DtpDate
- addWeekdays(int):DtpDate
- addYears(int):DtpDate
- after(DtpDate):boolean
- before(DtpDate):boolean
- calcDays(DtpDate):int
- calcWeekdays(DtpDate):int
- get12MonthNames():String[]
- get12ShortMonthNames():String[]
- get7DayNames():String[]
- getCWDate():String
- getDayOfMonth():String
- getDayOfWeek():String
- getHours():String
- getIntDay():int
- getIntDayOfWeek():int
- getIntHours():int
- getIntMilliSeconds():int
- getIntMinutes():int
- getIntMonth():int
- getIntSeconds():int
- getIntYear():int
- getMaxDate(BusObjArray, String, String):DtpDate
- getMaxDateBO(BusObj[], String, String):BusObj[]
- getMaxDateBO(BusObjArray, String, String):BusObj[]
- getMinDate(BusObjArray, String, String):DtpDate
- getMinDateBO(BusObj[], String, String):BusObj[]
- getMinDateBO(BusObjArray, String, String):BusObj[]
- getMinutes():String
- getMonth():String
- getMSSince1970():long
- getNumericMonth():String
- getSeconds():String
- getShortMonth():String
- getYear():String
- set12MonthNames(String[], boolean)
- set12MonthNamesToDefault()
- set12ShortMonthNames(String[])
- set12ShortMonthNamesToDefault()
- set7DayNames(String[])
- set7DayNamesToDefault()
- toString():String
- toString(String):String
- toString(String, boolean):String
DtpMapService
Dtp/
CxCommon/
- runMap(String, String, BusObj[], CxExecutionContext):BusObj[]
DtpSplitString
Dtp/
CxCommon/
- DtpSplitString(String, String)
- elementAt(int):String
- firstElement():String
- getElementCount():int
- getEnumeration():Enumeration
- lastElement():String
- nextElement():String
- prevElement():String
- reset()
DtpUtils
Dtp/
CxCommon/
- padLeft(String, char, int):String
- padRight(String, char, int):String
- stringReplace(String, String, String):String
- truncate(double):int
- truncate(double, int):double
- truncate(float):int
- truncate(float, int):double
- truncate(Object):int
- truncate(Object, int):double
BusObjInvalidVerbException (extends InterchangeExceptions)
Exceptions/
CxCommon/
IdentityRelationship
relationship/
utilities/
crossworlds/
com/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- foreignKeyLookup(String, String, BusObj, String, BusObj, String, CxExecutionContext)
- foreignKeyXref(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext)
- maintainChildVerb(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext, boolean, boolean)
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
MapExeContext
Dtp/
CxCommon/
- ACCESS_REQUEST - "SUBSCRIPTION_DELIVERY"
- ACCESS_RESPONSE - "ACCESS_RETURN_REQUEST"
- EVENT_DELIVERY - "SUBSCRIPTION_DELIVERY"
- SERVICE_CALL_FAILURE - "CONSUME_FAILED"
- SERVICE_CALL_REQUEST - "CONSUME"
- SERVICE_CALL_RESPONSE - "DELIVERBUSOBJ"
- getConnName():String
- getGenericBO():BusObj
- getInitiator():String
- getLocale():java.util.Locale
- getOriginalRequestBO():BusObj
- setConnName(String)
- setInitiator(String)
- setLocale(java.util.Locale)
Participant
RelationshipServices/
Server/
- Participant(String, String, int, BusObj)
- Participant(String, String, int, String)
- Participant(String, String, int, long)
- Participant(String, String, int, int)
- Participant(String, String, int, double)
- Participant(String, String, int, float)
- Participant(String, String, int, boolean)
- Participant(String, String, BusObj)
- Participant(String, String, String)
- Participant(String, String, long)
- Participant(String, String, int)
- Participant(String, String, double)
- Participant(String, String, float)
- Participant(String, String, boolean)
- getBoolean():boolean
- getBusObj():BusObj
- getDouble():double
- getFloat():float
- getInstanceId():int
- getInt():int
- getLong():long
- getParticipantDefinition():String
- getRelationshipDefinition():String
- getString():String INVALID_INSTANCE_ID
- set(boolean)
- set(BusObj)
- set(double)
- set(float)
- set(int)
- set(long)
- set(String)
- setInstanceId(int)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
Relationship
RelationshipServices/
Server/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- addParticipant(Participant):int
- addParticipant(String, String, boolean):int
- addParticipant(String, String, BusObj):int
- addParticipant(String, String, double):int
- addParticipant(String, String, float):int
- addParticipant(String, String, int):int
- addParticipant(String, String, int, boolean):int
- addParticipant(String, String, int, BusObj):int
- addParticipant(String, String, int, double):int
- addParticipant(String, String, int, float):int
- addParticipant(String, String, int, int):int
- addParticipant(String, String, int, long):int
- addParticipant(String, String, int, String):int
- addParticipant(String, String, long):int
- addParticipant(String, String, String):int
- create(Participant):int
- create(String, String, boolean):int
- create(String, String, BusObj):int
- create(String, String, double):int
- create(String, String, float):int
- create(String, String, int):int
- create(String, String, long):int
- create(String, String, String):int
- deactivateParticipant(Participant)
- deactivateParticipant(String, String, boolean)
- deactivateParticipant(String, String, BusObj)
- deactivateParticipant(String, String, double)
- deactivateParticipant(String, String, float)
- deactivateParticipant(String, String, int)
- deactivateParticipant(String, String, long)
- deactivateParticipant(String, String, String)
- deactivateParticipantByInstance(String, String, int)
- deactivateParticipantByInstance(String, String, int, boolean)
- deactivateParticipantByInstance(String, String, int, BusObj)
- deactivateParticipantByInstance(String, String, int, double)
- deactivateParticipantByInstance(String, String, int, float)
- deactivateParticipantByInstance(String, String, int, int)
- deactivateParticipantByInstance(String, String, int, long)
- deactivateParticipantByInstance(String, String, int, String)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteParticipant(Participant)
- deleteParticipant(String, String, boolean)
- deleteParticipant(String, String, BusObj)
- deleteParticipant(String, String, double)
- deleteParticipant(String, String, float)
- deleteParticipant(String, String, int)
- deleteParticipant(String, String, long)
- deleteParticipant(String, String, String)
- deleteParticipantByInstance(String, String, int)
- deleteParticipantByInstance(String, String, int, boolean)
- deleteParticipantByInstance(String, String, int, BusObj)
- deleteParticipantByInstance(String, String, int, double)
- deleteParticipantByInstance(String, String, int, float)
- deleteParticipantByInstance(String, String, int, int)
- deleteParticipantByInstance(String, String, int, long)
- deleteParticipantByInstance(String, String, int, String)
- getNewID(String):int
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- retrieveInstances(String, boolean):int[]
- retrieveInstances(String, BusObj):int[]
- retrieveInstances(String, double):int[]
- retrieveInstances(String, float):int[]
- retrieveInstances(String, int):int[]
- retrieveInstances(String, long):int[]
- retrieveInstances(String, String):int[]
- retrieveInstances(String, String, boolean):int[]
- retrieveInstances(String, String, BusObj):int[]
- retrieveInstances(String, String, double):int[]
- retrieveInstances(String, String, float):int[]
- retrieveInstances(String, String, int):int[]
- retrieveInstances(String, String, long):int[]
- retrieveInstances(String, String, String):int[]
- retrieveInstances(String, String[], boolean):int[]
- retrieveInstances(String, String[], BusObj):int[]
- retrieveInstances(String, String[], double):int[]
- retrieveInstances(String, String[], float):int[]
- retrieveInstances(String, String[], int):int[]
- retrieveInstances(String, String[], long):int[]
- retrieveInstances(String, String[], String):int[]
- retrieveParticipants(String):Participant[]
- retrieveParticipants(String, String):Participant[]
- retrieveParticipants(String, String[]):Participant[]
- retrieveParticipants(String, int):Participant[]
- retrieveParticipants(String, String, int):Participant[]
- retrieveParticipants(String, String[], int):Participant[]
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
- updateParticipant(String, String, BusObj)
- updateParticipantByInstance(Participant)
- updateParticipantByInstance(String, String, int)
- updateParticipantByInstance(String, String, int, BusObj)
UserStoredProcedureParam
Dtp/
CxCommon/
- UserStoredProcedureParam(int, String, Object, String, String)
- getParamDataTypeJavaObj():String
- getParamDataTypeJDBC():int
- getParamIndex():int
- getParamIOType():String
- getParamName():String
- getParamValue():Object
- setParamDataTypeJavaObj(String)
- setParamDataTypeJDBC(int)
- setParamIndex(int)
- setParamIOType(String)
- setParamName(String)
- setParamValue(Object)
- PARAM_TYPE_IN - "IN"
- PARAM_TYPE_OUT - "OUT"
- PARAM_TYPE_INOUT - "INOUT"
- DATA_TYPE_STRING - "String"
- DATA_TYPE_INTEGER - "Integer"
- DATA_TYPE_DOUBLE - "Double"
- DATA_TYPE_FLOAT - "Float"
- DATA_TYPE_BOOLEAN - "Boolean"
- DATA_TYPE_TIME - "java.sql.Time"
- DATA_TYPE_DATE - "java.sql.Date"
- DATA_TYPE_TIMESTAMP - "java.sql.Timestamp"
- DATA_TYPE_BIG_DECIMAL - "java.math.BigDecimal"
- DATA_TYPE_LONG_INTEGER - "Long"
- DATA_TYPE_BINARY - "byte[]"
- DATA_TYPE_CLOB - "Clob"
- DATA_TYPE_BLOB - "Blob"
- DATA_TYPE_ARRAY - "Array"
- DATA_TYPE_STRUCT - "Struct"
- DATA_TYPE_REF - "Ref"
BaseCollaboration
Collaboration/
- BaseCollaboration(com.ibm.bpe.api.ProcessInstanceData)
- AnyException - "AnyException"
- AppBusObjDoesNotExist - "BusObjDoesNotExist"
- AppLogOnFailure - "AppLogOnFailure"
- AppMultipleHits - "AppMultipleHits"
- AppRequestNotYetSent - "AppRequestNotYetSent"
- AppRetrieveByContentFailed - "AppRetrieveByContent"
- AppTimeOut - "AppTimeOut"
- AppUnknown - "AppUnknown"
- AttributeException - "AttributeException"
- existsConfigProperty(String):boolean
- getConfigProperty(String):String
- getConfigPropertyArray(String):String[]
- getCurrentLoopIndex():int
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection getLocale():java.util.Locale
- getMessage(int):String
- getMessage(int, Object[]):String
- getName():String
- implicitDBTransactionBracketing():boolean
- isCallerInRole(String):boolean
- isTraceEnabled(int):boolean
- JavaException - "JavaException"
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- not(boolean):boolean ObjectException - "ObjectException"
- OperationException - "OperationException"
- raiseException(CollaborationException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- ServiceCallException - "ConsumerException"
- ServiceCallTransportException - "ServiceCallTransportException"
- SystemException - "SystemException"
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
- TransactionException - "TransactionException"
CxExecutionContext
CxCommon/
- CxExecutionContext()
- getContext(String):Object
- MAPCONTEXT - "MAPCONTEXT"
- setContext(String, Object)
CollaborationException
Collaboration/
- getMessage():String
- getMsgNumber():int
- getSubType():String
- getText():String
- getType():String
- toString():String
Filter
crossworlds/
com/
- Filter(BaseCollaboration)
- filterExcludes(String, String):boolean
- filterIncludes(String, String):boolean
- recurseFilter(BusObj, String, boolean, String, String):boolean
- recursePreReqs(String, Vector):int
Globals
crossworlds/
com/
- Globals(BaseCollaboration)
- callMap(String, BusObj):BusObj
SmartCollabService
crossworlds/
com/
- SmartCollabService()
- SmartCollabService(BaseCollaboration)
- doAgg(BusObj, String, String, String):BusObj
- doMergeHash(Vector, String, String):Vector
- doRecursiveAgg(BusObj, String, String, String):BusObj
- doRecursiveSplit(BusObj, String):Vector
- doRecursiveSplit(BusObj, String, boolean):Vector
- getKeyValues(BusObj, String):String
- merge(Vector, String):BusObj
- merge(Vector, String, BusObj):BusObj
- split(BusObj, String):Vector
StateManagement
crossworlds/
com/
- StateManagement()
- beginTransaction()
- commit()
- deleteBO(String, String, String)
- deleteState(String, String, String, int)
- persistBO(String, String, String, String, BusObj)
- recoverBO(String, String, String):BusObj
- releaseDBConnection()
- resetData()
- retrieveState(String, String, String, int):int
- saveState(String, String, String, String, int, int, double)
- setDBConnection(CwDBConnection)
- updateBO(String, String, String, String, BusObj)
- updateState(String, String, String, String, int, int)
EventKeyAttrDef
EventManagement/
CxCommon/
- EventKeyAttrDef()
- EventKeyAttrDef(String, String)
- public String keyName
- public String keyValue
EventQueryDef
EventManagement/
CxCommon/
- EventQueryDef()
- EventQueryDef(String, String, String, String, int)
- public String nameConnector
- public String nameCollaboration
- public String nameBusObj
- public String verb
- public int ownerType
FailedEventInfo
EventManagement/
CxCommon/
- FailedEventInfo()
- FailedEventInfo(String x6, int, EventKeyAttrDef[], int, int, String, String,
int)
- public String nameOwner
- public String nameConnector
- public String nameBusObj
- public String nameVerb
- public String strTime
- public String strMessage
- public int wipIndex
- public EventKeyAttrDef[] strbusObjKeys
- public int nKeys
- public int eventStatus
- public String expirationTime
- public String scenarioName
- public int scenarioState
Mapeando o WebSphere Process Sever DataObject a partir do WebSphere InterChange
Server XML
Se você utilizar Legacy Adapters para se conectar ao WebSphere Process
Server, o algoritmo a seguir permitirá que você entenda melhor como o WebSphere Process Sever DataObject foi criado a partir do WebSphere InterChange Server XML.
Estas informações mostram onde os valores de dados foram colocados e também quais valores de dados foram escolhidos para substituir aqueles utilizados no WebSphere InterChange
Server.
Geral
- Para a definição do verbo no ChangeSummary, todas as definições serão feitas com as APIs markCreate/Update/Delete.
- Para a definição do verbo no ChangeSummary/EventSummary, os verbos Create, Update, e Delete serão definidos no ChangeSummary, enquanto todos os outros verbos serão definidos no EventSummary.
- Para obter o verbo a partir do ChangeSummary:
- Para impedir que um DataObject seja identificado como Create ao invés de Update, conforme pretendido, se a criação de log estiver ativada, você deve:
- Suspender a criação de log durante a criação do DataObject.
- Recomeçar a criação de log para a atualização do DataObject (ou utilizar a API markUpdated).
Loading
Loading irá carregar uma XML de tempo de execução do WebSphere InterChange Server em uma instância do WebSphere Business Integration BusinessGraph AfterImage.
- Uma instância do BusinessGraph apropriado será criada.
- A Criação de Log de ChangeSummary será ativada, para que sua ativação posterior não limpe as entradas.
- A Criação de Log de ChangeSummary será pausada para impedir que informações não desejadas sejam incluídas no ChangeSummary.
- Os atributos de primeiro nível do BusinessObject serão criados no DataObject (consulte a seção "Processamento de Atributos" abaixo).
- Se o BusinessObject de primeiro nível tiver BusinessObjects filhos, eles serão processados recursivamente.
- Os atributos destes BusinessObjects filhos serão criados no DataObject (consulte a seção "Processamento de Atributos" abaixo).
- O verbo do BusinessObject de primeiro nível será definido no verbo de primeiro nível do BusinessGraph e definido nos resumos.
- O verbo dos BusinessObjects filhos será definido nos resumos.
Saving
Saving irá salvar uma instância do WebSphere Business
Integration BusinessGraph AfterImage em um XML de tempo de execução WebSphere InterChange Server.
Uma exceção será emitida se o BusinessGraph de entrada não for AfterImage.
Processamendo de Atributos
- Todos os valores não apresentados abaixo serão carregados/salvos ASIS.
- ObjectEventId será carregado/salvo a partir do EventSummary.
- Para CxBlank e CxIgnore:
- No lado do WebSphere Business Integration BusinessObject da conversão, CxBlank e CxIgnore
serão definidos/identificados da seguinte forma:
- CxIgnore - não definido ou definido com o valor Java null
- CxBlank - valor dependente do tipo conforme mostrado na tabela abaixo
- No lado XML do WebSphere InterChange
Server da conversão, CxBlank e CxIgnore serão definidos/identificados da seguinte forma:
Tabela 1. Definindo CxBlank e CxIgnore
Tipo |
CxIgnore |
CxBlank |
Int |
Integer.MIN_VALUE |
Integer.MAX_VALUE |
Float |
Float.MIN_VALUE |
Float.MAX_VALUE |
Double |
Double.MIN_VALUE |
Double.MAX_VALUE |
String/date/longtext |
"CxIgnore" |
"" |
Children BusinessObjects |
(elemento vazio) |
N/D |
Capítulo 4. Migrando para o WebSphere Integration Developer a partir do WebSphere MQ
Workflow
O WebSphere Integration
Developer fornece as ferramentas necessárias para migrar do WebSphere MQ Workflow.
O Assistente de Migração permite converter definições FDL de processos de negócios exportados do componente build time do WebSphere MQ Workflow em artefatos correspondentes no WebSphere Integration Developer. Os artefatos gerados incluem definições de esquema XML para objetos de negócios, definições WSDL, BPEL, definições de importação e de componente e definições TEL.
A ferramenta de conversão requer uma definição FDL semanticamente completa
de um modelo de processo exportado do WebSphere MQ Workflow build time com a opção export deep. Esta opção assegura que todas as
especificações de dados necessários, de programa e de subprocesso estejam incluídas. Além disso, certifique-se
de que qualquer definição do UPES (User Defined Process Execution Server) referida no
modelo de processo do WebSphere MQ Workflow também seja selecionada quando o FDL for exportado do WebSphere MQ Workflow build time.
Nota: O Assistente de Migração não cobre a migração de:
- Instâncias de tempo de execução do WebSphere MQ
Workflow
- Aplicativos de programa que são chamados por um PEA (Program Execution Agent) do WebSphere MQ Workflow
ou PES do WebSphere MQ
Workflow (Process Execution Server para z/OS)
Para obter informações adicionais sobre migração utilizando a ferramenta de conversão FDL2BPEL, consulte o WebSphere MQ Workflow Support Site.
Antes de migrar para o WebSphere Integration Developer do WebSphere MQ
Workflow, primeiro é necessário assegurar que você tenha preparado corretamente seu ambiente.
O escopo e totalidade do mapeamento depende do grau de conformidade
com as seguintes instruções para migração:
- Certifique-se de que as atividades do programa FDL estejam associadas a um UPES (User Defined Process Execution Server) se elas não forem atividades de equipe puras.
- Certifique-se de que as designações de equipe para as atividades do programa WebSphere MQ Workflow
sejam compatíveis com os verbos de equipe padrão do TEL.
- Utilize nomes abreviados e simples para aprimorar a capacidade de leitura
de modelos de processos migrados. Observe que os nomes de FDL podem ser nomes de BPEL inválidos. O Assistente de Migração converte automaticamente nomes de FDL em nomes de BPEL válidos.
O Assistente de Migração produzirá construções do editor de processo de negócios sintaticamente corretas
mesmo para construções do WebSphere MQ Workflow que não podem ser migradas
(atividades do programa PEA ou PES, algumas designações de equipe dinâmicas e
outros), que precisam ser adaptadas manualmente para artefatos do editor de processo de negócios executáveis.
A tabela a seguir esboça as regras de mapeamento aplicadas:
Tabela 2. Regras de Mapeamento
WebSphere MQ Workflow |
WebSphere Integration Developer |
Processo |
Processo com modo de execução: longRunning; Links
do parceiro para interfaces de processo de entrada e de saída |
Origem e Depósito |
Variáveis para entrada e saída de processo; atividade de Recebimento
e atividade de resposta |
Atividade do programa |
Atividade de chamada |
Atividade do processo |
Atividade de chamada |
Atividade vazia |
Atividade de FMCINTERNALNOOP |
Bloquear |
Escopo com atividades de BPEL incorporadas |
Condição de saída de atividade |
Atividade While (incluindo a atividade real) |
Condição inicial de atividade |
Condição de junção da atividade |
Designação de equipe de atividade |
Atividade de tarefa manual |
Contêiner de entrada e de saída de atividade |
Variáveis utilizadas para especificar a entrada/saída da atividade chamada |
Conector de controle; Condição de transição |
Link; Condição de transição |
Conector de dados |
Atividade de designação |
Contexto de dados global |
Variável |
Nota: Inicialmente, você deve tentar o processo de migração com pequenos projetos, se
possível. O Assistente de Migração simplificará a conversão dos modelos de processos do WebSphere MQ
Workflow em modelos de processos do editor de processos de negócios, mas
é necessário estar ciente de que os processos não podem ser mapeados um para um, pois
você está criando um novo modelo de programação. Os escopos semânticos das linguagens de especificação de processos subjacentes
(FDL e BPEL) compartilham uma área de interseção, mas não se sobrepõem
no total. Caso contrário, não será possível esperar novos benefícios
do editor de processos de negócios. Os serviços da Web representam uma nova tecnologia
promissora que requer a substituição de soluções reprovadas por novas.
Em geral,
você deve sempre rever e, possivelmente, modificar os artefatos gerados. Pode ser necessário
esforço adicional para possibilitar uma migração bem-sucedida
ou para concluir a tarefa de migração.
Migrando o WebSphere MQ Workflow Utilizando o Assistente de Migração
O Assistente de Migração permite converter definições FDL de processos de negócios exportados do componente build time do WebSphere MQ Workflow em artefatos correspondentes no WebSphere Integration Developer. Os artefatos gerados incluem definições de esquema XML para objetos de negócios, definições WSDL, BPEL, definições de importação e de componente e definições TEL.
Nota: O Assistente de Migração não cobre a migração de:
- Instâncias de tempo de execução do WebSphere MQ
Workflow
- Aplicativos de programa que são chamados por um PEA (Program Execution Agent) do WebSphere MQ Workflow
ou PES do WebSphere MQ
Workflow (Process Execution Server para z/OS)
Para utilizar o Assistente de Migração para migrar os artefatos do WebSphere MQ Workflow, siga estas etapas:
- Chame o assistente selecionando
Arquivo (File) -> Importar (Import) -> Integração
de Negócios (Business Integration) -> WebSphere
MQ Workflow FDL File e clique em
Avançar (Next):
OU você também pode abrir o assistente de
Migração da página Bem-vindo (Welcome) clicando no ícone
Retornando Usuários (Returning Users)
para abrir a página
Retornando Usuários (Returning Users) (observe que você sempre pode retornar à pagina
Bem-vindo (Welcome) clicando em
Ajuda (Help) -> Bem-vindo (Welcome)
):
Clique em
Migração (Migration) à esquerda da página Retornando
Usuários (Returning Users) para abrir a página Migração (Migration).
Na página Migração (Migration), selecione a opção Migrar um processo do
WebSphere MQ Workflow (Migrate a WebSphere MQ Workflow process)
.
- É aberto o Assistente de Migração (Migration). Digite o caminho absoluto e o nome do arquivo FDL no campo Seleção de Origem (Source selection) ou selecione um do sistema de arquivos clicando no botão Procurar (Browse) e navegando até o arquivo. Digite o nome do módulo no campo relevante (é necessário digitar um nome de módulo no campo Nome do Módulo (Module name) para poder prosseguir). Clique em Avançar (Next):
- É aberta a página Opções de Migração. Nesta página é possível aceitar
os padrões de migração ou selecionar uma caixa de opções para alterar a opção. Selecionando
a caixa de opções Tratar conflitos de nomes como erros (Treat name conflicts as errors), você pode
evitar a inclusão automática de sufixos que pode resultar em erros de
interoperabilidade. A caixa de opção Inicializar
membros de dados predefinidos (Initialize predefined data members) inclui nós extra para o
processo para inicializar os membros de dados predefinidos:
- Clique em Concluir (Finish).
Uma barra de progresso na parte inferior do diálogo de
migração indica o progresso da migração.
Uma vez concluído o processo de migração, o diálogo de migração
desaparece e a janela Resultados da Migração (Migration Results) é exibida:
Verificando a Migração do WebSphere MQ Workflow
Se a migração for concluída com uma lista de mensagens de erro, aviso e/ou informativas, elas serão exibidas na janela Resultados da Migração (Migration Results).
Caso contrário, a janela do assistente será fechada se a migração foi concluída com êxito.
A página a seguir aparece se tiverem sido geradas mensagens de migração durante o processo de migração:
A janela Resultados da Migração (Migration Results) lista as mensagens de migração geradas durante o processo de migração.
Selecionando uma mensagem da lista Mensagens (Message) superior, é possível localizar informações adicionais em relação a essa mensagem na janela Descrição de Mensagem (Message Description) inferior.
Para guardar todas as mensagens para futuras consultas, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização de tarefa e/ou clique no botão Salvar como... (Save as...) para salvar as mensagens em um arquivo de texto no sistema de arquivos.
Para ver a lista A Fazer gerada, clique em
Janela -> Mostrar
Visualização -> Outra... -> Geral -> Tarefas
e clique em OK.
A visualização de Tarefas é aberta com a lista de A Fazer gerada a
partir do processo de migração.
Limitações do Processo de Migração (do WebSphere MQ Workflow)
Existem algumas limitações envolvidas no processo de migração do WebSphere MQ
Workflow.
- A migração do FDL gerará atividades de chamada para atividades UPES e os WSDLs correspondentes. No entanto, o ambiente de tempo de execução difere significativamente entre o IBM WebSphere MQ
Workflow e o IBM WebSphere Process
Server em termos das técnicas que são utilizadas para correlacionar mensagens de chamada e suas respostas.
- Os mecanismos de tempo de execução doIBM WebSphere MQ Workflow e do IBM WebSphere Process Server manipulam dados não inicializados de maneiras diferentes. Enquanto no IBM WebSphere MQ Workflow isso não causava erros, o IBM WebSphere Process Server trata dessa situação com uma exceção e pára de executar o processo. Para executar corretamente aplicativos migrados no IBM WebSphere Process Server, assegure-se de que todas as variáveis e subestruturas sejam inicializadas antes de serem utilizadas com atividades Designar, Chamar, Equipe e Responder .
Capítulo 5. Migrando Artefatos de Origem para o WebSphere Integration Developer do WebSphere Studio
Application Developer Integration Edition
Os artefatos de origem podem ser migrados do WebSphere Studio Application Developer
Integration Edition para o WebSphere Integration Developer. Migrar os artefatos de origem em um aplicativo inclui migrá-los para o novo modelo de programação do WebSphere Integration Developer para que a nova funcionalidade e recursos possam ser utilizados. O aplicativo pode então ser reimplementado e instalado no WebSphere Process Server.
Muitos recursos disponíveis no WebSphere Business Integration Server Foundation 5.1 foram movidos para o WebSphere Application Server 6.x base.
Consulte este tópico para obter dicas de migração desses recursos: Dicas para migração de extensões de modelo de programação.
Para migrar totalmente um projeto de serviço do WebSphere Studio Application Developer Integration Edition existem três etapas fundamentais a serem concluídas:
- Preparação dos artefatos de origem para a migração. Pode ser necessário executar essas ações no WebSphere Studio Application Developer Integration Edition.
- Utilize o assistente de Migração ou o script de linha de
comandos WSADIEServiceProjectMigration para migrar
automaticamente os artefatos para o projeto do Business Integration
Module.
- Utilize o WebSphere Integration
Developer para completar manualmente a migração. Isso envolve corrigir qualquer código Java que não pôde ser migrado automaticamente e verificar a ligação dos artefatos migrados.
Nota: A migração do tempo de execução (caminho de upgrade) não será fornecida no
WebSphere Process
Server 6.x, portanto esse caminho de migração do artefato de origem será a única opção para migrar projetos de serviço do WebSphere Studio Integration Edition na 6.x.
Antes de iniciar a migração de artefatos de origem
do WebSphere Studio
Application Developer Integration Edition, é necessário rever os caminhos de migração
suportados pelo WebSphere Integration Developer.
O assistente de Migração oferece a capacidade de migrar um projeto de serviço do WebSphere Studio
Application Developer Integration Edition Versão 5.1 (ou superior)
de cada vez. Ele não migrará um espaço de trabalho inteiro.
O assistente de Migração não migra binários de aplicativos - ele migra apenas
artefatos de origem localizados em um projeto de serviço do WebSphere Studio Application Developer Integration Edition.
Antes de migrar artefatos de origem para o WebSphere Integration Developer do WebSphere Studio
Application Developer Integration Edition, primeiro, certifique-se de que
tenha preparado corretamente seu ambiente.
As etapas a seguir descrevem como preparar seu ambiente antes de migrar
artefatos de origem para o WebSphere Integration Developer do WebSphere Studio
Application Developer Integration Edition:
- Certifique-se de ter uma cópia de backup do espaço de trabalho inteiro da 5.1 antes de tentar migrar.
- Reveja a seção de migração do Centro de Informações do Rational Application Developer para determinar a melhor maneira de migrar os projetos não específicos do WBI em seu espaço de trabalho:Migrating from WebSphere Studio V5.1, 5.1.1, or 5.1.2
- Reveja a seção de serviço da Web do Centro de Informações do Rational Application Developer para obter informações básicas sobre a funcionalidade de serviço da Web fornecida pelo Rational Application Developer: Developing Web services
- Certifique-se de que todos os recursos adequados do WebSphere Integration Developer estejam ativados. Se esses recursos não estiverem ativados, você não poderá ver as opções de menu que serão discutidas abaixo. Para ativar os recursos importantes:
- No WebSphere Integration
Developer, vá para o item de menu Janela e selecione Preferências.
- Vá para Workbench e, em seguida, selecione a categoria Recursos.
- Selecione todos os recursos nas seguintes categorias:
- J2EE Avançado
- Enterprise Java
- Desenvolvedor de Integração
- Java Developer
- Web Developer (típico)
- Web Service Developer
- XML Developer
- Clique OK.
- Utilize um novo diretório de espaço de trabalho para o WebSphere Integration Developer. Não
é recomendável abrir o WebSphere Integration Developer em um espaço de
trabalho antigo do WebSphere Studio
Application Developer Integration Edition que contenha projetos de serviço,
pois esses projetos primeiro devem ser migrados para um formato que possa ser
lido pelo WebSphere Integration
Developer. As etapas recomendadas para isso são:
- Copie todos os projetos não de serviço do espaço de trabalho antigo
para o novo. Não copie os projetos EJB, da Web e EAR 5.1 criados
durante a geração do código de implementação para um projeto de serviço 5.1. O novo código de implementação da 6.x
será gerado outra vez automaticamente quando o módulo BI for construído.
- Abra o WebSphere Integration
Developer no espaço de trabalho vazio e importe todos os projetos que não sejam de serviço clicando em Arquivo -> Importar -> Geral -> Projeto Existente para o Espaço de Trabalho e selecione os projetos copiados para o novo espaço de trabalho.
- Se o projeto for um projeto J2EE, então, você deverá migrá-lo para o nível 1.4 utilizando o assistente Rational Application Developer Migration:
- Clique com o botão direito do mouse no projeto e selecione Migração -> Assistente de Migração do J2EE....
- Reveja as instruções de aviso na primeira página e, a menos que seja indicado de outra maneira, clique em Avançar.
- Certifique-se de que o Projeto J2EE esteja marcado na lista Projetos. Deixe marcados Migrar estrutura do projeto e Migrar nível de especificação do J2EE. Escolha
J2EE versão 1.4 e WebSphere Process
Server v6.1 do Servidor de Destino.
- Selecione quaisquer outras opções que possam ser adequadas para seu projeto J2EE e clique em Concluir. Se essa etapa for concluída com êxito, você verá uma mensagem Migração concluída com êxito.
- Se houver erros no projeto J2EE após a migração, você deverá remover todas as entradas do caminho de classe que se referem aos arquivos .jar ou bibliotecas da v5 e incluir a Biblioteca do Sistema JRE e as bibliotecas de Destino do Servidor WPS no caminho de classe (discutido abaixo). Isso deverá remover a maioria dos erros ou todos.
- Para projetos EJB do WebSphere Business Integration com Extended Messaging (CMM) ou CMP/A (Container Managed Persistence over Anything), os arquivos do descritor de Extensão Jar EJB da IBM devem ser migrados depois da importação do projeto da 5.1 para o espaço de trabalho da 6.x.
Consulte "Migrando Projetos EJB do WebSphere Business Integration" para obter informações adicionais.
- Corrija o caminho de classe para cada projeto não de serviço importado
no espaço de trabalho. Para incluir as bibliotecas do JRE e do WebSphere Process Server no caminho de classe, clique com o botão
direito do mouse no projeto importado e selecione Propriedades.
Vá para
a entrada Caminho de Construção Java e selecione a guia Bibliotecas.
Então, faça o seguinte:
- Selecione Incluir
biblioteca -> Biblioteca do Sistema
JRE -> Alternar JRE - WPS Server v6.1
JRE -> Concluir.
- Em seguida, selecione Incluir Biblioteca -> Destino do Servidor WPS -> Configurar Caminho de Classe do Servidor wps -> Concluir.
- Por padrão, o WebSphere Integration Developer gera o código de implementação durante o tempo de construção.
- Para migrar totalmente os arquivos .bpel em um projeto de serviço,
é necessário assegurar que todos os arquivos .wsdl e .xsd referidos pelos arquivos .bpel
possam ser resolvidos em um projeto de integração de negócios no novo espaço de trabalho:
- Se os arquivos .wsdl e/ou .xsd estiverem no mesmo projeto de serviço
que o arquivo .bpel, nenhuma ação adicional será requerida.
- Se os arquivos .wsdl e/ou .xsd estiverem em um projeto de serviço diferente daquele que você está migrando, os artefatos da 5.1 deverão ser reorganizados utilizando o WebSphere Studio
Application Developer Integration Edition antes da migração. A razão para isso é que os projetos de Módulo do Business Integration podem não compartilhar artefatos.
A seguir estão as duas opções para reorganizar os artefatos da 5.1:
- No WebSphere Studio
Application Developer Integration Edition, crie um novo projeto Java que mantenha todos os artefatos comuns. Coloque todos os arquivos .wsdl e .xsd compartilhados por mais de um projeto de serviço nesse novo projeto Java. Inclua uma dependência nesse novo projeto Java para todos os projetos de serviço que utilizam esses artefatos comuns. No WebSphere Integration Developer, crie um novo projeto de Biblioteca do Business Integration com o mesmo nome do projeto Java compartilhado da 5.1 antes de migrar qualquer um dos projetos de serviço. Copie manualmente os arquivos .wsdl
e .xsd antigos do projeto Java compartilhado da 5.1 para esta nova pasta de projetos da Biblioteca de BI.
Isso deve ser feito antes da migração dos projetos de serviço do BPEL.
- Outra opção é manter
uma cópia local desses artefatos .wsdl e .xsd compartilhados em cada projeto de serviço de forma que não existam dependências entre projetos de serviço.
- Se os arquivos .wsdl e/ou .xsd estiverem em qualquer outro tipo de projeto (geralmente outros Projetos Java), será necessário criar um projeto de Biblioteca de Business Integration com o mesmo nome que o projeto 5.1. Você também deve configurar o caminho de classe do novo projeto de biblioteca, incluindo as entradas do projeto Java 5.1, se houver. Este tipo de projeto é útil para armazenar artefatos compartilhados.
Agora você está pronto para iniciar o processo de migração.
Considerações para o Processo de Migração de Artefatos de Origem
Existem diversas considerações para o processo de migração de artefatos de origem do WebSphere Studio
Application Developer Integration Edition.
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.x.
- Utilize o estilo WSDL doc-literal, pois este é o estilo preferido na 6.x.
- 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.x 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.x, 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.x, 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.x. Uma ligação posterior de oferta da interface MDB não estará disponível na 6.x.
- 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 6.x.
- 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.x, 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 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 6.x. No WebSphere Process Server 6.x, duas definições diferentes de
WSDL/XSD que têm o mesmo nome e o 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.x essas limitações são estritamente aplicadas.
Migrando Projetos de Serviço Utilizando o Assistente de Migração do WebSphere Integration Developer
O Assistente de Migração do WebSphere Integration
Developer permite a migração de projetos de serviço.
Nota:
- É necessário migrar os projetos de serviço na ordem de dependência. Por exemplo,
se um BPEL no projeto de serviço A efetuar uma chamada processo a processo para um BPEL no projeto de serviço B, então, o projeto de serviço B deve ser migrado antes do projeto de serviço A. Caso contrário, a chamada processo a processo não poderá ser configurada corretamente.
- Não é necessário desativar a auto-construção no WebSphere Integration Developer Migration 6.0.2 e posterior, já que a auto-construção é desligada automaticamente durante o processo de migração.
O Assistente de Migração faz o seguinte:
- Cria um novo módulo de integração de negócios (o nome do módulo é definido por você)
- Migra as entradas de caminho de classe do projeto de serviço para o novo módulo
- Copia todos os artefatos de origem do WebSphere Business
Integration Server Foundation do projeto de origem selecionado
para este módulo
- Migra as extensões de BPEL em arquivos WSDL
- Migra os processos de negócios (arquivos .bpel) do BPEL4WS versão 1.1 para o novo nível suportado pelo WebSphere Process Server, construído no BPEL4WS versão 1.1 com recursos importantes da especificação de lançamento do WS-BPEL versão 2.0
- Cria um componente SCA para cada processo .bpel
- Gera um arquivo de monitoramento .mon para cada processo BPEL para preservar
o comportamento de monitoramento padrão do WebSphere Studio Application Developer
Integration Edition (se necessário)
- Cria importações e exportações conforme as opções de implementação escolhidas no WebSphere Studio Application Developer Integration Edition
- Liga o componente BPEL aos seus links associados (importações, exportações e componentes Java)
Para migrar projetos de serviço utilizando o Assistente de Migração do WebSphere Integration Developer, siga estas etapas:
- Chame o assistente selecionando
Arquivo (File) -> Importar (Import) -> Integração
de Negócios (Business Integration) -> Projeto de Serviço do WebSphere
Studio Application Developer Integration
Edition (WebSphere
Studio Application Developer Integration Edition Service Project) e clique em
Avançar (Next):
OU você também pode abrir o assistente
para Migração da página Bem-vindo (Welcome) clicando no ícone
Retornando Usuários (Returning users)
para abrir a página Retornando
Usuários (Returning users) (Observe que você sempre pode retornar á página Bem-vindo (Welcome)
clicando em
Ajuda (Help) -> Bem-vindo (Welcome) ):
Clique
Migração (Migration) à esquerda da página Retornando
usuários (Returning users) para abrir a página Migração (Migration).
Na página Migração (Migration), selecione a opção Migrar um projeto
de serviço do Integration Edition 5.1 (Migrate an Integration Edition 5.1
service projec)
.
- É aberto o Assistente de Migração (Migration). Digite o caminho para a Seleção de Origem (Source Selection) ou clique no botão Procurar (Browse) para localizá-lo. Digite também o nome do Módulo (Module name) do local do Projeto de Serviço do WebSphere Studio Application Developer
Integration Edition que irá migrar:
Nota:
É recomendado que você escolha o nome do Projeto de Serviço como o nome do módulo, porque se houver outros projetos no espaço de trabalho do WebSphere Studio Application Developer
Integration Edition que são dependentes desse projeto, você não terá de atualizar os caminhos de classe dos projetos dependentes depois de importá-los para o WebSphere Integration Developer.
- Nas Opções de Migração, selecione a caixa de opção Preservar snippets Java do BPEL originais nos comentários (Preserve original BPEL Java snippets in the comments):
Clique em Concluir (Finish).
- Depois do processo de migração ser concluído, a janela Resultados da Migração (Migration Results) é aberta:
Um arquivo de log contendo essas mensagens de migração será automaticamente gerado para a pasta .metadata do espaço de trabalho da 6.x. O arquivo de log deve ser nomeado ".log".
Após a conclusão do Assistente de Migração, construa o módulo de Business Integration
criado e tente resolver erros de construção. Inspecione todos os arquivos
.bpel migrados: certifique-se de que eles tenham sido totalmente migrados e possam ser abertos
no Editor BPEL do WebSphere Integration
Developer. Existem alguns snippets Java de BPEL que não podem ser automaticamente
migrados. Se você vir erros nos snippets Java do BPEL, consulte "Migrando para o Modelo de Programação SCA" para obter as etapas necessárias para corrigir os erros. Além disso, se você tiver utilizado o Assistente de Migração para migrar um projeto de serviço
para um Módulo de BI, abra o editor de dependências de módulo para assegurar que as dependências
estejam configuradas corretamente. Para isso, vá para a perspectiva Business Integration
e dê um clique duplo no projeto do módulo da integração de negócios. Lá você pode incluir dependências em projetos de biblioteca de integração de negócios, em projetos Java e em projetos J2EE.
Migrando Projetos de Serviço Utilizando WSADIEServiceProjectMigration
O comando WSADIEServiceProjectMigration permite a migração de projetos de serviço.
O comando de migração faz o seguinte:
- Cria um novo módulo de integração de negócios (o nome do módulo é definido por você)
- Migra as entradas de caminho de classe do projeto de serviço para o novo módulo
- Copia todos os artefatos de origem do WebSphere Business
Integration Server Foundation do projeto de origem selecionado
para este módulo
- Migra as extensões de BPEL em arquivos WSDL
- Migra os processos de negócios (arquivos .bpel) do BPEL4WS versão 1.1 para o novo nível suportado pelo WebSphere Process Server, construído no BPEL4WS versão 1.1 com recursos importantes da especificação de lançamento do WS-BPEL versão 2.0
- Cria um componente SCA para cada processo .bpel
- Gera um arquivo de monitoramento .mon para cada processo BPEL para preservar
o comportamento de monitoramento padrão do WebSphere Studio Application Developer
Integration Edition (se necessário)
- Cria importações e exportações conforme as opções de implementação escolhidas no WebSphere Studio Application Developer Integration Edition
- Liga o componente BPEL aos seus links associados (importações, exportações e componentes Java)
Nota: É necessário migrar os projetos de serviço na ordem de dependência. Por exemplo,
se um BPEL no projeto de serviço A efetuar uma chamada processo a processo para um BPEL no projeto de serviço B, então o projeto de serviço B deve ser migrado antes do projeto de serviço A. Caso contrário, a chamada processo a processo não poderá ser configurada corretamente.
Para executar o script WSADIEServiceProjectMigration, siga estas etapas:
- Localize o scipt abrindo a pasta compartilhada especificada durante a instalação do WebSphere Integration
Developer. Por exemplo, o script será localizado abaixo do: SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0
- Chame o script como a seguir: WSADIEServiceProjectMigration
-e eclipse_dir -s source_project_dir -d workspace [-t target_project_name]
[-preserveSnippets true|false] [-debug]
Definições de Parâmetro:
- -e eclipse_dir
- O local de sua pasta Eclipse (Tempo de execução de Eclipse).
- -s source_project_dir
- O caminho completo para o projeto de serviço do WebSphere Studio Application Developer Integration Edition 5.1.
- -d workspace
- O espaço de trabalho onde o novo módulo de integração de negócios será criado.
- -t target_project_name
- O nome do novo módulo de integração de negócios a ser criado. O padrão é o mesmo para o projeto do WebSphere Studio Application Developer Integration
Edition 5.1 que está sendo migrado.
- -preserveSnippets flag
- Ativa ou desativa a preservação de snippets existentes de Java do BPEL conforme assinalado como comentário. O padrão é true.
- -debug flag
- Ativa a saída de depuração.
Por exemplo:
WSADIEServiceProjectMigration -e WID_HOME\eclipse" -d "\myWIDworkspace" -s "\\MyServiceProject" -t "MyBIModuleName" -preserveSnippets false -debug
- Após a conclusão do comando, inicie o novo espaço de trabalho no WebSphere Integration
Developer.
- Construa o módulo de Business Integration criado e tente resolver quaisquer erros de construção. Inspecione todos os arquivos
.bpel migrados: certifique-se de que eles tenham sido totalmente migrados e possam ser abertos
no Editor BPEL do WebSphere Integration
Developer. Existem alguns snippets Java de BPEL que não podem ser automaticamente
migrados. Se você vir erros nos snippets Java do BPEL, consulte "Migrando para o Modelo de Programação SCA para obter as etapas necessárias para corrigir os erros.
- Abra o editor de dependências de módulo para assegurar que as dependências
estejam configuradas corretamente. Para isso, vá para a perspectiva de integração de negócios
e dê um clique duplo no projeto do módulo de integração de negócios. Lá você pode incluir dependências em projetos de biblioteca de integração de negócios, em projetos Java e em projetos J2EE.
Completando a Migração de Aplicativo
Quando o Assistente de Migração tiver migrado com êxito os artefatos
para o novo módulo de Business Integration, os artefatos deverão ser ligados
para criar um aplicativo que esteja de acordo com o modelo SCA. Observe que embora o Assistente de Migração tente migrar os artefatos com êxito, também deve ser feita a verificação manual. As informações desta seção podem ser utilizada para ajudar a assegurar que a migração tenha sido correta.
- Abra o WebSphere Integration
Developer e vá para a perspectiva Business Integration. Devem aparecer os módulos
que foram criados pelo Assistente de Migração (um módulo para
cada projeto de serviço migrado). O primeiro artefato listado
no projeto do módulo é o arquivo de montagem do módulo (ele tem o mesmo nome
que o módulo).
- Dê um clique duplo no arquivo de montagem para abri-lo no Editor de Montagem no qual os componentes
SCA podem ser criados e ligados para obter uma funcionalidade semelhante
à do aplicativo da Versão 5.1. Se houver processos BPEL no projeto de serviço do WebSphere Studio
Application Developer Integration Edition, o assistente de migração
deve ter criado componentes SCA padrão para cada um desses processos e
eles estarão no Editor de Montagem.
- Selecione um componente e vá para a visualização Propriedades na qual as propriedades de Descrição,
Detalhes e Implementação serão exibidas e podem ser editadas.
Alguns projetos podem precisar de alguma religação após a migração para reconectar os serviços na forma em que estavam na 5.1. As informações a seguir descrevem mais detalhadamente como religar manualmente o aplicativo utilizando as ferramentas disponíveis no WebSphere Integration Developer:
Criando Componentes do SCA e Importações do SCA para os Serviços no Aplicativo de Religação
Todos os processos de negócios migrados devem ser ligados para seus parceiros de negócios. Um Componente ou Importação do SCA deve ser criado para todos os outros tipos de serviço. Para os projetos de serviço do WebSphere Studio Application Developer Integration Edition que interagem com os sistemas ou entidades externos ao projeto, uma Importação do SCA pode ser criada para que o projeto migrado acesse essas entidades como serviços de acordo com o modelo SCA.
Nota: O utilitário de migração tenta fazer isso automaticamente; entretanto, você pode consultar as informações a seguir para ajudar a verificar o que a ferramenta fez.
Para os projetos de serviço do WebSphere Studio Application Developer Integration Edition que interajem com as entidades dentro projeto (por exemplo, um processo de negócios, um serviço de transformador ou uma classe Java), uma Importação do SCA pode ser criada para que o projeto migrado acesse essas entidades como serviços de acordo com o modelo SCA.
As seções a seguir fornecem detalhes sobre a Importação do SCA ou Componentes do SCA a serem criados com base no tipo de serviço que deve ser migrado:
Migrando um Serviço Java
Você pode migrar um serviço Java para um Componente Java do SCA.
Se o Projeto de Serviço do WebSphere Studio
Application Developer Integration Edition era dependente de outros projetos
Java,
copie os projetos existentes para o novo diretório de espaço de trabalho e importe-os
para o WebSphere Integration
Developer utilizando o assistente Arquivo -> Importar -> Geral -> Projeto Existente para o Espaço de Trabalho.
No WebSphere Studio
Application Developer Integration Edition, ao gerar um novo serviço Java
a partir de uma classe Java existente, as seguintes opções eram fornecidas:
- Criar esquemas XSD para tipos de dados complexos:
- No arquivo WSDL da interface
- Como um novo arquivo para cada tipo de dados
- Suportar capacidade de tratamento de erro:
- Gerar falha
- Não gerar falha
- Outros detalhes sobre o serviço a ser gerado, como nomes de ligação
e de serviço
Existem muitos componentes novos que oferecem nova funcionalidade, como mapeamento de dados, mediação de interface, máquinas de estado de negócios, seletores, regras de negócios e muito mais. Primeiro, você deve determinar se um desses novos tipos de componentes pode substituir o componente Java customizado. Se isso não for possível, siga o caminho de migração descrito abaixo.
Importe o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo de integração de negócios com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition.
Na perspectiva Business Integration, expanda o módulo para ver seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).
Você tem as seguintes opções:
Criando o Componente Java Customizado: Opção 1
A técnica de migração recomendada é utilizar o tipo Componente Java do WebSphere Integration
Developer que permite representar o serviço Java como um componente SCA. Durante a migração, o código Java customizado deve ser escrito para conversão entre o estilo de interface Java do SCA e o estilo de interface do componente Java existente.
Para criar o componente Java customizado, siga estas etapas:
- No projeto de módulo, expanda Interfaces e selecione a interface WSDL que foi gerada para essa classe Java no WebSphere Studio Application Developer Integration.
- Arraste e solte essa interface sobre o Editor de Montagem. Um diálogo aparecerá solicitando que você selecione o tipo de componente que irá criar. Selecione Componente sem Tipo de Implementação e clique em OK.
- Um componente genérico aparecerá no diagrama de Montagem. Selecione-o e vá para a visualização Propriedades.
- Na guia Descrição, você pode alterar o nome e o nome de exibição do componente para algo mais descritivo.
- Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
- Certifique-se de que a classe Java que você está tentando acessar esteja no caminho de classe do projeto de serviço, se ela não estiver contida dentro do próprio projeto de serviço.
- Clique com o botão direito no projeto e selecione Abrir Editor de Dependência.... Na seção Java, certifique-se de que o projeto que contém a classe Java antiga esteja listada. Se não estiver, inclua-o clicando em Incluir....
- De volta ao Editor de Montagem, clique com o botão direito do mouse no componente que acabou de criar e selecione Gerar Implementação... -> Java Em seguida, selecione o pacote no qual a implementação Java será gerada.
Isso cria um esqueleto do serviço Java que adere à interface WSDL de acordo com o modelo de programação SCA, no qual os tipos complexos são representados por um objeto que é um commonj.sdo.DataObject e os tipos simples são representados por equivalentes de seus Objetos Java.
Os seguintes exemplos de código mostram:
- Definições relevantes da interface WSDL 5.1.
- Os métodos WebSphere Studio Application Developer Integration Edition 5.1 Java que correspondem ao WSDL
- Os métodos WebSphere Integration Developer 6.x Java para o mesmo WSDL
O seguinte código mostra as definições relevantes da interface WSDL 5.1:
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://migr.practice.ibm.com/"
xmlns:xsd1="http://migr.practice.ibm.com/">
<complexType name="StockInfo">
<all>
<element name="index" type="int"/>
<element name="price" type="double"/>
<element name="symbol" nillable="true"
type="string"/>
</all>
</complexType>
</schema>
</types>
<message name="getStockInfoRequest">
<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
<part name="result" type="xsd1:StockInfo"/>
</message>
<operation name="getStockInfo" parameterOrder="symbol">
<input message="tns:getStockInfoRequest"
name="getStockInfoRequest"/>
<output message="tns:getStockInfoResponse"
name="getStockInfoResponse"/>
</operation>
O seguinte código mostra os métodos WebSphere Studio Application Developer Integration Edition 5.1 Java que correspondem ao WSDL:
public StockInfo getStockInfo(String symbol)
{
return new StockInfo();
}
public void setStockPrice(String symbol, float newPrice)
{
// definir algumas coisas
}
O seguinte código mostra os métodos WebSphere Integration Developer 6.x Java para o mesmo WSDL:
public DataObject getStockInfo(String aString) {
//TODO Precisa ser implementado.
return null;
}
public void setStockPrice(String symbol, Float newPrice) {
//TODO Precisa ser implementado.
}
Agora, você precisará preencher o código no qual vê as tags "//TODO" na classe de implementação Java gerada. Existem duas opções:
- Mova a lógica da classe Java original para essa classe, adaptando-a para utilizar DataObjects.
- Essa será a opção recomendada se você tiver escolhido a abordagem de cima para baixo no WebSphere Studio
Application Developer Integration Edition e desejar que o componente Java lide com parâmetros DataObject. Esse retrabalho é necessário porque as classes Java geradas a partir de definições do WSDL no WebSphere Studio Application Developer
Integration Edition têm dependências do WSIF que devem ser eliminadas.
- Crie uma instância privada da classe Java antiga dentro dessa classe Java gerada e escreva código para:
- Converter todos os parâmetros da classe de implementação Java gerada em parâmetros que a classe
Java antiga espera.
- Chamar a instância privada da classe Java antiga com os parâmetros convertidos.
- Converter o valor de retorno da classe Java antiga para o tipo de valor de retorno declarado pelo método de implementação Java gerado.
- Essa opção é recomendada para cenários de consumo nos quais os proxies de serviço do WSIF devem ser consumidos pelos novos componentes Java de estilo da 6.x.
Depois de concluir uma das opções acima, você deverá religar o serviço Java. Não deve haver nenhuma referência, portanto, você precisa apenas religar a interface do componente Java:
- Se esse serviço for chamado por um processo de negócios no mesmo módulo, então, crie uma ligação da referência do processo de negócios adequada para essa interface do componente Java.
- Se esse serviço for chamado por um processo de negócios em outro módulo, crie uma Exportação com Ligação SCA e, a partir do outro módulo, arraste e solte essa exportação no Editor de Montagem desse módulo para criar a Importação com Ligação SCA correspondente. Ligue a referência do processo de negócios adequada àquela Importação.
- Se esse serviço tiver sido publicado no WebSphere Studio
Application Developer Integration Edition para expô-lo externamente, então, consulte a seção "Criando Exportações do SCA para Acessar o Serviço Migrado" para obter instruções sobre como publicar novamente o serviço.
Criando um Serviço da Web Java: Opção 2
Uma opção alternativa a considerar é a ferramenta de serviços da Web do Rational Application Developer que permite criar um serviço da Web em torno de uma classe Java.
Nota: Esta opção requer que o tempo de execução de um serviço da Web seja configurado através do WebSphere Integration
Developer antes de chamar o assistente de serviço da Web.
Se você tiver utilizado uma abordagem de baixo para cima no WebSphere Studio Application Developer
Integration Edition para gerar WSDL em torno da classe Java, então, siga estas etapas:
- Crie um novo projeto da Web e copie a classe Java em torno da qual gostaria de construir um serviço para a pasta de origem Java desse projeto da Web.
- Clique com o botão direito do mouse no projeto do aplicativo corporativo que é o contêiner para a classe Java em torno do qual você está criando um serviço.
- Selecione Propriedades, vá para as
propriedades do Servidor e certifique-se de
que Tempo de execução de destino esteja
definido para WebSphere Process Server v6.1 e
Servidor padrão esteja definido para o
WebSphere Process Server v6.1 instalado.
- Inicie o servidor de teste e implemente seu aplicativo para o servidor e certifique-se de que ele seja iniciado com êxito.
- Em seguida, clique com o botão direito do mouse na classe Java em torno da qual gostaria de criar um serviço e selecione Serviços da Web -> Criar serviço da Web.
- Para Tipo de Serviço da Web, selecione Serviço da Web Java bean e desmarque a opção Iniciar serviço da Web no projeto da Web a menos que deseje implementar o serviço da Web diretamente. Você também pode opcionalmente selecionar a geração de um proxy de cliente. Clique em Avançar.
- A classe Java na qual você clicou com o botão direito do mouse será mostrada, clique em Avançar.
- Agora você deve configurar as opções de implementação de serviço. Clique
em Editar....
Para o tipo de servidor, escolha WPS Server
v6.1 e para o tempo de execução do serviço da Web escolha
IBM WebSphere e J2EE versão
1.4. Se você não puder selecionar uma
combinação válida fazendo isso, consulte a seção "Preparando para
Migração" para obter informações sobre como migrar projetos J2EE
para o nível v1.4. Clique OK.
- Para o projeto Serviço, digite o nome do projeto da Web. Selecione também
o projeto EAR apropriado. Clique em Avançar. Observe que você poderá precisar esperar vários minutos.
- No painel Identidade do Java Bean de Serviço da Web, selecione o arquivo WSDL que conterá as definições do WSDL. Escolha os métodos que gostaria de expor no serviço da Web e escolha o estilo/codificação adequados (Document/Literal, RPC/Literal ou RPC/Encoded). Selecione a opção Definir
Mapeamento Customizado do Pacote para Espaço de Nomes e selecione um espaço de nomes
que seja exclusivo para a classe Java que está sendo migrada para todos os pacotes Java
utilizados por esta interface da classe Java (o espaço de nomes padrão será exclusivo
para o nome do pacote que pode causar conflitos se você criar outro Serviço da
Web que utiliza as mesmas classes Java). Conclua os outros parâmetros, se necessário.
- Clique em Avançar e no painel
de mapeamento de pacote de serviço da Web para espaço de
nomes, clique em Incluir e
na linha que é criada, digite o nome do pacote de Java bean,
em seguida inclua o espaço de nomes customizado que identifica
exclusivamente essa classe Java.
Continue incluindo mapeamentos para todos os pacotes Java utilizados pela interface do Java bean.
- Clique em Avançar. Observe que você poderá precisar esperar vários minutos.
- Clique em Concluir. Depois de concluir o assistente, você deverá copiar o arquivo WSDL gerado, que descreve o serviço Java para o projeto de módulo de integração de negócios, se o projeto de serviço for um consumidor do serviço Java. Ele pode ser localizado no projeto da Web do roteador gerado na pasta WebContent/WEB-INF/wsdl. Atualize/reconstrua o projeto de módulo de integração de negócios.
- Mude para a perspectiva Business Integration e expanda o módulo e, em seguida, a categoria lógica Portas do Serviço da Web.
- Selecione a porta que foi criada nas etapas anteriores e arraste-a e solte-a sobre o Editor de Montagem e selecione para criar uma Importação com Ligação de Serviço da Web. Selecione a interface WSDL da classe Java, se for solicitado.
Agora o componente SCA que consumiu o componente Java na 5.1 pode ser ligado a essa Importação para completar as etapas manuais de migração da religação.
Observe que a interface poderá ser ligeiramente diferente da interface 5.1 e você poderá precisar inserir um componente Mediação de Interface entre o consumidor da 5.1 e a nova Importação.
Para fazer isso, clique na ferramenta wire no Editor de Montagem e ligue o componente de origem SCA a essa nova Importação com Ligação de Serviço da Web. Como as interfaces são diferentes, você será avisado: Os nós de origem e destino não têm interfaces correspondentes.
Escolha criar um mapeamento de interface entre o nó de origem e de destino. Dê um clique duplo no componente de mapeamento que foi criado no Editor de Montagem. Isso abrirá o editor de mapeamento. Consulte o Centro de Informações para obter instruções sobre a criação de um mapeamento de interface.
Se você tiver utilizado uma abordagem de cima para baixo no WebSphere Studio Application Developer Integration Edition, gerando classes Java a partir de uma definição WSDL, siga estas etapas:
- Crie um novo projeto da Web e copie o arquivo WSDL que gostaria para o esqueleto Java para a pasta de origem desse projeto da Web.
- Clique com o botão direito do mouse no arquivo WSDL que contém o PortType do qual você deseja gerar um esqueleto Java e selecione Serviços da Web -> Gerar esqueleto de Java bean.
- Escolha o tipo de serviço da Web Serviço da Web Java bean de Esqueleto e complete o assistente.
Depois de concluir o assistente, você deve ter classes Java que implementem a interface de serviço e não sejam dependentes de APIs do WSIF.
Prós e Contras para Cada uma das Opções de Religação do Serviço Java
Existem prós e contras para cada uma das opções de religação do serviço Java.
A seguinte lista descreve as duas opções e os prós e contras de cada uma:
- A primeira opção provavelmente fornece melhor desempenho no tempo de execução porque a chamada de um serviço da Web é mais lenta do que a chamada de um componente Java.
- A primeira opção pode propagar contexto enquanto uma chamada de serviço da Web não propaga contexto da mesma maneira.
- A segunda opção não envolve a criação de nenhum código customizado.
- A segunda opção não poderá ser possível para algumas definições de interface Java, porque a geração de um serviço Java tem limitações. Consulte a documentação do Rational Application Developer aqui:
Limitations of Web services
- A segunda opção poderá resultar em uma alteração de interface e, então, em uma alteração no cliente SCA.
- A segunda opção requer que um servidor do WebSphere Process Server 6.x seja instalado e configurado para funcionar com o WebSphere Integration Developer.
Para ver os tempos de execução instalados que estão configurados para
o trabalho com o
WebSphere Integration
Developer, vá para
Window -> Preferences -> Server -> Installed Runtimes e
selecione a entrada do WebSphere Process Server
v6.1 se ela existir e certifique-se de que ela aponta
para o local onde o produto está instalado.
Certifique-se de que essa entrada esteja marcada se o servidor não existir e desmarcada se esse servidor não estiver realmente instalado. Você
também pode clicar em Incluir para incluir em outro servidor.
- Se o componente Java foi construído no WebSphere Studio Application Developer
Integration Edition utilizando a abordagem de cima para baixo, na qual o esqueleto do Java foi gerado a partir de um WSDL, então, os parâmetros dentro e fora dessa classe Java provavelmente serão a subclasse WSIFFormatPartImpl. Se for esse o caso, então, você escolherá a opção 1 para gerar um novo esqueleto Java de estilo SCA a partir do WSDL/XSDs original ou a opção 2 para gerar um novo esqueleto Java genérico (não dependente das APIs WSIF ou DataObject) a partir da interface WSDL original.
Migrando um Serviço EJB
Você pode migrar um serviço EJB para uma Importação do SCA com ligação de bean de sessão sem preservação de estado.
Se o Projeto de Serviço do WebSphere Studio
Application Developer Integration Edition era dependente de outro
EJB, cliente EJB ou projeto Java, importe esses projetos existentes utilizando o assistente Arquivo -> Importar -> Geral -> Projeto Existente para o Espaço de Trabalho. Geralmente, este era o caso quando um EJB era referido a partir de um projeto de serviço.
Se algum dos arquivos WSDL ou XSD referidos a partir do projeto de serviço
existir em outro tipo de projeto, crie uma nova Biblioteca de Business Integration
com o mesmo nome que o projeto de não-serviço antigo e copie todos os artefatos
para a biblioteca.
Importe o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo de integração de negócios com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition.
Na perspectiva Business Integration, expanda o módulo para ver seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).
Você tem as seguintes opções:
Criando o Componente EJB Customizado: Opção 1
A técnica de migração recomendada é utilizar o tipo Importar com Ligação de Sessão sem Preservação de Estado do WebSphere Integration
Developer que permite chamar um EJB de sessão sem preservação de estado como um componente SCA. Durante a migração, o código Java customizado deve ser escrito para conversão entre o estilo de interface Java do SCA e o estilo de interface EJB existente.
Nota: Embora a ferramenta de migração manipule isto automaticamente, quaisquer alterações feitas depois da migração para as interfaces e tipos de dados (objetos de negócios) envolvidos na interface EJB irão requerer atualizações manuais para o código de conversão mencionado aqui. Os erros podem ser exibidos no WebSphere Integration Developer conforme o tipo de alteração efetuada.
Para criar o componente EJB customizado, siga estas etapas:
- No projeto de módulo, expanda Interfaces e selecione a interface WSDL que foi gerada para esse EJB no WebSphere Studio
Application Developer Integration.
- Arraste e solte essa interface sobre o Editor de Montagem. Um diálogo aparecerá solicitando que você selecione o tipo de componente que irá criar. Selecione Componente sem Tipo de Implementação e clique em OK.
- Um componente genérico aparecerá no diagrama de Montagem. Selecione-o e vá para a visualização Propriedades.
- Na guia Descrição, você pode alterar o nome e o nome de exibição do componente para algo mais descritivo. Escolha um nome como seu nome do EJB, mas anexe um sufixo, como "JavaMed", porque ele será um componente Java que faz mediação entre a interface WSDL
gerada para o EJB no WebSphere Studio Application Developer Integration
e a interface Java do EJB.
- Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
- De volta ao Editor de Montagem, clique com o botão direito do mouse no componente que acabou de criar e selecione Gerar Implementação... -> Java Em seguida, selecione o pacote no qual a implementação Java será gerada.
Isso cria um esqueleto do serviço Java que adere à interface WSDL de acordo com o modelo de programação SCA, no qual os tipos complexos são representados por um objeto que é um commonj.sdo.DataObject e os tipos simples são representados por equivalentes de seus Objetos Java.
Os seguintes exemplos de código mostram:
- Definições relevantes da interface WSDL 5.1.
- Os métodos WebSphere Studio Application Developer Integration Edition 5.1 Java que correspondem ao WSDL
- Os métodos WebSphere Integration Developer 6.x Java para o mesmo WSDL
O seguinte código mostra as definições relevantes da interface WSDL 5.1:
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://migr.practice.ibm.com/"
xmlns:xsd1="http://migr.practice.ibm.com/">
<complexType name="StockInfo">
<all>
<element name="index" type="int"/>
<element name="price" type="double"/>
<element name="symbol" nillable="true"
type="string"/>
</all>
</complexType>
</schema>
</types>
<message name="getStockInfoRequest">
<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
<part name="result" type="xsd1:StockInfo"/>
</message>
<operation name="getStockInfo" parameterOrder="symbol">
<input message="tns:getStockInfoRequest"
name="getStockInfoRequest"/>
<output message="tns:getStockInfoResponse"
name="getStockInfoResponse"/>
</operation>
O seguinte código mostra os métodos WebSphere Studio Application Developer Integration Edition 5.1 Java que correspondem ao WSDL:
public StockInfo getStockInfo(String symbol)
{
return new StockInfo();
}
public void setStockPrice(String symbol, float newPrice)
{
// definir algumas coisas
}
O seguinte código mostra os métodos WebSphere Integration Developer 6.x Java para o mesmo WSDL:
public DataObject getStockInfo(String aString) {
//TODO Precisa ser implementado.
return null;
}
public void setStockPrice(String symbol, Float newPrice) {
//TODO Precisa ser implementado.
}
Eventualmente, você precisa preencher o código real no qual vê as tags "//TODO" na classe de implementação Java gerada. Primeiro, é necessário criar uma referência a partir desse componente Java para o EJB real a fim de que ele possa acessar o EJB de acordo com o modelo de programação SCA:
- Mantenha o Editor de Montagem aberto e mude para a perspectiva J2EE. Localize o projeto EJB que contém o EJB para o qual você está criando um serviço.
- Expanda seu item Descritor de Implementação: <nome_do_projeto> e localize o EJB. Arraste-o e solte-o sobre o Editor de Montagem. Se for avisado sobre dependências do projeto que precisam ser atualizadas, selecione a caixa de opções Abrir o editor de dependência do módulo... e clique em OK.
- Sob a seção J2EE, certifique-se de que o projeto EJB esteja
relacionado e se não estiver, inclua-o clicando em
Incluir....
- Salve as dependências do módulo e feche esse editor. Você verá que uma nova Importação foi criada no Editor de Montagem. Você pode selecioná-la e ir para a visualização Propriedades na guia Descrição para alterar o nome da importação e o nome de exibição para algo mais significativo. Na guia Ligação, você verá que o tipo de importação é automaticamente definido para Ligação de Bean de Sessão Sem Preservação de Estado e o nome JNDI do EJB já está definido adequadamente.
- Selecione a ferramenta de Ligação a partir da paleta no Editor de Montagem.
- Clique no componente Java e solte o mouse.
- Em seguida, clique em Importação EJB e solte o mouse.
- Quando for perguntado A referência correspondente será criada no nó de origem. Deseja continuar?, clique em OK.
Isso cria uma ligação entre os dois componentes.
- Selecione o componente Java no Editor de Montagem e a visualização Propriedades na guia Detalhes, expanda Referências e selecione a referência para o EJB que acabou de ser criado. Você pode atualizar o nome da referência se o nome gerado não for muito descritivo ou adequado. Lembre-se do nome dessa referência para uso futuro.
- Salve o diagrama de Montagem.
Você deve utilizar o modelo de programação SCA para chamar o EJB a partir da classe Java gerada.
Abra a classe Java gerada e siga estas etapas para escrever o código que chamará o serviço EJB. Para a classe de implementação Java gerada:
- Crie uma variável privada (cujo tipo é aquele de sua interface EJB remota):
private YourEJBInterface ejbService = null;
- Se houver tipos complexos na interface EJB, então, crie também uma variável privada para o BOFactory:
private BOFactory boFactory = (BOFactory)
ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo
/BOFactory");
- No construtor da classe de implementação Java, utilize as APIs do SCA para resolver a referência EJB (lembre-se de preencher o nome da referência EJB que você escreveu há algumas etapas atrás) e defina a variável privada igual a essa referência:
// Localize o serviço EJB
this.ejbService = (YourEJBInterface)
ServiceManager.INSTANCE.locateService("name-of-your-ejb-reference");
Para cada "//TODO" na classe de implementação Java gerada:
- Converta todos os parâmetros nos tipos de parâmetros que o EJB espera.
- Chame o método adequado na referência EJB utilizando o modelo de programação SCA, enviando os parâmetros convertidos.
- Converta o valor de retorno do EJB no tipo de valor de retorno declarado pelo método de implementação Java gerado.
/**
* Método gerado para suportar o tipo de porta WSDL de implementação nomeada
* "interface.MyBean".
*/
public DataObject getStockInfo(String aString) {
DataObject boImpl = null;
try {
// chame o método EJB
StockInfo stockInfo = this.ejbService.getStockInfo(aString);
// formule o objeto de dados SCA a ser retornado.
boImpl = (DataObject)
this.boFactory.createByClass(StockInfo.class);
// converta manualmente todos os dados do tipo de retorno EJB para o
// objeto de dados SCA a ser retornado
boImpl.setInt("index", stockInfo.getIndex());
boImpl.setString("symbol", stockInfo.getSymbol());
boImpl.setDouble("price", stockInfo.getPrice());
} catch (RemoteException e) {
e.printStackTrace();
}
return boImpl;
}
/**
* Método gerado para suportar o tipo de porta WSDL de implementação nomeada
* "interface.MyBean".
*/
public void setStockPrice(String symbol, Float newPrice) {
try {
this.ejbService.setStockPrice(symbol, newPrice.floatValue());
} catch (RemoteException e) {
e.printStackTrace();
}
}
Criando um Serviço da Web EJB: Opção 2
Uma opção alternativa a considerar é a ferramenta de serviços da Web do Rational Application Developer que permite criar um serviço da Web em torno de um EJB.
Nota: Esta opção requer que o tempo de execução de um serviço da Web seja configurado através do WebSphere Integration
Developer antes de chamar o assistente de serviço da Web.
Para criar um serviço da Web em torno de um EJB, siga estas etapas:
- Clique com o botão direito do mouse no projeto do aplicativo corporativo que é o contêiner para o EJB em torno do qual você está criando um serviço.
- Selecione Propriedades, vá para as
propriedades do Servidor e certifique-se de
que Tempo de execução de destino esteja
definido para WebSphere Process Server v6.1 e
Servidor padrão esteja definido para o
WebSphere Process Server v6.1 instalado.
- Inicie o servidor de teste e implemente seu aplicativo para o servidor e certifique-se de que ele seja iniciado com êxito.
- Na perspectiva J2EE, expanda o Projeto EJB na visualização Explorador de Projeto. Expanda o Descritor de Implementação e, em seguida, a categoria Beans de Sessão. Selecione o bean em torno do qual deseja gerar o serviço da Web.
- Clique com o botão direito do mouse e selecione Serviços da Web -> Criar serviço da Web.
- Para Tipo de Serviço da Web, selecione Serviço da Web EJB e desmarque a opção Iniciar serviço da Web no projeto da Web, a menos que deseje implementar o serviço da Web diretamente. Clique em Avançar.
- Certifique-se de que o EJB no qual clicou com o botão direito do mouse esteja selecionado aqui e clique em Avançar.
- Agora você deve configurar as opções de implementação de serviço. Clique
em Editar....
Para o tipo de servidor, escolha WPS Server
v6.1 e para o tempo de execução do serviço da Web escolha
IBM WebSphere e J2EE versão
1.4. Se você não puder selecionar uma combinação válida fazendo isso, consulte a seção "Preparando-se para a Migração" para obter informações sobre a migração de projetos J2EE para o nível v1.4. Clique OK.
- Para o projeto Serviço, digite o nome do projeto EJB que contém o EJB. Selecione também
o projeto EAR apropriado. Clique em Avançar. Observe que você poderá precisar esperar vários minutos.
- No painel Configuração EJB do Serviço da Web, selecione o projeto do roteador adequado a ser utilizado (escolha o nome do projeto da Web do roteador que gostaria que fosse criado e esse projeto será incluído no mesmo aplicativo corporativo do EJB original). Selecione o transporte desejado (SOAP sobre HTTP ou SOAP
sobre JMS). Clique em Avançar.
- Selecione o arquivo WSDL que conterá as definições do WSDL. Escolha os métodos que gostaria de expor no serviço da Web e escolha o estilo/codificação adequados (Document/Literal, RPC/Literal ou RPC/Encoded). Selecione a opção Definir
Mapeamento Customizado do Pacote para Espaço de Nomes e selecione um espaço de nomes que seja exclusivo para o EJB que está sendo migrado para todos os pacotes Java utilizados pelo EJB (o espaço de nomes padrão
será exclusivo para o nome do pacote que pode causar conflitos se você criar outro Serviço da
Web que utiliza as mesmas classes Java). Conclua os outros parâmetros, se necessário.
Existem limitações para cada uma das combinações de estilo/codificação.
Consulte as limitações para obter informações adicionais:
Limitações de serviços da Web
- Clique em Avançar e no painel
Mapeamento de Pacote de Serviço da Web para Espaço de
Nomes, clique em Incluir e na
linha que é criada, digite o nome do pacote de seu EJB,
em seguida, o espaço de nomes customizado que identifica
exclusivamente esse EJB. Continue
incluindo mapeamentos para todos os pacotes Java utilizados pela interface EJB.
- Clique em Avançar. Observe que você poderá precisar esperar vários minutos.
- Clique em Concluir. Depois de concluir o assistente, você deverá copiar o arquivo WSDL gerado, que descreve o serviço EJB para o projeto de módulo de integraçãode negócios, se o projeto de serviço for um consumidor do serviço EJB. Ele pode ser localizado no projeto da Web do roteador gerado na pasta WebContent/WEB-INF/wsdl. Atualize/reconstrua o projeto de módulo de integração de negócios.
- Mude para a perspectiva Business Integration e expanda o módulo migrado e, em seguida, a categoria lógica Portas do Serviço da Web.
- Selecione a porta que foi gerada nas etapas anteriores e arraste-a e solte-a sobre o Editor de Montagem e selecione para criar uma Importação com Ligação de Serviço da Web. Selecione a interface WSDL do EJB, se for solicitado.
Agora o componente SCA que consumiu o EJB na 5.1 pode ser ligado a essa Importação para completar as etapas manuais de migração da religação.
Se você tiver utilizado uma abordagem de cima para baixo no WebSphere Studio Application Developer
Integration Edition, gere um esqueleto EJB a partir de uma definição WSDL e, em seguida, siga estas etapas:
- Crie um novo projeto da Web e copie o arquivo WSDL do qual gostaria de gerar o esqueleto EJB para a pasta de origem desse projeto da Web.
- Clique com o botão direito do mouse no arquivo WSDL que contém o PortType do qual você deseja gerar um esqueleto EJB e selecione Serviços da Web -> Gerar esqueleto de Java bean.
- Escolha o tipo de serviço da Web Serviço da Web EJB de Esqueleto e complete o assistente.
Depois de concluir o assistente, você deve ter um EJB que implemente a interface de serviço e não seja dependente de APIs do WSIF.
Observe que a interface poderá ser ligeiramente diferente da interface 5.1 e você poderá precisar inserir um componente Mediação de Interface entre o consumidor da 5.1 e a nova Importação.
Para fazer isso, clique na ferramenta wire no Editor de Montagem e ligue o componente de origem SCA a essa nova Importação com Ligação de Serviço da Web. Como as interfaces são diferentes, você será avisado: Os nós de origem e destino não têm interfaces correspondentes.
Escolha criar um mapeamento de interface entre o nó de origem e de destino. Dê um clique duplo no componente de mapeamento que foi criado no Editor de Montagem. Isso abrirá o editor de mapeamento. Consulte o Centro de Informações para obter instruções sobre a criação de um mapeamento de interface.
Depois de concluir isso, você deverá religar o serviço EJB. Não deve haver nenhuma referência, portanto, você precisa apenas religar a interface do componente Java:
- Se esse serviço for chamado por um processo de negócios no mesmo módulo, então, crie uma ligação da referência do processo de negócios adequada para esse componente EJB.
- Se esse serviço for chamado por um processo de negócios em outro módulo, crie uma Exportação com Ligação SCA e, a partir do outro módulo, arraste e solte essa exportação no Editor de Montagem desse módulo para criar a Importação com Ligação SCA correspondente. Ligue a referência do processo de negócios adequada àquela Importação.
- Se esse serviço tiver sido publicado no WebSphere Studio
Application Developer Integration Edition para expô-lo externamente, então, consulte a seção "Criando Exportações do SCA para Acessar o Serviço Migrado" para obter instruções sobre como publicar novamente o serviço.
Prós e Contras para Cada uma das Opções de Religação do Serviço EJB
Existem prós e contras para cada uma das opções de religação do serviço EJB.
A seguinte lista descreve as duas opções e os prós e contras de cada uma:
- A primeira opção provavelmente fornece melhor desempenho no tempo de execução, porque a chamada de um serviço da Web é mais lenta do que a chamada de um EJB.
- A primeira opção pode propagar contexto enquanto uma chamada de serviço da Web não propaga contexto da mesma maneira.
- A segunda opção não envolve a criação de nenhum código customizado.
- A segunda opção não poderá ser possível para algumas definições de interface EJB, porque a geração de um serviço EJB tem limitações. Consulte a documentação do Rational Application Developer aqui:
Limitations of Web services
- A segunda opção poderá resultar em uma alteração de interface e, então, em uma alteração no cliente SCA.
- A segunda opção requer que um servidor do WebSphere Process Server 6.x seja instalado e configurado para funcionar com o WebSphere Integration Developer.
Para ver os tempos de execução instalados que estão configurados para
o trabalho com o
WebSphere Integration
Developer, vá para
Window -> Preferences -> Server -> Installed Runtimes e
selecione a entrada do WebSphere Process Server
v6.1 se ela existir e certifique-se de que ela aponta
para o local onde o produto está instalado.
Certifique-se de que essa entrada esteja marcada se o servidor não existir e desmarcada se esse servidor não estiver realmente instalado. Você
também pode clicar em Incluir para incluir em outro servidor.
- Se o componente Java foi construído no WebSphere Studio Application Developer
Integration Edition utilizando a abordagem de cima para baixo, na qual o esqueleto do EJB foi gerado a partir de um WSDL, então, os parâmetros dentro e fora dessa classe Java provavelmente serão a subclasse WSIFFormatPartImpl. Se for esse o caso, então, você escolherá a opção 2 para gerar um novo esqueleto EJB genérico (não dependente das APIs WSIF
ou DataObject) a partir da interface WSDL.
Migrando um Processo de Negócios para a Chamada do Serviço de Processo de Negócios
Este cenário aplica-se a um processo de negócios que chama outro processo de negócios, no qual o segundo processo de negócios é chamado utilizando uma Ligação do Processo WSIF. Esta seção mostra como migrar um BPEL para uma chamada de serviço BPEL utilizando uma ligação ou uma Importação/Exportação com Ligação SCA.
Para migrar um projeto de serviço de ligação de processo (BPEL) para um serviço de saída, siga estas etapas:
- Na perspectiva Business Integration, expanda o módulo para ver seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item
no projeto do módulo (ele terá o mesmo nome que o projeto).
- Existem vários cenários no qual um processo BPEL pode chamar outro processo BPEL. Localize o cenário abaixo que se aplica ao seu aplicativo:
- Se o BPEL que está sendo chamado estiver no mesmo módulo, crie uma ligação da referência
apropriada no primeiro componente BPEL para a interface apropriada
no componente BPEL de destino.
- Se o BPEL que está sendo chamado estiver em outro módulo (em que o outro módulo
é um projeto de serviço migrado):
- Crie uma Exportação com Ligação SCA para o segundo processo de negócios em seu diagrama de montagem de módulo.
- Expanda o ícone de montagem do segundo módulo no navegador na visualização Business Integration. Você deve ver a exportação que acabou de criar.
- Arraste e solte a exportação a partir da visualização Business Integration no segundo módulo sobre o editor de montagem aberto do primeiro módulo. Isso criará uma Importação com Ligação SCA no primeiro módulo. Se esse serviço tiver sido publicado no WebSphere Studio Application Developer Integration Edition para expô-lo externamente, então, consulte a seção "Criando Exportações do SCA para Acessar o Serviço Migrado".
- Ligue a referência adequada no primeiro processo de negócios para a importação que você acabou de criar no módulo.
- Salve o diagrama de Montagem.
- Para obter a ligação posterior quando chamar o segundo processo de negócios:
- Deixe a referência do componente do primeiro processo de negócios desligada. Abra o primeiro
processo no editor BPEL e, na seção Parceiros de Referência, selecione
o parceiro que corresponde ao segundo processo BPEL a ser chamado utilizando a ligação posterior.
- Na visualização Propriedades na guia Descrição, digite
o nome do segundo processo de negócios no campo Gabarito de Processo.
- Salve o processo de negócios. Agora você concluiu a configuração da chamada de limite posterior.
Migrando um Serviço da Web (SOAP/JMS)
Você pode migrar um Serviço da Web (SOAP/JMS) para uma Importação do SCA com Ligação de Serviço da Web.
Para migrar um projeto de serviço SOAP/JMS para uma migração de serviço de saída, siga estas etapas:
- Primeiro, você precisará importar o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration
com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados
no WebSphere Studio
Application Developer Integration Edition. Observe que, se o IBM Web Service
(SOAP/JMS) que este aplicativo chamará também for um serviço da Web do WebSphere Studio
Application Developer Integration Edition que será migrado,
pode ter havido atualizações desse serviço da Web durante a migração. Se este
for o caso, será necessário utilizar os arquivos WSDL migrados desse serviço da Web aqui.
- Na
perspectiva Business Integration, expanda o módulo para que seja possível ver
seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).
- Em seguida, inclua uma Importação que permitirá que o aplicativo interaja com o IBM Web
Service (via SOAP/JMS) de acordo com o modelo de programação SCA. Certifique-se de que as definições de interface, ligação e serviço WSDL estejam presentes no módulo migrado ou em uma biblioteca da qual o módulo migrado depende.
- Na perspectiva Business Integration, expanda o módulo migrado e abra seu Diagrama de Montagem no Editor de Montagem.
- Expanda a categoria lógica Portas de Serviço da Web e arraste e solte a porta correspondente ao serviço que você deseja chamar no Editor de Montagem.
- Escolha a criação de uma Importação com Ligação de Serviço da Web.
- Depois de criar a importação, selecione-a no Editor de Montagem e vá para a visualização Propriedades. Na guia Ligação, você verá a porta e o serviço aos quais a importação está ligada.
- Salve o diagrama de montagem.
Depois de concluir isso, você deverá religar o serviço:
- Se esse serviço for chamado por um processo de negócios no mesmo módulo, então, crie uma ligação da referência do processo de negócios adequada para essa Importação.
- Se esse serviço for chamado por um processo de negócios em outro módulo, crie uma Exportação com Ligação SCA e, a partir do outro módulo, arraste e solte essa exportação no Editor de Montagem desse módulo para criar a Importação com Ligação SCA correspondente. Ligue a referência do processo de negócios adequada àquela Importação.
- Salve o diagrama de montagem.
Migrando um Serviço da Web (SOAP/HTTP)
Você pode migrar um Serviço da Web (SOAP/HTTP) para uma Importação do SCA com Ligação de Serviço da Web.
Para migrar um projeto de serviço SOAP/HTTP para uma migração de serviço de saída, siga estas etapas:
- Primeiro, você precisará importar o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration
com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados
no WebSphere Studio
Application Developer Integration Edition. Observe que, se o IBM Web Service
(SOAP/HTTP) que este aplicativo chamará também for um serviço da Web do WebSphere Studio
Application Developer Integration Edition que será migrado,
pode ter havido atualizações desse serviço da Web durante a migração. Se este
for o caso, será necessário utilizar os arquivos WSDL migrados desse serviço da Web aqui.
- Na
perspectiva Business Integration, expanda o módulo para que seja possível ver
seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).
- Em seguida, inclua uma Importação que permitirá que o aplicativo interaja com o IBM Web
Service (via SOAP/HTTP) de acordo com o modelo de programação SCA. Certifique-se de que as definições de interface, ligação e serviço WSDL estejam presentes no módulo migrado ou em uma biblioteca da qual o módulo migrado depende.
- Na perspectiva Business Integration, expanda o módulo migrado e abra seu Diagrama de Montagem no Editor de Montagem.
- Expanda a categoria lógica Portas de Serviço da Web e arraste e solte a porta correspondente ao serviço que você deseja chamar no Editor de Montagem.
- Escolha a criação de uma Importação com Ligação de Serviço da Web.
- Depois de criar a importação, selecione-a no Editor de Montagem e vá para a visualização Propriedades. Na guia Ligação, você verá a porta e o serviço aos quais a importação está ligada.
- Salve o diagrama de montagem.
Depois de concluir isso, você deverá religar o serviço:
- Se esse serviço for chamado por um processo de negócios no mesmo módulo, então, crie uma ligação da referência do processo de negócios adequada para essa Importação.
- Se esse serviço for chamado por um processo de negócios em outro módulo, crie uma Exportação com Ligação SCA e, a partir do outro módulo, arraste e solte essa exportação no Editor de Montagem desse módulo para criar a Importação com Ligação SCA correspondente. Ligue a referência do processo de negócios adequada àquela Importação.
- Salve o diagrama de montagem.
Migrando um Serviço JMS
Você pode migrar um serviço JMS para uma Importação do SCA com Ligação JMS.
Nota: Se a mensagem JMS estiver sendo enviada para um WebSphere Business Integration Adapter, consulte a seção "Migrando Interações com o WebSphere Business Integration Adapter" no link abaixo.
Para migrar um projeto de serviço JMS para uma migração de serviço de saída, siga estas etapas:
- Primeiro, você precisará importar o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration
com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados
no WebSphere Studio
Application Developer Integration Edition.
- Na
perspectiva Business Integration, expanda o módulo para que seja possível ver
seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).
- Em seguida, inclua uma Importação que permitirá que o aplicativo interaja com uma fila JMS de acordo com o modelo de programação SCA.
- No Editor de Montagem, expanda o projeto de módulo migrado, a categoria Interfaces e localize PortType do WSDL que descreve o serviço da Web que o aplicativo chamará. Arraste-o e solte-o sobre o Editor de Montagem.
- Um diálogo Criação de Componente permitirá que você selecione o tipo de componente que irá criar. Escolha Importar sem Ligação.
- Você verá que uma nova Importação foi criada no Editor de Montagem e se selecioná-la e for para a visualização Propriedades na guia Descrição, poderá alterar o nome da importação e o nome de exibição para algo mais significativo.
- Você pode consultar a ligação WSDL 5.1 e arquivos de serviço para obter detalhes
sobre o serviço JMS que está sendo migrado e utilizá-los para preencher os detalhes
da "Importação com Ligação JMS" 6.x. Localize a ligação JMS 5.1 e os arquivos
WSDL de serviço no projeto de serviço 5.1 (geralmente, eles são denominados *JMSBinding.wsdl
e *JMSService.wsdl). Examine as informações de ligação e de serviço capturadas lá.
A partir da ligação,
você pode determinar se as mensagens de texto ou de objeto foram utilizadas e se as ligações
de formato de dados customizadas foram utilizadas. Se houver alguma, também será necessário considerar
a gravação de uma ligação de dados customizada para "Importação com Ligação JMS" de 6.x. A partir do serviço, é possível localizar o depósito de informações do provedor de contexto inicial, o nome da connection
factory JNDI, o nome do destino JNDI e o estilo do destino (fila).
- Clique com o botão direito do mouse na importação e selecione Gerar Ligação e, em seguida, Ligação do JMS. Você será solicitado a digitar os seguintes parâmetros:
- Selecionar domínio do sistema de mensagens JMS:
-
- Ponto-a-Ponto
- Publicação-Assinatura
- Independente do Domínio
- Selecione como os dados são serializados entre o Objeto de Negócios e a Mensagem JMS:
-
- Texto
- Objeto
- Fornecido pelo usuário
- Se Fornecido pelo Usuário for selecionado:
- Especifique o nome completo da classe de implementação com.ibm.websphere.sca.jms.data.JMSDataBinding. Será necessário especificar uma ligação de dados definida pelo usuário se seu aplicativo
precisar configurar quaisquer propriedades de cabeçalho JMS que, normalmente, não estão disponíveis
na Ligação de Importação JMS. Neste caso, é possível criar uma classe de ligação de dados customizada
que estende a ligação de dados JMS padrão "com.ibm.websphere.sca.jms.data.JMSDataBinding"
e incluir código customizado para acessar JMSMessage diretamente. Consulte exemplos de JMS em "Criando e Modificando Ligações para Componentes de Importação e Exportação" no link abaixo.
- A conectividade de entrada está utilizando a classe do seletor de função JMS padrão:
- <selecionado> ou <seleção cancelada>
- Selecione a importação que acabou de criar. Na visualização Propriedades, vá para a guia Ligação. Você pode preencher manualmente todas as informações sobre ligação listadas lá para os mesmos valores que especificou antes no WebSphere Studio Application Developer
Integration Edition. A informações de ligação que você poderá especificar são:
- Ligação de Importação do JMS (a mais importante)
- Conexão
- Adaptador de Recursos
- Destinos de JMS
- Ligações de Método
Depois de concluir isso, você deverá religar o serviço:
- Se esse serviço for chamado por um processo de negócios no mesmo módulo, então, crie uma ligação da referência do processo de negócios adequada para essa Importação.
- Se esse serviço for chamado por um processo de negócios em outro módulo, crie uma Exportação com Ligação SCA e, a partir do outro módulo, arraste e solte essa exportação no Editor de Montagem desse módulo para criar a Importação com Ligação SCA correspondente. Ligue a referência do processo de negócios adequada àquela Importação.
- Salve o diagrama de montagem.
Migrando um Serviço J2C-IMS
Você pode migrar um serviço J2C-CICS para uma Importação do SCA com Ligação EIS ou Importação do SCA com Ligação de Serviço da Web.
Não utilize nenhum dos artefatos do WebSphere Studio Application Developer
Integration Edition gerados para esse serviço IMS. Você precisará recriar o serviço utilizando os assistentes disponíveis no WebSphere Integration
Developer e religar manualmente o aplicativo.
Nota: Ative a Auto-construção ou construa o módulo manualmente.
Você tem as seguintes opções:
Nota: Para ambas as opções, observe que se um serviço BPEL chamar esse serviço IMS, o BPEL precisará ser alterado ligeiramente, porque a interface exposta pelo serviço EIS será ligeiramente diferente da antiga interface 5.1. Para fazer isso, abra o editor BPEL e ajuste o link de parceiro correspondente ao serviço EIS e utilize a nova interface (arquivo WSDL) gerada ao executar as etapas acima. Faça todas as alterações necessárias nas atividades do BPEL para a nova interface WSDL do serviço EIS.
Criando uma Importação do SCA para Chamar o Serviço IMS: Opção 1
Você pode criar uma Importação do SCA com Ligação EIS que utilizará DataObjects para armazenar a mensagem/dados para se comunicar com o sistema IMS.
Para criar uma Importação do SCA para chamar o serviço IMS, siga estas etapas:
- Crie um novo projeto de módulo de integração de negócios para hospedar esse novo serviço IMS.
- Para recriar o serviço EIS, vá para Arquivo -> Novo -> Outro -> Business
Integration -> External Service.
- Esse assistente permite importar um serviço a partir de um sistema EIS. Ele é muito similar ao assistente do WebSphere Studio Application Developer Integration
Edition que criou o serviço EIS baseado no WSIF na 5.1. Você pode importar o novo adaptador de recursos IMS do J2C nesse assistente. Você deve procurar o diretório no qual o WebSphere Integration Developer está instalado e pesquisar detalhadamente Adaptadores de Recursos -> ims15 -> imsico9102.rar.
Nota: Consulte o Centro de Informações para obter informações adicionais sobre a conclusão das propriedades de salvamento e dos painéis de operação. Durante o assistente External Service, quando você incluir uma operação também poderá criar objetos de negócios para o tipo de dados de entrada ou saída da operação. Isso requer que você tenha o arquivo de origem C ou COBOL utilizado no assistente do WebSphere Studio
Application Developer Integration Edition. Esses arquivos devem ter sido copiados para o projeto de serviço antigo, portanto, você poderá apontar para os arquivos de origem contidos nele. Você também pode importar os objetos de negócios utilizando o assistente Arquivo -> Novo -> Outro -> Business
Integration -> External Data.
- Depois de concluir o assistente, abra a perspectiva Business Integration e expanda o módulo para que possa ver seu conteúdo. Você deve ver novos objetos de negócios listados nos Tipos de Dados do módulo e novas interfaces listadas em Interfaces.
- Abra o Editor de Montagem dando um clique duplo no primeiro item
no projeto do módulo (ele terá o mesmo nome que o projeto). Você deve ver que existe uma Importação no canvas, essa Importação tem uma Ligação EIS e representa o serviço que você acabou de criar.
Agora consulte a seção intitulada "Criando Exportações do SCA para Acessar o Serviço Migrado" para obter instruções sobre como expor esse serviço para os consumidores.
Criando um Serviço da Web em torno do Serviço J2C: Opção 2
Você pode criar um serviço da Web J2C e se o consumidor do serviço for um componente do SCA, consuma o serviço como um IBM Web Service (SOAP/HTTP ou SOAP/JMS).
Para criar um serviço da Web em torno do serviço J2C, siga estas etapas:
- Crie o Java Bean do J2C clicando em Arquivo -> Novo -> J2C -> Java Bean do J2C
- Escolha a versão 1.5 do Conector IMS para Java e clique em Avançar.
- Marque Conexão Gerenciada e digite o nome de consulta do JNDI. Clique em Avançar.
- Especifique o projeto, o pacote e o nome para o novo Java bean.
O bean consiste em uma interface e em uma classe de implementação. Clique em Avançar.
- Inclua um método Java para cada função ou serviço que você deseja acessar a partir do EIS. Métodos adicionais podem ser incluídos posteriormente no editor de origem Java através da visualização Snippets. Ao clicar no botão Incluir..., escolha o nome para o método e clique em Avançar.
- Agora você pode escolher Procurar... para reutilizar tipos existentes ou Novo... para ativar o Assistente de Ligação de Dados Java do CICS/IMS (no qual você pode referir-se a um arquivo de origem COBOL ou C) para os tipos de dados de entrada e saída.
- Depois de concluir a criação de métodos Java, clique em Avançar.
- Complete as etapas restantes nesse assistente para criar o Java Bean do J2C.
- Crie o Serviço da Web clicando em Arquivo -> Novo -> J2C -> Página da Web, Serviço da Web ou EJB em Java Bean do J2C para criar o serviço da Web em torno do Java Bean do J2C.
- Complete o assistente.
Os consumidores desse serviço agora podem utilizar o serviço WSDL gerado por esse assistente para chamar o serviço IMS.
Prós e Contras para Cada uma das Opções de Religação do Serviço J2C-IMS
Existem prós e contras para cada uma das opções de religação do serviço J2C-IMS.
A seguinte lista descreve as duas opções e os prós e contras de cada uma:
- A primeira opção utiliza o componente SCA padrão para chamar o serviço IMS.
- A primeira opção tem algumas limitações:
- A API de especificação do SDO versão 1 não fornece acesso à matriz de byte COBOL ou C - isso terá impacto nos clientes que trabalham com vários segmentos IMS.
- A especificação do SDO versão 1 para serialização não suporta redefinições COBOL ou uniões C.
- A segunda opção utiliza a abordagem JSR 109 padrão para conectar-se ao serviço IMS.
Essa funcionalidade está disponível como parte do Rational Application Developer.
Migrando um Serviço ECI do J2C-CICS
Você pode migrar um serviço ECI do J2C-CICS para uma Importação do SCA com Ligação EIS ou Importação do SCA com Ligação de Serviço da Web.
Siga as instruções no tópico "Migrando um Serviço J2C-IMS", mas certifique-se de importar o seguinte arquivo RAR ao invés de do arquivo RAR do IMS:
- Procure o diretório no qual o WebSphere Integration Developer está instalado e pesquise detalhadamente Adaptadores de Recurso -> cics15 -> cicseci.rar.
Se você seguir a segunda opção para criar um serviço da Web do J2C, escolha o ECIResourceAdapter da v1.5 no segundo painel do assistente de criação do Java Bean do J2C.
Consulte também o tópico "Migrando
um Serviço J2C-IMS".
Migrando um Serviço EPI do J2C-CICS
Não há suporte direto para o serviço EPI do J2C-CICS no WebSphere Integration
Developer. Para acessar este serviço a partir de um módulo SCA, será necessário fazer a migração utilizando o cenário de consumo.
Consulte o tópico "O Cenário de Consumo para Migração de Serviço" para obter instruções
sobre como migrar este tipo de serviço para o WebSphere Integration Developer.
Migrando um Serviço J2C-HOD
Não há suporte direto para o serviço J2C-HOD no WebSphere Integration
Developer. Para acessar este serviço a partir de um módulo SCA, será necessário fazer a migração utilizando o cenário de consumo.
Consulte o tópico "O Cenário de Consumo para Migração de Serviço" para obter instruções
sobre como migrar este tipo de serviço para o WebSphere Integration Developer.
Você pode migrar um serviço de transformador para um Mapa de Dados e Mapa de Interface do SCA, quando possível. Você também pode utilizar o cenário de consumo para acessar este serviço a partir de um módulo SCA.
Os componentes do mapa de dados e do mapa de interface são novos na versão 6.0.
Eles oferecem função similar para o serviço de transformador da 5.1, mas não têm a capacidade total de transformação do XSL. Se você não puder substituir seu serviço de transformador por um desses componentes, então, deverá migrar utilizando o cenário de consumo, pois não há suporte direto para o serviço de transformador no WebSphere Integration Developer. Siga as etapas documentadas na seção "O Cenário de Consumo para Migração
de Serviço" para acessar este serviço a partir de um módulo SCA.
O Cenário de Consumo para Migração de Serviço
Nos casos em que não há nenhuma contraparte direta para um tipo de serviço do WebSphere Studio
Application Developer Integration Edition, um cenário de consumo é necessário para consumir o serviço antigo do WebSphere Studio Application Developer Integration
Edition como está ao reprojetar o aplicativo no WebSphere Integration
Developer.
A seguir há algumas etapas para executar no WebSphere Studio Application Developer
Integration Edition antes de chamar o assistente de Migração:
- Crie um novo projeto Java para manter seu código do proxy de cliente. Não coloque esse código do proxy de cliente no projeto de serviço, porque as mensagens geradas no estilo 5.1
e as classes de
Java bean serão ignoradas pelo assistente de Migração automática
que migra projetos de serviço.
- Abra o WebSphere Studio
Application Developer Integration Edition e clique com o botão direito do mouse no arquivo WSDL que contém a ligação e o serviço do transformador e selecione Serviços Corporativos -> Gerar Proxy de Serviço.
Você será solicitado sobre o tipo de proxy que irá criar, mas apenas o WSIF (Web Services
Invocation Framework) estará disponível. Clique em Avançar.
- Você pode agora especificar o pacote e o nome da classe Java do proxy de serviço que irá criar (você criará o proxy no projeto de serviço atual). Clique em Avançar.
- Agora você pode especificar o estilo de proxy, escolher Stub de Cliente, selecionar as operações desejadas que irá incluir no proxy e clicar em Concluir.
Isto cria uma classe Java que expõe os mesmos métodos que o serviço do WebSphere Studio
Application Developer Integration Edition, em que os argumentos dos métodos
Java
são as partes da mensagem WSDL de origem.
Agora você pode migrar para o WebSphere Integration Developer:
- Copie o projeto Java do proxy do cliente para o novo espaço de trabalho e importe-o
indo para Arquivo -> Importar -> Projeto Existente para Espaço de Trabalho.
- Importe o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration
com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados
no WebSphere Studio
Application Developer Integration Edition.
- Na
perspectiva Business Integration, expanda o módulo para que seja possível ver
seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).
- Para criar o componente Java customizado, sob o projeto do módulo, expanda Interfaces e selecione a interface WSDL que foi gerada para esse serviço de transformador no WebSphere Studio Application Developer
Integration Edition.
- Arraste e solte essa interface sobre o Editor de Montagem. Um diálogo aparecerá solicitando que você selecione o tipo de componente que irá criar. Selecione Componente sem Tipo de Implementação e clique em OK.
- Um componente genérico aparecerá no diagrama de Montagem. Selecione-o e vá para a visualização Propriedades.
- Na guia Descrição, você pode alterar o nome e o nome de exibição do componente para algo mais descritivo (nesse caso, nomeie-o para algo como seu nome do EJB, mas anexe um sufixo, como "JavaMed", porque ele será um componente Java que faz mediação entre a interface WSDL gerada para o serviço de transformador no WebSphere Studio
Application Developer Integration Edition e a interface Java do proxy de cliente de transformador).
- Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
- De volta ao Editor de Montagem, clique com o botão direito do mouse no componente que acabou de criar e selecione Gerar Implementação... -> Java Em seguida, selecione o pacote no qual a implementação Java será gerada.
Isso cria um esqueleto do serviço Java que adere à interface WSDL de acordo com o modelo de programação SCA, no qual os tipos complexos são representados por um objeto que é um commonj.sdo.DataObject e os tipos simples são representados por equivalentes de seus Objetos Java.
Agora, você precisará preencher o código no qual vê as tags "//TODO" na classe de implementação Java gerada. Existem duas opções:
- Mova a lógica da classe Java original para essa classe, adaptando-a para a nova estrutura de dados.
- Crie uma instância privada da classe Java antiga dentro dessa classe Java gerada e escreva código para:
- Converter todos os parâmetros da classe de implementação Java gerada em parâmetros que a classe
Java antiga espera.
- Chamar a instância privada da classe Java antiga com os parâmetros convertidos.
- Converter o valor de retorno da classe Java antiga para o tipo de valor de retorno declarado pelo método de implementação Java gerado.
Depois de concluir as opções acima, você deverá religar o proxy de cliente. Não deve haver nenhuma "referência", portanto, você precisa apenas religar a interface do componente Java:
- Se esse serviço for chamado por um processo de negócios no mesmo módulo, então, crie uma ligação da referência do processo de negócios adequada para essa interface do componente Java.
- Se esse serviço for chamado por um processo de negócios em outro módulo, crie uma Exportação com Ligação SCA e, a partir do outro módulo, arraste e solte essa exportação no Editor de Montagem desse módulo para criar a Importação com Ligação SCA correspondente. Ligue a referência do processo de negócios adequada àquela Importação.
- Se esse serviço tiver sido publicado no WebSphere Studio
Application Developer Integration Edition para expô-lo externamente, então, consulte a seção "Criando Exportações do SCA para Acessar o Serviço Migrado" para obter instruções sobre como publicar novamente o serviço.
Criando Exportações SCA para Acessar o Serviço Migrado
Uma Exportação SCA deve ser criada para disponibilizar o serviço migrado
para consumidores externos, de acordo com o modelo SCA para todos os serviços para os quais o
código de implementação foi gerado no projeto de serviço do WebSphere Studio Application Developer
Integration Edition. Isto inclui todos os serviços chamados por clientes
externos para o aplicativo. Nota: O utilitário de migração tenta fazer isso automaticamente; entretanto, você pode consultar as informações a seguir para ajudar a verificar o que a ferramenta fez.
Se no WebSphere Studio Application Developer Integration
Edition, você clicava com o botão direito do mouse no processo BPEL ou em outro WSDL de Serviço e selecionava Serviços Corporativos -> Gerar Código de Implementação, será necessário desempenhar as etapas de migração manuais abaixo. Observe que o WebSphere Integration
Developer é diferente do WebSphere Studio Application Developer Integration
Edition porque ele armazena todas as opções de implementação. Quando o projeto
for construído, o código de implementação será atualizado automaticamente nos
projetos EJB e da Web gerados, portanto, não existe mais nenhuma opção para Gerar
Código de Implementação manualmente.
Foram especificadas cinco opções de ligação
na seção Interfaces para Parceiros do assistente Gerar Código de Implementação de BPEL.
As seguintes informações de migração de serviço do BPEL de entrada fornecem detalhes adicionais
sobre o tipo e propriedades da Exportação a ser criada com base nos tipos de ligação de
implementação que foram selecionados no WebSphere Studio Application Developer
Integration Edition:
- EJB
- IBM Web
Service (SOAP/JMS)
- IBM Web
Service (SOAP/HTTP)
- Apache Web Service (SOAP/HTTP)
- JMS
Migrando o EJB e as Ligações do Processo EJB
O EJB e as ligações do processo EJB podem ser migrados para a construção SCA
recomendada.
No WebSphere Studio
Application Developer Integration Edition, este tipo de ligação permite que clientes
se comuniquem com um processo BPEL ou outro tipo de serviço chamando um EJB.
Observe que este tipo de ligação não era opcional para microprocessos - ele era
sempre selecionado como EJB gerado utilizado internamente por outros tipos de
ligação.
O nome JNDI do EJB gerado era gerado automaticamente
como uma combinação do nome, espaço de nomes de destino e time stamp valid-from do BPEL.
Por exemplo, estes atributos podem ser localizados examinando as propriedades do processo BPEL
no editor BPEL nas guias de conteúdo Descrição e Servidor:
Tabela 3. Espaço de Nomes Gerado
Nome do Processo |
MyService |
Espaço de Nomes de Destino |
http://www.example.com/process87787141/ |
Válido a partir de |
01 de Jan de 2003 02:03:04 |
O espaço de nomes gerado para este exemplo é com/example/www/process87787141/MyService20030101T020304.
No WebSphere Studio
Application Developer Integration Edition, quando a ligação EJB era selecionada
como o tipo de implementação, nenhuma opção era especificada.
Existem
quatro opções para migrar a ligação do processo do WebSphere Studio Application Developer
Integration Edition. O tipo de cliente(s) que acessa(m) o serviço
determinará qual(is) opção(ções) de migração abaixo será(ão) desempenhada(s):
Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá
ser migrado para o novo modelo de programação.
Consulte o tópico apropriado para os seguintes tipos de clientes:
Tabela 4. Informações Adicionais para Migrar Clientes
Tipo de Cliente |
Para obter informações adicionais, consulte |
Cliente EJB que chama o bean de sessão gerado.
Tal cliente chamaria um método EJB correspondente à operação BPEL
a ser chamada |
"Migrando o Cliente EJB" |
Cliente WSIF que utiliza a ligação do processo EJB |
"Migrando o Cliente de Ligação de Processo EJB" |
API EJB Genérica do Business Process Choreographer |
"Migrando o Cliente da API EJB Genérica do Business Process Choreographer" |
API do Sistema de Mensagens Genérica do Business Process Choreographer |
"Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer" |
Outro processo BPEL no mesmo módulo |
N/D: Ligar componentes BPEL utilizando o Editor de Montagem |
Outro processo BPEL em um módulo diferente |
N/D: Criar uma Importação com Ligação SCA
no módulo de referência
e configurar sua ligação para apontar para a Exportação
com Ligação SCA criada abaixo na Opção 1 |
Opção de Migração 1 para o EJB e a Ligação de Processo EJB
A primeira opção de migração para a ligação do processo EJB do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis para
outro componente no mesmo módulo.
No Editor de Montagem, para ligar esse outro componente ao componente BPEL, siga estas etapas:
- Selecione o item Ligação na barra de ferramentas.
- Clique no outro componente para selecioná-lo como a origem
da ligação.
- Clique no componente BPEL SCA para selecioná-lo
como o destino da ligação.
- Salve o diagrama de montagem.
Opção de Migração 2 para o EJB e a Ligação de Processo EJB
A segunda opção de migração para a ligação do processo EJB do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis para
outros módulos e clientes SCA.
Nota: Estas etapas serão obrigatórias se as APIs genéricas do Business Process Choreographer
forem utilizadas para chamar o processo de negócios.
A Exportação com Ligação SCA torna um componente SCA acessível
por outros módulos SCA. Para criar uma Exportação com uma ligação SCA, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Exportação com Ligação SCA para cada interface de processo BPEL
que teve uma ligação EJB gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
- Selecione Exportar....
- Selecione Ligação SCA.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Quando a Exportação de SCA for criada, selecione a exportação no Editor
de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Salve o diagrama de montagem.
Opção de Migração 3 para o EJB e a Ligação de Processo EJB
A terceira opção de migração para a ligação do processo EJB do WebSphere Studio Application Developer
Integration Edition é tornar os módulos acessíveis por uma entidade
não-SCA (por exemplo, um cliente JSP ou Java).
A Referência Independente torna um componente SCA acessível
por qualquer cliente externo. Para criar uma Referência Independente, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente de Migração.
- Crie uma Referência Independente para cada interface de processo BPEL
que teve uma ligação EJB gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Selecione o item Referências Independentes
na barra de ferramentas.
- Clique no canvas do Editor de Montagem para criar uma
entidade SCA de Referências Independentes.
- Selecione o item Ligação na barra de ferramentas.
- Clique na entidade Referências Independentes
para selecioná-la como a origem da ligação.
- Clique no componente BPEL SCA para selecioná-lo
como o destino da ligação.
- Você verá um alerta A referência correspondente
será criada no nó de origem. Deseja continuar?, clique em OK.
- Selecione a entidade Referências Independentes
recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
- Expanda o link Referências e selecione
a referência recém-criada. O nome e a descrição da referência são listados
e podem ser modificados se necessário.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Salve o diagrama de montagem.
Opção de Migração 4 para o EJB e a Ligação de Processo EJB
A quarta opção de migração para a ligação de processo EJB do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis por
um cliente de Serviços da Web.
A Exportação com ligação de serviço da Web torna um componente SCA acessível
por um cliente de serviços da Web externo. Para criar uma Exportação com ligação de Serviço da Web, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Exportação com Ligação SCA para cada interface de processo BPEL
que teve uma ligação EJB gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
- Selecione Exportar... .
- Selecione Ligação de Serviço da Web.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Selecione o transporte: soap/http ou soap/jms.
- Quando a Exportação de Serviços da Web for criada, selecione a exportação no
Editor de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Salve o diagrama de montagem.
Migrando o JMS e as Ligações do Processo JMS
O JMS e as ligações do processo JMS podem ser migrados para a construção SCA recomendada.
No WebSphere Studio
Application Developer Integration Edition, este tipo de ligação permite que os clientes
se comuniquem com um processo BPEL ou outro tipo de serviço enviando
uma mensagem para um MDB. Observe que este tipo de ligação não era opcional para processos
de execução longa e ele era sempre selecionado. De fato, este tipo de ligação era o único tipo de ligação
permitido para interfaces de pedido-resposta de processos de execução longa. Para outros tipos de serviço, um MDB será gerado e chamará o serviço adequado.
O nome
JNDI utilizado pela ligação JMS era uma combinação do nome, do espaço de nomes de destino e
de time stamp valid-from de BPEL.
No WebSphere Studio Application Developer
Integration Edition, quando a ligação JMS era selecionada como o tipo de implementação
para um processo BPEL, as seguintes opções eram especificadas:
- Connection Factory JNDI - o padrão é jms/BPECF (este é o nome JNDI da connection factory de fila do contêiner do processo de negócios de destino)
- Fila de Destino JNDI - o padrão é jms/BPEIntQueue (esse é o nome JNDI da fila interna do contêiner de processo de negócios de destino)
- URL do Provedor JNDI: Fornecido pelo Servidor ou Customizado -
é necessário digitar um endereço. O padrão é iiop://localhost:2809
Existem
cinco opções para migrar a ligação do processo JMS do WebSphere Studio Application Developer
Integration Edition. O tipo de cliente(s) que acessa(m) o serviço
determinará qual(is) opção(ções) de migração abaixo será(ão) desempenhada(s):
Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá
ser migrado para o novo modelo de programação.
Consulte o tópico apropriado para os seguintes tipos de clientes:
Tabela 5. Informações Adicionais para Migrar Clientes
Tipo de Cliente |
Para obter informações adicionais, consulte |
Cliente WSIF que utiliza a ligação de processo JMS |
"Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer e o Cliente de Ligação de Processo JMS" |
API EJB Genérica do Business Process Choreographer |
"Migrando o Cliente da API EJB Genérica do Business Process Choreographer" |
API do Sistema de Mensagens Genérica do Business Process Choreographer -
Migrando Negócios |
"Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer" |
Outro processo BPEL no mesmo módulo |
N/D: Ligar componentes BPEL utilizando o Editor de Montagem |
Outro processo BPEL em um módulo diferente |
N/D: Criar uma Importação com Ligação SCA
no módulo de referência e configurar sua ligação para apontar para a Exportação
com Ligação SCA criada abaixo na Opção 1. |
Opção de Migração 1 para o JMS e a Ligação de Processo JMS
A primeira opção de migração para a ligação do processo JMS do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis para
outro componente no mesmo módulo.
No Editor de Montagem, para ligar esse outro componente ao componente BPEL, siga estas etapas:
- Selecione o item Ligação na barra de ferramentas.
- Clique no outro componente para selecioná-lo como a origem
da ligação.
- Clique no componente BPEL SCA para selecioná-lo
como o destino da ligação.
- Salve o diagrama de montagem.
Opção de Migração 2 para o JMS e a Ligação de Processo JMS
A segunda opção de migração para a ligação do processo JMS do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis para
outros módulos e clientes SCA.
A Exportação com Ligação SCA torna um componente SCA acessível
por outros módulos SCA. Para criar uma Exportação com uma ligação SCA, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Exportação com Ligação SCA para cada interface de processo BPEL
que teve uma ligação JMS gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
- Selecione Exportar....
- Selecione Ligação SCA.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Quando a Exportação de SCA for criada, selecione a exportação no Editor
de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Salve o diagrama de montagem.
Opção de Migração 3 para o JMS e a Ligação de Processo JMS
A terceira opção de migração para a ligação do processo JMS do WebSphere Studio Application Developer
Integration Edition é tornar os processos de negócios acessíveis por uma entidade
não-SCA (por exemplo, um cliente JSP ou Java).
A Referência Independente torna um componente SCA acessível
por qualquer cliente externo. Para criar uma Referência Independente, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Referência Independente para cada interface de processo BPEL
que teve uma ligação JMS gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Selecione o item Referências Independentes
na barra de ferramentas.
- Clique no canvas do Editor de Montagem para criar uma
entidade SCA de Referências Independentes.
- Selecione o item Ligação na barra de ferramentas.
- Clique na entidade Referências Independentes
para selecioná-la como a origem da ligação.
- Clique no componente BPEL SCA para selecioná-lo
como o destino da ligação.
- Você verá um alerta A referência correspondente
será criada no nó de origem. Deseja continuar?, clique em OK.
- Selecione a entidade Referências Independentes
recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
- Expanda o link Referências e selecione
a referência recém-criada. O nome e a descrição da referência são listados
e podem ser modificados se necessário.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Salve o diagrama de montagem.
Opção de Migração 4 para o JMS e a Ligação de Processo JMS
A quarta opção de migração para a ligação do processo JMS do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis por
um cliente de serviços da Web.
A Exportação com ligação de serviço da Web torna um componente SCA acessível
por um cliente de serviços da Web externo. Para criar uma Exportação com ligação de serviço da Web, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Exportação com Ligação SCA para cada interface de processo BPEL
que teve uma ligação JMS gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
- Selecione Exportar... .
- Selecione Ligação de Serviço da Web.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Selecione o transporte: soap/http ou soap/jms.
- Quando a Exportação de Serviços da Web for criada, selecione a exportação no
Editor de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Salve o diagrama de montagem.
Opção de Migração 5 para o JMS e a Ligação de Processo JMS
A quinta opção de migração para a ligação do processo JMS do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis por
um cliente JMS.
A Exportação com ligação JMS torna um componente SCA acessível
por um cliente JMS externo. Para criar uma Exportação com ligação JMS, siga estas etapas:
- Para serviços BPEL, será necessário criar e fazer referência a novos recursos de fila, pois a ligação de processo JMS 5.1 era muito diferente da ligação JMS
5.1 padrão. Para serviços não-BPEL, é possível localizar os valores selecionados para o código de implementação
JMS no WebSphere Studio Application Developer
Integration Edition 5.1, localizando o arquivo WSDL denominado JMSBinding.wsdl e JMSService.wsdl
no pacote apropriado, sob a pasta ejbModule/META-INF do projeto EJB gerado
e inspecionando as informações de ligação e de serviço capturadas lá. A partir da ligação,
você pode determinar se as mensagens de texto ou de objeto foram utilizadas e se as ligações
de formato de dados customizadas foram utilizadas. Se houver alguma, também será necessário considerar
a gravação de uma ligação de dados customizada para Exportação com Ligação JMS de 6.x. A partir do serviço, é possível localizar o depósito de informações do provedor de contexto inicial, o nome da connection
factory JNDI, o nome do destino JNDI e o estilo do destino (fila).
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Exportação com Ligação JMS para cada interface de processo BPEL
que teve uma ligação JMS gerada para ela no WebSphere Studio Application Developer
Integration Edition, clicando com o botão direito do mouse no componente BPEL no Editor de Montagem.
- Selecione Exportar... .
- Selecione Ligação JMS.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- No próximo painel (atributos de Ligação de Exportação JMS), selecione Domínio
do Sistema de Mensagens JMS. Defina este atributo como Ponto-a-Ponto.
- Selecione como os dados são serializados entre o Objeto de Negócios
e a Mensagem JMS e digite os seguintes valores (é recomendável selecionar
Texto em vez de Objeto porque o texto,
que geralmente é XML, é independente do tempo de execução e permite a integração de serviço
entre sistemas diferentes):
- Para Texto, selecione para utilizar o Seletor
de função JMS padrão ou digite o nome completo da
classe de implementação FunctionSelector.
- Para Objeto, selecione para utilizar o Seletor
de função JMS padrão ou digite o nome completo da
classe de implementação FunctionSelector.
- Para Fornecido pelo Usuário, digite o nome completo
da classe de implementação JMSDataBinding. Será necessário selecionar Fornecido
pelo Usuário se seu aplicativo precisar acessar propriedades do cabeçalho JMS
que não estão prontamente disponíveis na Ligação de Importação JMS. Neste caso, é necessário criar uma classe de ligação de dados customizada que estende a ligação de dados JMS padrão
com.ibm.websphere.sca.jms.data.JMSDataBinding e incluir
o código customizado para acessar JMSMessage diretamente. Em seguida, você fornecerá
o nome de sua classe customizada para este campo. Consulte exemplos de JMS em "Criando e Modificando Ligações para Componentes de Importação e Exportação" no link abaixo.
- Para Fornecido pelo Usuário, selecione para utilizar o Seletor
de função JMS padrão ou digite o nome completo da classe de implementação
FunctionSelector.
- Quando a Exportação com Ligação JMS tiver sido criada, selecione a exportação
no Editor de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Selecione a área de janela de conteúdo Ligação para ver muito mais opções.
- Salve o diagrama de montagem.
Migrando a Ligação do IBM Web Service (SOAP/JMS)
A ligação do IBM Web
Service (SOAP/JMS) para um processo BPEL ou outro tipo de serviço pode ser migrada
para a construção SCA recomendada.
No WebSphere Studio
Application Developer Integration Edition, este tipo de ligação permitia que os clientes
se comunicassem com um processo BPEL ou outro tipo de serviço, chamando
um IBM Web
Service, no qual o protocolo de comunicação era JMS e a mensagem seguia as regras
de codificação SOAP.
A seguir está um exemplo das convenções utilizadas
durante a geração de um IBM Web Service (SOAP/JMS) para um serviço BPEL 5.1. O nome JNDI do IBM Web Service gerado era uma combinação do nome, espaço de nomes de destino e time stamp valid-from do BPEL, bem como o nome
da interface (tipo de porta WSDL para o qual o código de implementação foi gerado).
Por exemplo, estes atributos podem ser localizados examinando
as propriedades do processo BPEL no editor
BPEL nas guias de conteúdo Descrição e Servidor:
Tabela 6. Espaço de Nomes Gerado
Nome do Processo |
MyService |
Espaço de Nomes de Destino |
http://www.example.com/process87787141/ |
Válido a partir de |
01 de Jan de 2003 02:03:04 |
Interface |
ProcessPortType |
O espaço de nomes gerado para este exemplo é com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.
No WebSphere Studio
Application Developer Integration Edition, quando a ligação do IBM Web Service (SOAP/JMS) foi selecionada como o tipo de implementação
para um processo BPEL ou outro tipo de serviço, foram especificadas as seguintes opções:
- Para Estilo de Documento, o padrão era DOCUMENT / outra opção:
RPC
- Para Utilização do Documento, o padrão era LITERAL / outra opção: ENCODED
- Para URL do Provedor JNDI, ela era Fornecida pelo Servidor ou Customizada (deve ser digitado um endereço, o padrão é iiop://localhost:2809)
- Para Estilo de Destino, o padrão era queue / outra opção
era topic
- Para Connection Factory JNDI, o padrão era jms/qcf (este
é o nome JNDI da connection factory de fila para a fila do MDB gerada)
- Para Fila de Destino JNDI, o padrão era jms/queue (este
é o nome JNDI da fila do MDB gerada)
- Para Porta Listener MDB, o padrão era <Nome do Projeto de Serviço>MdbListenerPort
Um arquivo WSDL que especifica a ligação e o serviço SOAP/JMS do IBM Web Service é criado no projeto
EJB gerado, mas não no próprio projeto de serviço.
Isto significa que você deve localizar manualmente esse arquivo e copiá-lo para seu projeto de módulo
de integração de negócios, se for importante que o código de cliente IBM Web Service não seja alterado.
Por padrão, este arquivo WSDL foi criado no projeto EJB em ejbModule/META-INF/wsdl/<nome
do processo de negócios>_ <nome do tipo de porta da interface do processo de negócios>_JMS.wsdl
O
PortType e Mensagens WSDL da interface do processo de negócios são realmente copiados
também para este arquivo WSDL, em vez de referir-se ao
PortType e Mensagens WSDL existentes no projeto de serviço.
Se for importante que
o código de cliente IBM
Web Service permaneça inalterado após a migração, as informações neste arquivo
serão requeridas para as etapas de migração manuais abaixo.
Existem
duas opções para migrar a ligação do processo SOAP/JMS do WebSphere Studio Application Developer
Integration Edition. A opção terá que ser feita, se migrar o cliente para o modelo de programação
SCA ou se deixá-lo como um cliente de serviços da Web:
Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá
ser migrado para o novo modelo de programação.
Consulte o tópico apropriado para os seguintes tipos de clientes:
Tabela 7. Informações Adicionais para Migrar Clientes
Tipo de Cliente |
Para obter informações adicionais, consulte |
Cliente IBM Web Service |
"Migrando o Cliente IBM Web service (SOAP/JMS)" |
Opção de Migração 1 para a Ligação do IBM Web Service (SOAP/JMS)
A primeira opção de migração para a ligação SOAP/JMS do WebSphere Studio Application Developer
Integration Edition é tornar o serviço acessível para um cliente de serviços da Web.
A Exportação com Ligação de Serviço da Web torna um componente SCA acessível
por um cliente de serviços da Web externo. Para criar uma Exportação com Ligação de Serviço da Web, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Exportação com Ligação SCA para cada interface de serviço
que teve uma ligação do IBM
Web Service (SOAP/JMS) gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Clique com o botão direito do mouse no componente SCA no Editor de Montagem.
- Selecione Exportar....
- Selecione Ligação de Serviço da Web.
- Se houver várias interfaces para o componente, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Selecione o transporte soap/jms.
- Quando a Exportação de Serviços da Web for criada, selecione a exportação no
Editor de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Salve o diagrama de montagem.
- Selecione a área de janela de conteúdo Ligação e verá que uma Ligação e o Serviço de Ligação WSDL do IBM Web Service
foram gerados diretamente na pasta do projeto do módulo.
Ele será denominado componente que foi exportado Exportar Nome
de PortType WSDL Jms_Service.wsdl. Se você inspecionar este arquivo, perceberá
que a ligação agrupada de Document/Literal é utilizada por padrão, pois é o
estilo preferido na 6.x. Este é o WSDL que os clientes IBM Web Service utilizarão para chamar
o serviço.
- Siga estas etapas para gerar um novo serviço e uma nova ligação de serviço da Web, se a preservação do código do cliente for desejada:
- Copie o arquivo WSDL da 5.1 do projeto EJB gerado da 5.1 em
ejbModule/META-INF/wsdl/nome do processo de negócios/nome do tipo de porta
da interface do processo de negóciosJMS.wsdl para o projeto de módulo de integração denegócios.
- Depois de copiar sobre o arquivo e reconstruir o módulo, você poderá ver mensagens de erro porque os tipos de esquema XML, as mensagens do WSDL e os tipos de porta do WSDL utilizados pelo serviço da Web estão duplicados no arquivo WSDL do IBM Web Service na 5.1. Para corrigir isso, exclua essas definições duplicadas do WSDL de ligação/serviço do IBM Web Service e em seu lugar inclua uma importação do WSDL para o WSDL da interface real. Nota:
É importante observar que quando o WebSphere Studio Application Developer
Integration Edition gerou o código de implementação do IBM Web Service, ele modificou as definições de esquema em alguns casos. Isso poderá causar inconsistências para clientes existentes que utilizam o WSDL do IBM Web Service. Por exemplo, o atributo de esquema "elementFormDefault" foi definido para "qualificado" no esquema seqüencial gerado no WSDL do IBM Web Service mesmo que a definição de esquema original não tenha sido qualificada. Isso causará a geração do seguinte erro durante o tempo de execução:
WSWS3047E: Erro: Não é possível desserializar o elemento.
- Clique com o botão direito do mouse neste arquivo WSDL recém-copiado para o módulo de integração de negócios e selecione Abrir
com e, em seguida, Editor WSDL.
- Vá para a guia Origem. Exclua todos os
PortTypes e Mensagens WSDL definidos neste arquivo.
- Agora você verá o erro: O tipo de porta '<Tipo_de_porta>' especificado para a ligação '<ligação>' está indefinido.
Para corrigir isso, no editor WSDL da guia Gráfico, clique com o botão direito do mouse na seção Importações
e selecione Incluir Importação.
- Na visualização Propriedades na guia
Geral, clique no botão ... à direita
do campo Local. Procure o WSDL da interface no qual as definições de mensagem e de tipo de porta do WSDL estão localizadas e clique em OK para importar o WSDL da interface para o WSDL de serviço/ligação.
- Salve o arquivo WSDL.
- Atualize/reconstrua o projeto. Vá para a perspectiva Business Integration. Abra o Diagrama de Montagem do módulo no Editor de Montagem.
- Na visualização Explorador de Projeto, expanda o módulo que você está migrando e expanda a categoria lógica Portas de Serviço da Web. Você deve ver a porta existente no WSDL de ligação/serviço listado. Arraste-a e solte-a sobre o Editor de Montagem.
- Escolha a criação de uma Exportação com Ligação de Serviço da Web e selecione o nome de porta adequado. Isso criará a Exportação que utiliza a ligação/serviço antigo de forma que clientes de serviço da Web existentes não tenham de fazer alterações. Se você selecionar a exportação que acabou de criar no Editor de Montagem e for para a visualização Propriedades, na guia Ligação deverá ver que os nomes de porta e de serviço da 5.1 foram preenchidos.
- Salve todas as alterações.
- Pouco antes de implementar o aplicativo, você pode alterar a configuração do projeto da Web gerado para que corresponda ao endereço de serviço da 5.1 (você precisa fazer essas alterações toda vez que fizer alterações no módulo SCA, o que faz com que esse arquivo seja regenerado). Se você examinar a definição de Serviço do IBM Web Service WSDL que está sendo reutilizada da 5.1, verá o endereço de serviço para o qual o cliente 5.1 foi codificado:<wsdlsoap:address
location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
- Para fazer com que os artefatos do projeto da Web gerado da 6.x correspondam a esse endereço de serviço antigo, você deve modificar o descritor de implementação do projeto da Web gerado. Abra o descritor de implementação no WebSphere Integration Developer e na guia Servlets, inclua um Mapeamento de URL adicional que é muito similar ao mapeamento de URL existente para aquela exportação, com o mesmo nome de servlet, mas um padrão de URL diferente.
- Além disso, se você precisar modificar a raiz de contexto deste projeto da Web
de forma que ela corresponda à raiz de contexto no endereço de serviço original (neste
exemplo, a raiz de contexto é "MyServiceWeb"), poderá abrir o descritor de implementação
para o J2EE Enterprise Application no qual este projeto da Web está localizado
e alterar a raiz de contexto desse módulo da Web para corresponder à raiz de contexto do endereço de serviço antigo.
Você poderá ver o seguinte erro que pode ser ignorado: CHKJ3017E:
Projeto da Web: <NOME DO PROJ DA WEB> está mapeado para uma raiz de Contexto inválida: <RAIZ DE CONTEXTO NOVO> no Projeto EAR: <NOME DO APLICATIVO>.
Opção de Migração 2 para a Ligação do IBM Web Service (SOAP/JMS)
A segunda opção para a ligação do processo SOAP/JMS do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis a uma entidade
não-SCA (por exemplo, um cliente JSP ou Java).
A Referência Independente torna um componente SCA acessível
por qualquer cliente externo. Para criar uma Referência Independente, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Referência Independente para cada interface de processo BPEL
que teve uma ligação IBM
Web Service (SOAP/JMS) gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Selecione o item Referências Independentes
na barra de ferramentas.
- Clique no canvas do Editor de Montagem para criar uma
entidade SCA de Referências Independentes.
- Selecione o item Ligação na barra de ferramentas.
- Clique na entidade Referências Independentes
para selecioná-la como a origem da ligação.
- Clique no componente BPEL SCA para selecioná-lo
como o destino da ligação.
- Você verá um alerta A referência correspondente
será criada no nó de origem. Deseja continuar?, clique em OK.
- Selecione a entidade Referências Independentes
recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
- Expanda o link Referências e selecione
a referência recém-criada. O nome e a descrição da referência são listados
e podem ser modificados se necessário.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Salve o diagrama de montagem.
Migrando a Ligação do IBM Web Service (SOAP/HTTP)
A ligação do IBM Web
Service (SOAP/HTTP) para um processo BPEL ou outro tipo de serviço pode ser migrada
para a construção SCA recomendada.
No WebSphere Studio
Application Developer Integration Edition, este tipo de ligação permitia que os clientes
se comunicassem com um processo BPEL ou outro tipo de serviço, chamando
um IBM Web
Service, no qual o protocolo de comunicação era HTTP e a mensagem seguia as regras
de codificação SOAP.
A seguir está um exemplo das convenções utilizadas
durante a geração de um IBM Web Service (SOAP/HTTP) para um serviço BPEL 5.1. O nome JNDI do IBM Web Service gerado era uma combinação do nome, espaço de nomes de destino e time stamp valid-from do BPEL, bem como o nome
da interface (tipo de porta WSDL para o qual o código de implementação foi gerado).
Por exemplo, estes atributos podem ser localizados examinando
as propriedades do processo BPEL no editor
BPEL nas guias de conteúdo Descrição e Servidor:
Tabela 8. Espaço de Nomes Gerado
Nome do Processo |
MyService |
Espaço de Nomes de Destino |
http://www.example.com/process87787141/ |
Válido a partir de |
01 de Jan de 2003 02:03:04 |
Interface |
ProcessPortType |
O espaço de nomes gerado para este exemplo é com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.
No WebSphere Studio
Application Developer Integration Edition, quando a ligação do IBM Web Service (SOAP/HTTP) foi selecionada como o tipo de implementação
para um processo BPEL ou outro tipo de serviço, foram especificadas as seguintes opções:
- Para Estilo de Documento, o padrão era RPC / outra opção:
DOCUMENT
- Para Utilização do Documento, o padrão era ENCODED / outra opção: LITERAL
- Para Endereço do Roteador, o padrão era http://localhost:9080
Um arquivo WSDL que especifica a ligação e o serviço SOAP/HTTP IBM Web Service é criado nos projetos
da Web e EJB gerados, mas não no próprio projeto de serviço.
Isto significa que você deve localizar manualmente esse arquivo e copiá-lo para seu projeto de módulo
de integração de negócios, se for importante que o código de cliente IBM Web Service não seja alterado.
Por padrão, este arquivo WSDL foi criado no projeto Web em
WebContent/WEB-INF/wsdl/<nome do processo de negócios>_<nome do tipo de porta da interface do processo de negócios>_HTTP.wsdl
O
PortType e Mensagens WSDL da interface do processo de negócios são realmente copiados
também para este arquivo WSDL, em vez de referir-se ao
PortType e Mensagens WSDL existentes no projeto de serviço.
Se for importante que
o código de cliente IBM
Web Service permaneça inalterado após a migração, as informações neste arquivo
serão requeridas para as etapas de migração manuais abaixo.
Existem
duas opções para migrar a ligação do processo SOAP/HTTP do WebSphere Studio Application Developer
Integration Edition. A opção terá que ser feita, se migrar o cliente para o modelo de programação
SCA ou se deixá-lo como um cliente de serviços da Web:
Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá
ser migrado para o novo modelo de programação.
Consulte o tópico apropriado para os seguintes tipos de clientes:
Tabela 9. Informações Adicionais para Migrar Clientes
Tipo de Cliente |
Para obter informações adicionais, consulte |
Cliente IBM Web Service |
"Migrando o Cliente IBM Web service (SOAP/HTTP)" |
Opção de Migração 1 para a Ligação do IBM Web Service (SOAP/HTTP)
A primeira opção de migração para a ligação do processo SOAP/HTTP do WebSphere Studio Application Developer
Integration Edition é tornar os processos de negócios
acessíveis a um cliente de serviços da Web.
A Exportação com Ligação de Serviço da Web torna um componente SCA acessível
por um cliente de serviços da Web externo. Para criar uma Exportação com Ligação de Serviço da Web, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente de Migração.
- Crie uma Exportação com Ligação SCA para cada interface de processo BPEL
que teve uma ligação IBM
Web Service (SOAP/HTTP) gerada para ela no WebSphere Studio Application Developer
Integration Edition, clicando com o botão direito do mouse no componente BPEL no Editor de Montagem.
- Selecione Exportar....
- Selecione Ligação de Serviço da Web.
- Se houver várias interfaces para o componente, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Selecione o transporte soap/http.
- Quando a Exportação de Serviços da Web for criada, selecione a exportação no
Editor de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição.
O nome e a descrição da Exportação são listados e podem ser modificados
se necessário.
- Salve o diagrama de montagem.
- Siga estas etapas para gerar um novo serviço e uma nova ligação de serviço da Web, se a preservação do código do cliente for desejada:
- Copie o arquivo WSDL da 5.1 do projeto EJB gerado da 5.1 em
ejbModule/META-INF/wsdl/nome do processo de negócios/nome do tipo de porta
da interface do processo de negócios_HTTP.wsdl para o projeto de módulo de integraçãode negócios.
- Depois de copiar sobre o arquivo e reconstruir o módulo, você poderá ver mensagens de erro porque os tipos de esquema XML, as mensagens do WSDL e os tipos de porta do WSDL utilizados pelo serviço da Web estão duplicados no arquivo WSDL do IBM Web Service na 5.1. Para corrigir isso, exclua essas definições duplicadas do WSDL de ligação/serviço do IBM Web Service e em seu lugar inclua uma importação do WSDL para o WSDL da interface real. Nota:
É importante observar que quando o WebSphere Studio Application Developer
Integration Edition gerou o código de implementação do IBM Web Service, ele modificou as definições de esquema em alguns casos. Isso poderá causar inconsistências para clientes existentes que utilizam o WSDL do IBM Web Service. Por exemplo, o atributo de esquema "elementFormDefault" foi definido para "qualificado" no esquema seqüencial gerado no WSDL do IBM Web Service mesmo que a definição de esquema original não tenha sido qualificada. Isso causará a geração do seguinte erro durante o tempo de execução:
WSWS3047E: Erro: Não é possível desserializar o elemento.
- Clique com o botão direito do mouse neste arquivo WSDL recém-copiado para o módulo de integração de negócios e selecione Abrir
com e, em seguida, Editor WSDL.
- Vá para a guia Origem. Exclua todos os
PortTypes e Mensagens WSDL definidos neste arquivo.
- Agora você verá o erro: O tipo de porta '<Tipo_de_porta>' especificado para a ligação '<ligação>' está indefinido.
Para corrigir isso, no editor WSDL da guia Gráfico, clique com o botão direito do mouse na seção Importações
e selecione Incluir Importação.
- Na visualização Propriedades na guia
Geral, clique no botão ... à direita
do campo Local. Procure o WSDL da interface no qual as definições de mensagem e de tipo de porta do WSDL estão localizadas e clique em OK para importar o WSDL da interface para o WSDL de serviço/ligação.
- Salve o arquivo WSDL.
- Atualize/reconstrua o projeto. Vá para a perspectiva Business Integration. Abra o Diagrama de Montagem do módulo no Editor de Montagem.
- Na visualização Explorador de Projeto, expanda o módulo que você está migrando e expanda a categoria lógica Portas de Serviço da Web. Você deve ver a porta existente no WSDL de ligação/serviço listado. Arraste-a e solte-a sobre o Editor de Montagem.
- Escolha a criação de uma Exportação com Ligação de Serviço da Web e selecione o nome de porta adequado. Isso criará a Exportação que utiliza a ligação/serviço antigo de forma que clientes de serviço da Web existentes não tenham de fazer alterações. Se você selecionar a exportação que acabou de criar no Editor de Montagem e for para a visualização Propriedades, na guia Ligação deverá ver que os nomes de porta e de serviço da 5.1 foram preenchidos.
- Salve todas as alterações.
- Pouco antes de implementar o aplicativo, você pode alterar a configuração do projeto da Web gerado para que corresponda ao endereço de serviço da 5.1 (você precisa fazer essas alterações toda vez que fizer alterações no módulo SCA, o que faz com que esse arquivo seja regenerado). Se você consultar a definição de serviço do IBM Web Service
WSDL que está reutilizando do 5.1, verá o endereço de serviço para o qual o cliente 5.1 é codificado: <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
- Para fazer com que os artefatos do projeto da Web gerado da 6.x correspondam a esse endereço de serviço antigo, você deve modificar o descritor de implementação do projeto da Web gerado. Abra o descritor de implementação no WebSphere Integration Developer e na guia Servlets, inclua um Mapeamento de URL adicional que é muito similar ao mapeamento de URL existente para aquela exportação, com o mesmo nome de servlet, mas um padrão de URL diferente.
- Além disso, se você precisar modificar a raiz de contexto deste projeto da Web
de forma que ela corresponda à raiz de contexto no endereço de serviço original (neste
exemplo, a raiz de contexto é "MyServiceWeb"), poderá abrir o descritor de implementação
para o J2EE Enterprise Application no qual este projeto da Web está localizado
e alterar a raiz de contexto desse módulo da Web para corresponder à raiz de contexto do endereço de serviço antigo.
Você poderá ver o seguinte erro que pode ser ignorado: CHKJ3017E:
Projeto da Web: <NOME DO PROJ DA WEB> está mapeado para uma raiz de Contexto inválida: <RAIZ DE CONTEXTO NOVO> no Projeto EAR: <NOME DO APLICATIVO>.
Opção de Migração 2 para a Ligação do IBM Web Service (SOAP/HTTP)
A segunda opção para a ligação do processo SOAP/HTTP do WebSphere Studio Application Developer
Integration Edition é tornar processos de negócios acessíveis a uma entidade
não-SCA (por exemplo, um cliente JSP ou Java).
A Referência Independente torna um componente SCA acessível
por qualquer cliente externo. Para criar uma Referência Independente, siga estas etapas:
- Abra o Editor de Montagem para o módulo criado pelo assistente
de migração.
- Crie uma Referência Independente para cada interface
que teve uma ligação IBM
Web Service (SOAP/HTTP) gerada para ela no WebSphere Studio Application Developer
Integration Edition:
- Selecione o item Referências Independentes
na barra de ferramentas.
- Clique no canvas do Editor de Montagem para criar uma
entidade SCA de Referências Independentes.
- Selecione o item Ligação na barra de ferramentas.
- Clique na entidade Referências Independentes
para selecioná-la como a origem da ligação.
- Clique no componente SCA para selecioná-lo
como o destino da ligação.
- Você verá um alerta A referência correspondente
será criada no nó de origem. Deseja continuar?, clique em OK.
- Selecione a entidade Referências Independentes
recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
- Expanda o link Referências e selecione
a referência recém-criada. O nome e a descrição da referência são listados
e podem ser modificados se necessário.
- Se houver várias interfaces para o processo, selecione
as interfaces a serem exportadas com este tipo de ligação.
- Salve o diagrama de montagem.
Migrando a Ligação do Apache Web Service (SOAP/HTTP)
A ligação do Apache Web Service (SOAP/HTTP) para um processo BPEL ou outro tipo de serviço pode ser migrada para a construção SCA recomendada.
No WebSphere Studio
Application Developer Integration Edition, este tipo de ligação permite que os clientes
se comuniquem com um processo BPEL ou outro tipo de serviço, chamando um
Apache Web Service.
No WebSphere Studio Application Developer
Integration Edition, quando a ligação do Apache Web Service foi selecionada como o tipo de implementação
para um processo BPEL ou outro tipo de serviço, foram especificadas as seguintes opções:
- Para Estilo de Documento, era RPC (nenhuma outra opção
disponível)
- Para ação do SOAP, era URN:WSDL PortType name
- Para Endereço, era http://localhost:9080/Service Project NameWeb/servlet/rpcrouter
- Para Utilizar Codificação, o padrão era yes (Se yes,
o Estilo de Codificação era configurado como: http://schemas.xmlsoap.org/soap/encoding/)
Um arquivo WSDL que especifica a ligação do Apache SOAP e o serviço
é criado no projeto de serviço. Por padrão, ele é criado no mesmo diretório que o serviço
que está agrupando com o nome <nome do processo de negócios>_<nome do tipo de porta de interface do processo de negócios>_SOAP.wsdl.
O PortType e Mensagens WSDL
da interface do processo de negócios são utilizados por esta ligação e serviço diretamente.
Após a migração, você não deve utilizar este WSDL para nada além de talvez
utilizar o mesmo espaço de nomes, porta e nomes de serviços no novo WSDL que será
gerado na Versão 6.x.
Existem
duas opções para migrar a ligação do processo do WebSphere Studio Application Developer Integration Edition Web Service. A opção terá que ser feita, se migrar o cliente para o modelo de programação
SCA ou se deixá-lo como um modelo de programação IBM Web Services. Não existe mais nenhuma ligação que seja
equivalente ao tipo de ligação do Apache Web Service (SOAP/HTTP)
no modelo de programação SCA da 6.
Você deve migrar esse Apache Web Service para utilizar o mecanismo do IBM Web Service. Consulte o tópico "Migrando a Ligação do IBM Web Service (SOAP/HTTP)"
para obter instruções sobre como executar essa migração e criar um IBM Web Service (SOAP/HTTP).
Para qualquer código Java de formato livre que interaja com um serviço do WebSphere Studio
Application Developer Integration Edition, esta seção mostrará como
migrar do modelo de programação do WSIF para o novo modelo de programação SCA
no qual os dados que fluem pelo aplicativo são armazenados nos SDOs
(Service Data Objects) do Eclipse. Esta seção também mostrará como migrar manualmente os tipos de cliente mais comuns para o novo modelo de programação.
Para qualquer processo BPEL que contenha snippets Java, esta seção explica como
migrar da API de snippet Java antiga para a nova API de snippet Java
na qual os dados que fluem pelo aplicativo são armazenados nos SDOs (Service
Data Objects) do Eclipse. Sempre que possível, os snippets são migrados automaticamente
pelo assistente de migração, mas existem snippets que o assistente de migração
não pode migrar totalmente, indicando que são requeridas etapas manuais para concluir a migração.
A seguir há um resumo das alterações no modelo de programação:
- Modelo de Programação da V5.1
-
- Baseado no WSIF e no WSDL
- Proxies gerados para serviços
- Rotinas de tratamento de beans e formatos para tipos
- Modelo de Programação da V6.x (Mais centralizado em Java)
-
- Serviços SCA baseados em SDOs com tags doclet
- Ligações de interface para serviços
- SDOs e Databindings para tipos
Migrando Chamadas de API WSIFMessage para APIs SDO
A seção a seguir detalha como migrar do modelo de programação antigo do WebSphere Business
Integration Server Foundation Versão 5.1 no qual os dados que fluem por meio do
aplicativo são representados como objetos WSIFMessage com uma
interface gerada que foi altamente especificada para o novo modelo de programação do WebSphere Process
Server no qual os dados são representados como SDOs (Service
Data Objects) e não é gerada nenhuma interface altamente especificada.
Tabela 10. Alterações e Soluções para Migrar Chamadas da API WSIFMessage para APIs do SDO
Alterar |
Solução |
As classes do wrapper baseadas no WSIFMessage não são mais geradas para tipos de mensagens do WSDL, nem são as classes do assistente do Java bean geradas para os tipos de esquema complexos. |
Ao escrever código que interage com serviços do SCA, as APIs genéricas do SDO devem ser utilizadas para manipular as mensagens commonj.sdo.DataObject que mantêm os dados que fluem através do aplicativo.
As definições de mensagem que têm uma única parte digitada simples agora serão representadas por um tipo Java simples que representa diretamente a parte em vez de ter um wrapper em torno dos dados reais. Se a única parte da mensagem for um tipo complexo, então, os dados serão representados como um DataObject que adere à definição do tipo complexo.
As definições de mensagens do WSDL que têm várias partes agora correspondem a um DataObject que tem propriedades para todas as partes da mensagem, em que complexTypes são representados como propriedades "reference-type" do DataObject pai, acessíveis através dos métodos getDataObject e setDataObject. |
Os métodos getter altamente especificados para partes WSIFMessage e os Java gerados não devem ser utilizados. |
A API SDO pouco especificada deve ser utilizada para obter as propriedades de DataObject. |
Os métodos setter altamente especificados para partes de mensagem das variáveis BPEL não estão mais disponíveis. |
A API SDO pouco especificada deve ser utilizada para definir as propriedades de DataObject. |
Os métodos getter pouco especificados para as propriedades de WSIFMessage não devem mais ser utilizados. |
A API SDO pouco especificada deve ser utilizada para definir as propriedades de DataObject. |
Os métodos setter pouco especificados para as propriedades de WSIFMessage não devem mais ser utilizados. |
A API SDO pouco especificada deve ser utilizada para definir as propriedades de DataObject. |
Todas as chamadas da API WSIFMessage devem ser migradas para a API SDO, onde possível. |
Migre a chamada para uma chamada de API SDO equivalente, onde possível. Se não for possível, projete novamente a lógica. |
Migrando o Código de Cliente do WebSphere Business Integration Server Foundation
Esta seção mostra como migrar os vários tipos de clientes que eram possíveis para os tipos de serviço do WebSphere Business Integration Server Foundation 5.1.
Migrando o Cliente EJB
Este tópico mostra como migrar clientes que utilizam uma interface EJB
para chamar um serviço.
- Arraste e solte a Exportação com Ligação SCA do módulo migrado
para o Editor de Montagem deste novo módulo. Isto criará uma Importação com Ligação SCA.
Para que um cliente obtenha uma referência a esta importação, deve ser
criada uma Referência Independente.
- Na paleta, selecione o item Referência Independente. Clique no canvas do
Editor de Montagem uma vez, para criar uma nova referência independente para este novo módulo.
- Selecione a ferramenta de ligação e clique na referência de serviço e, em seguida, clique em Importar.
- Clique em OK quando receber um alerta de que será criada uma referência
correspondente no nó de origem.
- Será perguntado: É mais fácil para um cliente Java utilizar uma interface
Java com esta referência - deseja converter a referência WSDL
em uma referência Java compatível?:
- Responda Sim se desejar que o cliente examine esse serviço e lance-o como uma classe Java para chamá-lo utilizando uma interface Java.
Esta nova interface Java
utiliza o nome do PortType WSDL, no qual o pacote da interface é derivado
do espaço de nomes do PortType WSDL. Existe um método definido
para cada operação definida no PortType WSDL, e cada parte da mensagem WSDL
é representada como um argumento para os métodos de interface.
- Responda Não se desejar que o cliente examine esse serviço e utilize a interface genérica com.ibm.websphere.sca.Service para chamá-lo utilizando a operação de chamada como um serviço SCA genérico.
- Renomeie a referência independente para um nome mais significativo, se apropriado,
selecionado o componente Referências Independentes no Editor de Montagem. Vá para
a visualização Propriedades, para a guia Detalhes, fazendo uma pesquisa detalhada e selecionando
a referência recém-criada e modificando o nome. Lembre-se do nome escolhido para essa referência porque o cliente precisará utilizar esse nome ao chamar o método locateService da instância com.ibm.websphere.sca.ServiceManager.
- Clique em Salvar para salvar o diagrama de Montagem.
O cliente deve ter este novo módulo em seu caminho de classe local para acessar
o módulo EJB migrado em execução no servidor.
A seguir é mostrado o aspecto
do código do cliente para um serviço de tipo "CustomerInfo":
// Crie um novo ServiceManager
ServiceManager serviceManager = ServiceManager.INSTANCE;
// Localize o serviço CustomerInfo
CustomerInfo customerInfoService = (CustomerInfo) serviceManager.locateService
("<name-of-standalone-reference-from-previous-step");
// Chame o serviço CustomerInfo
System.out.println(" [getMyValue] getting customer info...");
DataObject customer = customerInfoService.getCustomerInfo(customerID);
O cliente deve alterar a forma que a mensagem é construída. As mensagens eram baseadas na classe WSIFMessage, mas agora
elas devem ser baseadas na classe commonj.sdo.DataObject.
Migrando o Cliente de Ligação do Processo EJB
Este tópico mostra como migrar clientes que utilizam a ligação de processo EJB de WSIF para acessar um serviço BPEL.
Clientes que utilizaram a Ligação do Processo EJB para chamar um processo de negócios devem agora utilizar a API SCA para chamar o serviço (o processo de negócios migrado deve ter uma Exportação com Ligação SCA) ou a API do IBM Web Service Client para chamar o serviço (o processo de negócios migrado deve ter uma Exportação com Ligação de Serviço da Web).
Consulte os tópicos "Migrando o Cliente EJB", "Migrando o Cliente IBM Web Service (SOAP/JMS)" ou "Migrando o Cliente IBM Web
Service (SOAP/HTTP)" para obter informações adicionais sobre a geração de tais clientes.
Migrando o Cliente IBM Web Service (SOAP/JMS)
Este tópico mostra como migrar clientes que utilizam APIs do Web Service
(SOAP/JMS) para chamar um serviço.
Nenhuma migração é necessária para clientes existentes durante a migração. Observe que você deve modificar manualmente o projeto da Web gerado (criar um novo mapeamento de servlet) e, às vezes, modificar a raiz de contexto do projeto da Web no descritor de implementação do aplicativo corporativo para publicar o serviço para o mesmo endereço exato que foi publicado no WebSphere Business Integration Server
Foundation. Consulte o tópico "Migrando a Ligação IBM Web Service (SOAP/JMS)".
É importante observar que ao contrário da 5.1, na qual um proxy de cliente do WSIF ou RPC pode ser gerado, na 6.x as ferramentas suportam apenas a geração de cliente RPC, porque o RPC é a API preferida da 6.x em relação à API do WSIF.
Nota:
Para gerar um novo proxy de cliente a partir do WebSphere Integration Developer, é necessário ter um WebSphere Process Server ou um WebSphere Application Server instalado.
- Certifique-se de que tenha um WebSphere Process Server ou um WebSphere Application Server instalado.
- Na perspectiva Recursos ou Java, localize o arquivo do WSDL correspondente à Exportação com Ligação de Serviço da Web e, em seguida, clique com o botão direito do mouse e selecione Serviços da Web -> Gerar Cliente (Observe que esse assistente é muito similar ao assistente da 5.1).
- Para o Tipo de Proxy de Cliente, escolha Proxy Java e clique em Avançar.
- O local do WSDL deve ser preenchido. Clique em Avançar.
- Em seguida, você deve selecionar as opções adequadas para especificar a configuração do ambiente do cliente incluindo o tempo de execução e o servidor do serviço da Web, a versão do J2EE e o tipo de cliente (Java, EJB, Web, Application Client). Clique em Avançar.
- Finalize as etapas restantes para gerar o proxy de cliente.
Migrando o Cliente IBM Web Service (SOAP/HTTP)
Este tópico mostra como migrar clientes que utilizam APIs do Web Service
(SOAP/HTTP) para chamar um serviço.
Nenhuma migração é necessária para clientes existentes durante a migração. Observe que você deve modificar manualmente o projeto da Web gerado (criar um novo mapeamento de servlet) e, às vezes, modificar a raiz de contexto do projeto da Web no descritor de implementação do aplicativo corporativo para publicar o serviço para o mesmo endereço exato que foi publicado no WebSphere Business Integration Server
Foundation. Consulte o tópico "Migrando a Ligação IBM Web Service (SOAP/HTTP)".
Se tiverem ocorrido alterações de design e você desejar gerar um novo proxy de cliente, as seguintes etapas mostrarão como fazer isso. É importante observar que ao contrário da 5.1, na qual um proxy de cliente do WSIF ou RPC pode ser gerado, na 6.x as ferramentas suportam apenas a geração de cliente RPC, porque o RPC é a API preferida da 6.x em relação à API do WSIF.
Nota:
Para gerar um novo proxy de cliente a partir do WebSphere Integration Developer, é necessário ter um WebSphere Process Server ou um WebSphere Application Server instalado.
- Certifique-se de que tenha um WebSphere Process Server ou um WebSphere Application Server instalado.
- Selecione o arquivo do WSDL correspondente à Exportação com Ligação de Serviço da Web e, em seguida, clique com o botão direito do mouse e selecione Serviços da Web -> Gerar Cliente (Observe que esse assistente é muito similar ao assistente da 5.1).
- Para o Tipo de Proxy de Cliente, escolha Proxy Java e clique em Avançar.
- O local do WSDL deve ser preenchido. Clique em Avançar.
- Em seguida, você deve selecionar as opções adequadas para especificar a configuração do ambiente do cliente incluindo o tempo de execução e o servidor do serviço da Web, a versão do J2EE e o tipo de cliente (Java, EJB, Web, Application Client). Clique em Avançar.
- Finalize as etapas restantes para gerar o proxy de cliente.
Migrando o Cliente Apache Web Service (SOAP/HTTP)
As APIs do cliente Apache Web Service não são apropriadas para chamar
um serviço do WebSphere Integration
Developer. O código do cliente deve ser migrado para utilizar as APIs do cliente IBM Web Service
(SOAP/HTTP).
Consulte o tópico "Migrando o Cliente IBM Web Service (SOAP/HTTP)" para obter informações adicionais.
Na
5.1, se um proxy de cliente fosse automaticamente gerado, esse proxy utilizaria APIs do WSIF para interargir com o serviço. Na 6.x, as ferramentas suportam apenas a geração de cliente RPC porque o RPC é a API preferida da 6.x em relação à API do WSIF.
Nota:
Para gerar um novo proxy de cliente a partir do WebSphere Integration Developer, é necessário ter um WebSphere Process Server ou um WebSphere Application Server instalado.
- Certifique-se de que tenha um WebSphere Process Server ou um WebSphere Application Server instalado.
- Selecione o arquivo do WSDL correspondente à Exportação com Ligação de Serviço da Web e, em seguida, clique com o botão direito do mouse e selecione Serviços da Web -> Gerar Cliente (Observe que esse assistente é muito similar ao assistente da 5.1).
- Para o Tipo de Proxy de Cliente, escolha Proxy Java e clique em Avançar.
- O local do WSDL deve ser preenchido. Clique em Avançar.
- Em seguida, você deve selecionar as opções adequadas para especificar a configuração do ambiente do cliente incluindo o tempo de execução e o servidor do serviço da Web, a versão do J2EE e o tipo de cliente (Java, EJB, Web, Application Client). Clique em Avançar.
- Finalize as etapas restantes para gerar o proxy de cliente.
Migrando o Cliente JMS
Os clientes que se comunicaram com um serviço 5.1 por meio da API JMS (enviando uma
mensagem JMS para uma fila) podem requerer migração manual. Este tópico mostra como migrar
clientes que utilizam APIs JMS (enviando uma mensagem JMS para uma fila)
para chamar um serviço.
É necessário assegurar que a Exportação com Ligação JMS criada em uma etapa anterior possa aceitar esta mensagem de texto ou de objeto
sem alterações. Pode ser necessário gravar uma ligação de dados customizada para fazer isso.
Consulte a seção "Migrando o JMS e as Ligações de Processo JMS" para obter
informações adicionais.
O cliente deve alterar a forma que a mensagem é construída. Anteriormente, as mensagens eram baseadas na classe WSIFMessage mas agora
elas devem ser baseadas na classe commonj.sdo.DataObject. Consulte a seção "Migrando as Chamadas da API WSIFMessage para APIS do SDO" para obter detalhes adicionais como fazer essa migração manual.
Migrando o Cliente da API EJB Genérica do Business Process Choreographer
Este tópico mostra como migrar clientes que utilizam a API de EJB genérico do process choreographer 5.1 para chamar um serviço BPEL.
Existe uma nova versão da API de EJB Genérica que utiliza DataObjects
como seu formato de mensagem. O cliente deve alterar a forma que a mensagem é construída. Anteriormente, as mensagens eram baseadas na classe WSIFMessage mas agora
elas devem ser baseadas na classe commonj.sdo.DataObject. Observe que a API de
EJB Genérica não foi alterada significativamente, pois o ClientObjectWrapper ainda fornece
um wrapper de mensagem no formato de mensagem específico.
Ex: DataObject dobj = myClientObjectWrapper.getObject();
String result = dobj.getInt("resultInt");
O nome JNDI do EJB Genérico antigo que obtém o objeto WSIFMessage
é:
GenericProcessChoreographerEJB
Nome JNDI: com/ibm/bpe/api/BusinessProcessHome
Interface: com.ibm.bpe.api.BusinessProcess
Existem dois EJBs genéricos na 6.0 porque as operações de tarefa manual agora estão disponíveis como um EJB separado. Os nomes JNDI da 6.0 desses EJBs Genéricos são:
GenericBusinessFlowManagerEJB
JNDI Name: com/ibm/bpe/api/BusinessFlowManagerHome
Interface: com.ibm.bpe.api.BusinessFlowManager
HumanTaskManagerEJB
JNDI Name: com/ibm/task/api/TaskManagerHome
Interface: com.ibm.task.api.TaskManager
Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer e o Cliente de Ligação de Processo JMS
Não existe uma API do sistema de mensagens genérica no WebSphere Process Server. Consulte a seção
"Migrando o JMS e Ligações de Processo JMS" para escolher uma maneira diferente de
expor o processo de negócios para consumidores e regravar o cliente de acordo
com a ligação escolhida.
Migrando o Cliente da Web do Business Process Choreographer
Este tópico mostra como migrar as configurações do cliente Web do Process Choreographer 5.1 e JSPs customizados.
O assistente de Migração preserva as configurações do cliente Web 5.1 e, no
Human Task Editor, não é possível editar estas configurações. Você deve criar novas configurações
do cliente Web e JSPs utilizando o WebSphere Integration Developer 6.x.
- Migrando Modificações do Cliente Web
- Na 5.1, você pode modificar a aparência e comportamento do cliente Web baseado em Struts modificando
seu JSP Header.jsp e folha de estilo dwc.css.
Como o cliente Web 6.x (renomeado para Business Process
Choreographer Explorer) é baseado em JSF (Java Server Faces) em vez de Struts, a migração automática de modificações do cliente Web não é possível. Portanto, recomenda-se que você consulte a documentação do "Business Process Choreographer Explorer" para obter detalhes sobre a customização da versão 6.x desse aplicativo.
JSPs definidos pelo usuário poderão ser definidos para processos de negócios e para atividades de equipe. O cliente Web utiliza essas JSPs para exibir mensagens de entrada e saída para o processo e as atividades.
Essas JSPs são particularmente úteis quando:
- Mensagens têm partes não primitivas para aprimorar a usabilidade da estrutura de dados da mensagem.
- Você deseja estender as capacidades do cliente Web.
Existem opções adicionais e diferentes disponíveis ao especificar configurações do cliente Web para um processo 6.x, portanto você terá de utilizar o WebSphere Integration
Developer para reprojetar as configurações do cliente Web para processos e atividades migrados:
- Selecione o canvas do processo ou uma atividade no processo.
- Na visualização Propriedades, selecione a guia Cliente para reprojetar as configurações do cliente Web.
- Migre manualmente qualquer JSP definida pelo usuário:
- Consulte a seção "Migrando para o Modelo de Programação SCA" para obter as alterações do modelo de programação.
- O cliente Web utiliza as APIs Genéricas para interagir com processos de negócios.
Consulte as seções que mostram como migrar chamadas para essas APIs genéricas.
- Especifique o nome da nova JSP nas configurações do cliente Web 6.x para o processo
Nota: O mapeamento de JSPs não é necessário com o Business Process Choreographer Explorer 6.x Business Process
Choreographer Explorer porque os DataObjects não precisam de nenhum mapeamento customizado.
Migrando Snippets Java do BPEL do WebSphere Business Integration Server Foundation
Para processos BPEL que contenham snippets Java, esta seção detalha como
migrar da API de snippet Java antiga para a nova API de snippet Java
na qual os dados que fluem pelo aplicativo são armazenados como SDOs (Service
Data Objects) do Eclipse.
Consulte a seção "Migrando das Chamadas da API WSIFMessage para APIS do SDO" para obter as etapas de migração para executar ações específicas à transição do WSIFMessage para o SDO.
Sempre que possível, os snippets são migrados automaticamente
pelo assistente de migração, mas existem snippets que o assistente de migração
não pode migrar totalmente. Isto requer etapas manuais extras para concluir
a migração. Consulte o tópico Limitações para obter detalhes sobre os tipos de snippets Java que devem ser migrados manualmente.
Sempre que um desses snippets for encontrado, o assistente de Migração explicará por que ele não pode ser migrado automaticamente e emitirá uma mensagem de aviso ou de erro.
A seguinte tabela detalha as alterações no modelo de programação e na API do snippet Java
do BPEL do Process Choreographer versão 5.1 para 6.x:
Tabela 11. Alterações e Soluções para Migrar Snippets Javado BPEL do WebSphere Business Integration Server Foundation
Alterar |
Solução |
As classes do wrapper baseadas no WSIFMessage não são mais geradas para tipos de mensagens do WSDL, nem são as classes do assistente do Java bean geradas para os tipos de esquema complexos. |
As variáveis BPEL podem ser acessadas diretamente pelo nome. Observe que, para
variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis
agora representarão diretamente a parte em vez de ter um wrapper
ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application
Developer Integration Edition era um WSIFMessage).
Como as variáveis BPEL podem ser utilizadas diretamente nos snippets 6.x, há menos necessidade de variáveis locais do que havia na 5.1.
Os getters altamente especificados para as variáveis BPEL inicializavam implicitamente o objeto do wrapper WSIFMessage em torno das partes da mensagem. Não há nenhum objeto 'wrapper' para as variáveis BPEL cuja definição de mensagem do WSDL tem apenas uma única parte: nesse caso, as variáveis BPEL representam diretamente a parte (No caso em que a única parte é um tipo simples XSD, a variável BPEL será representada como o tipo de wrapper do objeto Java, como java.lang.String,
java.lang.Integer, etc). As variáveis BPEL com definições de mensagens do WSDL de várias partes são manipuladas de forma diferente: ainda há um wrapper em torno das partes e esse wrapper DataObject deve ser explicitamente inicializado no trecho de código Java 6.x se ainda não tiver sido definido por uma operação anterior.
Se qualquer variável local dos snippets da 5.1 tiver o mesmo nome da variável BPEL, poderão ocorrer conflitos; portanto, tente remediar essa situação, se possível. |
Os objetos WSIFMessage não são mais utilizados para representar variáveis BPEL. |
Se qualquer classe Java customizada chamada a partir dos snippets Java tiver um parâmetro WSIFMessage, ela precisará ser migrada de forma que aceite/retorne um DataObject. |
Os métodos getter altamente especificados para variáveis BPEL não estão mais disponíveis. |
As variáveis podem ser acessadas diretamente pelo nome. Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, agora representarão diretamente a parte em vez de ter um wrapper em torno dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application
Developer Integration Edition era um WSIFMessage). |
Os métodos setter altamente especificados para variáveis BPEL não estão mais disponíveis. |
As variáveis podem ser acessadas diretamente pelo nome. Observe que, para
variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis
agora representarão diretamente a parte em vez de ter um wrapper
ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application
Developer Integration Edition era um WSIFMessage). |
Os métodos getter pouco especificados para variáveis BPEL que retornam um WSIFMessage não estão mais disponíveis. |
As variáveis podem ser acessadas diretamente pelo nome. Observe que, para
variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis
agora representarão diretamente a parte em vez de ter um wrapper
ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application
Developer Integration Edition era um WSIFMessage).
Observe que há duas variações do método getVariableAsWSIFMessage:
getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName, boolean
forUpdate)
Para uma atividade de snippet Java, o acesso padrão é de leitura/gravação.
É possível alterá-lo para de leitura especificando @bpe.readOnlyVariables
com a lista de nomes das variáveis em um comentário no snippet. Por exemplo, você pode configurar
a variável B e a variável D como de leitura da seguinte forma:
variableB.setString("/x/y/z", variableA.getString("/a/b/c"));
// @bpe.readOnlyVariables names="variableA"
variableD.setInt("/x/y/z", variableC.getInt("/a/b/c"));
// @bpe.readOnlyVariables names="variableC"
Além disso, se você tiver um snippet Java em uma condição, as variáveis serão de leitura
por padrão, mas será possível torná-las de leitura/gravação especificando @bpe.readWriteVariables... |
Os métodos setter pouco especificados para variáveis BPEL não estão mais disponíveis. |
As variáveis podem ser acessadas diretamente pelo nome. Observe que, para
variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis
agora representarão diretamente a parte em vez de ter um wrapper
ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application
Developer Integration Edition era um WSIFMessage). |
Os métodos getter pouco especificados para partes de mensagem das variáveis BPEL não são adequados para mensagens de uma única parte e foram alterados para mensagens de várias partes. |
Migre para o método getter pouco especificado para as propriedades das variáveis BPEL (DataObject's).
Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, a variável BPEL representa diretamente a parte e deve ser acessada diretamente sem utilizar um método getter.
Há duas variações do método getVariablePartAsObject:
getVariablePartAsObject(String variableName, String
partName)
getVariablePartAsObject(String variableName, String
partName,boolean forUpdate)
Para mensagens de várias partes, a funcionalidade equivalente é fornecida para esse método na 6.x:
getVariableProperty(String variableName, QName
propertyName);
Na
6.x, não há nenhuma noção da utilização de uma variável para acesso de leitura (que era o caso na 5.1 para o primeiro método acima, bem como o segundo método com forUpdate='false'). A variável é diretamente utilizada no snippet da 6.x e está sempre apta para ser atualizada. |
Os métodos setter pouco especificados para partes de mensagem das variáveis BPEL não são adequados para mensagens de uma única parte e foram alterados para mensagens de várias partes. |
Migre para o método setter pouco especificado para as propriedades das variáveis BPEL (DataObject's).
Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, a variável BPEL representa diretamente a parte e deve ser acessada diretamente sem utilizar um método setter.
As chamadas para o seguinte método devem ser migradas:
setVariableObjectPart(String variableName,
String partName, Object data)
Para mensagens de várias partes, a funcionalidade equivalente é fornecida para esse método na 6.x:
setVariableProperty(String variableName, QName
propertyName, Serializable value); |
Os métodos getter altamente especificados para links de parceiros BPEL não estão mais disponíveis. |
Migre para os métodos getter pouco especificados para links de parceiros BPEL. |
Os métodos setter altamente especificados para links de parceiros BPEL não estão mais disponíveis. |
Migre para os métodos setter pouco especificados para links de parceiros BPEL. |
Os métodos getter altamente especificados para conjuntos de correlações BPEL não estão mais disponíveis. |
- Snippet da V5.1:
-
String corrSetPropStr =
getCorrelationSetCorrSetAPropertyCustomerName();
int corrSetPropInt =
getCorrelationSetCorrSetBPropertyCustomerId();
- Snippet da V6.x:
-
String corrSetPropStr = (String) getCorrelationSetProperty
("CorrSetA", new QName("CustomerName"));
int corrSetPropInt = ((Integer) getCorrelationSetProperty
("CorrSetB", new QName("CustomerId"))).intValue();
|
Parâmetros adicionais necessários para os métodos getter pouco especificados para propriedades customizadas da atividade BPEL. |
- Snippet da V5.1:
-
String val =
getActivityCustomProperty("propName");
- Snippet da V6.x:
-
String val = getActivityCustomProperty
("name-of-current-activity", "propName");
|
Parâmetros adicionais necessários para os métodos setter pouco especificados para propriedades customizadas da atividade BPEL. |
- Snippet da V5.1:
-
String newVal = "new value";
setActivityCustomProperty
("propName", newVal);
- Snippet da V6.x:
-
String newVal = "new value";
setActivityCustomProperty("name-of-current-activity",
"propName", newVal);
|
O método raiseFault(QName faultQName, Serializable message)
não existe mais. |
Migre para o raiseFault(QName faultQName, String variableName) onde possível; caso contrário, migre para o método raiseFault(QName faultQName) ou crie uma nova variável BPEL para o objeto Serializable. |
Migrando Interações com o WebSphere Business Integration Adapters
Se o JMS Client for um WebSphere Business Integration Adapter, poderá ser necessário utilizar as ferramentas External Service para criar a Importação
com Ligação JMS. Esta Importação utiliza uma ligação de dados especial para serializar
o SDO para o formato exato esperado pelo WebSphere Business Integration Adapter.
Para acessar a ferramenta External Service, siga estas etapas:
- Vá para Arquivo -> Novo -> Outro -> Business Integration e selecione External Service. Clique em Avançar.
- Escolha Adaptadores. Clique em Avançar.
- Digite o caminho do arquivo de configuração do WebSphere Business Integration Adapter
(.cfg) e o diretório que contém o esquema XML dos objetos de negócios
que o adaptador utiliza. Clique em Avançar.
- Examine a consulta que é gerada e, se estiver correta, clique em Executar Consulta. Na lista Objetos descobertos por consulta, selecione os objetos que deseja incluir (um a um) e clique no botão >> Incluir.
- Aceite os parâmetros de configuração para o objeto de negócios e clique em OK.
- Repita essa operação para cada objeto de negócios.
- Clique em Avançar.
- Para o Formato do objeto de negócios de tempo de execução selecione SDO.
Para o Projeto de Destino selecione o módulo que acabou de migrar.
Deixe o campo Pasta em branco.
- Clique em Concluir.
Esta ferramenta migrará os XSDs antigos para o formato esperado pela ligação de dados
especial, portanto, remova os XSDs antigos do WebSphere Business Integration Adapter
do módulo e utilize os novos XSDs. Se o módulo não for receber mensagens do adaptador, exclua as Exportações geradas por essa ferramenta. Se o módulo não enviar nenhuma mensagem para o adaptador, exclua a Importação. Consulte o
centro de informações para obter informações adicionais sobre este recurso.
Migrando Interfaces WSDL com Tipos de Matrizes Codificadas pelo SOAP
Esta seção mostra como migrar ou manipular esquemas XML que têm tipos de matrizes codificadas pelo SOAP.
Os tipos de matrizes codificados pelo SOAP que possuem o estilo RPC serão tratados
como seqüências não ligadas de um tipo concreto na 6.x. Não é recomendado que você crie nenhum tipo XSD que faça referência aos tipos soapend:Array de nenhuma maneira, porque o modelo de programação move-se em direção ao estilo Document/Literal agrupado em vez de ao estilo RPC (embora isso possa ser alterado).
Há casos em que um aplicativo SCA deve chamar um serviço externo que não utiliza o tipo soapend:Array. Em alguns casos, não existe
uma maneira de evitar isto, portanto, a seguir é mostrado como lidar com esta situação:
Código WSDL de amostra:
<xsd:complexType name="Vendor">
<xsd:all>
<xsd:element name="name" type="xsd:string" />
<xsd:element name="phoneNumber" type="xsd:string" />
</xsd:all>
</xsd:complexType>
</xsd:schema>
<xsd:complexType name="Vendors">
<xsd:complexContent mixed="false">
<xsd:restriction base="soapenc:Array">
<xsd:attribute wsdl:arrayType="tns:Vendor[]" ref="soapenc:arrayType"
xmlnxsd:wsdl="http://schemas.xmlsoap.org/wsdl/" />
</xsd:restriction>
</xsd:complexContent>
<xsd:complexType name="VendorsForProduct">
<xsd:all>
<xsd:element name="productId" type="xsd:string" />
<xsd:element name="vendorList" type="tns:Vendors" />
</xsd:all>
</xsd:complexType>
<xsd:complexType name="Product">
<xsd:all>
<xsd:element name="productId" type="xsd:string" />
<xsd:element name="productName" type="xsd:string" />
</xsd:all>
</xsd:complexType>
<message name="doFindVendorResponse">
<part name="returnVal" type="tns:VendorsForProduct" />
</message>
<operation name="doFindVendor">
<input message="tns:doFindVendor" />
<output message="tns:doFindVendorResponse" />
</operation>
Código de amostra para um cliente deste Serviço da Web:
// Localize o serviço do fornecedor e a operação doFindVendor
Service findVendor=(Service)ServiceManager.INSTANCE.locateService("vendorSearch");
OperationType doFindVendorOperationType=findVendor.getReference().getOperationType("doGoogleSearch");
// Crie o DataObject de entrada
DataObject doFindVendor=DataFactory.INSTANCE.create(doFindVendorOperationType.getInputType());
doFindVendor.setString("productId", "12345");
doFindVendor.setString("productName", "Refrigerator");
// Chame o serviço FindVendor
DataObject FindVendorResult = (DataObject)findVendor.invoke(doFindVendorOperationType, doFindVendor);
// Exiba os resultados
int resultProductId=findVendorResult.getString("productId");
DataObject resultElements=findVendorResult.getDataObject("vendorList");
Sequence results=resultElements.getSequence(0);
for (int i=0, n=results.size(); i
for (int i=0, n=results.size(); i
Aqui há outro exemplo em que o tipo de raiz do objeto de dados é um soapenc:Array.
Observe como o
sampleElements DataObject é criado utilizando o segundo esquema listado acima.
O tipo do DataObject é obtido primeiro e, em seguida, é obtida a propriedade para sampleStructElement.
Isso é realmente uma propriedade do sinalizador de substituição e é utilizada apenas para obter uma propriedade válida a ser utilizada ao incluir o DataObjects na seqüência.
Um padrão como esse pode ser utilizado em seu cenário:
Código WSDL de amostra:
<s:schema elementFormDefault="qualified" targetNamespace="http://soapinterop.org/xsd">
<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
<s:import namespace="http://schemas.xmlsoap.org/wsdl/" />
<s:complexType name="SOAPStruct">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varInt" type="s:int" />
<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varString" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varFloat" type="s:float" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfSOAPStruct">
<s:complexContent mixed="false">
<s:restriction base="soapenc:Array">
<s:attribute wsdl:arrayType="s0:SOAPStruct[]" ref="soapenc:arrayType" />
</s:restriction>
</s:complexContent>
</s:complexType>
</s:schema>
<wsdl:message name="echoStructArraySoapIn">
<wsdl:part name="inputStructArray" type="s0:ArrayOfSOAPStruct" />
</wsdl:message>
<wsdl:message name="echoStructArraySoapOut">
<wsdl:part name="return" type="s0:ArrayOfSOAPStruct" />
</wsdl:message>
<wsdl:operation name="echoStructArray">
<wsdl:input message="tns:echoStructArraySoapIn" />
<wsdl:output message="tns:echoStructArraySoapOut" />
</wsdl:operation>
<schema targetNamespace="http://sample/elements"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://sample/elements">
<element name="sampleStringElement" type="string"/>
<element name="sampleStructElement" type="any"/>
</schema>
Código de amostra para um cliente deste Serviço da Web:
// Crie o DataObject de entrada e obtenha a seqüência de SDO para qualquer
// elemento
DataFactory dataFactory=DataFactory.INSTANCE;
DataObject arrayOfStruct = dataFactory.create("http://soapinterop.org/xsd","ArrayOfSOAPStruct");
Sequence sequence=arrayOfStruct.getSequence("any");
// Obtenha a propriedade de SDO para o elemento de amostra que desejamos utilizar
// aqui para ocupar a seqüência
// Definimos este elemento em um arquivo XSD, consulte SampleElements.xsd
DataObject sampleElements=dataFactory.create("http://sample/elements",
"DocumentRoot");
Property property = sampleElements.getType().getProperty("sampleStructElement");
// Inclua os elementos na seqüência
DataObject item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 1);
item.setString("varString", "Hello");
item.setFloat("varFloat", 1.0f);
sequence.add(property, item);
item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 2);
item.setString("varString", "World");
item.setFloat("varFloat", 2.0f);
sequence.add(property, item);
// Chame a operação echoStructArray
System.out.println("[client] invoking echoStructArray operation");
DataObject echoArrayOfStruct = (DataObject)interopTest.invoke("echoStructArray", arrayOfStruct);
// Exiba os resultados
if (echoArrayOfStruct!=null) {
sequence=echoArrayOfStruct.getSequence("any");
for (int i=0, n=sequence.size(); i<n; i++) {
item=(DataObject)sequence.getValue(i);
System.out.println("[client] item varInt = "+
item.getInt("varInt")+"
varString="+item.getString("varString")+"
varFloat="+item.getFloat("varFloat"));
Migrando Projetos EJB do WebSphere Business Integration
No WebSphere Studio
Application Developer Integration Edition, os projetos EJB podem ter recursos especiais do WebSphere Business
Integration como o Extended Messaging (CMM) e CMP/A (Component-managed
Persistence Anywhere). Os descritores de implementação para tais projetos devem ser migrados e esta seção mostra como executar essa migração.
Para desempenhar essa migração, siga estas etapas:
- Copie o projeto EJB do WebSphere Business Integration EJB para o novo espaço de trabalho e importe-o a partir do WebSphere Integration
Developer utilizando o assistente Arquivo -> Importar -> Projeto Existente para Espaço de Trabalho.
Opcionalmente, você também pode executar o assistente de Migração do J2EE.
- Feche todas as instâncias do WebSphere Integration Developer em execução no espaço de trabalho da 6.x.
- Execute o seguinte script que migrará os descritores de implementação do WebSphere Business Integration no projeto EJB:
- No Windows:
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.bat
- No Linux:
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.sh
Os seguintes parâmetros são suportados, em que o nome do espaço de trabalho e do projeto são obrigatórios:
Uso: WSADIEEJBProjectMigration.bat
[-e eclipse-folder] -d workspace -p project
eclipse-folder: O local da pasta do eclipse -- normalmente é 'eclipse'
localizado na pasta de instalação do produto.
workspace: O espaço de trabalho que contém o projeto EJB do WSADIE a ser migrado.
project: O nome do projeto a ser migrado.
Por exemplo:
WSADIEEJBProjectMigration.bat -e "C:\IBM\WID6\eclipse" -d "d:\my60workspace" -p "MyWBIEJBProject"
- Ao abrir o WebSphere Integration Developer, você precisará atualizar o projeto EJB para obter os arquivos atualizados.
- Procure o arquivo ibm-web-ext.xmi no projeto EJB. Se um for localizado, certifique-se de que a seguinte linha esteja presente no arquivo sob o elemento:
<webappext:WebAppExtension> element:
<webApp href="WEB-INF/web.xml#WebApp"/>
- Remova o código de implementação antigo que foi gerado na 5.1. Gere novamente o código de implementação seguindo as diretrizes do WebSphere Application Server.
Excluindo Manualmente Definições do WSIF (Web Services Invocation Framework) 5.1
Depois de concluir a migração de seus artefatos de origem, é necessário excluir
todas as definições WSDL de Ligação e Serviço do WSIF 5.1 de seus projetos de 6.x que não estão sendo mais utilizados. O cenário de consumo para migração de serviço
é o único caso em que uma Ligação ou Serviço do WSIF ainda estaria sendo utilizado.
Os espaços de nomes
WSDL a seguir indicam que uma definição de ligação ou de serviço é um Serviço do
WSIF 5.1 e pode ser descartado se não for mais utilizado:
- Espaço de Nomes de WSIF EJB:
- http://schemas.xmlsoap.org/wsdl/ejb/
- Espaço de Nomes de WSIF Java:
- http://schemas.xmlsoap.org/wsdl/java/
- Espaço de Nomes de WSIF JMS:
- http://schemas.xmlsoap.org/soap/jms/
- Espaço de Nomes de WSIF do Processo de Negócios:
- http://schemas.xmlsoap.org/wsdl/process/
- Espaço de Nomes de WSIF do Transformador:
- http://schemas.xmlsoap.org/wsdl/transformer/
- Espaço de Nomes de WSIF do IMS:
- http://schemas.xmlsoap.org/wsdl/ims/
- Espaço de Nomes de WSIF CICS-ECI:
- http://schemas.xmlsoap.org/wsdl/cicseci/
- Espaço de Nomes de WSIF CICS-ECI:
- http://schemas.xmlsoap.org/wsdl/cicsepi/
- Espaço de Nomes de WSIF do HOD:
- http://schemas.xmlsoap.org/wsdl/hod3270/
Verificando a Migração de Artefatos de Origem
Se a migração for concluída com uma lista de mensagens de erro, aviso e/ou informativas, elas serão exibidas na janela Resultados da Migração (Migration Results).
Caso contrário, a janela do assistente será fechada se a migração foi concluída com êxito.
A página a seguir aparece se tiverem sido geradas mensagens de migração durante o processo de migração:
Na janela Resultados da Migração (Migration Results), é possível ver as mensagens de migração geradas durante o processo de migração. Selecionando uma mensagem da lista Mensagens (Message) superior, é possível localizar informações adicionais em relação a essa mensagem na janela Descrição de Mensagem (Message Description) inferior.
Para guardar todas as mensagens para futuras consultas, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização de tarefa e/ou clique no botão Salvar como... (Save as...) para salvar as mensagens em um arquivo de texto no sistema de arquivos.
Examine cada mensagem para verificar se é necessário tomar alguma ação para corrigir imediatamente um artefato que não pôde ser totalmente migrado.
Para ver a lista A Fazer gerada, clique em
Janela -> Mostrar
Visualização -> Outra... -> Geral -> Tarefas
e clique em OK.
A visualização de Tarefas é aberta com a lista de A Fazer gerada a
partir do processo de migração.
Para verificar
se uma parte da migração foi concluída, vá para a perspectiva Business
Integration e certifique-se de que todos os processos e interfaces WSDL
do projeto de serviço antigo apareçam no novo módulo. Construa o projeto
e corrija quaisquer erros que impedem a construção do projeto.
Depois de executar as etapas de migração manuais requeridas para concluir a migração do aplicativo Business Integration, exporte o aplicativo como um arquivo EAR e instale-o em um WebSphere Process Server, configurando os recursos apropriados.
Desempenhe as etapas de migração
manuais requeridas para migrar qualquer código de cliente ou gerar novo código de cliente utilizando o WebSphere Integration
Developer. Certifique-se de que o cliente possa acessar o aplicativo e que o aplicativo
tenha o mesmo comportamento existente no ambiente de tempo de execução anterior.
Trabalhando com Falhas de Migração de Artefatos de Origem
Se a migração de artefatos de origem do WebSphere Studio Application Developer
Integration Edition falhar, existem várias maneiras de lidar com
as falhas.
A seguir estão algumas das possíveis falhas de migração de artefatos de origem:
Se o assistente de Migração for concluído sem esta mensagem, será exibida uma lista de mensagens informativas, de aviso e de erro. Elas significam que alguma parte do projeto de serviço
não pôde ser migrada automaticamente e que as alterações manuais devem ser executadas para completar a migração.
Limitações do Processo de Migração (Para Migração de Artefatos de Origem)
Existem algumas limitações envolvidas no processo de migração de artefatos de origem do WebSphere Studio
Application Developer Integration Edition.
As listas a seguir detalham algumas das limitações do processo de migração
para migração de artefatos de origem:
Limitações Gerais
- O WebSphere Studio Application Developer Integration Edition não impunha rigorosamente a consistência entre WSDLs e outros artefatos em projetos. O WebSphere Integration Developer é muito mais rigoroso e relata as inconsistências que o WebSphere Studio Application Developer Integration Edition não relatava (e que também eram executadas no tempo de execução do WebSphere Business Integration Server Foundation sem nenhum problema).
- Embora o WebSphere Studio Application Developer Integration Edition permitisse várias definições idênticas de Ligação de Serviço da Web e de Serviço (nome e espaço de nomes), o WebSphere não permite. É necessário resolver essas duplicatas manualmente antes da migração (no WebSphere Studio Application Developer Integration Edition) ou depois da migração (no WebSphere Integration Developer). Por exemplo, no WebSphere Studio Application Developer Integration Edition, todas as definições de serviço geradas nos arquivos WSDL com nomes diferentes (terminando com _EJB, _JMS, etc) tinham este aspecto:
<service name="OrderProcessIntfcService">
Para corrigir a duplicata, simplesmente anexe o tipo de ligação ao nome do arquivo. Para o arquivo *_EJB.wsdl, ele seria alterado para
<service name="OrderProcessIntfcServiceEJB">
Para o arquivo *_JMS.wsdl, ele seria alterado para
<service name="OrderProcessIntfcServiceJMS">
No entanto, depois que esse nome é alterado, a Exportação gerada no WebSphere Integration Developer para utilizar esse serviço também deverá ser alterada para utilizar o nome correto.
- Este assistente de Migração não pode manipular espaços de trabalho inteiros do WebSphere Studio Application Developer
Integration Edition. Ele destina-se a migrar um projeto de serviço do WebSphere Studio
Application Developer Integration Edition de cada vez.
- O assistente de Migração não migra binários de aplicativos, ele migra apenas
artefatos de origem localizados em um projeto de serviço do WebSphere Studio Application Developer Integration
Edition.
- O Business Rule Beans foi reprovado no WebSphere Process Server 6.x mas existe uma opção
durante a instalação do WebSphere Process Server para instalar o suporte para o
Business Rule Beans reprovado, de forma que ele será executado "como está" em
um servidor do WebSphere Process Server 6.x. No entanto, não existe nenhum suporte a ferramentas para o Business
Rule Beans antigo e se você desejar que os artefatos do Business Rule Bean antigo sejam compilados
nas ferramentas, deverá seguir a documentação do WebSphere Integration Developer para instalar esses recursos reprovados sobre o servidor de teste do WebSphere Process
Server 6.x incorporado e, em seguida, incluir manualmente os arquivos jar reprovados
no caminho de classe do projeto como jars externos. Você deve utilizar as novas ferramentas do Business Rule disponíveis no WebSphere Integration Developer para recriar suas regras de negócios de acordo com a especificação de 6.x.
- O suporte ao Extended Messaging foi reprovado no WebSphere Process Server 6.x mas existe uma opção
durante a instalação do WebSphere Process Server para instalar suporte para os recursos
reprovados do Extended Messaging, de forma que os aplicativos existentes possam ser executados "como estão" em um servidor do WebSphere Process Server 6.x. No entanto, não existe nenhum suporte a ferramentas para os recursos do Extended
Messaging antigo e, se você desejar que os artefatos do Extended Messaging Bean antigo sejam compilados
nas ferramentas, deverá seguir a documentação do
WebSphere Integration Developer para instalar esses recursos reprovados sobre o servidor de teste do WebSphere Process
Server 6.x incorporado e, em seguida, incluir manualmente os arquivos jar reprovados
no caminho de classe do projeto como "jars externos".
- A ligação de dados JMS padrão fornecida não oferece acesso a propriedades de cabeçalho
JMS customizadas. Uma ligação de dados customizada deve ser gravada para que os serviços SCA
obtenham acesso a quaisquer propriedades de cabeçalho JMS customizadas.
Limitações do Modelo de Programação SCA
- A especificação do SDO versão 1 não fornece acesso à matriz de byte COBOL ou C - isso terá impacto nos que trabalham com vários segmentos IMS.
- A especificação do SDO versão 1 para serialização não suporta redefinições COBOL ou uniões C.
- Ao reprojetar os artefatos de origem de acordo com o modelo de programação SCA, observe que o estilo document/literal agrupado do WSDL (que é o estilo padrão para os novos artefatos criados utilizando as ferramentas do WebSphere Integration Developer)
não suporta a sobrecarga de métodos. Os outros estilos do WSDL ainda são suportados, portanto, é recomendado que outro estilo/codificação do WSDL diferente de document/literal agrupado seja utilizado para esses casos.
- O suporte nativo para matrizes é limitado. Para chamar um serviço externo que expõe
uma interface WSDL com tipos soapenc:Array, será necessário criar uma interface
WSDL que define um elemento cujo atributo "maxOccurs" seja maior que um
(esta é a abordagem recomendada para projetar um tipo de matriz).
Limitações Técnicas do Processo de Migração de BPEL
- Várias Respostas por Operação de BPEL - No WebSphere Business
Integration Server Foundation, um processo de negócios poderia ter uma atividade de recebimento
e várias atividades de resposta para a mesma operação. 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.x, apenas um conjunto de configurações do cliente será suportado por resposta de operação.
- Limitações de Migração do Snippet Java BPEL - O modelo de programação
foi alterado significativamente do WebSphere Studio Application Developer
Integration Edition para o WebSphere Integration Developer e nem todas as APIs suportadas do WebSphere Studio
Application Developer Integration Edition podem ser migradas diretamente
para as APIs correspondentes do WebSphere Integration
Developer. Qualquer lógica Java pode ser localizada nos snippets Java BPEL
de modo que a ferramenta de migração automática pode não estar apta a converter cada snippet Java
para o novo modelo de programação. A maior parte das chamadas de API do snippet padrão será migrada
automaticamente do modelo de programação do snippet Java 5.1 para o modelo de programação do snippet Java 6.x. As chamadas de API do WSIF são migradas para as chamadas da API DataObject
onde for possível. As classes Java customizadas que aceitam objetos WSIFMessage
precisarão de migração manual de forma que então aceitem e retornem objetos commonj.sdo.DataObject:
- APIs de Metadados WSIFMessage - A migração manual pode ser necessária para alguns metadados WSIFMessage e outras APIs do WSIF.
- APIs EndpointReference/EndpointReferenceType -
Estas classes não são migradas automaticamente. A migração manual é necessária
porque os métodos getter/setter de link do parceiro lidam com objetos commonj.sdo.DataObject
em vez dos objetos com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType
da 5.1.
- Tipos Complexos com Nomes Duplicados - Se um aplicativo declarar tipos
complexos (em WSDLs ou XSDs) com espaços de nomes e nomes locais idênticos
ou espaços de nomes diferentes mas nomes locais idênticos, os snippets Java
que utilizam estes tipos poderão não ser migrados corretamente. Verifique se os
snippets estão corretos após a conclusão do assistente de migração.
- Tipos complexos com nomes locais idênticos a classes Java
no pacote java.lang - Se um aplicativo declarar tipos complexos
(em WSDLs ou XSDs) com nomes locais idênticos a classes no pacote java.lang
do J2SE 1.4.2, os snippets Java que utilizam a classe
de java.lang correspondente poderão não ser migrados corretamente. Verifique se os
snippets estão corretos após a conclusão do assistente de migração.
- Variáveis BPEL de leitura e de leitura/gravação - Em qualquer trecho de código
Java 5.1,
era possível configurar uma variável BPEL como "de leitura", indicando que as alterações
feitas neste objeto não afetarão o valor da variável BPEL.
Também era possível configurar uma variável BPEL como de "leitura/gravação", indicando que as
alterações feitas no objeto seriam refletidas para a própria variável BPEL.
A seguir são mostradas quatro maneiras em que um snippet Java poderia ser acessado como "de leitura"
em qualquer snippet Java de BPEL 5.1:
getMyInputVariable()
getMyInputVariable(false)
getVariableAsWSIFMessage("MyInputVariable")
getVariableAsWSIFMessage("MyInputVariable", false)
A seguir estão duas maneiras em que uma variável BPEL poderia ser acessada como
de "leitura/gravação" em qualquer snippet Java de BPEL 5.1:
getMyInputVariable(true)
getVariableAsWSIFMessage("MyInputVariable", true)
Na 6.x,
o acesso de leitura e de leitura/gravação a variáveis BPEL é manipulado em uma "base por snippet", indicando que é possível incluir um comentário especial no snippet Java de BPEL para especificar se as atualizações na variável
BPEL devem ser descartadas ou mantidas após a conclusão da execução do snippet. A seguir estão as configurações de acesso padrão para os tipos de snippet Java BPEL 6.x:
Atividade de Snippet Java de BPEL
Acesso Padrão: leitura/gravação
Substituir Acesso Padrão pelo comentário contendo:
@bpe.readOnlyVariables names="variableA,variableB"
Expressão de Snippet Java de BPEL (Utilizada em um Tempo Limite, Condição, etc)
Acesso Padrão: de leitura
Substituir Acesso Padrão pelo comentário contendo:
@bpe.readWriteVariables names="variableA,variableB"
Durante a migração, estes comentários serão criados automaticamente quando uma variável tiver sido acessada
de uma maneira que não seja o padrão na 6.x. No caso de haver um conflito
(indicando que a variável BPEL foi acessada como "de leitura" e como "leitura/gravação"
no mesmo snippet), será emitido um aviso e o acesso será configurado como "leitura/gravação".
Se você receber algum desses avisos, certifique-se de que a configuração do acesso à variável BPEL como de "leitura/gravação" esteja correta para sua situação. Se ela não estiver correta, será necessário
corrigi-la manualmente utilizando o editor BPEL do WebSphere Integration Developer.
- Propriedades primitivas com diversos valores em tipos complexos -
Na 5.1, as propriedades com diversos valores são representadas por matrizes do
tipo da propriedade. Por isso, as chamadas para obter e configurar a propriedade utilizam matrizes. Na 6.x,
java.util.List é utilizado para esta representação. A migração automática manipulará todos os casos
em que a propriedade com diversos valores é algum tipo de objeto Java, mas no caso de o tipo da propriedade
ser um primitivo Java (int, long, short, byte, char, float,
double e boolean), as chamadas para obter e configurar toda a matriz não são convertidas.
A migração manual neste caso pode exigir a inclusão de um loop para agrupar/desagrupar
os primitivos em/de sua classe de wrapper Java (Integer, Long, Short,
Byte, Character, Float, Double e Boolean) para utilização no restante do snippet.
- Instanciação de classes geradas que representam tipos complexos -
Na 5.1, as classes geradas de tipos complexos definidos em um aplicativo podem ser
facilmente instanciadas em um snippet Java utilizando o construtor sem argumento padrão.
Um exemplo disto é:
MyProperty myProp = new MyProperty();
InputMessageMessage myMsg = new InputMessageMessage();
myMsg.setMyProperty(myProp);
Na 6.x, uma classe de depósito de informações do provedor especial deve ser utilizada para instanciar
estes tipos ou uma instância do tipo de abrangência pode ser utilizada para criar o subtipo. Se uma variável de processo BPEL InputVariable tiver sido definida como tendo o tipo InputMessage,
a versão 6.x do snippet precedente será:
com.ibm.websphere.bo.BOFactory boFactory=
(com.ibm.websphere.bo.BOFactory)
com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService(
"com/ibm/websphere/bo/BOFactory");
commonj.sdo.DataObject myMsg =
boFactory.createByType(getVariableType("InputVariable"));
commonj.sdo.DataObject myProp =
myMsg.createDataObject("MyProperty");
O conversor de snippet tenta fazer esta alteração mas, se a ordem em que
ocorrem as instanciações originais não seguir o padrão parent-then-child, a migração
manual será requerida (ou seja, o conversor não tenta reordenar de maneira inteligente
as instruções de instanciação no snippet).
- No WebSphere Business
Integration Server Foundation 5.1, referências dinâmicas são representadas como partes de mensagens do WSDL do tipo EndpointReferenceType ou elemento EndpointReference a partir do espaço de nomes:
http://wsaddressing.bpel.srm.websphere.ibm.com
Tais referências serão migradas para o tipo de elemento service-ref padrão a partir do espaço de nomes do processo de negócios padrão:
http://schemas.xmlsoap.org/ws/2004/03/business-process/
http://schemas.xmlsoap.org/ws/2004/08/addressing
Consulte a documentação do BPEL Editor para obter instruções sobre a importação manual dessas definições de esquema para o seu projeto a fim de que todas as referências sejam resolvidas adequadamente.
- Tipo de Mensagem de Variável BPEL - Um tipo de mensagem WSDL deve ser especificado para todas as variáveis BPEL utilizadas em snippets Java. Não é possível migrar snippets Java que acessam variáveis BPEL sem o atributo "messageType" especificado.
Avisos
Direitos Restritos para Usuários
do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule
Contract com a IBM Corporation.
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos. É possível que a IBM não ofereça os produtos,
serviços ou recursos discutidos nesta publicação em outros países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM(R), não significa que apenas produtos, programas ou serviços IBM
possam ser utilizados.
Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM, poderá se utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM são de responsabilidade do Cliente.
A IBM pode ter patentes ou solicitação de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240
Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS OU CONDIÇÕES DE NÃO-INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.
Alguns países não permitem a exclusão de garantias expressas
ou implícitas em certas transações; portanto, esta disposição pode não se aplicar
ao Cliente.
Estas informações podem conter imprecisões técnicas ou erros
tipográficos. Periodicamente, são
feitas alterações nas informações aqui contidas; tais alterações serão
incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aviso
prévio.
Referências nestas informações a Web sites não-IBM são
fornecidas apenas por conveniência e não representam de forma alguma
um endosso a esses Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais desse produto IBM e a utilização desses Web sites é de inteira responsabilidade do Cliente.
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.
Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240
Tais informações podem estar disponíveis, sujeitas a termos e
condições apropriadas, incluindo em alguns casos o pagamento de uma taxa.
O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato de Licença de Programa Internacional IBM ou de qualquer outro contrato equivalente.
Todos os dados de desempenho aqui contidos foram determinados
em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas de nível de desenvolvimento e não há garantia de que estas medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas medidas podem ter sido estimadas por
extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados aplicáveis para seu ambiente específico.
As informações relativas a produtos não-IBM foram obtidas junto aos fornecedores dos respectivos
produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos
não-IBM. Dúvidas sobre os recursos de produtos não-IBM devem ser encaminhadas diretamente a seus fornecedores.
Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aviso prévio e
representam apenas metas e objetivos.
Estas informações contêm exemplos de dados e relatórios utilizados
nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança com nomes e endereços utilizados por uma empresa real é mera coincidência.
LICENÇA DE COPYRIGHT:
Estas informações contêm programas de aplicativos de exemplo na linguagem
fonte, ilustrando as técnicas de programação em diversas
plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM,
com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo
para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM
não pode garantir ou implicar confiabilidade, manutenção ou função destes
programas. O Cliente pode copiar, modificar e distribuir estes programas de exemplo de qualquer maneira sem pagamento à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com interfaces de programação de aplicativos da IBM.
Cada cópia ou parte destes programas de exemplo ou qualquer trabalho derivado deve incluir um aviso de copyright com os dizeres:
(C) (nome da empresa) (ano). Partes deste código são derivadas dos
Programas de Exemplo da IBM Corp. (C) Copyright IBM Corp. 2000, 2007. Todos os direitos reservados.
Se estas informações estiverem sendo exibidas em cópia eletrônica,
as fotografias e ilustrações coloridas podem não aparecer.
Informações sobre a Interface de Programação
As informações sobre interface de programação destinam-se a facilitar a criação de software aplicativo utilizando este programa.
As interfaces de programação de uso geral permitem que o cliente desenvolva o software aplicativo que obtém os serviços das ferramentas deste programa.
No entanto, estas informações também podem conter informações sobre diagnósticos, modificações e ajustes. As informações sobre diagnósticos, modificações e ajustes são fornecidas para ajudá-lo a depurar seu software aplicativo.
Aviso:
Não utilize estas informações sobre diagnósticos, modificações e ajustes
como uma interface de programação, pois elas estão sujeitas a alterações.
Marcas Registradas e Marcas de Serviço
IBM,
o Logotipo IBM, WebSphere, Rational, DB2, Universal Database DB2, Tivoli, Lotus, Passport
Advantage, developerWorks, Redbooks, CICS, z/OS,
e IMS
são marcas ou marcas registradas da International Business Machines Corporation
nos Estados Unidos e/ou em outros países.
UNIX
é uma marca registrada do The Open Group nos Estados Unidos e/ou em
outros países.
Java
e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas
registradas da Sun Microsystems, Inc. nos Estados Unidos e/ou em
outros países.
Microsoft
e Windows
são marcas ou marcas registradas da
Microsoft
Corporation nos Estados Unidos e/ou em outros países.
Linux
é uma marca registrada de Linus Torvalds nos Estados Unidos e/ou em
outros países.
Adobe é uma marca ou marca registrada da Adobe Systems Incorporated nos
Estados Unidos e/ou em outros países.
Outros nomes de empresas, produtos e serviços podem ser
marcas registradas ou marcas de serviço de terceiros.
Termos de Uso
Permissões para uso de publicações são concedidas para os
seguintes termos e condições.
Uso Pessoal: O cliente pode reproduzir essas publicações
para uso pessoal, não comercial, desde que todos os avisos do
proprietário sejam preservados.
Não é permitido distribuir, exibir ou criar trabalho derivativos
dessas publicações ou de qualquer parte delas, sem autorização
expressa
da IBM.
Uso
Comercial: O cliente pode reproduzir, distribuir ou exibir essas
publicações unicamente dentro da empresa do cliente, desde que todos os
avisos do proprietário sejam preservados.
O Cliente não poderá criar derivativos destas publicações ou
reproduzir, distribuir ou exibir estas publicações ou qualquer parte
das mesmas fora da empresa do Cliente sem a autorização expressa, por escrito
da IBM.
Exceto quando concedido expressamente nesta permissão, nenhuma outra permissão, licença ou direito são concedidos, seja de maneira expressa ou implícita, para as publicações ou quaisquer informações, dados ou software ou outra propriedade intelectual neles contidos.
A
IBM
reserva-se no direito de cancelar as permissões concedidas
neste documento sempre que, de acordo com seus critérios, o uso das
publicações for nocivo aos seus interesses ou, conforme determinado
pela IBM,
caso as instruções acima não estejam sendo seguidas corretamente.
O Cliente não poderá fazer download, exportar ou reexportar estas informações, exceto quando em total conformidade com todas as leis e regulamentações aplicáveis, incluindo todas as leis e regulamentações de exportação dos Estados Unidos.
A
IBM
NÃO GARANTE O CONTEÚDO DESTAS PUBLICAÇÕES.
ESTAS PUBLICAÇÕES SÃO FORNECIDAS "NO ESTADO EM QUE SE ENCONTRAM", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE
COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.
(C) Copyright IBM Corporation
2005, 2007. Todos os Direitos Reservados.