WebSphere Integration Developer, Vers�2 Sistemas Operacionais: Linux, Windows


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.

Índice

Capítulo 1. Migrando para o WebSphere Integration Developer
Capítulo 2. Migrando de versões anteriores do WebSphere Integration Developer
Considerações do Processo de Migração de Versão para Versão
Níveis de Versão de Desenvolvimento e Implementação
Capítulo 3. Migrando para o WebSphere Process Server do WebSphere InterChange Server
Caminhos de Migração Suportados
Preparando a Migração do WebSphere InterChange Server
Migrando do WebSphere Business Integration Server Express (WBISX)
Cenários de Migração do WebSphere InterChange Server
Considerações para o Processo de Migração do WebSphere InterChange Server
Considerações: Desenvolvimento Geral
Considerações: Utilitários de Código Comuns:
Considerações: Conjuntos de Conexões com o Banco de Dados
Considerações: Objetos de Negócios
Considerações: Modelos de Colaboração
Considerações: Mapas
Considerações: Relacionamentos
Considerações: Clientes de Estrutura de Acesso
Considerações: Evitando colisões de banco de dados
Considerações: Pós-Migração
Migrando os Artefatos do WebSphere InterChange Server Utilizando o Assistente de Migração
Verificando a Migração do WebSphere InterChange Server
Trabalhando com Falhas de Migração do WebSphere InterChange Server
Artefatos do WebSphere InterChange Server Manipulados por Ferramentas de Migração
APIs do WebSphere InterChange Server Suportadas
Mapeando o WebSphere Process Sever DataObject a partir do WebSphere InterChange Server XML
Capítulo 4. Migrando para o WebSphere Integration Developer a partir do WebSphere MQ Workflow
Preparando a Migração do WebSphere MQ Workflow
Migrando o WebSphere MQ Workflow Utilizando o Assistente de Migração
Otimizando os Processos de Negócios Migrados
Verificando a Migração do WebSphere MQ Workflow
Limitações do Processo de Migração (do WebSphere MQ Workflow)
Capítulo 5. Migrando do WebSphere Studio Application Developer Integration Edition
Migrando seu Espaço de Trabalho
Caminhos de Migração Suportados para Migração de Artefatos de Origem
Preparando Artefatos de Origem para Migração
Considerações de Pré-migração
Migrando os Espaços de Trabalho Utilizando o Assistente de Migração do WebSphere Integration Developer
Migrando os Espaços de Trabalho Utilizando o WSADIEWorkspaceMigration
Verificando a Migração de Artefatos de Origem
Trabalhando com Falhas de Migração de Artefatos de Origem
Limitações de Migração de Artefatos de Origem
Informações Adicionais de Migração
Criando Componentes do SCA e Importações do SCA para os Serviços no Aplicativo de Religação
Migrando um Serviço Java
Migrando um Serviço EJB
Migrando um Processo de Negócios para a Chamada do Serviço de Processo de Negócios
Migrando um Serviço da Web (SOAP/JMS)
Migrando um Serviço da Web (SOAP/HTTP)
Migrando um Serviço JMS
Migrando um Serviço J2C-IMS
Migrando um Serviço ECI do J2C-CICS
Migrando um Serviço EPI do J2C-CICS
Migrando um Serviço J2C-HOD
Migrando um Serviço do Transformador
O Cenário de Consumo para Migração de Serviço
Criando Exportações SCA para Acessar o Serviço Migrado
Migrando o EJB e as Ligações do Processo EJB
Migrando o JMS e as Ligações do Processo JMS
Migrando a Ligação do IBM Web Service (SOAP/JMS)
Migrando a Ligação do IBM Web Service (SOAP/HTTP)
Migrando a Ligação do Apache Web Service (SOAP/HTTP)
Migrando para o Modelo de Programação SCA
Migrando Chamadas de API WSIFMessage para APIs SDO
Migrando o Código de Cliente do WebSphere Business Integration Server Foundation
Migrando Snippets Java do BPEL do WebSphere Business Integration Server Foundation
Migrando Interações com o WebSphere Business Integration Adapters
Migrando Interfaces WSDL com Tipos de Matrizes Codificadas pelo SOAP
Excluindo Manualmente Definições do WSIF (Web Services Invocation Framework) 5.1
Avisos
Termos de Uso

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.

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.

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:

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:

Preparando a Migração do WebSphere InterChange 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:

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:

  1. 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".
  2. 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:

  1. 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.
  2. 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:

