IBM WebSphere WebSphere Integration Developer Versão 6.1

Migration Guide

Version 6 Release 1

Comunicado

Antes de utilizar essas informações e o produto suportado por elas, leia as informações em Avisos.

Esta edição aplica-se à versão 6, release 1, do WebSphere Integration Developer.

Copyright International Business Machines Corporation 2005, 2007. Todos os direitos reservados.

Í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 para o WebSphere InterChange Server
Preparando a 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 o 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
Verificando a Migração do WebSphere MQ Workflow
Limitações do Processo de Migração (do WebSphere MQ Workflow)
Capítulo 5. Migrando Artefatos de Origem para o WebSphere Integration Developer do WebSphere Studio Application Developer Integration Edition
Caminhos de Migração Suportados para Migração de Artefatos de Origem
Preparando Artefatos de Origem para Migração
Considerações para o Processo de Migração de Artefatos de Origem
Migrando Projetos de Serviço Utilizando o Assistente de Migração do WebSphere Integration Developer
Migrando Projetos de Serviço Utilizando WSADIEServiceProjectMigration
Completando a Migração de Aplicativo
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
Migrando Projetos EJB do WebSphere Business Integration
Excluindo Manualmente Definições do WSIF (Web Services Invocation Framework) 5.1
Verificando a Migração de Artefatos de Origem
Trabalhando com Falhas de Migração de Artefatos de Origem
Limitações do Processo de Migração (Para Migração de Artefatos de Origem)
Avisos
Termos de Uso

Capítulo 1. Migrando para o WebSphere Integration Developer

O WebSphere Integration Developer Versão 6.1 fornece as ferramentas necessárias para migrar seu ambiente existente.

Nota: Os projetos WebSphere Integration Developer 6.0.2 e 6.1 não podem ser utilizados no WebSphere Integration Developer 6.0.1. Uma vez feito o upgrade do WebSphere Integration Developer 6.0.2 ou 6.1, você não retornar os projetos para o WebSphere Integration Developer 6.0.1.x. O suporte também não está disponível para um usuário de 6.0.2 ou 6.1 que marca seu código em um repositório ou exporta projetos e então compartilha-os com um usuário do WebSphere Integration Developer 6.0.1.

Os tópicos a seguir descrevem conceitos, informações de referência e instruções passo a passo de migração para o WebSphere Integration Developer:

Capítulo 2. Migrando de versões anteriores do WebSphere Integration Developer

A migração de versões anteriores do WebSphere Integration Developer para WebSphere Integration Developer 6.1 é suportada. Isso é referido como migração de versão-para-versão.

A migração do WebSphere Integration Developer 6.1 preserva a estrutura básica de seu aplicativo existente exigindo uma reconfiguração mínima. Observe que o processo de versão-para-versão não tem um assistente de migração associado a ele.

Os tópicos a seguir fornecem melhor orientação sobre o processo de migração de versão-para-versão do WebSphere Integration Developer:

Considerações do Processo de Migração de Versão para Versão

Ao migrar de uma versão anterior do WebSphere Integration Developer para V6.1, grande parte da migração é feita por você. Entretanto, há algumas considerações que requerem uma configuração manual adicional.

As considerações a seguir destinam-se ajudar no processo de migração de versão para versão:

Adaptadores
Aplicativos que utilizam um nível anterior de adaptador podem ter uma migração mais rápida para o nível atual com um utilitário. Para obter mais informações, consulte o tópico "Migrando para aplicativos que utilizam níveis de adaptadores anterior" na seção de link relacionado abaixo.

Eventos CEI
Os modelos de monitor do WebSphere Integration Developer 6.0.2 não podem ser criados recentemente mas podem ser utilizados no WebSphere Integration Developer 6.1 se eles já tiverem sido criados.

Editor de Definição de Evento
Esse editor é reprovado no WebSphere Integration Developer 6.1.

XSD Federation
O XSD Federation (ou seja, geração de inclusões xsd) foi removido no WebSphere Integration Developer 6.1. Portanto, apenas PIs antigos precisam ter inclusões de xsd incluídos no PI. Isso acontece automaticamente para PIs exportados no WebSphere Integration Developer 6.0.2.x. Entretanto, para exportar PIs do 6.0.1.2, você precisa explicitamente ativar a caixa de opção Incluir arquivos derivados quando executar a exportação.

Primitivas do XSL Transformation
No WebSphere Integration Developer 6.1, a primitiva XSL Transformation tem um novo editor de mapeamento XML. Os mapas XML que foram construídos em uma versão anterior precisam ser migrados para o novo formato para poderem ser editados. Para obter mais informações, consulte o tópico "Migrando uma primitiva de XSL Transformation" na seção de link relacionado abaixo.

Níveis de Versão de Desenvolvimento e Implementação

Sua decisão sobre qual nível de versão precisará em seu ambiente dependerá dos níveis de versão com os quais seus aplicativos foram desenvolvidos.

O WebSphere Process Server 6.1 e o WebSphere Integration Developer 6.1 são compatíveis com releases anteriores da seguinte maneira:

Nota: Para sistemas i5/OS, não há versões anteriores instaladas.

Capítulo 3. Migrando para o WebSphere Process Server do WebSphere InterChange Server

A migração do WebSphere InterChange Server para o WebSphere Process Server é suportada através das funções a seguir no WebSphere Integration Developer.

Nota: Consulte as notas sobre o release para obter informações sobre limitações relacionadas à migração neste release do WebSphere Process Server.

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:

Caminhos de Migração Suportados para o WebSphere InterChange Server

As ferramentas de migração do WebSphere Process Server suportam migração do WebSphere InterChange Server versões 4.2.2 ou posteriores.

Toda liberação do WebSphere InterChange Server anterior à Versão 4.2.2 primeiro precisará migrar para a versão 4.2.2 ou 4.3 antes de migrar para o WebSphere Process Server.

Preparando a Migração do WebSphere InterChange Server

Antes de migrar para o WebSphere Process Server do WebSphere InterChange Server, primeiro, é necessário assegurar que você tenha preparado corretamente seu ambiente. O WebSphere Process Server fornece as ferramentas necessárias para migrar do WebSphere InterChange Server.

