Boas Práticas para o Processo de Migração do WebSphere InterChange Server

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

Estas recomendações destinam-se a ser utilizadas apenas como um guia para o desenvolvimento de novas soluções de integração. É reconhecido que o conteúdo existente pode não seguir estas diretrizes. Também é entendido que pode haver casos em que é necessário desviar-se destas diretrizes. 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 diretrizes descritas aqui não incluem as boas práticas para o desenvolvimento de artefatos do WebSphere InterChange Server em geral. Elas estão limitadas no escopo às considerações que podem afetar a facilidade em que os artefatos podem ser migrados futuramente.

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 boas práticas para desenvolvimento geral de soluções baseadas no WebSphere InterChange Server para ajudar a facilitar a migração futura:
  • Utilizar o WebSphere InterChange Server para soluções de integração de processos em tempo real e automatizadas
  • Documentar o design do sistema e do componente
  • Utilizar as ferramentas de desenvolvimento para editar artefatos de integração
  • Alavancar boas práticas para definir regras com as ferramentas e snippets Java

Embora possa parecer óbvio, é importante que as soluções de integração sigam o modelo de programação e a arquitetura fornecida pelo WebSphere InterChange Server. É melhor ajustado para soluções de integração de processo em tempo real, automatizadas. Além disso, cada um dos componentes de integração no WebSphere InterChange Server desempenha uma função bem definida na 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 boa prática geral que aprimorará significativamente o êxito 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 artefatos, é importante que apenas as ferramentas de desenvolvimento fornecidas sejam utilizadas. Evite a manipulação manual de metadados de artefatos (ex. edição direta de arquivos XML), que pode danificar o artefato para migração.

Ao desenvolver código Java em gabaritos de colaboração, mapas, utilitários de códigos comuns e outros componentes, existem várias considerações a serem levadas em conta:
  • Utilizar apenas as APIs publicadas
  • Utilizar o Activity Editor
  • Utilizar adaptadores para acessar EISs
  • Evitar dependências externas no trecho de código Java
  • Seguir as práticas de desenvolvimento de J2EE para portabilidade
  • Não efetuar spawn de encadeamentos ou utilizar primitivas de sincronização de encadeamento. Se tiver que fazer isso, estas tarefas deverão ser convertidas para utilizar Beans Assíncronos durante a migração.
  • Não fazer nenhuma E/S de disco utilizando java.io.* Utilizar JDBC para armazenar dados.
  • Não desempenhar funções que podem estar reservadas para um contêiner EJB, como E/S de soquete, carregamento de classe, carregamento de bibliotecas nativas, etc. Se tiver que fazer isso, estes snippets precisarão de conversão manual para utilizar as funções de contêiner EJB durante a migração.

Utilizar apenas as APIs publicadas na documentação do produto para os artefatos. Estas tarefas estão descritas detalhadamente nos guias de desenvolvimento do WebSphere InterChange Server. Embora em muitos casos as APIs de compatibilidade serão fornecidas no WebSphere Process Server, apenas as APIs publicadas serão incluídas. Embora o WebSphere InterChange Server possua muitas interfaces internas que um desenvolvedor pode querer utilizar, não há garantia de que elas serão suportadas durante o avanço.

Ao projetar a lógica de negócios e regras de transformação em mapas e gabaritos de colaboração, certifique-se de utilizar a ferramenta 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. 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, pois elas precisarão ser migradas manualmente.

Em quaisquer trechos de código Java que pode ser desenvolvido, é recomendável que o código seja 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, etc. 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. Geralmente, esta é a boa prática para design da 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 de J2EE, como evitar variáveis estáticas, execução de spawn em encadeamentos e E/S de disco. Estas são as boas práticas recomendáveis que devem ser seguidas, em geral, mas serão pertinentes à portabilidade.

Utilitários de Código Comuns

Conforme indicado anteriormente, é 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.

Conjuntos de Conexões com o Banco de Dados

Os conjuntos de conexões com o banco de dados definidos pelo usuário são muito úteis em mapas e gabaritos de colaboração para consultas de dados simples e para gerenciamento de estados mais sofisticado através de instâncias de processo. 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. No entanto, a maneira que as conexões e transações são gerenciadas pode ser diferente.

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.

Business Objects

As considerações primárias para o desenvolvimento de objetos de negócios será utilizar apenas as ferramentas fornecidas para configurar artefatos, utilizar tipos de dados e comprimentos explícitos para atributos de dados e utilizar apenas as APIs documentadas.

Os objetos de negócios com o WebSphere Process Server são baseados em SDOs (Service Data Objects), que utilizam atributos de dados altamente especificados. Para objetos de negócios no WebSphere InterChange Server e adaptadores, os atributos de dados não são altamente especificados e, às vezes, os usuários especificam tipos de dados de cadeia para atributos de dados sem cadeia. Para evitar problemas no WebSphere Process Server, seja explícito na especificação de tipos de dados.