É 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 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:

  1. Os adaptadores serão migrados para ligações nativas se eles puderem ser suportados como ligações nativas e
  2. 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:

  1. 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.
  2. 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.
  3. Digite o nome de uma biblioteca nova ou de uma já existente do WebSphere Integration Developer.
  4. 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.
  5. 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.
  6. 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:
    Página Opções de Conversão de Migração
    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.
  7. Clique em Avançar. Uma página Resumo da Migração é aberta de forma semelhante ao exemplo a seguir:
    Página Resumo da Migração
  8. 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:

Página Resultados da Migração

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.

  1. 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.
  2. 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:

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:

As ferramentas de migração não manipulam os seguintes artefatos do WebSphere InterChange Server:

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/

JavaConnectorUtil
AppSide_Connector/

JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/

BusObj
Collaboration/

BusObjArray
Collaboration/

BaseDLM
DLM/

CwDBConnection
CwDBConnection/
CxCommon/

CwDBConstants
CwDBConnection/
CxCommon/

CwDBStoredProcedureParam
CwDBConnection/
CxCommon/

DataHandler (Abstract Class)
DataHandlers/
crossworlds/
com/

NameHandler (Abstract Class)
DataHandlers/
crossworlds/
com/

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/

CxObjectAttr
CxCommon/

CxObjectContainerInterface
CxCommon/

DtpConnection
Dtp/
CxCommon/

DtpDataConversion
Dtp/
CxCommon/

DtpDate
Dtp/
CxCommon/

DtpMapService
Dtp/
CxCommon/

DtpSplitString
Dtp/
CxCommon/

DtpUtils
Dtp/
CxCommon/

BusObjInvalidVerbException (extends InterchangeExceptions)
Exceptions/
CxCommon/

IdentityRelationship
relationship/
utilities/
crossworlds/
com/

MapExeContext
Dtp/
CxCommon/

Participant
RelationshipServices/
Server/

Relationship
RelationshipServices/
Server/

UserStoredProcedureParam
Dtp/
CxCommon/

BaseCollaboration
Collaboration/

CxExecutionContext
CxCommon/

CollaborationException
Collaboration/

Filter
crossworlds/
com/

Globals
crossworlds/
com/

SmartCollabService
crossworlds/
com/

StateManagement
crossworlds/
com/

EventKeyAttrDef
EventManagement/
CxCommon/

EventQueryDef
EventManagement/
CxCommon/

FailedEventInfo
EventManagement/
CxCommon/

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

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.

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

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:

Para obter informações adicionais sobre como migrar utilizando a ferramenta de conversão FDL2BPEL, consulte o site de suporte do WebSphere MQ Workflow.

Preparando a Migração 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:

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:

Para utilizar o Assistente de Migração para migrar os artefatos do WebSphere MQ Workflow, siga estas etapas:

  1. 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.
  2. 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:
    Assistente de migração do FDL com os nomes do arquivo de origem e do módulo indicados
  3. 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:
    Página Opções de Migração do WebSphere MQ Workflow para as configurações de criação de artefatos
  4. 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:
    Página Opções de Migração do WebSphere MQ Workflow para otimizar os processos de negócios migrados
    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.
  5. 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:

Página Resultados da migração do WebSphere MQ Workflow

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:

Janela Resultados da Migração (Migration Results)

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.

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:

  1. Prepare os artefatos de origem para migração. Pode ser necessário executar essas ações no WebSphere Studio Application Developer Integration Edition.
  2. Utilize o assistente de Migração ou o script da linha de comandos WSADIEWorkspaceMigration para migrar o espaço de trabalho.
  3. 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.

Caminhos de Migração Suportados para Migração de Artefatos de Origem

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.