Estas ferramentas de migração podem ser chamadas de:

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. assegurar que você esteja executando uma versão do WebSphere InterChange Server que pode ser migrada para WebSphere Process Server. Consulte o tópico "Caminhos de Migração Suportados para o WebSphere InterChange Server".
  2. exportar os artefatos de origem do WebSphere InterChange Server para um arquivo jar do repositório utilizando o comando repos_copy do WebSphere InterChange Server conforme descrito na documentação do WebSphere InterChange Server. O assistente requer como entrada um arquivo JAR do repositório WebSphere InterChange Server. Esse arquivo JAR deve ser auto-contido com respeito a aplicativos que estão sendo migrados. Ou seja, todos os artefatos referidos por algum dos artefatos no arquivo JAR também precisam estar contido no arquivo JAR. Para assegurar que o arquivo JAR do repositório que será gerado é auto-contido, execute o comando repos_copy com a opção -vr antes de exportar o repositório do servidor (isso valida o repositório). Se o repositório for válido, então o repos_copy grava a seguinte saída para o console: Validação bem-sucedida. Todas as Dependências Resolvidas. Se o repositório não for válido, então o comando repos_copy imprime uma lista de dependências que precisam ser resolvidas. Resolva as dependências antes de exportar o repositório. Exporte os artefatos de repositório e crie o arquivo JAR do repositório, utilizando o comando WebSphere InterChange Server repos_copy com a opção -o (Consulte a documentação WebSphere InterChange Server 4.3 para obter mais detalhes, inclusive como exportar componentes individuais.

Considerações para o Processo de Migração do WebSphere InterChange Server

As considerações a seguir destinam-se a ajudar no desenvolvimento de artefatos de integração do WebSphere InterChange Server. Seguindo estas diretrizes, você pode facilitar a migração de artefatos do WebSphere InterChange Server para o WebSphere Process Server.

Essas recomendações destinam-se a serem utilizadas somente como um guia. Pode haver casos em que é necessário desviar-se dessas orientações. Neste casos, é necessário ter cuidado para limitar o escopo do desvio para minimizar a quantidade de retrabalho requerido para migrar os artefatos. Observe que as orientações destacadas aqui não são todas recomendações gerais para o desenvolvimento de artefatos do WebSphere InterChange Server. Elas estão limitadas no escopo às considerações que podem afetar a facilidade em que os artefatos podem ser migrados futuramente.

Considerações: Desenvolvimento Geral

Existem várias considerações que se aplicam amplamente à maioria dos artefatos de integração. Em geral, os artefatos que alavancam os recursos fornecidos pelas ferramentas e estão de acordo com os modelos de metadados aplicados pelas ferramentas serão migrados de maneira mais uniforme. Além disso, os artefatos com extensões importantes e dependências externas provavelmente precisarão de mais intervenção manual durante a migração.

A lista a seguir resume as considerações para desenvolvimento geral de soluções baseadas no WebSphere InterChange Server para ajudar a facilitar a migração futura:

É importante para soluções de integração aderir ao modelo de programação e arquitetura fornecido pelo WebSphere InterChange Server. Cada componente de integração dentro do WebSphere InterChange Server desempenha uma função bem definida dentro da arquitetura. Os desvios significativos deste modelo o tornarão mais desafiador para migrar o conteúdo para os artefatos apropriados no WebSphere Process Server.

Outra prática geral que melhorará o sucesso de futuros projetos de migração é documentar o design do sistema. Certifique-se de capturar a arquitetura e design de integração, incluindo os requisitos de design funcional e de qualidade de serviço, as interdependências de artefatos compartilhados entre projetos e também as decisões de design que foram tomadas durante a implementação. Isto ajudará na análise do sistema durante a migração e minimizará os esforços de retrabalho.

Para criar, configurar e modificar definições de artefato, utilize apenas a ferramenta de desenvolvimento fornecida. Evite a manipulação manual de metadados de artefatos (por exemplo, a edição direta de arquivos XML), que pode danificar o artefato para migração.

Siga essas diretrizes quando desenvolver o código Java dentro de modelo de colaboração, mapas, utilitários de código comum e outros componentes:

Utilize apenas APIs publicadas na documentação do produto WebSphere InterChange Server para os artefatos. Estas tarefas estão descritas detalhadamente nos guias de desenvolvimento do WebSphere InterChange Server. APIs de compatibilidade serão fornecidas no WebSphere Process Server para APIs WebSphere InterChange Server publicadas. Embora o WebSphere InterChange Server tenha muitas interfaces internas que você pode desejar utilizar, essa prática é desencorajada porque essas interfaces não são garantidas como suportadas futuramente.

Ao projetar a lógica de negócios e as regras de transformação em mapas e modelo de colaboração, tente evitar bibliotecas de utilitário de código comum desenvolvidas em campo, incluídas como um arquivo Java archive (*.jar) no caminho de classe do WebSphere InterChange Server, já que elas precisarão ser migradas manualmente.

Utilize a ferramenta do Activity Editor para a maior extensão possível. Isto assegurará que a lógica seja descrita por meio de metadados que podem ser mais prontamente convertidos para os novos artefatos. Para operações que você deseja reutilizar nas ferramentas, utilize o recurso "Minhas Coletas" do Activity Editor sempre que possível.

Em quaisquer trechos de código Java que precise ser desenvolvido, o código ser o mais simples e atômico possível. O nível de sofisticação no código Java deve estar na ordem de script, envolvendo avaliações básicas, operações e cálculos, formatação de dados, conversões de tipos, e assim por diante. Se for requerida uma lógica de aplicativo mais extensiva ou sofisticada, será necessário utilizar os EJBs em execução no WebSphere Application Server para encapsular a lógica e utilizar chamadas de serviços da Web para chamá-la do WebSphere InterChange Server. Utilize bibliotecas JDK padrão em vez de bibliotecas de terceiros ou externas que precisariam ser migradas separadamente. Colete também toda a lógica relacionada em um único trecho de código e evite utilizar lógica onde os contextos de conexão e de transação estendem vários trechos de código. Com operações do banco de dados, por exemplo, o código relacionado à obtenção de uma conexão, ao início e fim de uma transação e à liberação da conexão deve estar em um trecho de código.

Em geral, certifique-se de que o código projetado para interagir com um EIS (Enterprise Information System) esteja colocado em adaptadores e não em mapas ou em gabaritos de colaboração. Isso geralmente é uma prática recomendada para design de arquitetura. Além disso, isto ajudará a evitar pré-requisitos para bibliotecas de terceiros e considerações relacionadas no código, como gerenciamento de conexões e possíveis implementações de JNI (Java Native Interface).

Torne o código o mais seguro possível utilizando a manipulação de exceção apropriada. Torne também o código compatível para execução em um ambiente do servidor de aplicativos J2EE, mesmo que ele esteja em execução em um ambiente J2SE. Siga as práticas de desenvolvimento do J2EE, como evitar variáveis estáticas, execução de spawn em encadeamentos e E/S de disco. Ao mesmo tempo em que são boas práticas geralmente recomendadas, elas podem melhorar a portabilidade.

Considerações: Utilitários de Código Comuns:

É recomendável evitar o desenvolvimento de bibliotecas de utilitário de código comum para utilização nos artefatos de integração no ambiente do WebSphere InterChange Server. Onde é necessária a reutilização de código nos artefatos de integração, é recomendável alavancar o recurso "Minhas Coletas" da ferramenta Activity Editor. Considere também a utilização de EJBs em execução no WebSphere Application Server para encapsular a lógica e utilizar chamadas de serviços da Web para chamá-la a partir do WebSphere InterChange Server.

Embora seja possível que algumas bibliotecas de utilitários de código comuns sejam executadas apropriadamente no WebSphere Process Server, o usuário será responsável pela migração dos utilitários customizados.

Considerações: Conjuntos de Conexões com o Banco de Dados

Um conjunto de conexões do banco de dados do WebSphere InterChange Server dentro de um mapa ou modelo de colaboração será finalizado como um recurso JDBC padrão no WebSphere Process Server. Entretanto, o modo como as conexões e transações são gerenciadas pode ser diferente entre o WebSphere InterChange Server e o WebSphere Process Server, portanto evite manter as transações do banco de dados ativas através dos snippets Java.

Os conjuntos de conexão com o banco de dados definidos pelo usuário são úteis dentro de mapas e modelos de colaboração para consultas de dados simples e para instâncias de gerenciamento de estado mais sofisticadas. Um conjunto de conexões com o banco de dados no WebSphere InterChange Server será apresentado como um recurso JDBC padrão no WebSphere Process Server e a função básica será a mesma. Entretanto, o modo como as conexões e transações são gerenciadas pode diferir.

Para maximizar a portabilidade futura, evite manter transações do banco de dados ativas em nós de snippet Java em um gabarito ou mapa de colaboração. Por exemplo, o código relacionado à obtenção de uma conexão, ao início e fim de uma transação e à liberação da conexão deve estar em um trecho de código.

Considerações: Objetos de Negócios

Para o desenvolvimento dos objetos de negócios, utilize apenas as ferramentas fornecidas para configurar artefatos, utilize os tipos de dados e comprimentos explícitos para atributos de dados e utilize apenas as APIs documentadas.

Objetos de negócios dentro do WebSphere Process Server são baseados em SDOs (Service Data Objects). Os SDOs utilizam atributos de dados fortemente caracterizados. Para objetos de negócios no WebSphere InterChange Server e adaptadores, os atributos de dados não são fortemente caracterizados, e os usuários as vezes especificam tipos de dados em cadeias para atributos de dados sem cadeia. Para evitar problemas no WebSphere Process Server, especifique explicitamente os tipos de dados.

Como os objetos de negócios dentro do WebSphere Process Server podem ser serializados em tempo de execução assim como são transmitidos entre os componentes, é importante ser explícito com os comprimentos exigidos para atributos de dados, a fim de minimizar a utilização dos recursos do sistema. Por isso, não utilize o comprimento máximo de 255 caracteres para um atributo de cadeia, por exemplo. Além disso, não especifique atributos de comprimento zero que, no momento, têm como padrão 255 caracteres. Em vez disso, especifique o comprimento exato requerido para atributos.

As regras do XSD NCName se aplicam a nomes de atributo de objeto de negócios no WebSphere Process Server. Portanto, não utilize qualquer espaço ou ":" nos nomes para atributos de objeto de negócios. Os nomes de atributos de objeto de negócios com espaços ou ":" são inválidos no WebSphere Process Server. Renomeie os atributos de objeto de negócios antes da migração.

Se utilizar uma matriz em um objeto de negócios, você não pode confiar na ordem da matriz quando indexar dentro da matriz em Mapas e/ou Relacionamentos. A construção migrada para dentro do WebSphere Process Server não garante a ordem de índice, particularmente quando as entradas são excluídas.

É importante utilizar apenas a ferramenta do Business Object Designer para editar definições de objeto de negócios, e utilizar apenas as APIs publicadas para objetos de negócios dentro de artefatos de integração.

Considerações: Modelos de Colaboração

Muitas das diretrizes que já foram descritas aplicam-se ao desenvolvimento de modelos de colaboração.

Para assegurar que os processos sejam descritos apropriadamente com metadados, sempre utilize a ferramenta Process Designer para a criação e modificação de gabaritos de colaboração e evite editar os arquivos de metadados diretamente. Utilize a ferramenta Activity Editor sempre que possível para aumentar a utilização de metadados para descrever a lógica requerida.

Para minimizar a quantidade de retrabalho manual que pode ser requerido na migração, utilize apenas as APIs documentadas em gabaritos de colaboração. Evite utilizar variáveis estáticas. Em vez disso, utilize variáveis não estáticas e propriedades de colaboração para abordar os requisitos da lógica de negócios. Evite utilizar qualificadores Java finais, transientes e nativos em snippets Java. Não podem ser forçados em snippets do BPEL Java que são o resultado da migração dos Modelos de Colaboração.

Para maximizar a portabilidade futura, evite utilizar chamadas de liberação de conexão explícitas e chaves de transação explícitas (ou seja, confirmações explícitas e recuperações explícitas) para Conjuntos de Conexão de Banco de Dados Definidos pelo Usuário. Em vez disso, utilize a limpeza de conexão implícita gerenciada por contêiner e o suporte a transações implícito. Além disso, evite manter conexões e transações do sistema ativas em nós de snippet Java em um gabarito de colaboração. Isto se aplica a qualquer conexão com um sistema externo, bem como conjuntos de conexões com o banco de dados definidos pelo usuário. Operações com um EIS externo devem ser gerenciadas dentro de um adaptador, e o código relacionado à operação do banco de dados deve estar contido dentro de um trecho de código. Isto pode ser necessário em uma colaboração que, quando apresentada como um componente do processo de negócios de BPEL, pode ser seletivamente implementada como um fluxo que pode ser interrompido. Neste caso, o processo pode ser composto de várias transações separadas, apenas com informações de estados e de variáveis globais transmitidas entre as atividades. O contexto para qualquer conexão do sistema ou transação relacionada que estendeu estas transações de processos será perdido.

Dê nomes à propriedade do modelo de colaboração de acordo com as convenções de nomenclatura do W3C XML NCName. O WebSphere Process Server aceita nomes conforme essas convenções. Quaisquer caracteres desaprovados são inválidos nos nomes de propriedade BPEL aos quais serão migrados. Renomeie propriedades para remover todos os caracteres desaprovados antes de migrar para evitar erros sintáticos no BPEL gerados pela migração.

Não faça referência a variáveis utilizando "this." Por exemplo, em vez de "this.inputBusObj" utilize apenas "inputBusObj"

Utilize o escopo de nível de classe em variáveis em vez de variáveis com escopo definido pelo cenário. O escopo de cenário não é transportado durante a migração.

Inicialize todas as variáveis declaradas em snippets Java com um valor padrão: "Object myObject = null;" por exemplo. Certifique-se de que todas as variáveis sejam inicializadas durante a declaração antes de migrar.

Certifique-se de que não haja instruções de importação Java nas seções modificáveis pelo usuário de seus modelos de colaboração. Na definição do modelo de colaboração, utilize os campos de importação para especificar os pacotes Java para importar.

Não configure valores de objeto de negócios de entrada para serem armazenados na variável triggeringBusObj. Dentro do WebSphere InterChange Server, o triggeringBusObj é de leitura e seus valores não podem ser sobrescritos, assim os valores de objeto de negócios de entrada não serão salvos. Se o triggeringBusObj for utilizado como a variável de recebimento para um objeto de negócios de entrada em uma chamada de serviço de entrada, então após a migração o comportamento da chamada de serviço de entrada será diferente: dentro do processo BPEL, o valor de entrada da chamada de serviço de entrada sobrescreverá o valor armazenado em triggeringBusObj.

Considerações: Mapas

Muitas das diretrizes já descritas para modelos de colaboração também se aplicam a mapas.

Para assegurar que os mapas sejam descritos corretamente com metadados, sempre utilize a ferramenta Map Designer para a criação e modificação de mapas e evite editar os arquivos de metadados diretamente. Utilize a ferramenta Activity Editor sempre que possível para aumentar a utilização de metadados para descrever a lógica requerida.

Ao fazer referência a objetos de negócios filho em um mapa, utilize um submapa para os objetos de negócios filho.

Evite utilizar o código Java como o "valor" em um SET, já que ele não é válido no WebSphere Process Server. Em vez disso, utilize constantes. Por exemplo, se o valor configurado for "xml version=" + "1.0" + " encoding=" + "UTF-8", isto não será válido no WebSphere Process Server. Em vez disso, altere-o para "xml version=1.0 encoding=UTF-8" antes da migração.

Para minimizar a quantidade de retrabalho manual necessário na migração, utilize apenas as APIs documentadas dentro de mapas. Evite utilizar variáveis estáticas. Em vez disso, utilize variáveis não-estáticas. Evite o uso de qualificadores Java finais, temporários e nativos em código customizado de mapa.

Se utilizar uma matriz em um objeto de negócios, não confie na ordem da matriz quando indexar dentro da matriz em mapas. A construção migrada para dentro do WebSphere Process Server não garante a ordem de índice, particularmente quando as entradas são excluídas.

Para maximizar a portabilidade futura, evite utilizar chamadas de liberação de conexão explícitas e chaves de transação explícitas (ou seja, confirmações explícitas e recuperações explícitas) para Conjuntos de Conexão de Banco de Dados Definidos pelo Usuário. Em vez disso, utilize a limpeza de conexão implícita gerenciada por contêiner e o suporte a transações implícito. Também, evite manter conexões e transações do sistema ativas em etapas de mapa customizado através dos limites do nó de transformação. Isto se aplica a qualquer conexão com um sistema externo, bem como conjuntos de conexões com o banco de dados definidos pelo usuário. Operações com um EIS externo devem ser gerenciadas dentro do adaptador, e código relacionado a operação do banco de dados deve estar contido em uma etapa customizada.

Não utilize classes internas em seus mapas. O comando de migração (reposMigrate) não migra classes internas e você receberá erros se seus mapas as tiver. Em um repositório do WebSphere InterChange, uma classe interna não pode ser definida em um nó e ser referida por outros nós dentro do mesmo modelo de colaboração. Em WebSphere Process Server, uma classe interna definida em um componente BPEL não pode ser utilizada por outro componente. Devido a essa limitação, as classes internas não são convertidas e devem ser tratadas manualmente. As alterações recomendadas incluem pacote de código de classe interna em uma biblioteca como uma classe externa, ou remover a declaração de classe interna, resolvendo todos os erros, e colocando o código conforme necessário por todo o BPEL.

Considerações: Relacionamentos

Para relacionamentos, lembre-se de que embora as definições de relacionamentos poderão ser migradas para utilização no WebSphere Process Server, o esquema da tabela de relacionamentos e os dados da instância podem ser reutilizados pelo WebSphere Process Server e também compartilhados simultaneamente entre o WebSphere InterChange Server e o WebSphere Process Server.

Para relacionamentos, utilize apenas a ferramenta fornecida para configurar os componentes relacionados e utilize apenas as APIs publicadas para relacionamentos dentro de artefatos de integração.

Utilize apenas a ferramenta de Relationship Designer para editar definições de relacionamentos. Além disso, permita que apenas o WebSphere InterChange Server configure os esquemas de relacionamentos, os quais são gerados automaticamente através da implementação das definições de relacionamentos. Não altere o esquema da tabela de relacionamentos diretamente com ferramentas de banco de dados ou scripts SQL.

Se você modificar manualmente dados da instância do relacionamento dentro do esquema de tabela de relacionamento, certifique-se de utilizar os recursos fornecidas pelo Relationship Manager.

Utilize apenas APIs publicadas para relacionamentos dentro de artefatos de integração.

Considerações: Clientes de Estrutura de Acesso

Não desenvolva novos clientes adotando as APIs da interface IDL CORBA. Isto não será suportado no WebSphere Process Server.

Considerações: Evitando colisões de banco de dados

Você pode evitar colisões do banco de dados planejando eventos que ocorrem pelo menos a cada dois segundos.

Se um aplicativo migrado causar vários eventos ao mesmo tempo para os componentes do WebSphere Business Integration, podem ocorrer colisões de banco de dados ou conflitos. Isso ocorre quando o WebSphere Process Server Application Scheduler (AppScheduler) planeja vários eventos para ocorrerem exatamente ao mesmo tempo. Quando ocorre um conflito, o evento que o causou é retornado e tentado novamente assim que possível. Esse ciclo continua até que cada um dos encadeamentos que estão tentando acessar o banco de dados consiga atualizá-lo com sucesso.

Por exemplo:

AppScheduler E com.ibm.wbiserver.scheduler.AppSchedulerMB process CWLWS0021E:
O método AppSchedulerMB.process gerou uma exceção.
WSRdbXaResour E DSRA0304E: ocorreu XAException. O conteúdo e
detalhes da XAException são:
A mensagem de Erro do DB2 é: Erro ao executar uma XAResource.end(), Server retornou
XA_RBDEADLOCK O código do Erro DB2 é: -4203
O DB2 SQLState está : nulo  

Para evitar isso, planeje os eventos para ocorrerem distantes entre si o suficiente para não ocorrer conflito. Planeje os eventos para ocorrerem com pelo menos dois segundos de distância entre si, entretanto, a quantidade de tempo que você precisará pode variar de acordo com outros fatores em seu ambiente que afetam o desempenho, como o tamanho do banco de dados, hardware, velocidade da conexão e outros fatores.

Considerações: Pós-Migração

Quando os aplicativos forem migrados do WebSphere InterChange Server para oWebSphere Integration Developer ou para o WebSphere Process Server, uma atenção especial é necessária em algumas áreas para possibilitar que os aplicativos migrados funcionem no WebSphere Integration Developer e no WebSphere Process Server consistentemente com a função destinada devido às diferenças com a arquitetura do WebSphere InterChange Server.

Para obter mais informações sobre as considerações de pós-migração, consulte Considerações pós-migração.

Migrando o WebSphere InterChange Server Utilizando o Assistente de Migração

Você pode utilizar o Assistente de Migração do WebSphere Integration Developer para migrar seus artefatos existentes do WebSphere InterChange Server.

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

  1. Chame o assistente selecionando Arquivo (File) -> Importar (Import) -> Integração de Negócios (Business Integration) -> WebSphere InterChange Server JAR File e clique em Avançar (Next):
    Importe a seleção do WebSphere InterChange Server JAR File
    OU você também pode abrir o assistente de Migração a partir da página Bem-vindo (Welcome) clicando no ícone Retornando Usuários (Returning Users) Retornando usuários (Returning users) para abrir a página Retornando Usuários (Returning Users) (observe que você sempre pode retornar para a página Bem-vindo (Welcome) clicando em Ajuda (Help) -> Bem-vindo (Welcome) ):
    Página Retornando Usuários (Returning users)
    Clique em Migração (Migration) à esquerda da página Retornando Usuários (Returning Users) para abrir a página de Migração (Migration). Na página Migração (Migration), selecione a opção Migrar um repositório do WebSphere ICS (Migrate a WebSphere ICS repository) Página Migração (Migration) com a opção Migrar um repositório do WebSphere ICS (Migrate a WebSphere ICS repository) selecionada.
  2. É aberto o Assistente de Migração (Migration). Digite o nome do arquivo de origem no campo Seleção de Origem (Source selection) clicando no botão Procurar (Browse) e navegando para o arquivo. Digite o nome da biblioteca no campo relevante. Se a biblioteca compartilhada não existir no espaço de trabalho, ela precisa ser criada clicando em Novo... (New...). Clique em Avançar (Next):
    Assistente de Migração do ICS
  3. É aberta a janela de Opções de Migração. Dela você pode aceitar os padrões da migração ou selecionar uma caixa de opção para alterar a opção:
    Opções de Migração
    A tabela a seguir destaca as opções de migração disponíveis:
    Opção Descrição
    Aviso em caso de erros de análise Java (Warn in case of Java(TM) parsing errors) (Opcional) Por padrão, a migração de um artefato individual irá falhar se ocorrer um problema de conversão de Java. Se essa opção for configurada, todos os problemas de conversão Java serão tratados como avisos apenas, e o artefato será migrado assim que possível.
    Parar migração na primeira falha (Stop the migration on the first failure) (Opcional) Por padrão, o assistente de Migração continuará o processo dos artefatos restantes no arquivo JAR se ocorrer um erro durante o processamento de um certo artefato. Se essa opção estiver configurada, o processamento irá parar assim que for detectado um erro. O artefato com erro, e todos os artefatos subseqüentes, não são processados.
    Usar o desembaraçamento de loop do modelo de colaboração (Use collaboration template loop unraveling) (Opcional) Solicita que todos os loops presentes em um Modelo de Colaboração sejam mantidos. Se essa opção não estiver presente, o padrão é que a migração utilize o desembaraçamento de loop.
    Ativar seqüenciamento de eventos (Enable event sequencing) (Opcional) Solicita que o Seqüenciamento de Eventos seja ativado para todos os métodos de WSDL Assíncrono. Se essa opção não estiver presente, o padrão é que a migração não ative seqüenciamento de eventos em nenhum método WSDL.
    Usar modelo padrão (Use default template) (Opcional) Solicita que todos os modelos de editor de montagem no diretório especificado sejam carregados e utilizados para XML na conversão de Java. O padrão para essa propriedade é apenas para o Standard Assembly Editor Template v4.3.3 ser utilizado para XML na conversão Java.
  4. Clique em Concluir (Finish).

Uma barra de progresso na parte inferior do diálogo de migração indica o progresso da migração. Uma vez concluído o processo de migração, o diálogo de migração desaparece e a janela de Resultados da Migração é exibida.

Verificando a Migração do WebSphere InterChange Server

Se não forem relatados erros durante a migração do arquivo jar do WebSphere InterChange Server, isto indica que a migração dos artefatos foi bem-sucedida. Se a migração não tiver sido concluída com êxito, será exibida uma lista de mensagens de erros, avisos e/ou informativas. Estas mensagens podem ser utilizadas para verificar a migração do WebSphere InterChange Server.

Nota: Devido à complexidade de migração do WebSphere InterChange Server para o WebSphere Process Server, é altamente recomendável desempenhar um teste extensivo dos aplicativos resultantes em execução no WebSphere Process Server para assegurar que eles funcionem conforme o esperado, antes de colocá-los em produção.

A página a seguir aparece se tiverem sido geradas mensagens de migração durante o processo de migração:

Janela Resultados da Migração (Migration Results)

Na janela Resultados da Migração (Migration Results), é possível ver as mensagens de migração geradas durante o processo de migração. Selecionando uma mensagem da lista Mensagens (Message) superior, é possível localizar informações adicionais em relação a essa mensagem na janela Descrição de Mensagem (Message Description) inferior.

Para guardar todas as mensagens para futuras consultas, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização de tarefa e/ou clique no botão Salvar como... (Save as...) para salvar as mensagens em um arquivo de texto no sistema de arquivos. Para ver a lista A Fazer gerada, clique em Janela -> Mostrar Visualização -> Outra... -> Geral -> Tarefas e clique em OK. A visualização de Tarefas é aberta com a lista de A Fazer gerada a partir do processo de migração.

Trabalhando com Falhas de Migração do WebSphere InterChange Server

Se a migração do WebSphere InterChange Server falhar, existem duas maneiras para lidar com as falhas.

Nota: Você pode preferir a primeira opção por estar, inicialmente, mais familiarizado com o WebSphere InterChange Server. No entanto, à medida que se torna mais experiente com o WebSphere Process Server e seus novos artefatos, você pode optar por reparar os artefatos migrados no WebSphere Integration Developer.
  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.

O Assistente de Migração permite converter definições FDL de processos de negócios exportados do componente build time do WebSphere MQ Workflow em artefatos correspondentes no WebSphere Integration Developer. Os artefatos gerados incluem definições de esquema XML para objetos de negócios, definições WSDL, BPEL, definições de importação e de componente e definições TEL.

A ferramenta de conversão requer uma definição FDL semanticamente completa de um modelo de processo exportado do WebSphere MQ Workflow build time com a opção export deep. Esta opção assegura que todas as especificações de dados necessários, de programa e de subprocesso estejam incluídas. Além disso, certifique-se de que qualquer definição do UPES (User Defined Process Execution Server) referida no modelo de processo do WebSphere MQ Workflow também seja selecionada quando o FDL for exportado do WebSphere MQ Workflow build time.

Nota: O Assistente de Migração não cobre a migração de:

Para obter informações adicionais sobre migração utilizando a ferramenta de conversão FDL2BPEL, consulte o WebSphere MQ Workflow Support Site.

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.

O escopo e totalidade do mapeamento depende do grau de conformidade com as seguintes instruções 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.

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. Chame o assistente selecionando Arquivo (File) -> Importar (Import) -> Integração de Negócios (Business Integration) -> WebSphere MQ Workflow FDL File e clique em Avançar (Next):
    Importe seleção para WebSphere MQ Workflow FDL File
    OU você também pode abrir o assistente de Migração da página Bem-vindo (Welcome) clicando no ícone Retornando Usuários (Returning Users) Retornando usuários (Returning users) para abrir a página Retornando Usuários (Returning Users) (observe que você sempre pode retornar à pagina Bem-vindo (Welcome) clicando em Ajuda (Help) -> Bem-vindo (Welcome) ):
    página Retornando Usuários (Returning users)
    Clique em Migração (Migration) à esquerda da página Retornando Usuários (Returning Users) para abrir a página Migração (Migration). Na página Migração (Migration), selecione a opção Migrar um processo do WebSphere MQ Workflow (Migrate a WebSphere MQ Workflow process) Página Migração (Migration) com a opção Migrar um processo do WebSphere MQ Workflow (Migrate a WebSphere MQ Workflow process) selecionada.
  2. É aberto o Assistente de Migração (Migration). Digite o caminho absoluto e o nome do arquivo FDL no campo Seleção de Origem (Source selection) ou selecione um do sistema de arquivos clicando no botão Procurar (Browse) e navegando até o arquivo. Digite o nome do módulo no campo relevante (é necessário digitar um nome de módulo no campo Nome do Módulo (Module name) para poder prosseguir). Clique em Avançar (Next):
    Assistente de Migração do FDL
  3. É aberta a página Opções de Migração. Nesta página é possível aceitar os padrões de migração ou selecionar uma caixa de opções para alterar a opção. Selecionando a caixa de opções Tratar conflitos de nomes como erros (Treat name conflicts as errors), você pode evitar a inclusão automática de sufixos que pode resultar em erros de interoperabilidade. A caixa de opção Inicializar membros de dados predefinidos (Initialize predefined data members) inclui nós extra para o processo para inicializar os membros de dados predefinidos:
    Página Opções de Migração do WebSphere MQ Workflow (WebSphere MQ Workflow Migration Options)
  4. Clique em Concluir (Finish).

Uma barra de progresso na parte inferior do diálogo de migração indica o progresso da migração. Uma vez concluído o processo de migração, o diálogo de migração desaparece e a janela Resultados da Migração (Migration Results) é exibida:

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

Verificando a Migração do WebSphere MQ Workflow

Se a migração for concluída com uma lista de mensagens de erro, aviso e/ou informativas, elas serão exibidas na janela Resultados da Migração (Migration Results). Caso contrário, a janela do assistente será fechada se a migração foi concluída com êxito.

A página a seguir aparece se tiverem sido geradas mensagens de migração durante o processo de migração:

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 guardar todas as mensagens para futuras consultas, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização de tarefa e/ou clique no botão Salvar como... (Save as...) para salvar as mensagens em um arquivo de texto no sistema de arquivos. Para ver a lista A Fazer gerada, clique em Janela -> Mostrar Visualização -> Outra... -> Geral -> Tarefas e clique em OK. A visualização de Tarefas é aberta com a lista de A Fazer gerada a partir do processo de migração.

Limitações do Processo de Migração (do WebSphere MQ Workflow)

Existem algumas limitações envolvidas no processo de migração do WebSphere MQ Workflow.

Capítulo 5. Migrando Artefatos de Origem para o WebSphere Integration Developer do WebSphere Studio Application Developer Integration Edition

Os artefatos de origem podem ser migrados do WebSphere Studio Application Developer Integration Edition para o WebSphere Integration Developer. Migrar os artefatos de origem em um aplicativo inclui migrá-los para o novo modelo de programação do WebSphere Integration Developer para que a nova funcionalidade e recursos possam ser utilizados. O aplicativo pode então ser reimplementado e instalado no WebSphere Process Server.

Muitos recursos disponíveis no WebSphere Business Integration Server Foundation 5.1 foram movidos para o WebSphere Application Server 6.x base. Consulte este tópico para obter dicas de migração desses recursos: Dicas para migração de extensões de modelo de programação.

Para migrar totalmente um projeto de serviço do WebSphere Studio Application Developer Integration Edition existem três etapas fundamentais a serem concluídas:

  1. Preparação dos artefatos de origem para a migração. Pode ser necessário executar essas ações no WebSphere Studio Application Developer Integration Edition.
  2. Utilize o assistente de Migração ou o script de linha de comandos WSADIEServiceProjectMigration para migrar automaticamente os artefatos para o projeto do Business Integration Module.
  3. Utilize o WebSphere Integration Developer para completar manualmente a migração. Isso envolve corrigir qualquer código Java que não pôde ser migrado automaticamente e verificar a ligação dos artefatos migrados.

Nota: A migração do tempo de execução (caminho de upgrade) não será fornecida no WebSphere Process Server 6.x, portanto esse caminho de migração do artefato de origem será a única opção para migrar projetos de serviço do WebSphere Studio Integration Edition na 6.x.

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

Antes de iniciar a migração de artefatos de origem do WebSphere Studio Application Developer Integration Edition, é necessário rever os caminhos de migração suportados pelo WebSphere Integration Developer.

O assistente de Migração oferece a capacidade de migrar um projeto de serviço do WebSphere Studio Application Developer Integration Edition Versão 5.1 (ou superior) de cada vez. Ele não migrará um espaço de trabalho inteiro.

O assistente de Migração não migra binários de aplicativos - ele migra apenas artefatos de origem localizados em um projeto de serviço do WebSphere Studio Application Developer Integration Edition.

Preparando Artefatos de Origem para Migração

Antes de migrar artefatos de origem para o WebSphere Integration Developer do WebSphere Studio Application Developer Integration Edition, primeiro, certifique-se de que tenha preparado corretamente seu ambiente.

As etapas a seguir descrevem como preparar seu ambiente antes de migrar artefatos de origem para o WebSphere Integration Developer do WebSphere Studio Application Developer Integration Edition:

  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 migração do Centro de Informações do Rational Application Developer para determinar a melhor maneira de migrar os projetos não específicos do WBI em seu espaço de trabalho:Migrating from WebSphere Studio V5.1, 5.1.1, or 5.1.2
  3. 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
  4. Certifique-se de que todos os recursos adequados do WebSphere Integration Developer estejam ativados. Se esses recursos não estiverem ativados, você não poderá ver as opções de menu que serão discutidas abaixo. Para ativar os recursos importantes:
  5. Utilize um novo diretório de espaço de trabalho para o WebSphere Integration Developer. Não é recomendável abrir o WebSphere Integration Developer em um espaço de trabalho antigo do WebSphere Studio Application Developer Integration Edition que contenha projetos de serviço, pois esses projetos primeiro devem ser migrados para um formato que possa ser lido pelo WebSphere Integration Developer. As etapas recomendadas para isso são:
    1. Copie todos os projetos não de serviço do espaço de trabalho antigo para o novo. Não copie os projetos EJB, da Web e EAR 5.1 criados durante a geração do código de implementação para um projeto de serviço 5.1. O novo código de implementação da 6.x será gerado outra vez automaticamente quando o módulo BI for construído.
    2. Abra o WebSphere Integration Developer no espaço de trabalho vazio e importe todos os projetos que não sejam de serviço clicando em Arquivo -> Importar -> Geral -> Projeto Existente para o Espaço de Trabalho e selecione os projetos copiados para o novo espaço de trabalho.
      • Se o projeto for um projeto J2EE, então, você deverá migrá-lo para o nível 1.4 utilizando o assistente Rational Application Developer Migration:
        1. Clique com o botão direito do mouse no projeto e selecione Migração -> Assistente de Migração do J2EE....
        2. Reveja as instruções de aviso na primeira página e, a menos que seja indicado de outra maneira, clique em Avançar.
        3. Certifique-se de que o Projeto J2EE esteja marcado na lista Projetos. Deixe marcados Migrar estrutura do projeto e Migrar nível de especificação do J2EE. Escolha J2EE versão 1.4 e WebSphere Process Server v6.1 do Servidor de Destino.
        4. Selecione quaisquer outras opções que possam ser adequadas para seu projeto J2EE e clique em Concluir. Se essa etapa for concluída com êxito, você verá uma mensagem Migração concluída com êxito.
        5. Se houver erros no projeto J2EE após a migração, você deverá remover todas as entradas do caminho de classe que se referem aos arquivos .jar ou bibliotecas da v5 e incluir a Biblioteca do Sistema JRE e as bibliotecas de Destino do Servidor WPS no caminho de classe (discutido abaixo). Isso deverá remover a maioria dos erros ou todos.
      • Para projetos EJB do WebSphere Business Integration com Extended Messaging (CMM) ou CMP/A (Container Managed Persistence over Anything), os arquivos do descritor de Extensão Jar EJB da IBM devem ser migrados depois da importação do projeto da 5.1 para o espaço de trabalho da 6.x. Consulte "Migrando Projetos EJB do WebSphere Business Integration" para obter informações adicionais.
      • Corrija o caminho de classe para cada projeto não de serviço importado no espaço de trabalho. Para incluir as bibliotecas do JRE e do WebSphere Process Server no caminho de classe, clique com o botão direito do mouse no projeto importado e selecione Propriedades. Vá para a entrada Caminho de Construção Java e selecione a guia Bibliotecas. Então, faça o seguinte:
        1. Selecione Incluir biblioteca -> Biblioteca do Sistema JRE -> Alternar JRE - WPS Server v6.1 JRE -> Concluir.
        2. Em seguida, selecione Incluir Biblioteca -> Destino do Servidor WPS -> Configurar Caminho de Classe do Servidor wps -> Concluir.
  6. Por padrão, o WebSphere Integration Developer gera o código de implementação durante o tempo de construção.
  7. Para migrar totalmente os arquivos .bpel em um projeto de serviço, é necessário assegurar que todos os arquivos .wsdl e .xsd referidos pelos arquivos .bpel possam ser resolvidos em um projeto de integração de negócios no novo espaço de trabalho:

Agora você está pronto para iniciar o processo de migração.

Considerações para o Processo de Migração de Artefatos de Origem

Existem diversas considerações para o processo de migração de artefatos de origem do WebSphere Studio Application Developer Integration Edition.

As práticas a seguir mostram como projetar serviços do WebSphere Studio Application Developer Integration Edition para assegurar que eles sejam migrados com êxito para o novo modelo de programação:

Migrando Projetos de Serviço Utilizando o Assistente de Migração do WebSphere Integration Developer

O Assistente de Migração do WebSphere Integration Developer permite a migração de projetos de serviço.

Nota:

O Assistente de Migração faz o seguinte:

  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. Liga o componente BPEL aos seus links associados (importações, exportações e componentes Java)

Para migrar projetos de serviço utilizando o Assistente de Migração do WebSphere Integration Developer, siga estas etapas:

  1. Chame o assistente selecionando Arquivo (File) -> Importar (Import) -> Integração de Negócios (Business Integration) -> Projeto de Serviço do WebSphere Studio Application Developer Integration Edition (WebSphere Studio Application Developer Integration Edition Service Project) e clique em Avançar (Next):
    Importe seleção para migração de artefato de origem
    OU você também pode abrir o assistente para Migração da página Bem-vindo (Welcome) clicando no ícone Retornando Usuários (Returning users) Retornando usuários (Returning users) para abrir a página Retornando Usuários (Returning users) (Observe que você sempre pode retornar á página Bem-vindo (Welcome) clicando em Ajuda (Help) -> Bem-vindo (Welcome) ):
    página Retornando usuários (Returning users)
    Clique Migração (Migration) à esquerda da página Retornando usuários (Returning users) para abrir a página Migração (Migration). Na página Migração (Migration), selecione a opção Migrar um projeto de serviço do Integration Edition 5.1 (Migrate an Integration Edition 5.1 service projec) Página Migração (Migration) com a opção Migrar um projeto de serviço do Integration Edition 5.1 (Migrate an Integration Edition 5.1 service projec) selecionada.
  2. É aberto o Assistente de Migração (Migration). Digite o caminho para a Seleção de Origem (Source Selection) ou clique no botão Procurar (Browse) para localizá-lo. Digite também o nome do Módulo (Module name) do local do Projeto de Serviço do WebSphere Studio Application Developer Integration Edition que irá migrar:
    Assistente de Migração (Migration) de Artefatos de Origem
    Nota: É recomendado que você escolha o nome do Projeto de Serviço como o nome do módulo, porque se houver outros projetos no espaço de trabalho do WebSphere Studio Application Developer Integration Edition que são dependentes desse projeto, você não terá de atualizar os caminhos de classe dos projetos dependentes depois de importá-los para o WebSphere Integration Developer.
  3. Nas Opções de Migração, selecione a caixa de opção Preservar snippets Java do BPEL originais nos comentários (Preserve original BPEL Java snippets in the comments):
    Opções de migração
    Clique em Concluir (Finish).
  4. Depois do processo de migração ser concluído, a janela Resultados da Migração (Migration Results) é aberta:
    Janela Resultados da Migração (Migration Results)
    Um arquivo de log contendo essas mensagens de migração será automaticamente gerado para a pasta .metadata do espaço de trabalho da 6.x. O arquivo de log deve ser nomeado ".log".

Após a conclusão do Assistente de Migração, construa o módulo de Business Integration criado e tente resolver erros de construção. Inspecione todos os arquivos .bpel migrados: certifique-se de que eles tenham sido totalmente migrados e possam ser abertos no Editor BPEL do WebSphere Integration Developer. Existem alguns snippets Java de BPEL que não podem ser automaticamente migrados. Se você vir erros nos snippets Java do BPEL, consulte "Migrando para o Modelo de Programação SCA" para obter as etapas necessárias para corrigir os erros. Além disso, se você tiver utilizado o Assistente de Migração para migrar um projeto de serviço para um Módulo de BI, abra o editor de dependências de módulo para assegurar que as dependências estejam configuradas corretamente. Para isso, vá para a perspectiva Business Integration e dê um clique duplo no projeto do módulo da integração de negócios. Lá você pode incluir dependências em projetos de biblioteca de integração de negócios, em projetos Java e em projetos J2EE.

Migrando Projetos de Serviço Utilizando WSADIEServiceProjectMigration

O comando WSADIEServiceProjectMigration permite a migração de projetos de serviço.

O comando de migração faz o seguinte:

Nota: É necessário migrar os projetos de serviço na ordem de dependência. Por exemplo, se um BPEL no projeto de serviço A efetuar uma chamada processo a processo para um BPEL no projeto de serviço B, então o projeto de serviço B deve ser migrado antes do projeto de serviço A. Caso contrário, a chamada processo a processo não poderá ser configurada corretamente.

Para executar o script WSADIEServiceProjectMigration, siga estas etapas:

  1. Localize o scipt abrindo a pasta compartilhada especificada durante a instalação do WebSphere Integration Developer. Por exemplo, o script será localizado abaixo do: SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0
  2. Chame o script como a seguir: WSADIEServiceProjectMigration -e eclipse_dir -s source_project_dir -d workspace [-t target_project_name] [-preserveSnippets true|false] [-debug]

    Definições de Parâmetro:

    -e eclipse_dir
    O local de sua pasta Eclipse (Tempo de execução de Eclipse).
    -s source_project_dir
    O caminho completo para o projeto de serviço do WebSphere Studio Application Developer Integration Edition 5.1.
    -d workspace
    O espaço de trabalho onde o novo módulo de integração de negócios será criado.
    -t target_project_name
    O nome do novo módulo de integração de negócios a ser criado. O padrão é o mesmo para o projeto do WebSphere Studio Application Developer Integration Edition 5.1 que está sendo migrado.
    -preserveSnippets flag
    Ativa ou desativa a preservação de snippets existentes de Java do BPEL conforme assinalado como comentário. O padrão é true.
    -debug flag
    Ativa a saída de depuração.

    Por exemplo:

    WSADIEServiceProjectMigration -e WID_HOME\eclipse" -d "\myWIDworkspace" -s "\\MyServiceProject" -t "MyBIModuleName" -preserveSnippets false -debug
  3. Após a conclusão do comando, inicie o novo espaço de trabalho no WebSphere Integration Developer.
  4. Construa o módulo de Business Integration criado e tente resolver quaisquer erros de construção. Inspecione todos os arquivos .bpel migrados: certifique-se de que eles tenham sido totalmente migrados e possam ser abertos no Editor BPEL do WebSphere Integration Developer. Existem alguns snippets Java de BPEL que não podem ser automaticamente migrados. Se você vir erros nos snippets Java do BPEL, consulte "Migrando para o Modelo de Programação SCA para obter as etapas necessárias para corrigir os erros.
  5. Abra o editor de dependências de módulo para assegurar que as dependências estejam configuradas corretamente. Para isso, vá para a perspectiva de integração de negócios e dê um clique duplo no projeto do módulo de integração de negócios. Lá você pode incluir dependências em projetos de biblioteca de integração de negócios, em projetos Java e em projetos J2EE.

Completando a Migração de Aplicativo

Quando o Assistente de Migração tiver migrado com êxito os artefatos para o novo módulo de Business Integration, os artefatos deverão ser ligados para criar um aplicativo que esteja de acordo com o modelo SCA. Observe que embora o Assistente de Migração tente migrar os artefatos com êxito, também deve ser feita a verificação manual. As informações desta seção podem ser utilizada para ajudar a assegurar que a migração tenha sido correta.

  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 do módulo é 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 processos BPEL no projeto de serviço do WebSphere Studio Application Developer Integration Edition, o assistente de migração deve ter criado componentes SCA padrão para cada um desses processos e eles estarão no Editor de Montagem.
  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 mais detalhadamente como religar manualmente o aplicativo utilizando as ferramentas disponíveis no WebSphere Integration Developer:

Criando Componentes do SCA e Importações do SCA para os Serviços no Aplicativo de Religação

Todos os processos de negócios migrados devem ser ligados para seus parceiros de negócios. Um Componente ou Importação do SCA deve ser criado para todos os outros tipos de serviço. Para os projetos de serviço do WebSphere Studio Application Developer Integration Edition que interagem com os sistemas ou entidades externos ao projeto, uma Importação do SCA pode ser criada para que o projeto migrado acesse essas entidades como serviços de acordo com o modelo SCA.

Nota: O utilitário de migração tenta fazer isso automaticamente; entretanto, você pode consultar as informações a seguir para ajudar a verificar o que a ferramenta fez.

Para os projetos de serviço do WebSphere Studio Application Developer Integration Edition que interajem com as entidades dentro projeto (por exemplo, um processo de negócios, um serviço de transformador ou uma classe Java), uma Importação do SCA pode ser criada para que o projeto migrado acesse essas entidades como serviços de acordo com o modelo SCA.

As seções a seguir fornecem detalhes sobre a Importação do SCA ou Componentes do SCA a serem criados com base no tipo de serviço que deve ser migrado:

Migrando um Serviço Java

Você pode migrar um serviço Java para um Componente Java do SCA.

Se o Projeto de Serviço do WebSphere Studio Application Developer Integration Edition era dependente de outros projetos Java, copie os projetos existentes para o novo diretório de espaço de trabalho e importe-os para o WebSphere Integration Developer utilizando o assistente Arquivo -> Importar -> Geral -> Projeto Existente para o Espaço de Trabalho.

No WebSphere Studio Application Developer Integration Edition, ao gerar um novo serviço Java a partir de uma classe Java existente, as seguintes opções eram fornecidas:

Existem muitos componentes novos que oferecem nova funcionalidade, como mapeamento de dados, mediação de interface, máquinas de estado de negócios, seletores, regras de negócios e muito mais. Primeiro, você deve determinar se um desses novos tipos de componentes pode substituir o componente Java customizado. Se isso não for possível, siga o caminho de migração descrito abaixo.

Importe o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo de integração de negócios com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition.

Na perspectiva Business Integration, expanda o módulo para ver seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).

