IBM WebSphere WebSphere Integration Developer
Versão 6.2
Guia de Migração
Version 6 Release 2
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 2, do WebSphere Integration Developer.
Copyright International Business Machines Corporation 2005, 2009.
Capítulo 1. Migrando para o WebSphere Integration Developer
O WebSphere Integration
Developer Versão 6.2 fornece as ferramentas necessárias para migrar seu ambiente existente.
Nota: Depois de fazer upgrade para o WebSphere Integration
Developer 6.2, não é possível voltar os projetos para o WebSphere Integration Developer 6.1.x.
O suporte também não estará disponível se você for um usuário 6.2 verificando seu
código em um repositório ou exportando projetos e, em seguida, compartilhando-os com
um usuário do WebSphere Integration
Developer 6.1.x.
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 o WebSphere Integration Developer
6.2 é suportada. Isso é referido como
migração de versão-para-versão.
Por Que e Quando Desempenhar Esta Tarefa
Migrar para o WebSphere Integration
Developer 6.2 preserva a estrutura básica do aplicativo existente com uma reconfiguração
mínima necessária. 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 a versão 6.2, a maior parte da migração é feita automaticamente. 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
não podem ser recentemente criados, mas poderão ser utilizados no WebSphere Integration Developer 6.2 se eles já tiverem sido criados.
- Editor de Definição de Evento
- Este editor foi reprovado no WebSphere Integration
Developer 6.1.
- Sincronização
- A sincronização entre o WebSphere Business Modeler
e o WebSphere Integration Developer funcionará apenas se
o modelo tiver sido criado no WebSphere Business Modeler 6.1.2 ou posterior e for utilizado no WebSphere Integration
Developer 6.1.2 ou posterior. A sincronização com o Rational Asset Manager 7.1 funciona apenas com projetos que foram migrados para o WebSphere Integration Developer 6.2.
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.2 e o WebSphere Integration
Developer 6.2 são compatíveis com releases anteriores como segue:
Nota: Para
sistemas i5/OS,
não há versões anteriores instaladas.
- A implementação do WebSphere Integration
Developer 6.0.2.x ou 6.1 para o WebSphere Process
Server 6.2 é suportada.
- Os aplicativos criados e gerados utilizando o WebSphere Integration Developer 6.0.2.x ou 6.1 podem ser publicados para servidores WebSphere Process Server 6.2.
- Os aplicativos criados em, gerados em e exportados do WebSphere Integration Developer
6.0.2.x ou 6.1 podem ser instalados em servidores WebSphere Process Server 6.2.
- A execução de artefatos do WebSphere Process
Server 6.2 no WebSphere Process
Server 6.0.2.x ou 6.1 não é suportada.
- Os aplicativos criados com o WebSphere Integration
Developer 6.2 não podem ser publicados ou instalados em servidores WebSphere Process Server 6.0.2.x ou 6.1 (qualquer release anterior). Tal conteúdo não será executado corretamente no
WebSphere Process Server 6.0.2.x ou 6.1 e as alterações na geração de códigos fará com que os aplicativos não sejam executados corretamente no
WebSphere Process Server 6.0.2.x ou 6.1.
- Os aplicativos criados com o WebSphere Integration
Developer 6.0.2.x ou 6.1 e gerados no WebSphere Integration Developer 6.2 não podem ser publicados ou instalados em servidores WebSphere Process Server 6.0.2.x ou 6.1. As alterações na geração de códigos fará com que os aplicativos não sejam executados corretamente no WebSphere Process Server 6.0.2.x ou 6.1.
- Os aplicativos gerados utilizando serviceDeploy de um servidor
WebSphere Process Server 6.2 não podem ser instalados em um servidor WebSphere Process Server 6.0.2.x ou
6.1. As alterações na geração de códigos fará com que os aplicativos não sejam executados corretamente no WebSphere Process Server 6.0.2.x ou 6.1.
Capítulo 3. Migrando para o WebSphere Process Server do WebSphere InterChange
Server
O WebSphere Integration
Developer fornece as ferramentas necessárias para migrar do WebSphere InterChange Server.
Por Que e Quando Desempenhar Esta Tarefa
A migração do WebSphere InterChange
Server para o WebSphere Process
Server é suportada através das seguintes funções 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 através de ferramentas de migração que podem
ser chamadas da seguinte maneira:
- Através do menu Arquivo -> Importar -> Business Integration do WebSphere Integration Developer.
- A partir da página de boas-vindas do WebSphere Integration
Developer.
- Suporte nativo no tempo de execução de muitas APIs do WebSphere InterChange Server.
- Suporte para a tecnologia atual do WebSphere Business
Integration Adapter, de modo que os adaptadores existentes sejam compatíveis
com o WebSphere Process
Server.
- Opções para migrar configurações do conector do WebSphere Business
Integration Adapter para ligações nativas ou adaptadores equivalentes do WebSphere Process Server.
- Migração do conector para módulos de mediação.
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
Nota: O
WebSphere Business Integration Server
Express (WBISX) inclui os mesmos tipos de artefatos que o
WebSphere InterChange Server. Apenas dois recursos, Business Rules e Business Probe, não são suportados
pela migração.
Caminhos de Migração Suportados
As ferramentas de migração do WebSphere Process Server
suportam a migração do WebSphere InterChange Server versão 4.3 ou
mais recente ou do WebSphere Business Integration Server
Express versão 4.4 ou mais recente.
Antes de migrar, observe os seguintes requisitos:
Nota:
- Todo release do WebSphere InterChange
Server anterior à versão 4.3 precisará primeiro migrar para a versão 4.3
antes de migrar para o WebSphere Process Server.
- Todo release do WebSphere Business Integration Server
Express anterior à versão 4.4 precisará primeiro migrar para a
versão 4.4 antes de migrar para o WebSphere Process
Server.
Antes de migrar para o WebSphere Process
Server a partir do WebSphere InterChange
Server utilizando o WebSphere Integration
Developer, primeiro é necessário assegurar que tenha preparado corretamente seu
ambiente.
Por Que e Quando Desempenhar Esta Tarefa
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:
- Certifique-se de estar executando uma versão do WebSphere InterChange Server que possa ser migrada para o WebSphere Process Server. Consulte o tópico "Caminhos de Migração
Suportados para o WebSphere InterChange Server".
- Exporte os artefatos de origem do WebSphere
InterChange Server para um arquivo jar de repositório utilizando o comando repos_copy do
WebSphere InterChange Server conforme descrito na documentação para
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.
Migrando do WebSphere Business Integration Server
Express (WBISX)
O assistente WebSphere Integration Developer Migration
pode ser usado para migrar artefatos do WebSphere InterChange
Server de um ambiente do WebSphere Business Integration Server
Express.
Por Que e Quando Desempenhar Esta Tarefa
Para obter informações adicionais sobre como migrar de um ambiente do
WebSphere Business Integration Server
Express, consulte o tópico
Migrando
do WebSphere InterChange Server ou
WebSphere Business Integration Server
Express no centro de informações do
WebSphere Process Server.
Se você tiver a documentação do
WebSphere Process Server ou do
WebSphere ESB instalada localmente, você poderá localizar estas
informações em
Migrando do
WebSphere InterChange Server ou do
WebSphere Business Integration Server
Express.
Para obter informações sobre como fazer download da documentação do servidor,
consulte Visualizando ou Fazendo Download da Documentação do WebSphere Process Server.
Cenários de Migração do WebSphere InterChange
Server
Há uma série de cenários de migração do WebSphere InterChange
Server que são suportados pelo WebSphere Integration Developer.
Os seguintes cenários descrevem o processo de migração do WebSphere InterChange Server:
Migrando um Adaptador EJB do WebSphere Business
Integration para um Bean de Sessão sem Estado do WebSphere Process
Server
O assistente Migração fornece a opção de migrar para
uma ligação JMS conectando ao adaptador doWebSphere Business Integration
existente ou para um novo Bean de Sessão sem Estado. A migração gerará artefatos
reduzidos.
Migrando um Adaptador HTTP do WebSphere
Business Integration para uma Ligação Nativa do WebSphere
Process Server
Se o conector HTTP tiver sido configurado com um
listener de protocolo, será necessário modificar seu aplicativo cliente
antes de conectar ao conector migrado. Por exemplo, se o
conector for chamado de HTTPConnector, estiver atendendo
na porta 8080 e utilizando a URL /wbia/samples/webservices, então,
quando migrado para o WebSphere Process
Server, a porta será 9080 (a porta WC_defaulthost)
e a URL será alterada para /HTTPConnectorWeb/wbia/samples/http.
No WebSphere InterChange Server,
você pode acessar isto utilizando http://localhost:8080/wbia/http/samples enquanto
no WebSphere Process Server
será http://localhost:9080/HTTPConnectorWeb/wbia/http/samples .
O
assistente Migração fornece a opção de migrar para uma ligação JMS conectando
ao adaptador do WebSphere Business
Integration existente ou a uma nova ligação HTTP. O assistente permitirá
selecionar um manipulador de dados padrão ICS, criar um esboço do manipulador
de dados WPS ou utilizar um manipulador de dados customizado. O manipulador de dados padrão no
assistente Migração é o manipulador de dados XML.
Este cenário de migração
também suporta o roteamento de terminal dinâmico.
Migrando um Adaptador JMS do WebSphere Business Integration
para uma Ligação Nativa JMS ou JMS Genérico do WebSphere Process
Server
O assistente Migração fornece a opção de migrar para uma
ligação JMS conectando ao adaptador do WebSphere Business
Integration existente ou a uma nova ligação do JMS ou do JMS Genérico. O assistente permitirá
selecionar um manipulador de dados padrão ICS, criar um esboço do manipulador
de dados WPS ou utilizar um manipulador de dados customizado. Escolher a opção do
manipulador de dados padrão fornece CwDataHandler.
Se você
selecionar a ligação JMS, será necessário criar o JMS Genérico, o
Queue Connection Factory, Filas JMS e Portas Listener JMS e será necessário
também gerar um novo arquivo de ligações que inclua entradas para as
filas. Consulte o centro de informações do WebSphere Process
Server para obter informações adicionais sobre como trabalhar com ligações JMS. Se tiver a documentação do WebSphere Process Server instalada
localmente, você poderá localizar estas informações em ligações JMS. Para obter informações sobre como fazer download da documentação do servidor,
consulte Visualizando ou Fazendo Download da Documentação do WebSphere Process Server.
Se
você selecionar a ligação JMS Genérico, será necessário criar o JMS Genérico,
o Queue Connection Factory e Filas JMS e será necessário também gerar um novo
arquivo de ligações que inclua entradas para as filas.
As portas listener são criadas durante a implementação. Consulte o centro de informações do WebSphere Process Server para obter informações adicionais sobre como
trabalhar com Ligações do JMS Genérico. Se tiver a documentação do WebSphere Process Server instalada localmente, você poderá localizar estas informações em Ligações do JMS Genérico. Para obter informações sobre como fazer download da documentação do servidor,
consulte Visualizando ou Fazendo Download da Documentação do WebSphere Process Server.
O
JMS ou o JMS Genérico suporta o roteamento de terminal dinâmico. Por causa disso,
a fila Enviar na importação não é utilizada e a migração deixou este valor
em branco. Será necessário fornecer um valor antes que o módulo possa ser
implementado e iniciado.
Migrando um Adaptador MQ do WebSphere Business
Integration para uma Ligação Nativa MQ ou MQ JMS do WebSphere Process
Server
O assistente Migração fornece a opção de migrar para uma
ligação JMS conectando ao adaptador do WebSphere Business Integration
existente ou para uma nova ligação MQ ou MQ JMS.
O MQ ou o MQ JMS suporta o
roteamento de terminal dinâmico. Por causa disso, a fila Pedido não é utilizada
e a migração deixou este valor em branco. Será necessário fornecer
uma fila válida (mas recomenda-se não-utilizada no caso de problemas)
antes que o módulo possa ser implementado e iniciado. Além disso, forneça uma
fila Resposta válida para a exportação.
O assistente permitirá
selecionar um manipulador de dados padrão ICS, criar um esboço do manipulador
de dados WPS ou utilizar um manipulador de dados customizado. Escolher a opção do manipulador de dados padrão
fornece CwDataHandler.
Se você selecionar o MQ JMS, será necessário
configurar também a Fila de Destino e o Connection
Factory. Abra o mapa de saída para o MFC e edite a URL na Etapa
Customizada #3 para incluir o nome do Connection Factory. Uma URL de amostra é parecida
com o seguinte:
jms:/queue?destination=MQOUTPUT&connectionFactory=&targetService=Output
Digite o valor entre connectionFactory= e &.
A cadeia final será parecida com o seguinte:
jms:/queue?destination=MQOUTPUT&connectionFactory=MYCONNECTIONFACTORY&targetService=Output
Migrando um Adaptador Serviços da Web do WebSphere Business Integration para uma Ligação Nativa HTTP do WebSphere Process Server
Se o conector WS tiver sido configurado com um listener de protocolo, será
necessário modificar seu aplicativo cliente antes de conectar ao conector
migrado. Por exemplo, se o conector for chamado de WSConnector, estiver atendendo
na porta 8080 e utilizando a URL /wbia/samples/webservices, então,
quando migrado para o WebSphere Process
Server, a porta será 9080 (a porta WC_defaulthost) e a
URL será alterada para /WSConnectorWeb/wbia/samples/webservices
Há dois
cenários possíveis para este tipo de migração:
- Se o adaptador Serviços da Web utilizar o protocolo de transporte HTTP, o assistente Migração fornecerá a opção
de migrar para uma ligação JMS conectando ao adaptador do WebSphere Business Integration existente ou a uma nova ligação HTTP.
- Se o adaptador Serviços da Web utilizar o protocolo de transporte JMS,
a única opção para migração será a ligação JMS conectando ao adaptador
do WebSphere Business
Integration existente.
Observe que neste tipo de migração, o assistente não permitirá
que você selecione um manipulador de dados customizado.
Este cenário de migração
também suporta o roteamento de terminal dinâmico.
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 utilizam 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:
- Documente o design do sistema e do componente
- Utilize as ferramentas de desenvolvimento para editar artefatos de integração
- Utilize 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 criação, configuração e modificação de definições de artefatos, utilize apenas as ferramentas de desenvolvimento fornecidas. 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 editor de atividade.
- 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 possua muitas interfaces internas que você possa utilizar, esta prática não é recomendada pois estas interfaces não são garantidas como suportadas no futuro.
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 editor de atividade 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.
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:
Se possível, deve-se evitar o desenvolvimento de bibliotecas
de utilitário de código comum para uso nos artefatos de integração no
ambiente do WebSphere InterChange
Server. 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, você 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. No entanto, a
maneira na qual as conexões e transações são gerenciadas pode ser diferente
entre o WebSphere InterChange
Server e o WebSphere Process
Server. Portanto, deve-se evitar manter transações do banco de dados
ativas nos 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 de objetos de negócios, deve-se utilizar
apenas as ferramentas fornecidas para configurar artefatos e utilizar
os tipos de dados e comprimentos explícitos para atributos de dados
e utilizar apenas as APIs documentadas.
Objetos de negócios dentro do WebSphere Process
Server são baseados em SDOs (Service Data Objects) que possuem atributos de dados
que são altamente caracterizados. Para objetos de negócios no WebSphere InterChange Server e adaptadores,
os atributos de dados não são altamente caracterizados e os tipos de dados de cadeia
às vezes são especificados 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 esse motivo,
não utilize o comprimento máximo de 255 caracteres para um atributo de cadeia.
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 estiver utilizando uma matriz em um objeto de negócios, você não pode confiar na ordem da matriz
quando indexar na matriz nos mapas 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 o uso de variáveis estáticas e, como alternativa, 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 para os 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, por exemplo, "Object myObject = null;".
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 a modificação de
mapas e evite editar os arquivos de metadados diretamente. Utilize a ferramenta
do editor de atividade sempre que possível para maximizar o uso 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 de migrar.
Para minimizar a quantidade de retrabalho manual necessário na
migração, utilize apenas as APIs documentadas dentro de mapas. Evite o uso
de variáveis estáticas e, como alternativa, 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, enquanto as definições de relacionamento
poderão ser migradas para uso 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.
Utilize apenas as ferramentas fornecidas para configurar os componentes relacionados
e apenas APIs publicadas para relacionamentos nos artefatos de
integração.
Utilize apenas o editor de relacionamento para editar definições de relacionamento.
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.
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
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.
É possível evitar que colisões do banco de dados
ocorram, planejando que os eventos ocorram em tempos diferentes.
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.
Para obter informações sobre como fazer download da documentação do servidor,
consulte Visualizando ou Fazendo Download da Documentação do WebSphere Process Server.
Migrando os Artefatos do 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.
Por Que e Quando Desempenhar Esta Tarefa
O assistente desempenhará a migração com base nas seguintes informações:
- Os adaptadores serão migrados para ligações nativas se eles puderem ser suportados
como ligações nativas e
- Se um adaptador for detectado como um que possui um conector JCA equivalente,
a opção será fornecida para importá-lo. Ao importar o conector, você
configura o ambiente a ser migrado para o adaptador JCA utilizando o
assistente Migração.
Para utilizar o Assistente de Migração para migrar os artefatos do WebSphere InterChange Server, siga estas etapas:
- Invoque o assistente, selecionando
Arquivo -> Importar -> Integração de
Negócios -> WebSphere InterChange Server Repository e
clique em Avançar. Nota:
Também é possível abrir o assistente de Migração a partir da página de Boas-vindas,
clicando no ícone Retornando Usuários para abrir a página
Retornando Usuários (você sempre pode retornar à página de Boas-vindas, clicando em AjudaBem-vindo).
Clique em Migração à esquerda da página Retornando Usuários para abrir a página
Migração e selecione a opção Migrar um repositório do WebSphere ICS.
- O assistente Migração é aberto. Digite o caminho de repositório do WebSphere InterChange
Server ou clique em Procurar JARs, para selecionar o arquivo
JAR a ser utilizado no processo de migração.
- Digite o nome de uma biblioteca nova ou de uma já existente do WebSphere Integration Developer.
- Também é possível incluir um modelo do editor de montagem do WebSphere InterChange
Server a ser carregado e utilizado para conversão XML para Java. Se APIs customizadas (Minha Biblioteca) forem criadas para uso no editor de atividade, a ferramenta
de migração deverá fazer referência ao modelo de editor de atividade customizado para determinar
como migrar a API customizada para Java.
Esses modelos podem ser localizados no diretório raiz .wbiActEditorSettings
localizado no diretório do espaço de trabalho do WebSphere InterChange
Server. Geralmente, os arquivos de modelo têm uma extensão de
arquivo .bbt. Certifique-se de carregar esses modelos na caixa de
modelos. Se não incluir
um modelo, o Standard Assembly Editor Template v4.3.3 será utilizado
para conversão XML para Java.
- Clique em Avançar para definir as configurações
de migração para cada conector. Nesta página, é possível selecionar os manipuladores
de dados e ligação de destino apropriados para cada conector que está sendo migrado.
Selecione o conector a partir da lista e escolha uma ligação de destino
e, em seguida, um arquivo JAR do manipulador de dados customizado. Observe que o assistente Migração
não permitirá que o processo de migração continue até que todos os valores do conector
sejam configurados.
- Clique em Avançar. A página Opções de Conversão é aberta. A partir daqui é possível aceitar as opções recomendadas
ou alterá-las:

A tabela a seguir
descreve as opções de conversão de migração disponíveis:
Opção |
Descrição |
Os erros de análise Java encontrados
no processo de migração devem ser tratados como: |
- Erros (recomendado)
- Todos os problemas de conversão Java
são tratados como erros e será necessário rever o log de erros, para
obter detalhes adicionais.
- Avisos
- Todos os problemas de conversão Java
são tratados apenas como avisos e o artefato será migrado pelo
assistente de Migração da melhor forma possível.
|
No erro, o processo de migração deve: |
- Continuar até ser concluído (recomendado)
- O assistente de Migração continuará a processar os artefatos restantes
em um arquivo JAR, mesmo se ocorrer um erro durante o processamento de um
determinado artefato.
- Terminar imediatamente
- O processo de migração será parado assim que um erro for detectado.
O artefato com erro, e todos os artefatos subseqüentes, não
são processados.
|
Seqüenciamento de eventos para todos os métodos WSDL assíncronos: |
- Desativar (recomendado)
- O processo de migração não ativará o seqüenciamento de eventos em quaisquer
métodos WSDL.
- Ativar
- O processo de migração ativará o seqüenciamento de eventos para todos os
métodos WSDL.
|
- Clique em Avançar. Uma página Resumo da Migração
é aberta de forma semelhante ao exemplo a seguir:
- Assim que você revisado os detalhes do resumo, clique em Concluir
para iniciar o processo de migração.
O que Fazer Depois
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, o
diálogo desaparece e a janela Resultados da Migração é aberta:
Clique em Fechar para concluir
o processo e construir o novo espaço de trabalho. Você poderá cancelar a seleção da opção Construir
Espaço de Trabalho no Fechamento se não desejar que o espaço de trabalho seja
construído dessa vez.
Verificando a Migração do WebSphere InterChange Server
Se nenhum erro for relatado durante a migração do arquivo .jar do WebSphere InterChange Server,
a migração dos artefatos terá sido bem-sucedida. Se a migração
não tiver sido concluída com êxito, uma lista de erros, avisos e mensagens
informativas será exibida na janela Resultados da Migração. Estas mensagens
podem ser utilizadas para verificar a migração do WebSphere InterChange
Server.
Por Que e Quando Desempenhar Esta Tarefa
Nota: Devido à complexidade da migração do WebSphere InterChange Server para o WebSphere Process Server, você é
bastante incentivado a desempenhar um teste abrangente dos aplicativos resultantes
em execução no WebSphere Process
Server para assegurar que eles funcionem conforme esperado antes de colocá-los
na produção.
Se decidir não parar na primeira falha, você
verá um ícone de visto verde na janela Resultados da Migração, mas poderá
haver também Xs vermelhos na lista. Portanto, será necessário revisá-los
na lista. Se decidir parar na primeira falha e receber uma
falha ou erro, você verá um X vermelho na janela Resultados da
Migração em vez de um visto verde e será necessário revisar as
falhas na lista.
Trabalhando com Falhas de Migração do WebSphere InterChange Server
Se o processo de migração do WebSphere InterChange Server falhar, há
duas maneiras para lidar com as falhas.
Por Que e Quando Desempenhar Esta Tarefa
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 tornam-se objetos de negócios do WebSphere Process Server.
- Mapas tornam-se mapas do WebSphere Process
Server.
- Relacionamentos tornam-se relacionamentos e funções do WebSphere Process Server.
- Modelos de colaboração tornam-se BPEL e WSDL do WebSphere Process Server.
- Objetos de colaboração tornam-se módulos do WebSphere Process Server que contêm o limite do componente SCA para o BPEL do Modelo de Colaboração e toda a instalação elétrica SCA
necessária.
- Definições do conector tornam-se módulos de mediação do WebSphere Process Server que contêm importações e exportações SCA e componentes do fluxo de mediação se o conector for migrado para uma ligação nativa. As definições do conector tornam-se
módulos do WebSphere Process Server que contêm importações e exportações SCA
e componentes do fluxo de mediação que permitem a comunicação com Adaptadores Legados, Artefato Administrativo do Adaptador Legado e toda a instalação elétrica 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.
Por Que e Quando Desempenhar Esta Tarefa
O assistente Migração converte as definições FDL dos processos de negócios exportados
do componente build time do WebSphere MQ Workflow para os 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 todas as definições do servidor de execução do processo definidas (UPES) referidas no modelo de processo do WebSphere MQ Workflow também sejam selecionadas quando você exportar o FDL
do build time do WebSphere MQ Workflow.
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 como migrar utilizando a ferramenta de conversão FDL2BPEL,
consulte o site de suporte do
WebSphere
MQ Workflow.
Antes de migrar para o WebSphere Integration Developer do WebSphere MQ
Workflow, primeiro é necessário assegurar que você tenha preparado corretamente seu ambiente.
Por Que e Quando Desempenhar Esta Tarefa
O escopo e a integridade do mapeamento depende de como você
adere às seguintes diretrizes 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.
Por Que e Quando Desempenhar Esta Tarefa
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:
- Invoque o assistente selecionando Arquivo -> Importar -> Business Integration -> Arquivo FDL do WebSphere MQ Workflow e
clique em Avançar. Nota:
Também é possível abrir o assistente de Migração a partir da página de Boas-vindas,
clicando no ícone Retornando Usuários para abrir a página
Retornando Usuários (você sempre pode retornar à página de Boas-vindas, clicando em AjudaBem-vindo).
Clique em Migração à esquerda da página Retornando
Usuários para abrir a página Migração e selecionar a opção Migrar
um processo do WebSphere MQ Workflow.
- O assistente Migração é aberto. 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. Você deve também fornecer o nome de um módulo antes de
continuar. Clique em Avançar:
- A página Opções de Migração do WebSphere MQ
Workflow para as configurações de criação de artefatos é aberta. 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ção Tratar conflitos de nomes como erros, você pode evitar a adição automática de sufixos
que poderiam resultar em erros de interoperabilidade. A caixa de opção Criar membros de dados predefinidos inclui nós extra ao processo para inicializar os membros de dados
predefinidos:
- Clique em Avançar. A página Opções de Migração do WebSphere MQ Workflow para otimizar os processos de negócios migrados
é aberta:
Nesta página, você pode configurar as opções para otimizar os
processos de negócios migrados. Para obter informações adicionais sobre estas opções,
consulte o tópico "Otimizando os processos de negócios migrados" nos links relacionados
abaixo ou clique em F1 ao selecionar ou desmarcar cada item.
- Depois de ter selecionado e revisado suas opções de otimização,
clique em Concluir.
O que Fazer Depois
Uma barra de progresso na parte inferior do diálogo de
migração indica o progresso da migração.
Depois que o processo de migração for concluído, o
diálogo de migração desaparecerá e a janela Resultados da Migração será aberta:
Para manter todas as mensagens para referência
futura, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar
uma lista de tarefas "A Fazer" na visualização de tarefas ou clique no botão Salvar
Como 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.
Otimizando os Processos de Negócios Migrados
Durante a migração dos processos de negócios, há várias opções
de otimização que ajudarão na eficiência geral, no desempenho e na capacidade
de utilização do processo de negócios migrado. Por exemplo, você pode
reduzir o número de snippets Java,
remover elementos estruturais desnecessários e reduzir o número de variáveis BPEL
através das opções de otimização no assistente Migração.
A tabela a seguir detalha as opções de otimização de migração do WebSphere MQ Workflow e os resultados associados para cada:
Tabela 3. Opções de Otimização de Migração do WebSphere MQ Workflow
Opção |
Resultado |
Fundir snippets Java adjacentes |
Selecionar esta caixa de opção otimizará o processo de
negócios combinando snippets Java onde
possível (serial, paralelo ou combinado). O processo será executado de maneira mais eficiente conforme as variáveis
forem compartilhadas em um snippet Java e as partes do código duplicadas puderem ser eliminadas.
Não selecionar esta caixa de opção significa que o processo ainda é válido, porém, isto resultará
em muitos snippets Java únicos no processo BPEL. |
Remover elementos estruturais desnecessários |
Selecionar esta caixa de opção otimizará o processo de
negócios removendo elementos estruturais. O aninhamento desnecessário de atividades
BPEL estruturais não é eficiente para o fluxo do processo. |
Reduzir o número de variáveis |
Selecionar esta caixa de opção otimizará o processo de
negócios reduzindo o número de variáveis BPEL. Utilize a barra de slide para
selecionar o nível de redução. Ao migrar um processo FDL para BPEL, muitas
variáveis BPEL são criadas com base em variáveis FDL. Você pode suprimir
todas, algumas ou nenhuma das variáveis FDL a serem transferidas para o processo BPEL.
- Nível 0 de redução de variáveis: Esta opção permite o compartilhamento
mínimo de variáveis. Isto fundirá as variáveis FDL correspondentes de contêineres
de saída e de entrada em uma variável BPEL.
- Nível 1 de redução de variáveis: Esta opção permite o compartilhamento
moderado de variáveis. Isto fundirá as variáveis FDL correspondentes de contêineres
de saída e de entrada em uma variável BPEL. Compartilhará também variáveis
enquanto tolera um conflito potencial com o membro de dados predefinidos
"Prioridade".
- Nível 2 de redução de variáveis: Esta opção permite o compartilhamento
médio de variáveis. Isto fundirá as variáveis FDL correspondentes de contêineres
de saída e de entrada em uma variável BPEL. Compartilhará também variáveis
enquanto tolera conflitos potenciais com os membros de dados predefinidos
"Prioridade" e "Notificação".
Nota: Em casos raros, uma variável
BPEL é compartilhada incorretamente. Nestes casos, execute a migração
novamente com um nível de otimização diminuído.
- Nível 3 de redução de variáveis: Esta opção permite que quase todas as
variáveis possíveis sejam compartilhadas. Isto fundirá as variáveis FDL correspondentes de contêineres
de saída e de entrada em uma variável BPEL. Compartilhará também variáveis enquanto tolera conflitos potenciais
com os membros de dados predefinidos "Prioridade", "Notificação" e "Equipe".
Nota: Em casos raros, uma variável
BPEL é compartilhada incorretamente. Nestes casos, execute a migração
novamente com um nível de otimização diminuído.
- Nível 4 de redução de variáveis: Esta opção permite o compartilhamento
de tantas variáveis quantas forem possíveis. Isto fundirá as variáveis FDL correspondentes de contêineres
de saída e de entrada em uma variável BPEL. Compartilhará também variáveis enquanto tolera conflitos potenciais
com os membros de dados predefinidos "Prioridade", "Notificação", "Equipe" e
as configurações de dados padrão.
Nota: Em casos raros, uma variável
BPEL é compartilhada incorretamente. Nestes casos, execute a migração
novamente com um nível de otimização diminuído. |
Para obter informações adicionais relativas às opções de otimização e também informações sobre a ferramenta de linha de comandos para a migração do MQ Workflow, consulte o site de Suporte do WebSphere Process
Server.
Verificando a Migração do WebSphere MQ Workflow
Se a migração for concluída com uma lista de mensagens de erros, avisos e 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 tiver sido
concluída com êxito.
Por Que e Quando Desempenhar Esta Tarefa
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 manter todas as mensagens
para referência futura, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar
uma lista de tarefas "A Fazer" na visualização de tarefas ou clique no botão Salvar
Como 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.
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 do WebSphere Studio
Application Developer Integration Edition
Os artefatos de origem para projetos do WebSphere Business
Integration Server Foundation (WBISF) 5.1 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.
Migrando seu Espaço de Trabalho
No WebSphere Integration
Developer 6.2, é possível migrar apenas um espaço de trabalho válido (um espaço de trabalho
que contém pelo menos um projeto de serviço). Esta seção fornece informações para migrar seu
espaço de trabalho do WebSphere Studio
Application Developer Integration Edition.
Por Que e Quando Desempenhar Esta Tarefa
Para migrar
totalmente um espaço de trabalho do WebSphere Studio Application Developer Integration
Edition, existem três tarefas fundamentais a serem concluídas:
- Prepare os artefatos de origem para 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 da linha de comandos WSADIEWorkspaceMigration para migrar o espaço de trabalho.
- Onde necessário, utilize o WebSphere Integration Developer para concluir 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.Informações adicionais para estas tarefas podem ser localizadas na seção "Informações Adicionais de Migração".
O que Fazer Depois
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 espaços de trabalho do WebSphere Studio
Integration Edition na 6.x.
Antes de migrar artefatos de origem do WebSphere Studio Application Developer Integration Edition, certifique-se de que os espaços de trabalho com projetos do WebSphere Business Integration Server Foundation contenham
um ou mais projetos de serviço.
O assistente de Migração oferece a capacidade de migrar um espaço de trabalho do
WebSphere Studio Application Developer Integration Edition Versão 5.1 (ou superior) de cada vez.
O assistente de Migração não migra os binários de aplicativos
- ele migrará apenas artefatos de origem localizados em um espaço de trabalho do
WebSphere Studio Application Developer Integration Edition.
Antes de migrar os artefatos de origem para o WebSphere Integration Developer do
WebSphere Studio Application Developer Integration Edition, certifique-se primeiro de
ter preparado corretamente seu ambiente para o processo de migração.
Por Que e Quando Desempenhar Esta Tarefa
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 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
você não tiver estes recursos ativados, as opções de menu que serão discutidas abaixo não poderão ser visíveis.
Para ativar os recursos importantes:
- No WebSphere Integration Developer, selecione
Janela -> Preferências.
- Clique em Geral e selecione a categoria Recursos.
- Selecione todos os recursos nas seguintes categorias:
- Enterprise Java Developer
- Desenvolvedor de Integração
- Java Developer
- Web Developer (típico)
- Web Service Developer
- XML Developer
- Clique em OK.
- Utilize um novo espaço de trabalho como o espaço de trabalho de destino de migração.
- Por padrão, o WebSphere Integration
Developer gera o código de implementação durante build time para os projetos
WEB, EJB e EAR de suporte para módulos do WebSphere Integration
Developer.
Nota: O código de implementação para outros projetos (por
exemplo, J2EE) não é gerado.
- Para migrar totalmente os arquivos BPEL dentro de um espaço de trabalho, é necessário assegurar
que todos os arquivos WSDL e XSD referenciados 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 ou XSD estiverem no projeto atual, no projeto referido
ou em uma biblioteca comum com o arquivo BPEL, nenhuma ação adicional será
necessária.
- Se os arquivos WSDL ou XSD estiverem em um projeto diferente daquele no qual você está
migrando, os artefatos da versão 5.1 devem ser reorganizados utilizando o WebSphere Studio Application
Developer Integration Edition anterior à migração porque os projetos do módulo do Business
Integration (BI) não podem compartilhar os 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 neste novo projeto Java.
Inclua uma dependência deste novo projeto Java em todos os projetos que utilizam esses artefatos comuns.
- Outra opção é manter uma cópia local desses artefatos WSDL e XSD compartilhados em cada projeto,
de forma que não existam dependências entre os projetos.
- Se os arquivos WSDL ou XSD estiverem em qualquer outro tipo de projeto (geralmente outros Projetos
Java), você deve criar um projeto de biblioteca do
Business Integration com o mesmo nome do projeto da versão 5.1. Você também deve configurar o caminho de classe do novo projeto de biblioteca, incluindo as entradas do projeto Java 5.1. Este tipo de projeto é útil para armazenar artefatos compartilhados. Observe que dois arquivos WSDL não podem
definir portType, serviço ou porta com o mesmo nome e espaço de nomes de destino.
Isto deve ser corrigido manualmente antes da migração para evitar erros.
Nota: O WebSphere Integration Developer não suporta
tipos XML-SOAP conforme definidos no espaço de nomes http://xml.apache.org/xml-soap.
Você deve remover referências a esses tipos no WebSphere Studio Application Developer Integration Edition antes de migrar para evitar uma falha do processo de
migração.
O que Fazer Depois
Agora você está pronto para iniciar o processo de migração.
Considerações de Pré-migração
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:
- O espaço de trabalho de destino do WebSphere
Integration Developer deve estar vazio significando que os projetos não são apenas removidos do
espaço de trabalho, mas que todas as pastas e arquivos também são removidos da pasta de espaço de
trabalho no sistema de arquivo.
- Os tipos de projeto WebSphere Studio Application
Developer Integration Edition suportados pelo assistente de Migração são: Projetos de Serviço,
Projetos Java, Projetos EJB, Projetos de Conector, Projetos
do Aplicativo Corporativo, Projetos do Cliente de Aplicativo, Projetos da Web Dinâmicos e Projetos
Estáticos da Web. Quaisquer outros tipos de projetos que possam existir no
WebSphere Studio Application Developer Integration
Edition serão copiados para o espaço de trabalho
WebSphere Integration Developer, mas não terão qualquer
processamento para migração.
- Tente utilizar a atividade de Designação onde for possível
(em oposição ao serviço 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
transformador. Adicionalmente, não há nenhum suporte especial a ferramentas no WebSphere Integration
Developer para os serviços transformadores criados na versão 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 transformador).
- Especifique uma parte por mensagem WSDL se o WSDL for um estilo de documento de acordo com a
especificação Web Services Interoperability (WS-I) e o estilo preferido da 6.x.Isto não se aplica a WSDLs do estilo RPC.
- 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. O exemplo a seguir mostra a maneira recomendada para definir tipos e elementos complexos de tal 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 serviços da Web IBM (em oposição ao Apache SOAP/HTTP) porque os serviços da Web
IBM são diretamente suportados na 6.x e os serviços da Web Apache 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 em um projeto Java ao qual o espaço de trabalho possa fazer referência.
- Mantenha uma cópia local de todos os arquivos WSDL/XSD que um projeto referencia no próprio projeto. Os projetos 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 em outros módulos (um projeto com dependências em outro
projeto pelo motivo de compartilhamento de arquivos WSDL ou XSD não será migrado de forma limpa).
- 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 e 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 os Espaços de Trabalho Utilizando o Assistente de Migração do WebSphere Integration Developer
O assistente de Migração do WebSphere Integration Developer
permite a migração de espaços de trabalho, incluindo todos os projetos.
Por Que e Quando Desempenhar Esta Tarefa
Especificamente para a migração de projetos de serviço, o assistente de Migração
executa as seguintes tarefas:
- 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
- Conecta o componente BPEL com seus links associados (importações, exportações e componentes Java)
Nota: Utilize um novo espaço de trabalho do WebSphere Integration Developer como o destino da migração.
Para migrar os espaços de trabalho utilizando o assistente de Migração do
WebSphere Integration Developer, siga estas etapas:
- Invoque o assistente selecionando
Arquivo -> Importar -> Integração de
Negócios -> Espaço de Trabalho do WebSphere Studio Application Developer Integration
Edition e clique em Avançar.Nota:
Também é possível abrir o assistente de Migração a partir da página Bem-vindo, clicando no ícone
Retornando Usuários para abrir a página Retornando Usuários
(Observe que você sempre pode retornar à página de Boas-vindas, clicando em
Ajuda -> Bem-vindo ). Clique em
Migração à esquerda da página Retornando Usuários para abrir a página
Migração e selecionar a opção Migrar um espaço de trabalho do Integration Edition 5.1.
- O assistente Migração é aberto. Digite o caminho para o espaço de trabalho a
ser migrado ou clique em Procurar para localizá-lo. Clique em Avançar.
- A partir da página de opções de migração, é possível alterar a opção para preservar os snippets
BPEL Java originais nos comentários.
- Clique em Concluir para iniciar o processo de migração. Você verá uma
barra de status de migração na parte inferior da janela do assistente de Migração.
- Depois que o processo for concluído, você verá a seguinte mensagem:
Clique em Avançar para
iniciar o processo de validação da migração.
- Selecione os projetos do espaço de trabalho a serem migrados:
Clique em
Avançar.
- Os recursos de projeto que podem sofre impacto pelo processo de migração são listados:
Reveja esta lista e clique em
Avançar.
- Quando estiver pronto, clique em Concluir para iniciar a
migração dos projetos selecionados.
- Depois que o processo de validação da migração tiver sido concluído, você deve ver a seguinte mensagem:
- Depois que o processo tiver sido concluído, a janela Resultados de Migração será 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 terá uma extensão .log.
- Para guardar todas as mensagens para referência futura, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização da tarefa 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.
O que Fazer Depois
Após a conclusão do Assistente de Migração, construa o espaço de trabalho que foi
criado e tente resolver quaisquer erros de construção. Inspecione todos os arquivos BPEL migrados e
assegure-se de que estejam totalmente migrados e possam ser abertos no
WebSphere Integration Developer BPEL Editor.
Existem alguns snippets BPEL Java 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 espaço de trabalho, abra o editor de dependências 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 os Espaços de Trabalho Utilizando o WSADIEWorkspaceMigration
O comando WSADIEWorkspaceMigration possibilita
a migração de espaços de trabalho.
Por Que e Quando Desempenhar Esta Tarefa
Especificamente para a migração de projetos de serviço, o comando de migração executa as seguintes tarefas:
- Cria um novo módulo de integração de negócios (o nome do módulo é definido por você)
- Migra as entradas do 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 com uma extensão .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
- Conecta o componente BPEL com seus links associados (importações, exportações e componentes Java)
Para executar o script WSADIEWorkspaceMigration, siga estas etapas:
- Localize o script abrindo a pasta compartilhada especificada durante a instalação do WebSphere Integration Developer. Por exemplo, o script estará localizado em um caminho de diretório semelhante ao seguinte: <wid_root>\wstools\eclipse\plugins\com.ibm.wbit.migration.wsadie_6.2.0.v20081112_0200
- Invoque o script da seguinte maneira: WSADIEWorkspaceMigration.bat -WIDstartup eclipse_dir -WIDworkspace WID_target_workspace -WSADIEworkspace source_WSADIE_Workspace_dir
Definições de Parâmetro:
- -WIDstartup
- O local de sua pasta Eclipse (Tempo de execução de Eclipse).
- -WIDworkspace
- O novo espaço de trabalho no qual o novo módulo de integração de negócios será
criado.
- -WSADIEworkspace
- O caminho completo para o espaço de trabalho do
WebSphere Studio Application Developer Integration Edition 5.1.
Por exemplo:
WSADIEWorkspaceMigration.bat -WIDstartup "C:\IBM\WID\eclipse" -WIDworkspace
"c:\WID Workspaces\myWIDWorkspace" -WSADIEworkspace
"c:\wsadie workspaces\myWSADIEWorkspace"
- Depois que o comando tiver concluído a execução, inicie o novo espaço de trabalho no
WebSphere Integration Developer.
- Construa o espaço de trabalho criado e tente resolver quaisquer erros de construção. Inspecione todos os arquivos BPEL migrados e certifique-se de que estejam totalmente migrados e possam ser abertos no editor BPEL do
WebSphere Integration Developer.
Existem alguns snippets BPEL Java 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 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.
Verificando a Migração de Artefatos de Origem
Se a migração for concluída com uma lista de mensagens de erros, avisos e 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.
Por Que e Quando Desempenhar Esta Tarefa
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 referência futura, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização da tarefa 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.
Por Que e Quando Desempenhar Esta Tarefa
Os exemplos a seguir mostram 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 de Migração de Artefatos de Origem
Há limitações envolvidas com o processo de migração de artefatos de origem doWebSphere 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
- Os tipos de projeto WebSphere Studio Application
Developer Integration Edition suportados pelo assistente de Migração são: Projetos de Serviço,
Projetos Java, Projetos EJB, Projetos de Conector, Projetos
do Aplicativo Corporativo, Projetos do Cliente de Aplicativo, Projetos da Web Dinâmicos e Projetos
Estáticos da Web. Quaisquer outros tipos de projetos que possam existir no
WebSphere Studio Application Developer Integration
Edition serão copiados para o espaço de trabalho
WebSphere Integration Developer, mas não terão qualquer
processamento para migração.
- 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). Um exemplo é aquele 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
e assim por diante) se parecem como:
<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.
- 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.
- Os Business Rule Beans estão obsoletos 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 obsoleto, desta forma, eles serão executados "no estado em que se encontram" em um servidor WebSphere Process Server 6.x. Não há suporte para ferramentas para os Business Rule Beans antigos, entretanto, se você desejar que os artefatos do Business Rule Bean
antigo sejam compilados nas ferramentas, deve seguir a documentação do WebSphere Integration Developer para instalar esses recursos obsoletos sobre o servidor de teste incorporado do WebSphere Process
Server 6.x e, então, incluir manualmente os arquivos jar obsoletos no caminho de classe do projeto como jars externos. Você
deve utilizar as novas ferramentas de regra de negócios disponíveis no WebSphere Integration Developer para criar suas regras de negócios de acordo com a especificação 6.x.
- 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.
- O WebSphere Integration Developer não suporta
tipos XML-SOAP conforme definidos no espaço de nomes http://xml.apache.org/xml-soap.
Você deve remover referências a esses tipos no WebSphere Studio Application Developer Integration Edition antes de migrar para evitar uma falha do processo de
migração.
- Quando um espaço de trabalho é migrado, alguns módulos podem ter dependências em outros
módulos. Isto não é verificado pelo WebSphere Integration Developer, porém, haverá erros semelhantes aos seguintes após a implementação do aplicativo:
======== TravelOperationsApp ========
O aplicativo não pode ser iniciado: TravelOperationsApp
com.ibm.ws.exception.RuntimeWarning: javax.resource.ResourceException:
Falha ao consultar ActivationSpec.sca/TravelOperations/ActivationSpec
Após a
migração, você deve revisar os módulos e remover manualmente as dependências do projeto
e do caminho de construção entre os módulos. Isso pode exigir mover alguns
arquivos WSDL e Java para um projeto
de biblioteca comum.
- Os projetos do tipo J2EE não são migrados para o nível J2EE mais atual.
Por exemplo, se os projetos no espaço de trabalho do WebSphere Studio
Application Developer Integration Edition estiverem no nível 1.3 e, quando migrados,
continuarem no nível 1.3 e não 1.4 (o mais atual na V6.2), isto não causará nenhum problema. Se desejar fazer
upgrade para o nível mais atual, você poderá utilizar o menu de ferramentas J2EE clicando com o botão direito do
mouse em qualquer projeto do tipo J2EE (Web, EJB, EAR, Application
Client) e selecionando Ferramentas do J2EE -> Migração do J2EE.
Limitações de Migração de Projeto EJB
Você poderá encontrar um problema de
migração se o espaço de trabalho do WebSphere Studio
Application Developer Integration Edition de origem tiver um projeto EJB sem um projeto
cliente EJB. Se o projeto EJB for uma dependência de um ou mais projetos de serviço,
o espaço de trabalho migrado será construído okay, mas não será implementado corretamente. Isto acontece porque o WebSphere Integration Developer
tenta implementar o projeto EJB como um módulo J2EE e não um utilitário jar. Para resolver este problema, siga estas etapas:
- Migre o espaço de trabalho.
- No WebSphere Integration Developer, clique com o botão direito do
mouse em Projeto EJB -> Ferramentas J2EE -> Criar Projeto Cliente. Um projeto cliente EJB é criado.
- Substitua todas as referências ao projeto EJB em Módulos pelo cliente EJB.
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 WSDL documento/literal agrupado (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 documento/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 5.1 Java para o modelo de programação
do snippet 6.x Java. 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.
O exemplo a seguir mostra quatro maneiras pelas quais um snippet Java pode ser acessado
como "de leitura" em qualquer snippet Java 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 snippets tenta fazer esta alteração mas,
se a ordem em que ocorrem as instanciações originais não seguir o padrão pai-depois-filho, a migração
manual será necessária (ou seja, o conversor não tenta reordenar as instruções de instanciação no
snippet de maneira inteligente).
- 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.
Informações Adicionais de Migração
Após uma migração bem-sucedida, talvez ainda seja necessário revisar
as seguintes seções para identificar tarefas que são necessárias para concluir a
migração do seu espaço de trabalho. As informações nesta seção podem ser utilizadas
para ajudar a garantir que a migração foi concluída.
Por Que e Quando Desempenhar Esta Tarefa
- 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 é 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 quaisquer processos BPEL no espaço de trabalho 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 também como refazer manualmente a instalação elétrica do 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.
Por Que e Quando Desempenhar Esta Tarefa
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 do projeto (por exemplo, um processo de negócios, um serviço 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Utilizar
o assistente de Migração 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).
Nota: Se o assistente de Migração não migrou totalmente todos os projetos de serviço, você tem as
seguintes opções:
Criando o Componente Java Customizado: Opção 1
Se o assistente de Migração não migrou totalmente todos os seus projetos de serviço, é possível
utilizar o tipo de Componente do WebSphere Integration Developer Java para
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.
Por Que e Quando Desempenhar Esta Tarefa
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 modelo 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
Se o assistente de migração não migrou totalmente todos os seus projetos de serviço, uma opção alternativa
a ser considerada é 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.
Por Que e Quando Desempenhar Esta Tarefa
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 deste
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 em 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ê pode 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, o 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 a incluir mapeamentos para todos os pacotes Java utilizados pela interface
JavaBeans.
- Clique em Avançar. Observe que você pode 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 versão 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 modelo
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 modelo Java e selecione Serviços da Web -> Gerar modelo de Java bean.
- Escolha o tipo de serviço da Web Serviço da Web Java bean de modelo 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 modelo 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 modelo Java de estilo SCA a partir do WSDL/XSDs original ou a opção 2 para gerar um novo modelo 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.
Por Que e Quando Desempenhar Esta Tarefa
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).
Se
o assistente de Migração não migrou totalmente todos os projetos de serviço, você tem as seguintes opções:
Criando o Componente EJB Customizado: Opção 1
Se o assistente de Migração não migrou totalmente todos os seus projetos de serviço, é
possível utilizar o tipo Importar com ligação de sessão sem preservação de estado do
WebSphere Integration Developer que permite invocar 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.
Por Que e Quando Desempenhar Esta Tarefa
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", já que este será um componente
Java que fará mediação entre a interface WSDL gerada para o EJB no
WebSphere Studio Application Developer Integration e a interface
de 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 modelo 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ê poderá 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.
Por Que e Quando Desempenhar Esta Tarefa
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 em 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ê pode 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 (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, o 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ê pode 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ção de 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 modelo 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 modelo EJB para esta
pasta de origem de 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 modelo EJB e selecione Serviços da Web -> Gerar modelo de Java bean.
- Escolha o tipo de serviço da Web Serviço da Web EJB de modelo 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 versão 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
Se o assistente de Migração não migrou totalmente todos os projetos de serviço e você
optou por fazê-lo manualmente, observe que existem vantagens e desvantagens para 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 modelo 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 modelo 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, se o assistente de Migração não tiver migrado totalmente
todos os seus projetos de serviço.
Por Que e Quando Desempenhar Esta Tarefa
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)
Se o assistente de Migração não tiver migrado totalmente todos os seus projetos de serviço,
será possível migrar um Serviço da Web (SOAP/JMS) para uma Importação
SCA com ligação de Serviço da Web.
Por Que e Quando Desempenhar Esta Tarefa
Para migrar um projeto de serviço SOAP/JMS para uma migração de serviço de saída, siga estas etapas:
- 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. 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)
Se o assistente de Migração não tiver migrado totalmente todos os seus projetos de serviço,
será possível migrar um Serviço da Web (SOAP/HTTP) para uma Importação
SCA com ligação de Serviço da Web.
Por Que e Quando Desempenhar Esta Tarefa
Para migrar um projeto de serviço SOAP/HTTP para uma migração de serviço de saída, siga estas etapas:
- 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. 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).
- 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
Se o assistente de Migração não tiver migrado totalmente todos os seus projetos de serviço,
será possível migrar um Serviço JMS para uma Importação
SCA com ligação JMS.
Por Que e Quando Desempenhar Esta Tarefa
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:
- 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).
- 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 (eles freqüentemente 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
Se o assistente de Migração não tiver migrado totalmente todos os seus projetos de serviço,
será possível migrar um serviço J2C-IMS para uma Importação SCA com ligação EIS ou Importação SCA com
ligação de serviço da Web.
Por Que e Quando Desempenhar Esta Tarefa
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 o aplicativo manualmente.
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.
Por Que e Quando Desempenhar Esta Tarefa
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 criar o serviço EIS, vá para Arquivo -> Novo -> Outro -> Integração de Negócios -> Serviço Externo.
- 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 na tela,
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).
Por Que e Quando Desempenhar Esta Tarefa
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.
- Selecione Conexão Gerenciada e digite o nome de consulta 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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 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.
Por Que e Quando Desempenhar Esta Tarefa
Eles oferecem função similar para o serviço 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 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 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.
Por Que e Quando Desempenhar Esta Tarefa
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; escolha Stub de Cliente, selecione as operações que irá incluir no proxy e clique 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:
- Certifique-se de que o projeto Java esteja no antigo
espaço de trabalho (o projeto Java será migrado automaticamente pelo assistente de Migração).
- 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 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", já que este 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 do cliente do transformador).
- Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
- Retorne 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 modelo 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 assistente de Migração cria as exportações automaticamente; no entanto,
é possível consultar as seguintes informações para ajudar a verificar o que a ferramenta fez.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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 registro de data e horário válidos do BPEL. Por exemplo, esses atributos podem ser
encontrados examinando as propriedades do processo BPEL no editor BPEL nas guias de conteúdo Descrição e
Servidor:
Tabela 4. 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 5. 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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).
Por Que e Quando Desempenhar Esta Tarefa
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 na tela 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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 do
registro de data e horário válidos do 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:
- JNDI do Connection Factory - o padrão é jms/BPECF (este é o
nome JNDI do connection factory da fila do contêiner do processo de negócios de destino)
- Fila de Destino JNDI - o padrão é jms/BPEIntQueue (este é o
nome
JNDI da fila interna do contêiner do 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 6. 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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).
Por Que e Quando Desempenhar Esta Tarefa
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 na tela 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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 os arquivos WSDL denominados JMSBinding.wsdl
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 aí capturadas. 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 e-Export 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 da exportação e sua descrição são listados e podem ser modificados, conforme 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
O exemplo a seguir mostra as convenções utilizadas ao gerar 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 registro de data e hora 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 7. 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 8. 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.
Por Que e Quando Desempenhar Esta Tarefa
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 da janela de conteúdo Ligação e verá que uma Ligação e o Serviço do 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 necessária:
- 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 de 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ê poderá alterar a configuração do projeto da Web gerado
para que corresponda ao endereço de serviço 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"), então, você 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).
Por Que e Quando Desempenhar Esta Tarefa
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 na tela 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
O exemplo a seguir mostra as convenções utilizadas ao gerar 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 registro de data e hora 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 9. 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 10. 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.
Por Que e Quando Desempenhar Esta Tarefa
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 necessária:
- 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ção de 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ê poderá alterar a configuração do projeto da Web gerado
para que corresponda ao endereço de serviço 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"), então, você 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).
Por Que e Quando Desempenhar Esta Tarefa
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 na tela 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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 necessárias 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.
Por Que e Quando Desempenhar Esta Tarefa
Tabela 11. 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 do 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.
Por Que e Quando Desempenhar Esta Tarefa
Migrando o Cliente EJB
Este tópico mostra como migrar clientes que utilizam uma interface EJB
para chamar um serviço.
Por Que e Quando Desempenhar Esta Tarefa
- 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 na tela 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
Por Que e Quando Desempenhar Esta Tarefa
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, deve
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.
- 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.
Por Que e Quando Desempenhar Esta Tarefa
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, deve
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.
- 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).
Por Que e Quando Desempenhar Esta Tarefa
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 interagir 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.
- 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.
Por Que e Quando Desempenhar Esta Tarefa
É 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.
Por Que e Quando Desempenhar Esta Tarefa
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 nos quais as operações de tarefa manual estão
disponíveis como um EJB separados. Os nomes JNDI 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
For the generic messaging API in WebSphere Process Server, see the topic
"Developing JMS client applications" in the link below.
Por Que e Quando Desempenhar Esta Tarefa
Desenvolvendo aplicativos clientes JMS.
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.
Por Que e Quando Desempenhar Esta Tarefa
O assistente de Migração preserva as configurações do cliente da Web 5.1 e talvez não seja
necessário editar essas configurações no editor de Tarefa Manual. 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:
- As 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 a tela 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.
Por Que e Quando Desempenhar Esta Tarefa
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 12. 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 possua 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, e assim por diante).
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 código do snippet
6.x Java, se ele 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 somente 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, pode 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.
Por Que e Quando Desempenhar Esta Tarefa
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.
O que Fazer Depois
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.
Por Que e Quando Desempenhar Esta Tarefa
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. Não há como evitar isto em alguns casos, portanto, o exemplo a seguir mostra 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"));
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.
Por Que e Quando Desempenhar Esta Tarefa
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/
Avisos
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 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ções de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não lhe garante direito algum 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-0032, 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 A ELAS NÃO SE LIMITANDO, AS GARANTIAS IMPLÍCITAS 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, essa disposição pode não se aplicar
ao Cliente.
Essas informações podem conter imprecisões técnicas ou erros
tipográficos. São feitas alterações periódicas 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 Internacional de Licença do Programa 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 em 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.
Todos os preços IBM mostrados são preços de varejo sugeridos pela IBM, são atuais e estão sujeitos a alteração sem aviso prévio. Os preços do revendedor podem variar.
Estas informações foram projetadas apenas com o propósito de planejamento. As informações aqui contidas estão sujeitas a alterações antes que os produtos descritos estejam disponíveis.
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 a confiabilidade, manutenção ou função destes programas.
Cada cópia ou parte destes programas de exemplo ou qualquer trabalho derivado deve incluir um aviso de copyright com os dizeres:
© (nome da empresa) (ano). Partes deste código são derivadas dos
Programas de Exemplo da IBM Corp. © Copyright IBM Corp. _insira o ano ou anos_. 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, se fornecidas, 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ços
IBM,
o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países. Se estes e outros termos de marcas registradas IBM são marcados em sua primeira ocorrência nestas informações com um símbolo de marca registrada (® ou ™), estes símbolos indicam marcas registradas ou de direito consuetudinário dos Estados Unidos pertencentes à IBM no momento em que estas informações foram publicadas.
Tais marcas registradas também podem ser marcas registradas ou de direito consuetudinário em outros países. Uma lista atual de marcas registradas IBM está disponível na Web em "Copyright and trademark information" no endereço www.ibm.com/legal/copytrade.shtml.
Adobe, o logotipo Adobe logo, PostScript e o logotipo PostScript são marcas ou marcas registradas da Adobe Systems Incorporated nos Estados Unidos e/ou em outros países.
Java e todas as marcas registradas e logotipos baseados em Java são marcas registradas da Sun Microsystems, Inc. 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.
Microsoft, Windows, Windows NT e o logotipo Windows são marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.
Intel, o logotipo Intel, Intel Inside, o logotipo Intel Inside, Intel Centrino, o logotipo Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium e Pentium são marcas ou marcas registradas da Intel Corporation ou de suas subsidiárias nos Estados Unidos e/ou em outros países.
UNIX é uma marca registrada do The Open Group nos Estados Unidos e em outros países.
Outros nomes de empresas, produtos ou serviços podem ser marcas registradas ou marcas de serviço de terceiros.
Termos de Uso
As permissões para uso das publicações são concedidas de acordo com os seguintes termos e condições.
Uso Pessoal: O Cliente poderá reproduzir estas publicações para uso pessoal e não-comercial, contanto que todos os avisos do proprietário sejam preservados.
O Cliente não poderá distribuir, exibir ou criar trabalhos derivativos destas publicações ou de qualquer parte das mesmas sem a autorização expressa, por escrito, da IBM.
Uso Comercial: O Cliente poderá reproduzir, distribuir e exibir estas publicações somente dentro da empresa do Cliente, contanto que sejam preservados todos os avisos do proprietário. O Cliente não poderá criar trabalhos 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 se reserva o 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 A ELAS NÃO SE LIMITANDO, AS GARANTIAS IMPLÍCITAS DE
COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.
© Copyright IBM Corporation
2005, 2008. Todos os Direitos Reservados.