Preparando Artefatos de Origem para Migração

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:

  1. Certifique-se de ter uma cópia de backup do espaço de trabalho inteiro da 5.1 antes de tentar migrar.
  2. Reveja a seção de serviço da Web do Centro de Informações do Rational Application Developer para obter informações básicas sobre a funcionalidade de serviço da Web fornecida pelo Rational Application Developer: Developing Web services
  3. 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:
  4. Utilize um novo espaço de trabalho como o espaço de trabalho de destino de migração.
  5. 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.
  6. 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:
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:

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:

  1. Cria um novo módulo de integração de negócios (o nome do módulo é definido por você)
  2. Migra as entradas de caminho de classe do projeto de serviço para o novo módulo
  3. Copia todos os artefatos de origem do WebSphere Business Integration Server Foundation do projeto de origem selecionado para este módulo
  4. Migra as extensões de BPEL em arquivos WSDL
  5. 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
  6. Cria um componente SCA para cada processo BPEL
  7. 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)
  8. Cria importações e exportações conforme as opções de implementação escolhidas no WebSphere Studio Application Developer Integration Edition
  9. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Depois que o processo for concluído, você verá a seguinte mensagem:
    Mensagem do Rational Desktop Migration para observar que os projeto e os dados que precisam ser migrados foram detectados
    Clique em Avançar para iniciar o processo de validação da migração.
  6. Selecione os projetos do espaço de trabalho a serem migrados:
    Lista de projetos de espaço de trabalho a serem migrados
    Clique em Avançar.
  7. Os recursos de projeto que podem sofre impacto pelo processo de migração são listados:
    Lista de recursos de projeto a serem migrados
    Reveja esta lista e clique em Avançar.
  8. Quando estiver pronto, clique em Concluir para iniciar a migração dos projetos selecionados.
  9. Depois que o processo de validação da migração tiver sido concluído, você deve ver a seguinte mensagem:
    Mensagem de validação da Migração
  10. Depois que o processo tiver sido concluído, a janela Resultados de Migração será aberta:
    Janela Resultados de Migração com uma lista de resultados
    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.
  11. 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:

Para executar o script WSADIEWorkspaceMigration, siga estas etapas:

  1. 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
  2. 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"
  3. Depois que o comando tiver concluído a execução, inicie o novo espaço de trabalho no WebSphere Integration Developer.
  4. 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.
  5. 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:

Janela Resultados da 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

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:

  1. Migre o espaço de trabalho.
  2. 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.
  3. Substitua todas as referências ao projeto EJB em Módulos pelo cliente EJB.

Limitações do Modelo de Programação SCA

Limitações Técnicas do Processo de Migração de BPEL

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

  1. 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).
  2. 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.
  3. 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:

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:

  1. 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.
  2. 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.
  3. Um componente genérico aparecerá no diagrama de Montagem. Selecione-o e vá para a visualização Propriedades.
  4. Na guia Descrição, você pode alterar o nome e o nome de exibição do componente para algo mais descritivo.
  5. Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
  6. 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.
  7. 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....
  8. 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:

  1. Definições relevantes da interface WSDL 5.1.
  2. Os métodos WebSphere Studio Application Developer Integration Edition 5.1 Java que correspondem ao WSDL
  3. 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:

  1. Mova a lógica da classe Java original para essa classe, adaptando-a para utilizar DataObjects.
  2. Crie uma instância privada da classe Java antiga dentro dessa classe Java gerada e escreva código para:
    1. Converter todos os parâmetros da classe de implementação Java gerada em parâmetros que a classe Java antiga espera.
    2. Chamar a instância privada da classe Java antiga com os parâmetros convertidos.
    3. 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.
    4. 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:

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: Consulte as informações no site a seguir antes de tentar migrar utilizando este método: Creating a Web service from a Java bean
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:

  1. 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.
  2. 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.
  3. 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.
  4. Inicie o servidor de teste e implemente seu aplicativo para o servidor e certifique-se de que ele seja iniciado com êxito.
  5. 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.
  6. 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.
  7. A classe Java na qual você clicou com o botão direito do mouse será mostrada, clique em Avançar.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Clique em Avançar. Observe que você pode precisar esperar vários minutos.
  13. 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.
  14. Mude para a perspectiva Business Integration e expanda o módulo e, em seguida, a categoria lógica Portas do Serviço da Web.
  15. 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:

  1. 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.
  2. 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.
  3. 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:

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:

  1. No projeto de módulo, expanda Interfaces e selecione a interface WSDL que foi gerada para esse EJB no WebSphere Studio Application Developer Integration.
  2. 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.
  3. Um componente genérico aparecerá no diagrama de Montagem. Selecione-o e vá para a visualização Propriedades.
  4. 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.
  5. Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
  6. 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:

  1. Definições relevantes da interface WSDL 5.1.
  2. Os métodos WebSphere Studio Application Developer Integration Edition 5.1 Java que correspondem ao WSDL
  3. 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:

  1. 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.
  2. 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.
  3. Sob a seção J2EE, certifique-se de que o projeto EJB esteja relacionado e se não estiver, inclua-o clicando em Incluir....
  4. 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.
  5. Selecione a ferramenta de Ligação a partir da paleta no Editor de Montagem.
  6. Clique no componente Java e solte o mouse.
  7. Em seguida, clique em Importação EJB e solte o mouse.
  8. 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.
  9. 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.
  10. 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:

  1. Crie uma variável privada (cujo tipo é aquele de sua interface EJB remota):
    private YourEJBInterface ejbService = null;
  2. 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");
  3. 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:

  1. Converta todos os parâmetros nos tipos de parâmetros que o EJB espera.
  2. Chame o método adequado na referência EJB utilizando o modelo de programação SCA, enviando os parâmetros convertidos.
  3. 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: Consulte as informações no site a seguir antes de tentar migrar utilizando este método: Criando um serviço da Web a partir de um EJB (Enterprise Bean) utilizando o ambiente de tempo de execução do WebSphere
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:

  1. 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.
  2. 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.
  3. Inicie o servidor de teste e implemente seu aplicativo para o servidor e certifique-se de que ele seja iniciado com êxito.
  4. 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.
  5. Clique com o botão direito do mouse e selecione Serviços da Web -> Criar serviço da Web.
  6. 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.
  7. Certifique-se de que o EJB no qual clicou com o botão direito do mouse esteja selecionado aqui e clique em Avançar.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. Clique em Avançar. Observe que você pode precisar esperar vários minutos.
  14. 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.
  15. 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.
  16. 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:

  1. 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.
  2. 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.
  3. 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:

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:

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:

  1. 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).
  2. 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:

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:

  1. 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.
  2. 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).
  3. 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.
  4. Na perspectiva Business Integration, expanda o módulo migrado e abra seu Diagrama de Montagem no Editor de Montagem.
  5. 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.
  6. Escolha a criação de uma Importação com Ligação de Serviço da Web.
  7. 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.
  8. Salve o diagrama de montagem.