Você tem as seguintes opções:

Criando o Componente Java Customizado: Opção 1

A técnica de migração recomendada é utilizar o tipo Componente Java do WebSphere Integration Developer que permite representar o serviço Java como um componente SCA. Durante a migração, o código Java customizado deve ser escrito para conversão entre o estilo de interface Java do SCA e o estilo de interface do componente Java existente.

Para criar o componente Java customizado, siga estas etapas:

  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 esqueleto do serviço Java que adere à interface WSDL de acordo com o modelo de programação SCA, no qual os tipos complexos são representados por um objeto que é um commonj.sdo.DataObject e os tipos simples são representados por equivalentes de seus Objetos Java.

Os seguintes exemplos de código mostram:

  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

Uma opção alternativa a considerar é a ferramenta de serviços da Web do Rational Application Developer que permite criar um serviço da Web em torno de uma classe Java.

Nota: 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 desse 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 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ê poderá 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 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 incluindo mapeamentos para todos os pacotes Java utilizados pela interface do Java bean.
  12. Clique em Avançar. Observe que você poderá 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 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 esqueleto 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 esqueleto Java e selecione Serviços da Web -> Gerar esqueleto de Java bean.
  3. Escolha o tipo de serviço da Web Serviço da Web Java bean de Esqueleto e complete o assistente.