Como os objetos de negócios no WebSphere Process Server podem ser serializados no tempo de execução conforme são transmitidos entre componentes, é importante ser explícito com os comprimentos requeridos para atributos de dados, para minimizar a utilização de 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 XSD NCName se aplicam a nomes de atributos de objeto de negócios no WebSphere Process Server, portanto, não utilize espaços ou ":" em nomes para atributos de objeto de negócios. Os nomes de atributos de objeto de negócios com espaços ou ":" são inválidos no WebSphere Process Server. Renomeie os atributos de objeto de negócios antes da migração.

Se estiver utilizando uma matriz em um objeto de negócios, não poderá depender da ordem da matriz durante a indexação na matriz em Mapas e/ou Relacionamentos. A construção migrada para o WebSphere Process Server não garante uma ordem de indexação, principalmente quando entradas são excluídas.

Mais uma vez, como afirmamos anteriormente, é importante utilizar apenas a ferramenta Business Object Designer para editar definições de objeto de negócios e utilizar apenas as APIs publicadas para objetos de negócios em artefatos de integração.

Gabaritos de Colaboração

Muitas das diretrizes descritas anteriormente se aplicam ao desenvolvimento de gabaritos 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. Eles não podem ser impostos em snippets Java de BPEL que são o resultado da migração de Gabaritos de Colaboração.

Para maximizar a portabilidade futura, evite utilizar chamadas de liberação de conexão explícitas e suporte a transações explícito (ou seja, confirmações explícitas & rollbacks explícitos) para Conjuntos de Conexões com o 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. Conforme descrito anteriormente, as operações com um EIS externo devem ser gerenciadas em um adaptador e o código relacionado a uma operação do banco de dados deve estar contido em 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.

Não utilize caracteres especiais em nomes de propriedades do Gabarito de Colaboração. Estes caracteres especiais são inválidos em nomes de propriedades de BPEL para as quais eles serão migrados. Renomeie propriedades para remover estes caracteres especiais antes de migrar para evitar erros sintáticos no BPEL gerados pela migração.

Não faça referência a variáveis usando "this." Por exemplo, ao invés de "this.inputBusObj" use apenas "inputBusObj"

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

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

Certifique-se de que não existam instruções de importação Java nas seções modificáveis pelo usuário de seus Gabaritos de Colaboração. Na definição do Gabarito de Colaboração, utilize os campos de importação para especificar pacotes Java para importação.

Mapas

Muitas das diretrizes descritas para gabaritos 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.

Quando referir-se a um objeto de negócios filho em um mapa, utilize um submapa para os objetos de negócios filhos.

Evite utilizar o código Java como o "value" em um SET pois 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 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.

Se estiver utilizando uma matriz em um objeto de negócios, não poderá depender da ordem da matriz durante a indexação na matriz em Mapas. A construção migrada para o WebSphere Process Server não garante uma ordem de indexação, principalmente quando entradas são excluídas.

Para maximizar a portabilidade futura, evite utilizar chamadas de liberação de conexão explícitas e suporte a transações explícito (ou seja, confirmações explícitas & rollbacks explícitos) para Conjuntos de Conexões com o 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 trecho de código Java em limites de 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. Conforme descrito anteriormente, as operações com um EIS externo devem ser gerenciadas em um adaptador e o código relacionado a uma operação do banco de dados deve estar contido em um trecho de código.

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.

As principais considerações para relacionamentos são utilizar apenas as ferramentas fornecidas para configurar os componentes relacionados e utilizar apenas as APIs publicadas para relacionamentos em artefatos de integração.

É importante utilizar apenas a ferramenta Relationship Designer para editar definições de relacionamentos. Além disso, permita que apenas o WebSphere InterChange Server configure o esquema de relacionamento, que é gerado automaticamente durante a implementação de definições de relacionamentos. Não altere o esquema da tabela de relacionamentos diretamente com ferramentas de banco de dados ou scripts SQL.

Além disso, se tiver que modificar manualmente os dados da instância de relacionamento no esquema da tabela de relacionamentos, certifique-se de utilizar os recursos fornecidos pelo Relationship Designer.

Conforme afirmamos anteriormente, é importante utilizar apenas as APIs publicadas para relacionamentos em artefatos de integração.

Clientes da Estrutura de Acesso

Não desenvolva novos clientes adotando as APIs da interface IDL CORBA. Isto não será suportado no WebSphere Process Server.
Tarefas relacionadas
Verificando a Migração do WebSphere InterChange Server
Trabalhando com Falhas de Migração do WebSphere InterChange Server

Feedback
(C) Direitos Autorais IBM Corporation 2005, 2006. Todos os Direitos Reservados.