Depois de concluir isso, você deverá religar o serviço:

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:

  1. 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.
  2. 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).
  3. 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.
  4. Na perspectiva Business Integration, expanda o módulo migrado e abra seu Diagrama de Montagem no Editor de Montagem.
  5. 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.
  6. Escolha a criação de uma Importação com Ligação de Serviço da Web.
  7. 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.
  8. Salve o diagrama de montagem.

Depois de concluir isso, você deverá religar o serviço:

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:

  1. 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.
  2. 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).
  3. Inclua uma Importação que permitirá que o aplicativo interaja com uma fila JMS de acordo com o modelo de programação SCA.
  4. 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.
  5. Um diálogo Criação de Componente permitirá que você selecione o tipo de componente que irá criar. Escolha Importar sem Ligação.
  6. 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.
  7. 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).
  8. 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>
  9. 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:

Depois de concluir isso, você deverá religar o serviço:

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:

  1. Crie um novo projeto de módulo de integração de negócios para hospedar esse novo serviço IMS.
  2. Para criar o serviço EIS, vá para Arquivo -> Novo -> Outro -> Integração de Negócios -> Serviço Externo.
  3. 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.
  4. 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.
  5. 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:

  1. Crie o Java Bean do J2C clicando em Arquivo -> Novo -> J2C -> Java Bean do J2C
  2. Escolha a versão 1.5 do Conector IMS para Java e clique em Avançar.
  3. Selecione Conexão Gerenciada e digite o nome de consulta JNDI. Clique em Avançar.
  4. 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.
  5. 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.
  6. 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.
  7. Depois de concluir a criação de métodos Java, clique em Avançar.
  8. Complete as etapas restantes nesse assistente para criar o Java Bean do J2C.
  9. 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.
  10. 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:

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:

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.