Depois de concluir o assistente, você deve ter classes Java que implementem a interface de serviço e não sejam dependentes de APIs do WSIF.

Prós e Contras para Cada uma das Opções de Religação do Serviço Java

Existem prós e contras para cada uma das opções de religação do serviço Java.

A seguinte lista descreve as duas opções e os prós e contras de cada uma:

Migrando um Serviço EJB

Você pode migrar um serviço EJB para uma Importação do SCA com ligação de bean de sessão sem preservação de estado.

Se o Projeto de Serviço do WebSphere Studio Application Developer Integration Edition era dependente de outro EJB, cliente EJB ou projeto Java, importe esses projetos existentes utilizando o assistente Arquivo -> Importar -> Geral -> Projeto Existente para o Espaço de Trabalho. Geralmente, este era o caso quando um EJB era referido a partir de um projeto de serviço. Se algum dos arquivos WSDL ou XSD referidos a partir do projeto de serviço existir em outro tipo de projeto, crie uma nova Biblioteca de Business Integration com o mesmo nome que o projeto de não-serviço antigo e copie todos os artefatos para a biblioteca.

Importe o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo de integração de negócios com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition.

Na perspectiva Business Integration, expanda o módulo para ver seu conteúdo. Abra o Editor de Montagem dando um clique duplo no primeiro item no projeto do módulo (ele terá o mesmo nome que o projeto).

Você tem as seguintes opções:

Criando o Componente EJB Customizado: Opção 1

A técnica de migração recomendada é utilizar o tipo Importar com Ligação de Sessão sem Preservação de Estado do WebSphere Integration Developer que permite chamar um EJB de sessão sem preservação de estado como um componente SCA. Durante a migração, o código Java customizado deve ser escrito para conversão entre o estilo de interface Java do SCA e o estilo de interface EJB existente.

Nota: Embora a ferramenta de migração manipule isto automaticamente, quaisquer alterações feitas depois da migração para as interfaces e tipos de dados (objetos de negócios) envolvidos na interface EJB irão requerer atualizações manuais para o código de conversão mencionado aqui. Os erros podem ser exibidos no WebSphere Integration Developer conforme o tipo de alteração efetuada.

Para criar o componente EJB customizado, siga estas etapas:

  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", porque ele será um componente Java que faz mediação entre a interface WSDL gerada para o EJB no WebSphere Studio Application Developer Integration e a interface Java do EJB.
  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 esqueleto do serviço Java que adere à interface WSDL de acordo com o modelo de programação SCA, no qual os tipos complexos são representados por um objeto que é um commonj.sdo.DataObject e os tipos simples são representados por equivalentes de seus Objetos Java.

Os seguintes exemplos de código mostram:

  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ê pode atualizar o nome da referência se o nome gerado não for muito descritivo ou adequado. Lembre-se do nome dessa referência para uso futuro.
  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.

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 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ê poderá 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 desejado (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 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ê poderá 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çãode negócios, se o projeto de serviço for um consumidor do serviço EJB. Ele pode ser localizado no projeto da Web do roteador gerado na pasta WebContent/WEB-INF/wsdl. Atualize/reconstrua o projeto de módulo de integração de negócios.
  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 esqueleto 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 esqueleto EJB 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 esqueleto EJB e selecione Serviços da Web -> Gerar esqueleto de Java bean.
  3. Escolha o tipo de serviço da Web Serviço da Web EJB de Esqueleto e complete o assistente.

Depois de concluir o assistente, você deve ter um EJB que implemente a interface de serviço e não seja dependente de APIs do WSIF.

Observe que a interface poderá ser ligeiramente diferente da interface 5.1 e você poderá precisar inserir um componente Mediação de Interface entre o consumidor da 5.1 e a nova Importação. Para fazer isso, clique na ferramenta wire no Editor de Montagem e ligue o componente de origem SCA a essa nova Importação com Ligação de Serviço da Web. Como as interfaces são diferentes, você será avisado: Os nós de origem e destino não têm interfaces correspondentes. Escolha criar um mapeamento de interface entre o nó de origem e de destino. Dê um clique duplo no componente de mapeamento que foi criado no Editor de Montagem. Isso abrirá o editor de mapeamento. Consulte o Centro de Informações para obter instruções sobre a criação de um mapeamento de interface.

Depois de concluir isso, você deverá religar o serviço EJB. Não deve haver nenhuma referência, portanto, você precisa apenas religar a interface do componente Java:

Prós e Contras para Cada uma das Opções de Religação do Serviço EJB

Existem prós e contras para cada uma das opções de religação do serviço EJB.

A seguinte lista descreve as duas opções e os prós e contras de cada uma:

Migrando um Processo de Negócios para a Chamada do Serviço de Processo de Negócios

Este cenário aplica-se a um processo de negócios que chama outro processo de negócios, no qual o segundo processo de negócios é chamado utilizando uma Ligação do Processo WSIF. Esta seção mostra como migrar um BPEL para uma chamada de serviço BPEL utilizando uma ligação ou uma Importação/Exportação com Ligação SCA.

Para migrar um projeto de serviço de ligação de processo (BPEL) para um serviço de saída, siga estas etapas:

  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)

Você pode migrar um Serviço da Web (SOAP/JMS) para uma Importação do SCA com Ligação de Serviço da Web.

Para migrar um projeto de serviço SOAP/JMS para uma migração de serviço de saída, siga estas etapas:

  1. Primeiro, você precisará importar o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition. Observe que, se o IBM Web Service (SOAP/JMS) que este aplicativo chamará também for um serviço da Web do WebSphere Studio Application Developer Integration Edition que será migrado, pode ter havido atualizações desse serviço da Web durante a migração. Se este for o caso, será necessário utilizar os arquivos WSDL migrados desse serviço da Web aqui.
  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)

Você pode migrar um Serviço da Web (SOAP/HTTP) para uma Importação do SCA com Ligação de Serviço da Web.

Para migrar um projeto de serviço SOAP/HTTP para uma migração de serviço de saída, siga estas etapas:

  1. Primeiro, você precisará importar o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition. Observe que, se o IBM Web Service (SOAP/HTTP) que este aplicativo chamará também for um serviço da Web do WebSphere Studio Application Developer Integration Edition que será migrado, pode ter havido atualizações desse serviço da Web durante a migração. Se este for o caso, será necessário utilizar os arquivos WSDL migrados desse serviço da Web aqui.
  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/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

Você pode migrar um serviço JMS para uma Importação do SCA com Ligação JMS.

Nota: Se a mensagem JMS estiver sendo enviada para um WebSphere Business Integration Adapter, consulte a seção "Migrando Interações com o WebSphere Business Integration Adapter" no link abaixo.

Para migrar um projeto de serviço JMS para uma migração de serviço de saída, siga estas etapas:

  1. Primeiro, você precisará importar o projeto de serviço utilizando o assistente de Migração. Isto resultará na criação de um módulo do Business Integration com Mensagens, PortTypes, Ligações e Serviços do WSDL gerados no WebSphere Studio Application Developer Integration Edition.
  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 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 (geralmente, eles são denominados *JMSBinding.wsdl e *JMSService.wsdl). Examine as informações de ligação e de serviço capturadas lá. A partir da ligação, você pode determinar se as mensagens de texto ou de objeto foram utilizadas e se as ligações de formato de dados customizadas foram utilizadas. Se houver alguma, também será necessário considerar a gravação de uma ligação de dados customizada para "Importação com Ligação JMS" de 6.x. A partir do serviço, é possível localizar o depósito de informações do provedor de contexto inicial, o nome da connection factory JNDI, o nome do destino JNDI e o estilo do destino (fila).
  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

Você pode migrar um serviço J2C-CICS para uma Importação do SCA com Ligação EIS ou Importação do SCA com Ligação de Serviço da Web.

Não utilize nenhum dos artefatos do WebSphere Studio Application Developer Integration Edition gerados para esse serviço IMS. Você precisará recriar o serviço utilizando os assistentes disponíveis no WebSphere Integration Developer e religar manualmente o aplicativo.

Nota: Ative a Auto-construção ou construa o módulo manualmente.

Você tem as seguintes opções:

Nota: Para ambas as opções, observe que se um serviço BPEL chamar esse serviço IMS, o BPEL precisará ser alterado ligeiramente, porque a interface exposta pelo serviço EIS será ligeiramente diferente da antiga interface 5.1. Para fazer isso, abra o editor BPEL e ajuste o link de parceiro correspondente ao serviço EIS e utilize a nova interface (arquivo WSDL) gerada ao executar as etapas acima. Faça todas as alterações necessárias nas atividades do BPEL para a nova interface WSDL do serviço EIS.

Criando uma Importação do SCA para Chamar o Serviço IMS: Opção 1

Você pode criar uma Importação do SCA com Ligação EIS que utilizará DataObjects para armazenar a mensagem/dados para se comunicar com o sistema IMS.

Para criar uma Importação do SCA para chamar o serviço IMS, siga estas etapas:

  1. Crie um novo projeto de módulo de integração de negócios para hospedar esse novo serviço IMS.
  2. Para recriar o serviço EIS, vá para Arquivo -> Novo -> Outro -> Business Integration -> External Service.
  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 no canvas, essa Importação tem uma Ligação EIS e representa o serviço que você acabou de criar.

Agora consulte a seção intitulada "Criando Exportações do SCA para Acessar o Serviço Migrado" para obter instruções sobre como expor esse serviço para os consumidores.

Criando um Serviço da Web em torno do Serviço J2C: Opção 2

Você pode criar um serviço da Web J2C e se o consumidor do serviço for um componente do SCA, consuma o serviço como um IBM Web Service (SOAP/HTTP ou SOAP/JMS).

Para criar um serviço da Web em torno do serviço J2C, siga estas etapas:

  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. Marque Conexão Gerenciada e digite o nome de consulta do 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.

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.

Consulte o tópico "O Cenário de Consumo para Migração de Serviço" para obter instruções sobre como migrar este tipo de serviço para o WebSphere Integration Developer.

Migrando um Serviço J2C-HOD

Não há suporte direto para o serviço J2C-HOD no WebSphere Integration Developer. Para acessar este serviço a partir de um módulo SCA, será necessário fazer a migração utilizando o cenário de consumo.

Consulte o tópico "O Cenário de Consumo para Migração de Serviço" para obter instruções sobre como migrar este tipo de serviço para o WebSphere Integration Developer.

Migrando um Serviço do Transformador

Você pode migrar um serviço de transformador para um Mapa de Dados e Mapa de Interface do SCA, quando possível. Você também pode utilizar o cenário de consumo para acessar este serviço a partir de um módulo SCA.

Os componentes do mapa de dados e do mapa de interface são novos na versão 6.0. Eles oferecem função similar para o serviço de transformador da 5.1, mas não têm a capacidade total de transformação do XSL. Se você não puder substituir seu serviço de transformador por um desses componentes, então, deverá migrar utilizando o cenário de consumo, pois não há suporte direto para o serviço de transformador no WebSphere Integration Developer. Siga as etapas documentadas na seção "O Cenário de Consumo para Migração de Serviço" para acessar este serviço a partir de um módulo SCA.

O Cenário de Consumo para Migração de Serviço

Nos casos em que não há nenhuma contraparte direta para um tipo de serviço do WebSphere Studio Application Developer Integration Edition, um cenário de consumo é necessário para consumir o serviço antigo do WebSphere Studio Application Developer Integration Edition como está ao reprojetar o aplicativo no WebSphere Integration Developer.

A seguir há algumas etapas para executar no WebSphere Studio Application Developer Integration Edition antes de chamar o assistente de Migração:

  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, escolher Stub de Cliente, selecionar as operações desejadas que irá incluir no proxy e clicar em Concluir. Isto cria uma classe Java que expõe os mesmos métodos que o serviço do WebSphere Studio Application Developer Integration Edition, em que os argumentos dos métodos Java são as partes da mensagem WSDL de origem.

Agora você pode migrar para o WebSphere Integration Developer:

  1. Copie o projeto Java do proxy do cliente para o novo espaço de trabalho e importe-o indo para Arquivo -> Importar -> Projeto Existente para Espaço de Trabalho.
  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 de 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", porque ele será um componente Java que faz mediação entre a interface WSDL gerada para o serviço de transformador no WebSphere Studio Application Developer Integration Edition e a interface Java do proxy de cliente de transformador).
  8. Na guia Detalhes você verá que esse componente tem uma interface - aquela que você arrastou e soltou sobre o Editor de Montagem.
  9. De volta ao Editor de Montagem, clique com o botão direito do mouse no componente que acabou de criar e selecione Gerar Implementação... -> Java Em seguida, selecione o pacote no qual a implementação Java será gerada. Isso cria um esqueleto do serviço Java que adere à interface WSDL de acordo com o modelo de programação SCA, no qual os tipos complexos são representados por um objeto que é um commonj.sdo.DataObject e os tipos simples são representados por equivalentes de seus Objetos Java.

Agora, você precisará preencher o código no qual vê as tags "//TODO" na classe de implementação Java gerada. Existem duas opções:

  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 utilitário de migração tenta fazer isso automaticamente; entretanto, você pode consultar as informações a seguir para ajudar a verificar o que a ferramenta fez.

Se no WebSphere Studio Application Developer Integration Edition, você clicava com o botão direito do mouse no processo BPEL ou em outro WSDL de Serviço e selecionava Serviços Corporativos -> Gerar Código de Implementação, será necessário desempenhar as etapas de migração manuais abaixo. Observe que o WebSphere Integration Developer é diferente do WebSphere Studio Application Developer Integration Edition porque ele armazena todas as opções de implementação. Quando o projeto for construído, o código de implementação será atualizado automaticamente nos projetos EJB e da Web gerados, portanto, não existe mais nenhuma opção para Gerar Código de Implementação manualmente.

Foram especificadas cinco opções de ligação na seção Interfaces para Parceiros do assistente Gerar Código de Implementação de BPEL. As seguintes informações de migração de serviço do BPEL de entrada fornecem detalhes adicionais sobre o tipo e propriedades da Exportação a ser criada com base nos tipos de ligação de implementação que foram selecionados no WebSphere Studio Application Developer Integration Edition:

Migrando o EJB e as Ligações do Processo EJB

O EJB e as ligações do processo EJB podem ser migrados para a construção SCA recomendada.

No WebSphere Studio Application Developer Integration Edition, este tipo de ligação permite que clientes se comuniquem com um processo BPEL ou outro tipo de serviço chamando um EJB. Observe que este tipo de ligação não era opcional para microprocessos - ele era sempre selecionado como EJB gerado utilizado internamente por outros tipos de ligação.

O nome JNDI do EJB gerado era gerado automaticamente como uma combinação do nome, espaço de nomes de destino e time stamp valid-from do BPEL. Por exemplo, estes atributos podem ser localizados examinando as propriedades do processo BPEL no editor BPEL nas guias de conteúdo Descrição e Servidor:

Tabela 3. Espaço de Nomes Gerado
Nome do Processo MyService
Espaço de Nomes de Destino http://www.example.com/process87787141/
Válido a partir de 01 de Jan de 2003 02:03:04

O espaço de nomes gerado para este exemplo é com/example/www/process87787141/MyService20030101T020304.

No WebSphere Studio Application Developer Integration Edition, quando a ligação EJB era selecionada como o tipo de implementação, nenhuma opção era especificada.

Existem quatro opções para migrar a ligação do processo do WebSphere Studio Application Developer Integration Edition. O tipo de cliente(s) que acessa(m) o serviço determinará qual(is) opção(ções) de migração abaixo será(ão) desempenhada(s):

Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá ser migrado para o novo modelo de programação. Consulte o tópico apropriado para os seguintes tipos de clientes:

Tabela 4. Informações Adicionais para Migrar Clientes
Tipo de Cliente Para obter informações adicionais, consulte
Cliente EJB que chama o bean de sessão gerado. Tal cliente chamaria um método EJB correspondente à operação BPEL a ser chamada "Migrando o Cliente EJB"
Cliente WSIF que utiliza a ligação do processo EJB "Migrando o Cliente de Ligação de Processo EJB"
API EJB Genérica do Business Process Choreographer "Migrando o Cliente da API EJB Genérica do Business Process Choreographer"
API do Sistema de Mensagens Genérica do Business Process Choreographer "Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer"
Outro processo BPEL no mesmo módulo N/D: Ligar componentes BPEL utilizando o Editor de Montagem
Outro processo BPEL em um módulo diferente N/D: Criar uma Importação com Ligação SCA no módulo de referência e configurar sua ligação para apontar para a Exportação com Ligação SCA criada abaixo na Opção 1

Opção de Migração 1 para o EJB e a Ligação de Processo EJB

A primeira opção de migração para a ligação do processo EJB do WebSphere Studio Application Developer Integration Edition é tornar processos de negócios acessíveis para outro componente no mesmo módulo.

No Editor de Montagem, para ligar esse outro componente ao componente BPEL, siga estas etapas:

  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.

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

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 no canvas 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.

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.

No WebSphere Studio Application Developer Integration Edition, este tipo de ligação permite que os clientes se comuniquem com um processo BPEL ou outro tipo de serviço enviando uma mensagem para um MDB. Observe que este tipo de ligação não era opcional para processos de execução longa e ele era sempre selecionado. De fato, este tipo de ligação era o único tipo de ligação permitido para interfaces de pedido-resposta de processos de execução longa. Para outros tipos de serviço, um MDB será gerado e chamará o serviço adequado.

O nome JNDI utilizado pela ligação JMS era uma combinação do nome, do espaço de nomes de destino e de time stamp valid-from de BPEL.

No WebSphere Studio Application Developer Integration Edition, quando a ligação JMS era selecionada como o tipo de implementação para um processo BPEL, as seguintes opções eram especificadas:

Existem cinco opções para migrar a ligação do processo JMS do WebSphere Studio Application Developer Integration Edition. O tipo de cliente(s) que acessa(m) o serviço determinará qual(is) opção(ções) de migração abaixo será(ão) desempenhada(s):

Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá ser migrado para o novo modelo de programação. Consulte o tópico apropriado para os seguintes tipos de clientes:

Tabela 5. Informações Adicionais para Migrar Clientes
Tipo de Cliente Para obter informações adicionais, consulte
Cliente WSIF que utiliza a ligação de processo JMS "Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer e o Cliente de Ligação de Processo JMS"
API EJB Genérica do Business Process Choreographer "Migrando o Cliente da API EJB Genérica do Business Process Choreographer"
API do Sistema de Mensagens Genérica do Business Process Choreographer - Migrando Negócios "Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer"
Outro processo BPEL no mesmo módulo N/D: Ligar componentes BPEL utilizando o Editor de Montagem
Outro processo BPEL em um módulo diferente N/D: Criar uma Importação com Ligação SCA no módulo de referência e configurar sua ligação para apontar para a Exportação com Ligação SCA criada abaixo na Opção 1.

Opção de Migração 1 para o JMS e a Ligação de Processo JMS

A primeira opção de migração para a ligação do processo JMS do WebSphere Studio Application Developer Integration Edition é tornar processos de negócios acessíveis para outro componente no mesmo módulo.

No Editor de Montagem, para ligar esse outro componente ao componente BPEL, siga estas etapas:

  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.

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

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 no canvas 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.

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.

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 o arquivo WSDL denominado JMSBinding.wsdl e JMSService.wsdl no pacote apropriado, sob a pasta ejbModule/META-INF do projeto EJB gerado e inspecionando as informações de ligação e de serviço capturadas lá. A partir da ligação, você pode determinar se as mensagens de texto ou de objeto foram utilizadas e se as ligações de formato de dados customizadas foram utilizadas. Se houver alguma, também será necessário considerar a gravação de uma ligação de dados customizada para Exportação com Ligação JMS de 6.x. A partir do serviço, é possível localizar o depósito de informações do provedor de contexto inicial, o nome da connection factory JNDI, o nome do destino JNDI e o estilo do destino (fila).
  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 Exportação com Ligação JMS tiver sido criada, selecione a exportação no Editor de Montagem e, na visualização Propriedades, selecione a área de janela de conteúdo Descrição. O nome e a descrição da Exportação são listados e podem ser modificados se necessário.
  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.

No WebSphere Studio Application Developer Integration Edition, este tipo de ligação permitia que os clientes se comunicassem com um processo BPEL ou outro tipo de serviço, chamando um IBM Web Service, no qual o protocolo de comunicação era JMS e a mensagem seguia as regras de codificação SOAP.

A seguir está um exemplo das convenções utilizadas durante a geração de um IBM Web Service (SOAP/JMS) para um serviço BPEL 5.1. O nome JNDI do IBM Web Service gerado era uma combinação do nome, espaço de nomes de destino e time stamp valid-from do BPEL, bem como o nome da interface (tipo de porta WSDL para o qual o código de implementação foi gerado). Por exemplo, estes atributos podem ser localizados examinando as propriedades do processo BPEL no editor BPEL nas guias de conteúdo Descrição e Servidor:

Tabela 6. Espaço de Nomes Gerado
Nome do Processo MyService
Espaço de Nomes de Destino http://www.example.com/process87787141/
Válido a partir de 01 de Jan de 2003 02:03:04
Interface ProcessPortType

O espaço de nomes gerado para este exemplo é com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.