Migrando um Serviço do Transformador

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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).
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. Um componente genérico aparecerá no diagrama de Montagem. Selecione-o e vá para a visualização Propriedades.
  7. 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).
  8. Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
  9. 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:

  1. Mova a lógica da classe Java original para essa classe, adaptando-a para a nova estrutura de dados.
  2. Crie uma instância privada da classe Java antiga dentro dessa classe Java gerada e escreva código para:
    1. Converter todos os parâmetros da classe de implementação Java gerada em parâmetros que a classe Java antiga espera.
    2. Chamar a instância privada da classe Java antiga com os parâmetros convertidos.
    3. 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:

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:

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:

  1. Selecione o item Ligação na barra de ferramentas.
  2. Clique no outro componente para selecioná-lo como a origem da ligação.
  3. Clique no componente BPEL SCA para selecioná-lo como o destino da ligação.
  4. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
    2. Selecione Exportar....
    3. Selecione Ligação SCA.
    4. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    5. 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.
    6. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de Migração.
  2. 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:
    1. Selecione o item Referências Independentes na barra de ferramentas.
    2. Clique na tela do Editor de Montagem para criar uma entidade SCA de Referências Independentes.
    3. Selecione o item Ligação na barra de ferramentas.
    4. Clique na entidade Referências Independentes para selecioná-la como a origem da ligação.
    5. Clique no componente BPEL SCA para selecioná-lo como o destino da ligação.
    6. Você verá um alerta A referência correspondente será criada no nó de origem. Deseja continuar?, clique em OK.
    7. Selecione a entidade Referências Independentes recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
    8. 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.
    9. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    10. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
    2. Selecione Exportar... .
    3. Selecione Ligação de Serviço da Web.
    4. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    5. Selecione o transporte: soap/http ou soap/jms.
    6. 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.
    7. 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:

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:

  1. Selecione o item Ligação na barra de ferramentas.
  2. Clique no outro componente para selecioná-lo como a origem da ligação.
  3. Clique no componente BPEL SCA para selecioná-lo como o destino da ligação.
  4. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
    2. Selecione Exportar....
    3. Selecione Ligação SCA.
    4. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    5. 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.
    6. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Selecione o item Referências Independentes na barra de ferramentas.
    2. Clique na tela do Editor de Montagem para criar uma entidade SCA de Referências Independentes.
    3. Selecione o item Ligação na barra de ferramentas.
    4. Clique na entidade Referências Independentes para selecioná-la como a origem da ligação.
    5. Clique no componente BPEL SCA para selecioná-lo como o destino da ligação.
    6. Você verá um alerta A referência correspondente será criada no nó de origem. Deseja continuar?, clique em OK.
    7. Selecione a entidade Referências Independentes recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
    8. 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.
    9. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    10. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Clique com o botão direito do mouse no componente BPEL no Editor de Montagem.
    2. Selecione Exportar... .
    3. Selecione Ligação de Serviço da Web.
    4. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    5. Selecione o transporte: soap/http ou soap/jms.
    6. 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.
    7. 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:

  1. 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).
  2. Abra o editor de montagem para o módulo criado pelo assistente de migração.
  3. 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.
  4. Selecione Exportar... .
  5. Selecione Ligação JMS.
  6. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
  7. 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.
  8. 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):
    1. Para Texto, selecione para utilizar o Seletor de função JMS padrão ou digite o nome completo da classe de implementação FunctionSelector.
    2. Para Objeto, selecione para utilizar o Seletor de função JMS padrão ou digite o nome completo da classe de implementação FunctionSelector.
    3. 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.
    4. 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.
  9. 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.
  10. Selecione a área de janela de conteúdo Ligação para ver muito mais opções.
  11. 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:

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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Clique com o botão direito do mouse no componente SCA no Editor de Montagem.
    2. Selecione Exportar....
    3. Selecione Ligação de Serviço da Web.
    4. Se houver várias interfaces para o componente, selecione as interfaces a serem exportadas com este tipo de ligação.
    5. Selecione o transporte soap/jms.
  3. 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.
  4. Salve o diagrama de montagem.
  5. 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.
  6. 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:
    1. 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.
    2. 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.
    3. 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.
    4. Vá para a guia Origem. Exclua todos os PortTypes e Mensagens WSDL definidos neste arquivo.
    5. 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.
    6. 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.
    7. Salve o arquivo WSDL.
    8. Atualize/reconstrua o projeto. Vá para a perspectiva Business Integration. Abra o Diagrama de Montagem do módulo no Editor de Montagem.
    9. 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.
    10. 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.
    11. Salve todas as alterações.
    12. 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"/>
    13. 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.
    14. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Selecione o item Referências Independentes na barra de ferramentas.
    2. Clique na tela do Editor de Montagem para criar uma entidade SCA de Referências Independentes.
    3. Selecione o item Ligação na barra de ferramentas.
    4. Clique na entidade Referências Independentes para selecioná-la como a origem da ligação.
    5. Clique no componente BPEL SCA para selecioná-lo como o destino da ligação.
    6. Você verá um alerta A referência correspondente será criada no nó de origem. Deseja continuar?, clique em OK.
    7. Selecione a entidade Referências Independentes recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
    8. 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.
    9. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    10. 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:

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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de Migração.
  2. 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.
  3. Selecione Exportar....
  4. Selecione Ligação de Serviço da Web.
  5. Se houver várias interfaces para o componente, selecione as interfaces a serem exportadas com este tipo de ligação.
  6. Selecione o transporte soap/http.
  7. 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.
  8. Salve o diagrama de montagem.
  9. 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:
    1. 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.
    2. 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.
    3. 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.
    4. Vá para a guia Origem. Exclua todos os PortTypes e Mensagens WSDL definidos neste arquivo.
    5. 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.
    6. 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.
    7. Salve o arquivo WSDL.
    8. Atualize/reconstrua o projeto. Vá para a perspectiva Business Integration. Abra o Diagrama de Montagem do módulo no Editor de Montagem.
    9. 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.
    10. 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.
    11. Salve todas as alterações.
    12. 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"/>
    13. 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.
    14. 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:

  1. Abra o Editor de Montagem para o módulo criado pelo assistente de migração.
  2. 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:
    1. Selecione o item Referências Independentes na barra de ferramentas.
    2. Clique na tela do Editor de Montagem para criar uma entidade SCA de Referências Independentes.
    3. Selecione o item Ligação na barra de ferramentas.
    4. Clique na entidade Referências Independentes para selecioná-la como a origem da ligação.
    5. Clique no componente SCA para selecioná-lo como o destino da ligação.
    6. Você verá um alerta A referência correspondente será criada no nó de origem. Deseja continuar?, clique em OK.
    7. Selecione a entidade Referências Independentes recém-criada na visualização Propriedades e selecione a área de janela de conteúdo Descrição.
    8. 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.
    9. Se houver várias interfaces para o processo, selecione as interfaces a serem exportadas com este tipo de ligação.
    10. 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:

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).