No WebSphere Studio Application Developer Integration Edition, quando a ligação do IBM Web Service (SOAP/JMS) foi selecionada como o tipo de implementação para um processo BPEL ou outro tipo de serviço, foram especificadas as seguintes opções:

Um arquivo WSDL que especifica a ligação e o serviço SOAP/JMS do IBM Web Service é criado no projeto EJB gerado, mas não no próprio projeto de serviço. Isto significa que você deve localizar manualmente esse arquivo e copiá-lo para seu projeto de módulo de integração de negócios, se for importante que o código de cliente IBM Web Service não seja alterado. Por padrão, este arquivo WSDL foi criado no projeto EJB em ejbModule/META-INF/wsdl/<nome do processo de negócios>_ <nome do tipo de porta da interface do processo de negócios>_JMS.wsdl

O PortType e Mensagens WSDL da interface do processo de negócios são realmente copiados também para este arquivo WSDL, em vez de referir-se ao PortType e Mensagens WSDL existentes no projeto de serviço.

Se for importante que o código de cliente IBM Web Service permaneça inalterado após a migração, as informações neste arquivo serão requeridas para as etapas de migração manuais abaixo.

Existem duas opções para migrar a ligação do processo SOAP/JMS do WebSphere Studio Application Developer Integration Edition. A opção terá que ser feita, se migrar o cliente para o modelo de programação SCA ou se deixá-lo como um cliente de serviços da Web:

Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá ser migrado para o novo modelo de programação. Consulte o tópico apropriado para os seguintes tipos de clientes:

Tabela 7. Informações Adicionais para Migrar Clientes
Tipo de Cliente Para obter informações adicionais, consulte
Cliente IBM Web Service "Migrando o Cliente IBM Web service (SOAP/JMS)"

Opção de Migração 1 para a Ligação do IBM Web Service (SOAP/JMS)

A primeira opção de migração para a ligação SOAP/JMS do WebSphere Studio Application Developer Integration Edition é tornar o serviço acessível para um cliente de serviços da Web.

A Exportação com Ligação de Serviço da Web torna um componente SCA acessível por um cliente de serviços da Web externo. Para criar uma Exportação com Ligação de Serviço da Web, siga estas etapas:

  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 de janela de conteúdo Ligação e verá que uma Ligação e o Serviço de Ligação WSDL do IBM Web Service foram gerados diretamente na pasta do projeto do módulo. Ele será denominado componente que foi exportado Exportar Nome de PortType WSDL Jms_Service.wsdl. Se você inspecionar este arquivo, perceberá que a ligação agrupada de Document/Literal é utilizada por padrão, pois é o estilo preferido na 6.x. Este é o WSDL que os clientes IBM Web Service utilizarão para chamar o serviço.
  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 desejada:
    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 denegó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ê pode alterar a configuração do projeto da Web gerado para que corresponda ao endereço de serviço da 5.1 (você precisa fazer essas alterações toda vez que fizer alterações no módulo SCA, o que faz com que esse arquivo seja regenerado). Se você examinar a definição de Serviço do IBM Web Service WSDL que está sendo reutilizada da 5.1, verá o endereço de serviço para o qual o cliente 5.1 foi codificado:<wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
    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"), poderá abrir o descritor de implementação para o J2EE Enterprise Application no qual este projeto da Web está localizado e alterar a raiz de contexto desse módulo da Web para corresponder à raiz de contexto do endereço de serviço antigo. Você poderá ver o seguinte erro que pode ser ignorado: CHKJ3017E: Projeto da Web: <NOME DO PROJ DA WEB> está mapeado para uma raiz de Contexto inválida: <RAIZ DE CONTEXTO NOVO> no Projeto EAR: <NOME DO APLICATIVO>.
Opção de Migração 2 para a Ligação do IBM Web Service (SOAP/JMS)

A segunda opção para a ligação do processo SOAP/JMS do WebSphere Studio Application Developer Integration Edition é tornar processos de negócios acessíveis a uma entidade não-SCA (por exemplo, um cliente JSP ou Java).

A Referência Independente torna um componente SCA acessível por qualquer cliente externo. Para criar uma Referência Independente, siga estas etapas:

  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 no canvas 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.

No WebSphere Studio Application Developer Integration Edition, este tipo de ligação permitia que os clientes se comunicassem com um processo BPEL ou outro tipo de serviço, chamando um IBM Web Service, no qual o protocolo de comunicação era HTTP e a mensagem seguia as regras de codificação SOAP.

A seguir está um exemplo das convenções utilizadas durante a geração de um IBM Web Service (SOAP/HTTP) para um serviço BPEL 5.1. O nome JNDI do IBM Web Service gerado era uma combinação do nome, espaço de nomes de destino e time stamp valid-from do BPEL, bem como o nome da interface (tipo de porta WSDL para o qual o código de implementação foi gerado). Por exemplo, estes atributos podem ser localizados examinando as propriedades do processo BPEL no editor BPEL nas guias de conteúdo Descrição e Servidor:

Tabela 8. Espaço de Nomes Gerado
Nome do Processo MyService
Espaço de Nomes de Destino http://www.example.com/process87787141/
Válido a partir de 01 de Jan de 2003 02:03:04
Interface ProcessPortType

O espaço de nomes gerado para este exemplo é com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.

No WebSphere Studio Application Developer Integration Edition, quando a ligação do IBM Web Service (SOAP/HTTP) foi selecionada como o tipo de implementação para um processo BPEL ou outro tipo de serviço, foram especificadas as seguintes opções:

Um arquivo WSDL que especifica a ligação e o serviço SOAP/HTTP IBM Web Service é criado nos projetos da Web e EJB gerados, mas não no próprio projeto de serviço. Isto significa que você deve localizar manualmente esse arquivo e copiá-lo para seu projeto de módulo de integração de negócios, se for importante que o código de cliente IBM Web Service não seja alterado. Por padrão, este arquivo WSDL foi criado no projeto Web em WebContent/WEB-INF/wsdl/<nome do processo de negócios>_<nome do tipo de porta da interface do processo de negócios>_HTTP.wsdl

O PortType e Mensagens WSDL da interface do processo de negócios são realmente copiados também para este arquivo WSDL, em vez de referir-se ao PortType e Mensagens WSDL existentes no projeto de serviço.

Se for importante que o código de cliente IBM Web Service permaneça inalterado após a migração, as informações neste arquivo serão requeridas para as etapas de migração manuais abaixo.

Existem duas opções para migrar a ligação do processo SOAP/HTTP do WebSphere Studio Application Developer Integration Edition. A opção terá que ser feita, se migrar o cliente para o modelo de programação SCA ou se deixá-lo como um cliente de serviços da Web:

Nota: Após a conclusão das etapas de migração manuais, o cliente também deverá ser migrado para o novo modelo de programação. Consulte o tópico apropriado para os seguintes tipos de clientes:

Tabela 9. Informações Adicionais para Migrar Clientes
Tipo de Cliente Para obter informações adicionais, consulte
Cliente IBM Web Service "Migrando o Cliente IBM Web service (SOAP/HTTP)"

Opção de Migração 1 para a Ligação do IBM Web Service (SOAP/HTTP)

A primeira opção de migração para a ligação do processo SOAP/HTTP do WebSphere Studio Application Developer Integration Edition é tornar os processos de negócios acessíveis a um cliente de serviços da Web.

A Exportação com Ligação de Serviço da Web torna um componente SCA acessível por um cliente de serviços da Web externo. Para criar uma Exportação com Ligação de Serviço da Web, siga estas etapas:

  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 desejada:
    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çãode 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ê pode alterar a configuração do projeto da Web gerado para que corresponda ao endereço de serviço da 5.1 (você precisa fazer essas alterações toda vez que fizer alterações no módulo SCA, o que faz com que esse arquivo seja regenerado). Se você consultar a definição de serviço do IBM Web Service WSDL que está reutilizando do 5.1, verá o endereço de serviço para o qual o cliente 5.1 é codificado: <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
    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"), poderá abrir o descritor de implementação para o J2EE Enterprise Application no qual este projeto da Web está localizado e alterar a raiz de contexto desse módulo da Web para corresponder à raiz de contexto do endereço de serviço antigo. Você poderá ver o seguinte erro que pode ser ignorado: CHKJ3017E: Projeto da Web: <NOME DO PROJ DA WEB> está mapeado para uma raiz de Contexto inválida: <RAIZ DE CONTEXTO NOVO> no Projeto EAR: <NOME DO APLICATIVO>.
Opção de Migração 2 para a Ligação do IBM Web Service (SOAP/HTTP)

A segunda opção para a ligação do processo SOAP/HTTP do WebSphere Studio Application Developer Integration Edition é tornar processos de negócios acessíveis a uma entidade não-SCA (por exemplo, um cliente JSP ou Java).

A Referência Independente torna um componente SCA acessível por qualquer cliente externo. Para criar uma Referência Independente, siga estas etapas:

  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 no canvas 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.

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.

Para qualquer processo BPEL que contenha snippets Java, esta seção explica como migrar da API de snippet Java antiga para a nova API de snippet Java na qual os dados que fluem pelo aplicativo são armazenados nos SDOs (Service Data Objects) do Eclipse. Sempre que possível, os snippets são migrados automaticamente pelo assistente de migração, mas existem snippets que o assistente de migração não pode migrar totalmente, indicando que são requeridas etapas manuais para concluir a migração.

A seguir há um resumo das alterações no modelo de programação:

Modelo de Programação da V5.1
  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.

Tabela 10. Alterações e Soluções para Migrar Chamadas da API WSIFMessage para APIs do SDO
Alterar Solução
As classes do wrapper baseadas no WSIFMessage não são mais geradas para tipos de mensagens do WSDL, nem são as classes do assistente do Java bean geradas para os tipos de esquema complexos. Ao escrever código que interage com serviços do SCA, as APIs genéricas do SDO devem ser utilizadas para manipular as mensagens commonj.sdo.DataObject que mantêm os dados que fluem através do aplicativo.

As definições de mensagem que têm uma única parte digitada simples agora serão representadas por um tipo Java simples que representa diretamente a parte em vez de ter um wrapper em torno dos dados reais. Se a única parte da mensagem for um tipo complexo, então, os dados serão representados como um DataObject que adere à definição do tipo complexo.

As definições de mensagens do WSDL que têm várias partes agora correspondem a um DataObject que tem propriedades para todas as partes da mensagem, em que complexTypes são representados como propriedades "reference-type" do DataObject pai, acessíveis através dos métodos getDataObject e setDataObject.

Os métodos getter altamente especificados para partes WSIFMessage e os Java gerados não devem ser utilizados. A API SDO pouco especificada deve ser utilizada para obter as propriedades de DataObject.
Os métodos setter altamente especificados para partes de mensagem das variáveis BPEL não estão mais disponíveis. A API SDO pouco especificada deve ser utilizada para definir as propriedades de DataObject.
Os métodos getter pouco especificados para as propriedades de WSIFMessage não devem mais ser utilizados. A API SDO pouco especificada deve ser utilizada para definir as propriedades de DataObject.
Os métodos setter pouco especificados para as propriedades de WSIFMessage não devem mais ser utilizados. A API SDO pouco especificada deve ser utilizada para definir as propriedades de DataObject.
Todas as chamadas da API WSIFMessage devem ser migradas para a API SDO, onde possível. Migre a chamada para uma chamada de API SDO equivalente, onde possível. Se não for possível, projete novamente a lógica.

Migrando o Código de Cliente do WebSphere Business Integration Server Foundation

Esta seção mostra como migrar os vários tipos de clientes que eram possíveis para os tipos de serviço do WebSphere Business Integration Server Foundation 5.1.

Migrando o Cliente EJB

Este tópico mostra como migrar clientes que utilizam uma interface EJB para chamar um serviço.

  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 no canvas 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.

Clientes que utilizaram a Ligação do Processo EJB para chamar um processo de negócios devem agora utilizar a API SCA para chamar o serviço (o processo de negócios migrado deve ter uma Exportação com Ligação SCA) ou a API do IBM Web Service Client para chamar o serviço (o processo de negócios migrado deve ter uma Exportação com Ligação de Serviço da Web).

Consulte os tópicos "Migrando o Cliente EJB", "Migrando o Cliente IBM Web Service (SOAP/JMS)" ou "Migrando o Cliente IBM Web Service (SOAP/HTTP)" para obter informações adicionais sobre a geração de tais clientes.

Migrando o Cliente IBM Web Service (SOAP/JMS)

Este tópico mostra como migrar clientes que utilizam APIs do Web Service (SOAP/JMS) para chamar um serviço.

Nenhuma migração é necessária para clientes existentes durante a migração. Observe que você deve modificar manualmente o projeto da Web gerado (criar um novo mapeamento de servlet) e, às vezes, modificar a raiz de contexto do projeto da Web no descritor de implementação do aplicativo corporativo para publicar o serviço para o mesmo endereço exato que foi publicado no WebSphere Business Integration Server Foundation. Consulte o tópico "Migrando a Ligação IBM Web Service (SOAP/JMS)".

É importante observar que ao contrário da 5.1, na qual um proxy de cliente do WSIF ou RPC pode ser gerado, na 6.x as ferramentas suportam apenas a geração de cliente RPC, porque o RPC é a API preferida da 6.x em relação à API do WSIF.

Nota: Para gerar um novo proxy de cliente a partir do WebSphere Integration Developer, é necessário ter um WebSphere Process Server ou um WebSphere Application Server instalado.

  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 (Observe que esse assistente é muito similar ao assistente da 5.1).
  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.

Nenhuma migração é necessária para clientes existentes durante a migração. Observe que você deve modificar manualmente o projeto da Web gerado (criar um novo mapeamento de servlet) e, às vezes, modificar a raiz de contexto do projeto da Web no descritor de implementação do aplicativo corporativo para publicar o serviço para o mesmo endereço exato que foi publicado no WebSphere Business Integration Server Foundation. Consulte o tópico "Migrando a Ligação IBM Web Service (SOAP/HTTP)".

Se tiverem ocorrido alterações de design e você desejar gerar um novo proxy de cliente, as seguintes etapas mostrarão como fazer isso. É importante observar que ao contrário da 5.1, na qual um proxy de cliente do WSIF ou RPC pode ser gerado, na 6.x as ferramentas suportam apenas a geração de cliente RPC, porque o RPC é a API preferida da 6.x em relação à API do WSIF.

Nota: Para gerar um novo proxy de cliente a partir do WebSphere Integration Developer, é necessário ter um WebSphere Process Server ou um WebSphere Application Server instalado.

  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 (Observe que esse assistente é muito similar ao assistente da 5.1).
  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).

Consulte o tópico "Migrando o Cliente IBM Web Service (SOAP/HTTP)" para obter informações adicionais.

Na 5.1, se um proxy de cliente fosse automaticamente gerado, esse proxy utilizaria APIs do WSIF para interargir com o serviço. Na 6.x, as ferramentas suportam apenas a geração de cliente RPC porque o RPC é a API preferida da 6.x em relação à API do WSIF.

Nota: Para gerar um novo proxy de cliente a partir do WebSphere Integration Developer, é necessário ter um WebSphere Process Server ou um WebSphere Application Server instalado.

  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 (Observe que esse assistente é muito similar ao assistente da 5.1).
  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.

É necessário assegurar que a Exportação com Ligação JMS criada em uma etapa anterior possa aceitar esta mensagem de texto ou de objeto sem alterações. Pode ser necessário gravar uma ligação de dados customizada para fazer isso. Consulte a seção "Migrando o JMS e as Ligações de Processo JMS" para obter informações adicionais.

O cliente deve alterar a forma que a mensagem é construída. Anteriormente, as mensagens eram baseadas na classe WSIFMessage mas agora elas devem ser baseadas na classe commonj.sdo.DataObject. Consulte a seção "Migrando as Chamadas da API WSIFMessage para APIS do SDO" para obter detalhes adicionais como fazer essa migração manual.

Migrando o Cliente da API EJB Genérica do Business Process Choreographer

Este tópico mostra como migrar clientes que utilizam a API de EJB genérico do process choreographer 5.1 para chamar um serviço BPEL.

Existe uma nova versão da API de EJB Genérica que utiliza DataObjects como seu formato de mensagem. O cliente deve alterar a forma que a mensagem é construída. Anteriormente, as mensagens eram baseadas na classe WSIFMessage mas agora elas devem ser baseadas na classe commonj.sdo.DataObject. Observe que a API de EJB Genérica não foi alterada significativamente, pois o ClientObjectWrapper ainda fornece um wrapper de mensagem no formato de mensagem específico.

Ex: DataObject dobj = myClientObjectWrapper.getObject();
String result = dobj.getInt("resultInt");

O nome JNDI do EJB Genérico antigo que obtém o objeto WSIFMessage é:

GenericProcessChoreographerEJB
Nome JNDI: com/ibm/bpe/api/BusinessProcessHome
Interface: com.ibm.bpe.api.BusinessProcess

Existem dois EJBs genéricos na 6.0 porque as operações de tarefa manual agora estão disponíveis como um EJB separado. Os nomes JNDI da 6.0 desses EJBs Genéricos são:

GenericBusinessFlowManagerEJB
JNDI Name: com/ibm/bpe/api/BusinessFlowManagerHome
Interface: com.ibm.bpe.api.BusinessFlowManager

HumanTaskManagerEJB
JNDI Name: com/ibm/task/api/TaskManagerHome
Interface: com.ibm.task.api.TaskManager
Migrando o Cliente da API do Sistema de Mensagens Genérica do Business Process Choreographer e o Cliente de Ligação de Processo JMS

Não existe uma API do sistema de mensagens genérica no WebSphere Process Server. Consulte a seção "Migrando o JMS e Ligações de Processo JMS" para escolher uma maneira diferente de expor o processo de negócios para consumidores e regravar o cliente de acordo com a ligação escolhida.

Migrando o Cliente da Web do Business Process Choreographer

Este tópico mostra como migrar as configurações do cliente Web do Process Choreographer 5.1 e JSPs customizados.

O assistente de Migração preserva as configurações do cliente Web 5.1 e, no Human Task Editor, não é possível editar estas configurações. Você deve criar novas configurações do cliente Web e JSPs utilizando o WebSphere Integration Developer 6.x.

Migrando Modificações do Cliente Web
Na 5.1, você pode modificar a aparência e comportamento do cliente Web baseado em Struts modificando seu JSP Header.jsp e folha de estilo dwc.css.

Como o cliente Web 6.x (renomeado para Business Process Choreographer Explorer) é baseado em JSF (Java Server Faces) em vez de Struts, a migração automática de modificações do cliente Web não é possível. Portanto, recomenda-se que você consulte a documentação do "Business Process Choreographer Explorer" para obter detalhes sobre a customização da versão 6.x desse aplicativo.

JSPs definidos pelo usuário poderão ser definidos para processos de negócios e para atividades de equipe. O cliente Web utiliza essas JSPs para exibir mensagens de entrada e saída para o processo e as atividades.

Essas JSPs são particularmente úteis quando:

  1. 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 o canvas 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.

Consulte a seção "Migrando das Chamadas da API WSIFMessage para APIS do SDO" para obter as etapas de migração para executar ações específicas à transição do WSIFMessage para o SDO.

Sempre que possível, os snippets são migrados automaticamente pelo assistente de migração, mas existem snippets que o assistente de migração não pode migrar totalmente. Isto requer etapas manuais extras para concluir a migração. Consulte o tópico Limitações para obter detalhes sobre os tipos de snippets Java que devem ser migrados manualmente. Sempre que um desses snippets for encontrado, o assistente de Migração explicará por que ele não pode ser migrado automaticamente e emitirá uma mensagem de aviso ou de erro.

A seguinte tabela detalha as alterações no modelo de programação e na API do snippet Java do BPEL do Process Choreographer versão 5.1 para 6.x:

Tabela 11. Alterações e Soluções para Migrar Snippets Javado BPEL do WebSphere Business Integration Server Foundation
Alterar Solução
As classes do wrapper baseadas no WSIFMessage não são mais geradas para tipos de mensagens do WSDL, nem são as classes do assistente do Java bean geradas para os tipos de esquema complexos. As variáveis BPEL podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).

Como as variáveis BPEL podem ser utilizadas diretamente nos snippets 6.x, há menos necessidade de variáveis locais do que havia na 5.1.

Os getters altamente especificados para as variáveis BPEL inicializavam implicitamente o objeto do wrapper WSIFMessage em torno das partes da mensagem. Não há nenhum objeto 'wrapper' para as variáveis BPEL cuja definição de mensagem do WSDL tem apenas uma única parte: nesse caso, as variáveis BPEL representam diretamente a parte (No caso em que a única parte é um tipo simples XSD, a variável BPEL será representada como o tipo de wrapper do objeto Java, como java.lang.String, java.lang.Integer, etc). As variáveis BPEL com definições de mensagens do WSDL de várias partes são manipuladas de forma diferente: ainda há um wrapper em torno das partes e esse wrapper DataObject deve ser explicitamente inicializado no trecho de código Java 6.x se ainda não tiver sido definido por uma operação anterior.

Se qualquer variável local dos snippets da 5.1 tiver o mesmo nome da variável BPEL, poderão ocorrer conflitos; portanto, tente remediar essa situação, se possível.

Os objetos WSIFMessage não são mais utilizados para representar variáveis BPEL. Se qualquer classe Java customizada chamada a partir dos snippets Java tiver um parâmetro WSIFMessage, ela precisará ser migrada de forma que aceite/retorne um DataObject.
Os métodos getter altamente especificados para variáveis BPEL não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, agora representarão diretamente a parte em vez de ter um wrapper em torno dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Os métodos setter altamente especificados para variáveis BPEL não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Os métodos getter pouco especificados para variáveis BPEL que retornam um WSIFMessage não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).

Observe que há duas variações do método getVariableAsWSIFMessage:

getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName, boolean 
forUpdate)

Para uma atividade de snippet Java, o acesso padrão é de leitura/gravação. É possível alterá-lo para de leitura especificando @bpe.readOnlyVariables com a lista de nomes das variáveis em um comentário no snippet. Por exemplo, você pode configurar a variável B e a variável D como de leitura da seguinte forma:

variableB.setString("/x/y/z", variableA.getString("/a/b/c"));
// @bpe.readOnlyVariables names="variableA"
variableD.setInt("/x/y/z", variableC.getInt("/a/b/c"));
// @bpe.readOnlyVariables names="variableC"

Além disso, se você tiver um snippet Java em uma condição, as variáveis serão de leitura por padrão, mas será possível torná-las de leitura/gravação especificando @bpe.readWriteVariables...