Migrando para o Modelo de Programação SCA

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
  1. Baseado no WSIF e no WSDL
  2. Proxies gerados para serviços
  3. Rotinas de tratamento de beans e formatos para tipos
Modelo de Programação da V6.x (Mais centralizado em Java)
  1. Serviços SCA baseados em SDOs com tags doclet
  2. Ligações de interface para serviços
  3. 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

  1. 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.
  2. 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.
  3. Selecione a ferramenta de ligação e clique na referência de serviço e, em seguida, clique em Importar.
  4. Clique em OK quando receber um alerta de que será criada uma referência correspondente no nó de origem.
  5. 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?:
    1. 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.
    2. 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.
  6. 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.
  7. 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.

  1. Certifique-se de que tenha um WebSphere Process Server ou um WebSphere Application Server instalado.
  2. 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.
  3. Para o Tipo de Proxy de Cliente, escolha Proxy Java e clique em Avançar.
  4. O local do WSDL deve ser preenchido. Clique em Avançar.
  5. 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.
  6. 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.

  1. Certifique-se de que tenha um WebSphere Process Server ou um WebSphere Application Server instalado.
  2. 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.
  3. Para o Tipo de Proxy de Cliente, escolha Proxy Java e clique em Avançar.
  4. O local do WSDL deve ser preenchido. Clique em Avançar.
  5. 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.
  6. 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.

  1. Certifique-se de que tenha um WebSphere Process Server ou um WebSphere Application Server instalado.
  2. 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.
  3. Para o Tipo de Proxy de Cliente, escolha Proxy Java e clique em Avançar.
  4. O local do WSDL deve ser preenchido. Clique em Avançar.
  5. 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.
  6. 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:

  1. As mensagens têm partes não primitivas para aprimorar a usabilidade da estrutura de dados da mensagem.
  2. 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:

  1. Selecione a tela do processo ou uma atividade no processo.
  2. Na visualização Propriedades, selecione a guia Cliente para reprojetar as configurações do cliente Web.
  3. Migre manualmente qualquer JSP definida pelo usuário:
    1. Consulte a seção "Migrando para o Modelo de Programação SCA" para obter as alterações do modelo de programação.
    2. 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.
  4. 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:

  1. Vá para Arquivo -> Novo -> Outro -> Business Integration e selecione External Service. Clique em Avançar.
  2. Escolha Adaptadores. Clique em Avançar.
  3. 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.
  4. 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.
  5. Aceite os parâmetros de configuração para o objeto de negócios e clique em OK.
  6. Repita essa operação para cada objeto de negócios.
  7. Clique em Avançar.
  8. 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.
  9. 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.




Feedback

(C) Copyright IBM Corporation 2005, 2009. Todos os Direitos Reservados.
Este Centro de Informaº%s ® desenvolvido na tecnologia Eclipse. (http://www.eclipse.org)