Os métodos setter pouco especificados para variáveis BPEL não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Os métodos getter pouco especificados para partes de mensagem das variáveis BPEL não são adequados para mensagens de uma única parte e foram alterados para mensagens de várias partes. Migre para o método getter pouco especificado para as propriedades das variáveis BPEL (DataObject's).

Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, a variável BPEL representa diretamente a parte e deve ser acessada diretamente sem utilizar um método getter.

Há duas variações do método getVariablePartAsObject:

getVariablePartAsObject(String variableName, String
 partName)
getVariablePartAsObject(String variableName, String
 partName,boolean forUpdate)

Para mensagens de várias partes, a funcionalidade equivalente é fornecida para esse método na 6.x:

getVariableProperty(String variableName, QName
 propertyName);  		

Na 6.x, não há nenhuma noção da utilização de uma variável para acesso de leitura (que era o caso na 5.1 para o primeiro método acima, bem como o segundo método com forUpdate='false'). A variável é diretamente utilizada no snippet da 6.x e está sempre apta para ser atualizada.

Os métodos setter pouco especificados para partes de mensagem das variáveis BPEL não são adequados para mensagens de uma única parte e foram alterados para mensagens de várias partes. Migre para o método setter pouco especificado para as propriedades das variáveis BPEL (DataObject's).

Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, a variável BPEL representa diretamente a parte e deve ser acessada diretamente sem utilizar um método setter.

As chamadas para o seguinte método devem ser migradas:

setVariableObjectPart(String variableName,
 String partName, Object data)  

Para mensagens de várias partes, a funcionalidade equivalente é fornecida para esse método na 6.x:

setVariableProperty(String variableName, QName 
 propertyName, Serializable value);
Os métodos getter altamente especificados para links de parceiros BPEL não estão mais disponíveis. Migre para os métodos getter pouco especificados para links de parceiros BPEL.
Os métodos setter altamente especificados para links de parceiros BPEL não estão mais disponíveis. Migre para os métodos setter pouco especificados para links de parceiros BPEL.
Os métodos getter altamente especificados para conjuntos de correlações BPEL não estão mais disponíveis.
Snippet da V5.1:
String corrSetPropStr =
getCorrelationSetCorrSetAPropertyCustomerName();
int corrSetPropInt =
getCorrelationSetCorrSetBPropertyCustomerId();
Snippet da V6.x:
String corrSetPropStr = (String) getCorrelationSetProperty
("CorrSetA", new QName("CustomerName"));
int corrSetPropInt = ((Integer) getCorrelationSetProperty
("CorrSetB", new QName("CustomerId"))).intValue();
Parâmetros adicionais necessários para os métodos getter pouco especificados para propriedades customizadas da atividade BPEL.
Snippet da V5.1:
String val =
 getActivityCustomProperty("propName");
Snippet da V6.x:
String val = getActivityCustomProperty
("name-of-current-activity", "propName");
Parâmetros adicionais necessários para os métodos setter pouco especificados para propriedades customizadas da atividade BPEL.
Snippet da V5.1:
String newVal = "new value";
setActivityCustomProperty
("propName", newVal); 
Snippet da V6.x:
String newVal = "new value";
setActivityCustomProperty("name-of-current-activity",
"propName", newVal);
O método raiseFault(QName faultQName, Serializable message) não existe mais. Migre para o raiseFault(QName faultQName, String variableName) onde possível; caso contrário, migre para o método raiseFault(QName faultQName) ou crie uma nova variável BPEL para o objeto Serializable.

Migrando Interações com o WebSphere Business Integration Adapters

Se o JMS Client for um WebSphere Business Integration Adapter, poderá ser necessário utilizar as ferramentas External Service para criar a Importação com Ligação JMS. Esta Importação utiliza uma ligação de dados especial para serializar o SDO para o formato exato esperado pelo WebSphere Business Integration Adapter.

Para acessar a ferramenta External Service, siga estas etapas:

  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.

Esta ferramenta migrará os XSDs antigos para o formato esperado pela ligação de dados especial, portanto, remova os XSDs antigos do WebSphere Business Integration Adapter do módulo e utilize os novos XSDs. Se o módulo não for receber mensagens do adaptador, exclua as Exportações geradas por essa ferramenta. Se o módulo não enviar nenhuma mensagem para o adaptador, exclua a Importação. Consulte o centro de informações para obter informações adicionais sobre este recurso.

Migrando Interfaces WSDL com Tipos de Matrizes Codificadas pelo SOAP

Esta seção mostra como migrar ou manipular esquemas XML que têm tipos de matrizes codificadas pelo SOAP.

Os tipos de matrizes codificados pelo SOAP que possuem o estilo RPC serão tratados como seqüências não ligadas de um tipo concreto na 6.x. Não é recomendado que você crie nenhum tipo XSD que faça referência aos tipos soapend:Array de nenhuma maneira, porque o modelo de programação move-se em direção ao estilo Document/Literal agrupado em vez de ao estilo RPC (embora isso possa ser alterado).

Há casos em que um aplicativo SCA deve chamar um serviço externo que não utiliza o tipo soapend:Array. Em alguns casos, não existe uma maneira de evitar isto, portanto, a seguir é mostrado como lidar com esta situação:

Código WSDL de amostra:

		<xsd:complexType name="Vendor">
			<xsd:all>
				<xsd:element name="name" type="xsd:string" />
				<xsd:element name="phoneNumber" type="xsd:string" />
</xsd:all>
		</xsd:complexType>
	</xsd:schema>

		<xsd:complexType name="Vendors">
			<xsd:complexContent mixed="false">
				<xsd:restriction base="soapenc:Array">
					<xsd:attribute wsdl:arrayType="tns:Vendor[]" ref="soapenc:arrayType"
					xmlnxsd:wsdl="http://schemas.xmlsoap.org/wsdl/" />
		</xsd:restriction>
		</xsd:complexContent>

		<xsd:complexType name="VendorsForProduct">
			<xsd:all>
				<xsd:element name="productId" type="xsd:string" />
				<xsd:element name="vendorList" type="tns:Vendors" />
</xsd:all>
		</xsd:complexType>

		<xsd:complexType name="Product">
			<xsd:all>
				<xsd:element name="productId" type="xsd:string" />
				<xsd:element name="productName" type="xsd:string" />
</xsd:all>
		</xsd:complexType>

	<message name="doFindVendorResponse">
		<part name="returnVal" type="tns:VendorsForProduct" />
	</message>

	<operation name="doFindVendor">
		<input message="tns:doFindVendor" />
		<output message="tns:doFindVendorResponse" />
	</operation>

Código de amostra para um cliente deste Serviço da Web:

  // Localize o serviço do fornecedor e a operação doFindVendor

Service findVendor=(Service)ServiceManager.INSTANCE.locateService("vendorSearch");
            OperationType doFindVendorOperationType=findVendor.getReference().getOperationType("doGoogleSearch");
            
            // Crie o DataObject de entrada
            DataObject doFindVendor=DataFactory.INSTANCE.create(doFindVendorOperationType.getInputType());
            doFindVendor.setString("productId", "12345");
            doFindVendor.setString("productName", "Refrigerator");

            // Chame o serviço FindVendor
			DataObject FindVendorResult = (DataObject)findVendor.invoke(doFindVendorOperationType, doFindVendor);
            
            // Exiba os resultados
            int resultProductId=findVendorResult.getString("productId");
            
            DataObject resultElements=findVendorResult.getDataObject("vendorList");
            Sequence results=resultElements.getSequence(0);
            for (int i=0, n=results.size(); i
            for (int i=0, n=results.size(); i

Aqui há outro exemplo em que o tipo de raiz do objeto de dados é um soapenc:Array. Observe como o sampleElements DataObject é criado utilizando o segundo esquema listado acima. O tipo do DataObject é obtido primeiro e, em seguida, é obtida a propriedade para sampleStructElement. Isso é realmente uma propriedade do sinalizador de substituição e é utilizada apenas para obter uma propriedade válida a ser utilizada ao incluir o DataObjects na seqüência. Um padrão como esse pode ser utilizado em seu cenário:

Código WSDL de amostra:

<s:schema elementFormDefault="qualified" targetNamespace="http://soapinterop.org/xsd">
			<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
			<s:import namespace="http://schemas.xmlsoap.org/wsdl/" />
			<s:complexType name="SOAPStruct">
				<s:sequence>
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varInt" type="s:int" />
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varString" type="s:string" />
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varFloat" type="s:float" />
				</s:sequence>
			</s:complexType>

			<s:complexType name="ArrayOfSOAPStruct">
				<s:complexContent mixed="false">
					<s:restriction base="soapenc:Array">
						<s:attribute wsdl:arrayType="s0:SOAPStruct[]" ref="soapenc:arrayType" />
					</s:restriction>
				</s:complexContent>
			</s:complexType>
		</s:schema>

	<wsdl:message name="echoStructArraySoapIn">
		<wsdl:part name="inputStructArray" type="s0:ArrayOfSOAPStruct" />
	</wsdl:message>
	<wsdl:message name="echoStructArraySoapOut">
		<wsdl:part name="return" type="s0:ArrayOfSOAPStruct" />
	</wsdl:message>

		<wsdl:operation name="echoStructArray">
			<wsdl:input message="tns:echoStructArraySoapIn" />
			<wsdl:output message="tns:echoStructArraySoapOut" />
</wsdl:operation>

	<schema targetNamespace="http://sample/elements"
		xmlns="http://www.w3.org/2001/XMLSchema"
		xmlns:tns="http://sample/elements">

	<element name="sampleStringElement" type="string"/>
	
	<element name="sampleStructElement" type="any"/>

</schema>

Código de amostra para um cliente deste Serviço da Web:

// Crie o DataObject de entrada e obtenha a seqüência de SDO para qualquer
// elemento
DataFactory dataFactory=DataFactory.INSTANCE;
DataObject arrayOfStruct = dataFactory.create("http://soapinterop.org/xsd","ArrayOfSOAPStruct");
Sequence sequence=arrayOfStruct.getSequence("any");
            
// Obtenha a propriedade de SDO para o elemento de amostra que desejamos utilizar
// aqui para ocupar a seqüência
// Definimos este elemento em um arquivo XSD, consulte SampleElements.xsd
DataObject sampleElements=dataFactory.create("http://sample/elements",
"DocumentRoot");
Property property = sampleElements.getType().getProperty("sampleStructElement");
            
            // Inclua os elementos na seqüência
DataObject item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 1);
item.setString("varString", "Hello");
item.setFloat("varFloat", 1.0f);
sequence.add(property, item);
item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 2);
item.setString("varString", "World");
item.setFloat("varFloat", 2.0f);
sequence.add(property, item);

// Chame a operação echoStructArray
System.out.println("[client] invoking echoStructArray operation");
DataObject echoArrayOfStruct = (DataObject)interopTest.invoke("echoStructArray", arrayOfStruct);
            
// Exiba os resultados
if (echoArrayOfStruct!=null) {
    sequence=echoArrayOfStruct.getSequence("any");
    for (int i=0, n=sequence.size(); i<n; i++) {
      item=(DataObject)sequence.getValue(i);
      System.out.println("[client] item varInt = "+
          item.getInt("varInt")+"
          varString="+item.getString("varString")+"
          varFloat="+item.getFloat("varFloat"));

Migrando Projetos EJB do WebSphere Business Integration

No WebSphere Studio Application Developer Integration Edition, os projetos EJB podem ter recursos especiais do WebSphere Business Integration como o Extended Messaging (CMM) e CMP/A (Component-managed Persistence Anywhere). Os descritores de implementação para tais projetos devem ser migrados e esta seção mostra como executar essa migração.

Para desempenhar essa migração, siga estas etapas:

  1. Copie o projeto EJB do WebSphere Business Integration EJB para o novo espaço de trabalho e importe-o a partir do WebSphere Integration Developer utilizando o assistente Arquivo -> Importar -> Projeto Existente para Espaço de Trabalho. Opcionalmente, você também pode executar o assistente de Migração do J2EE.
  2. Feche todas as instâncias do WebSphere Integration Developer em execução no espaço de trabalho da 6.x.
  3. Execute o seguinte script que migrará os descritores de implementação do WebSphere Business Integration no projeto EJB:
    No Windows:
    SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.bat
    No Linux:
    SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.sh
    Os seguintes parâmetros são suportados, em que o nome do espaço de trabalho e do projeto são obrigatórios:
    Uso:      WSADIEEJBProjectMigration.bat
                [-e eclipse-folder] -d workspace -p project
    
    eclipse-folder: O local da pasta do eclipse -- normalmente é 'eclipse'
                    localizado na pasta de instalação do produto.
    
    workspace:  O espaço de trabalho que contém o projeto EJB do WSADIE a ser migrado.
    
    project:    O nome do projeto a ser migrado.
    Por exemplo:
     WSADIEEJBProjectMigration.bat -e "C:\IBM\WID6\eclipse" -d "d:\my60workspace" -p "MyWBIEJBProject"
  4. Ao abrir o WebSphere Integration Developer, você precisará atualizar o projeto EJB para obter os arquivos atualizados.
  5. Procure o arquivo ibm-web-ext.xmi no projeto EJB. Se um for localizado, certifique-se de que a seguinte linha esteja presente no arquivo sob o elemento:
    <webappext:WebAppExtension> element:
    <webApp href="WEB-INF/web.xml#WebApp"/>
  6. Remova o código de implementação antigo que foi gerado na 5.1. Gere novamente o código de implementação seguindo as diretrizes do WebSphere Application Server.

Excluindo Manualmente Definições do WSIF (Web Services Invocation Framework) 5.1

Depois de concluir a migração de seus artefatos de origem, é necessário excluir todas as definições WSDL de Ligação e Serviço do WSIF 5.1 de seus projetos de 6.x que não estão sendo mais utilizados. O cenário de consumo para migração de serviço é o único caso em que uma Ligação ou Serviço do WSIF ainda estaria sendo utilizado.

Os espaços de nomes WSDL a seguir indicam que uma definição de ligação ou de serviço é um Serviço do WSIF 5.1 e pode ser descartado se não for mais utilizado:

Espaço de Nomes de WSIF EJB:
http://schemas.xmlsoap.org/wsdl/ejb/
Espaço de Nomes de WSIF Java:
http://schemas.xmlsoap.org/wsdl/java/
Espaço de Nomes de WSIF JMS:
http://schemas.xmlsoap.org/soap/jms/
Espaço de Nomes de WSIF do Processo de Negócios:
http://schemas.xmlsoap.org/wsdl/process/
Espaço de Nomes de WSIF do Transformador:
http://schemas.xmlsoap.org/wsdl/transformer/
Espaço de Nomes de WSIF do IMS:
http://schemas.xmlsoap.org/wsdl/ims/
Espaço de Nomes de WSIF CICS-ECI:
http://schemas.xmlsoap.org/wsdl/cicseci/
Espaço de Nomes de WSIF CICS-ECI:
http://schemas.xmlsoap.org/wsdl/cicsepi/
Espaço de Nomes de WSIF do HOD:
http://schemas.xmlsoap.org/wsdl/hod3270/

Verificando a Migração de Artefatos de Origem

Se a migração for concluída com uma lista de mensagens de erro, aviso e/ou informativas, elas serão exibidas na janela Resultados da Migração (Migration Results). Caso contrário, a janela do assistente será fechada se a migração foi concluída com êxito.

A página a seguir aparece se tiverem sido geradas mensagens de migração durante o processo de migração:

Janela Resultados da Migração (Migration Results)

Na janela Resultados da Migração (Migration Results), é possível ver as mensagens de migração geradas durante o processo de migração. Selecionando uma mensagem da lista Mensagens (Message) superior, é possível localizar informações adicionais em relação a essa mensagem na janela Descrição de Mensagem (Message Description) inferior.

Para guardar todas as mensagens para futuras consultas, clique no botão Gerar Tarefas a Fazer (Generate ToDo's) para criar uma lista de tarefas "A Fazer" na visualização de tarefa e/ou clique no botão Salvar como... (Save as...) para salvar as mensagens em um arquivo de texto no sistema de arquivos. Examine cada mensagem para verificar se é necessário tomar alguma ação para corrigir imediatamente um artefato que não pôde ser totalmente migrado. Para ver a lista A Fazer gerada, clique em Janela -> Mostrar Visualização -> Outra... -> Geral -> Tarefas e clique em OK. A visualização de Tarefas é aberta com a lista de A Fazer gerada a partir do processo de migração.

Para verificar se uma parte da migração foi concluída, vá para a perspectiva Business Integration e certifique-se de que todos os processos e interfaces WSDL do projeto de serviço antigo apareçam no novo módulo. Construa o projeto e corrija quaisquer erros que impedem a construção do projeto.

Depois de executar as etapas de migração manuais requeridas para concluir a migração do aplicativo Business Integration, exporte o aplicativo como um arquivo EAR e instale-o em um WebSphere Process Server, configurando os recursos apropriados.

Desempenhe as etapas de migração manuais requeridas para migrar qualquer código de cliente ou gerar novo código de cliente utilizando o WebSphere Integration Developer. Certifique-se de que o cliente possa acessar o aplicativo e que o aplicativo tenha o mesmo comportamento existente no ambiente de tempo de execução anterior.

Trabalhando com Falhas de Migração de Artefatos de Origem

Se a migração de artefatos de origem do WebSphere Studio Application Developer Integration Edition falhar, existem várias maneiras de lidar com as falhas.

A seguir estão algumas das possíveis falhas de migração de artefatos de origem:

Se o assistente de Migração for concluído sem esta mensagem, será exibida uma lista de mensagens informativas, de aviso e de erro. Elas significam que alguma parte do projeto de serviço não pôde ser migrada automaticamente e que as alterações manuais devem ser executadas para completar a migração.

Limitações do Processo de Migração (Para Migração de Artefatos de Origem)

Existem algumas limitações envolvidas no processo de migração de artefatos de origem do WebSphere Studio Application Developer Integration Edition.

As listas a seguir detalham algumas das limitações do processo de migração para migração de artefatos de origem:

Limitações Gerais

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

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

Avisos

Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corporation.

Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos. É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos nesta publicação em outros países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM(R), não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM, poderá se utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM são de responsabilidade do Cliente.

A IBM pode ter patentes ou solicitação de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:

Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240

Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:

IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan 

O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS OU CONDIÇÕES DE NÃO-INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, esta disposição pode não se aplicar ao Cliente.

Estas informações podem conter imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aviso prévio.

Referências nestas informações a Web sites não-IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais desse produto IBM e a utilização desses Web sites é de inteira responsabilidade do Cliente.

A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.

Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:

Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240

Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em alguns casos o pagamento de uma taxa.

O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato de Licença de Programa Internacional IBM ou de qualquer outro contrato equivalente.

Todos os dados de desempenho aqui contidos foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas de nível de desenvolvimento e não há garantia de que estas medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas medidas podem ter sido estimadas por extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados aplicáveis para seu ambiente específico.

As informações relativas a produtos não-IBM foram obtidas junto aos fornecedores dos respectivos produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos de produtos não-IBM devem ser encaminhadas diretamente a seus fornecedores.

Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aviso prévio e representam apenas metas e objetivos.

Estas informações contêm exemplos de dados e relatórios utilizados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança com nomes e endereços utilizados por uma empresa real é mera coincidência.

LICENÇA DE COPYRIGHT:

Estas informações contêm programas de aplicativos de exemplo na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar confiabilidade, manutenção ou função destes programas. O Cliente pode copiar, modificar e distribuir estes programas de exemplo de qualquer maneira sem pagamento à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com interfaces de programação de aplicativos da IBM.

Cada cópia ou parte destes programas de exemplo ou qualquer trabalho derivado deve incluir um aviso de copyright com os dizeres:

(C) (nome da empresa) (ano). Partes deste código são derivadas dos Programas de Exemplo da IBM Corp. (C) Copyright IBM Corp. 2000, 2007. Todos os direitos reservados.

Se estas informações estiverem sendo exibidas em cópia eletrônica, as fotografias e ilustrações coloridas podem não aparecer.

Informações sobre a Interface de Programação

As informações sobre interface de programação destinam-se a facilitar a criação de software aplicativo utilizando este programa.

As interfaces de programação de uso geral permitem que o cliente desenvolva o software aplicativo que obtém os serviços das ferramentas deste programa.

No entanto, estas informações também podem conter informações sobre diagnósticos, modificações e ajustes. As informações sobre diagnósticos, modificações e ajustes são fornecidas para ajudá-lo a depurar seu software aplicativo.

Aviso: Não utilize estas informações sobre diagnósticos, modificações e ajustes como uma interface de programação, pois elas estão sujeitas a alterações.

Marcas Registradas e Marcas de Serviço

IBM, o Logotipo IBM, WebSphere, Rational, DB2, Universal Database DB2, Tivoli, Lotus, Passport Advantage, developerWorks, Redbooks, CICS, z/OS, e IMS são marcas ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países.

UNIX é uma marca registrada do The Open Group nos Estados Unidos e/ou em outros países.

Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e/ou em outros países.

Microsoft e Windows são marcas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.

Linux é uma marca registrada de Linus Torvalds nos Estados Unidos e/ou em outros países.

Adobe é uma marca ou marca registrada da Adobe Systems Incorporated nos Estados Unidos e/ou em outros países.

Outros nomes de empresas, produtos e serviços podem ser marcas registradas ou marcas de serviço de terceiros.

Termos de Uso

Permissões para uso de publicações são concedidas para os seguintes termos e condições.

Uso Pessoal: O cliente pode reproduzir essas publicações para uso pessoal, não comercial, desde que todos os avisos do proprietário sejam preservados. Não é permitido distribuir, exibir ou criar trabalho derivativos dessas publicações ou de qualquer parte delas, sem autorização expressa da IBM.

Uso Comercial: O cliente pode reproduzir, distribuir ou exibir essas publicações unicamente dentro da empresa do cliente, desde que todos os avisos do proprietário sejam preservados. O Cliente não poderá criar derivativos destas publicações ou reproduzir, distribuir ou exibir estas publicações ou qualquer parte das mesmas fora da empresa do Cliente sem a autorização expressa, por escrito da IBM.

Exceto quando concedido expressamente nesta permissão, nenhuma outra permissão, licença ou direito são concedidos, seja de maneira expressa ou implícita, para as publicações ou quaisquer informações, dados ou software ou outra propriedade intelectual neles contidos.

A IBM reserva-se no direito de cancelar as permissões concedidas neste documento sempre que, de acordo com seus critérios, o uso das publicações for nocivo aos seus interesses ou, conforme determinado pela IBM, caso as instruções acima não estejam sendo seguidas corretamente.

O Cliente não poderá fazer download, exportar ou reexportar estas informações, exceto quando em total conformidade com todas as leis e regulamentações aplicáveis, incluindo todas as leis e regulamentações de exportação dos Estados Unidos.

A IBM NÃO GARANTE O CONTEÚDO DESTAS PUBLICAÇÕES. ESTAS PUBLICAÇÕES SÃO FORNECIDAS "NO ESTADO EM QUE SE ENCONTRAM", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.

(C) Copyright IBM Corporation 2005, 2007. Todos os Direitos Reservados.