WebSphere Enterprise Service Bus, Versão 6.2.0 Sistemas Operacionais: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Mapeamento de Configuração Durante a Migração de Configuração de Produtos

Diversas configurações são mapeadas durante a migração de configuração de produtos.

A migração sempre envolve a migração de um único perfil para outro perfil único no mesmo sistema ou em um sistema separado. Exemplos incluem um gerenciador de implementação do WebSphere ESB Versão 6.1 migrando para um perfil de gerenciador de implementação versão 6.2 e um servidor independente Versão 6.1 migrando para um perfil de servidor independente versão 6.2.
Nota: Apenas um perfil do servidor independente pode ser migrado para um sistema separado.

Muitos cenários de migração são possíveis. As ferramentas de migração mapeiam objetos e atributos existentes na versão a partir da qual você está migrando para objetos e atributos correspondentes no ambiente de versão mais nova.

Porta de Auto-Inicialização
As ferramentas de migração mapeiam um valor não padrão diretamente para o ambiente da versão 6.2. Ao migrar a partir do versão 6.0.2.x, se o parâmetro -portBlock for especificado durante a chamada para WBIPostUpgrade, um novo valor de porta é fornecido para cada servidor que é migrado para versão 6.2.
Parâmetros da linha de comandos

As ferramentas de migração convertem parâmetros apropriados da linha de comandos para configurações da JVM (Java™ Virtual Machine) na definição do processo de servidor. A maioria das configurações é mapeada diretamente. Algumas configurações não são migradas, pois suas funções na configuração do WebSphere ESB versão 6.2 não existem, têm diferentes significados ou têm diferentes escopos.

Para obter informações sobre como alterar as configurações de definição de processo, consulte Configurações de Definição de Processo no centro de informações do WebSphere Application Server Network Deployment, versão 6.1. Para obter informações sobre como alterar as configurações da Java Virtual Machine, consulte Configurações de Java Virtual Machine no centro de informações do WebSphere Application Server Network Deployment, versão 6.1.

Tamanho de heap Java para migrar arquivos EAR

Ao migrar todos os arquivos EAR do WebSphere ESB para a versão 6.2 usando a ferramenta wsadmin, a ferramenta WBIPostUpgradeutiliza o valor máximo de tamanho de heap Java de 64 MB para instalar os arquivos EAR.

Se um arquivo EAR falhar ao instalar durante a migração porque o tamanho do heap Java não é grande o suficiente, você verá uma mensagem semelhante à seguinte:
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError 

Aumente o tamanho de heap Java máximo e siga o exemplo abaixo para instalar o aplicativo.

Exemplo de instalação de um aplicativo no WebSphere ESB versão 6.2

Suponhamos que:
Raiz de instalação
C:\WebSphere\DeploymentManager
Sinais de números (###)
Valor máximo do tamanho de heap
<EAR_file_name>
Nome do arquivo EAR
app_name
Nome do aplicativo
cluster_name
Nome do cluster no qual o arquivo EAR deve ser instalado
O comando é exibido em mais de uma linha por questão de clareza.
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
            C:\\WebSphere\\ProcServer
                   <EAR_file_name> 
        {-nodeployejb 
         -appname app_name 
         -cluster cluster_name}"
Migração de um nó da versão 6.0.x ou 6.1.x para um nó da versão 6.2

Você pode migrar um nó do WebSphere ESB versão 6.0.x ou 6.1.x que pertence a uma célula no WebSphere ESB versão 6.2 sem remover o nó da célula.

Migre o gerenciador de implementação primeiro, antes de migrar qualquer nó base na célula.

Utilize o mesmo nome de célula ao migrar do versão 6.0.x ou 6.1.x para o versão 6.2 . Se você utilizar um nome de célula diferente, os nós federados não poderão ser migrados com sucesso para a célula do WebSphere ESB versão 6.2.

A migração para um nó base do WebSphere ESB que está em uma célula para a versão 6.2 também migra o agente do nó para a versão 6.2.

Uma célula pode ter nós mistos, o que significa que ela pode conter alguns nós versão 6.2 e alguns nós versão 6.1.x.
Nota: Nós mistos não são suportados se você estiver migrando a partir do versão 6.0.2.x.
Arquivo de políticas
O WebSphere ESB versão 6.2 migra todos os arquivos de políticas que são instalados com arquivos de políticas versão 6.0.x ou 6.1.x com as seguintes características:
  • Quaisquer comentários localizados no arquivo de políticas versão 6.2 serão preservados. Quaisquer comentários contidos no arquivo de políticas versão 6.0.x ou 6.1.x não serão incluídos na versão 6.2.
  • A migração não tentará mesclar permissões ou concessões; é estritamente uma migração do tipo de inclusão. Se a permissão ou concessão não for localizada no arquivo versão 6.2, a migração irá transportá-la.
  • Segurança é um componente crítico; assim, a migração faz quaisquer inclusões no final do arquivo .policy original logo após o comentário MIGR0372I: Migrated grant permissions follow. Isso é feito para ajudar os administradores a verificarem quaisquer alterações do arquivo de políticas que a migração tenha realizado.
Propriedades e diretórios lib/app

A migração copia arquivos de diretórios de versões anteriores para a configuração do WebSphere ESB versão 6.2.

Arquivos de propriedades

O WebSphere migra todos os arquivos de propriedades que são instalados com o versão 6.0.x ou 6.1.x mesclando configurações nos arquivos de propriedades do versão 6.2.

A migração não sobrepõe arquivos de propriedades.

RARs (Resource Adapter Archives) referidos por recursos J2C

RARs e JARs que são referenciados por recursos J2C são migrados conforme a seguir:

Migrando recursos no nível do cluster

Os recursos de nível de cluster são configurados nos arquivos resourcexxx.xml nos diretórios de cluster. Por exemplo:
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

Se tiver um recurso no nível do cluster, esse recursos devem estar no mesmo local em cada membro do cluster (nó). Usando o exemplo acima, portanto, cada membro do cluster deve ter o arquivo RAR instalado no local ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} é resolvido em cada membro de cluster para obter o local exato.

Na migração de um gerenciador de implementação, as ferramentas migram os arquivos de cluster do gerenciador de implementação, incluindo os arquivos resourcexxx.xml.

Na migração de um nó gerenciado, as ferramentas processam cada adaptador J2C. Arquivos como arquivos RAR são migrados conforme a seguir do versão 6.0.x ou 6.1.x para o versão 6.2:
  • Migração de versão 6.0.2.x para versão 6.2: A migração copia arquivos como arquivos RAR ou JAR de WAS_INSTALL_ROOT para WAS_INSTALL_ROOT e de USER_INSTALL_ROOT para USER_INSTALL_ROOT
  • Migração de versão 6.1.x para versão 6.2: A migração copia arquivos de configuração conforme a seguir:
    • Se você instalar RAR ou JAR como parte da instalação do WebSphere ESB, os arquivos de configuração serão migrados para o perfil de destino de migração e atualizados para apontar para a nova versão dos arquivos RAR e JAR.
    • Se você instalar arquivos RAR ou JAR após a instalação de WebSphere ESB, o seguinte ocorrerá
      • Se você instalar os arquivos RAR ou JAR na instalação do WebSphere ESB anterior, somente os arquivos de configuração serão migrados e será necessário copiar ou instalar esses arquivos RAR ou JAR no perfil de destino de migração e certificar-se de que a configuração esteja correta antes de iniciar o servidor.
      • Se você instalar os arquivos RAR ou JAR fora da instalação do WebSphere ESB anterior (o que é recomendado), os arquivos de configuração serão migrados e não será necessário realizar nenhuma ação após a migração.

Se tiver codificado permanentemente um caminho para um arquivo RAR (archivePath="C:/WAS/installedConnectors/x2.rar", por exemplo) na versão 6.0.x ou 6.1.x, no entanto, as ferramentas de migração da versão 6.2 não podem alterar o atributo archivePath para refletir isso, pois isso interromperia todos os outros membros do cluster que não foram migrados.

Amostras

Durante a migração de um perfil independente, nenhuma amostra do WebSphere ESB é migrada. Amostras equivalentes do versão 6.2 estão disponíveis para todas as amostras do versão 6.2

Segurança
Nota: As informações de segurança a seguir se aplicam apenas se você estiver migrando a partir do versão 6.0.2.x

A segurança Java 2 é ativada por padrão quando você ativa a segurança no WebSphere ESB versão 6.2. A segurança Java 2 requer que permissões de segurança sejam concedidas explicitamente.

Há diversas técnicas que podem ser utilizadas para definir diferentes níveis da segurança Java 2 na versão 6.2. Uma é criar um arquivo was.policy como parte do aplicativo para ativar todas as permissões de segurança. As ferramentas de migração chamam o comando wsadmin para incluir um arquivo was.policy existente no diretório properties da versão 6.2 para aplicativos corporativos à medida que estão sendo migrados.

Ao migrar do WebSphere ESB versão 6.0.2.x para a versão 6.2, sua opção de migrar ou não para suportar a compatibilidade de scripts resultará em um de dois resultados diferentes.
  • Se optar por migrar para suportar compatibilidade de script, sua configuração de segurança é levada para a versão 6.2 sem quaisquer alterações.

    Esse é o padrão.

  • Se optar por não migrar para suportar compatibilidade de script, a configuração de segurança é convertida para a configuração padrão do WebSphere ESBversão 6.2. A configuração de segurança padrão versão 6.2 atua praticamente da mesma forma que nas versões anteriores, mas há algumas alterações.

    Por exemplo, keyfiles e trustfiles existentes são movidos para fora do repertório SSLConfig e novos objetos keystore e truststore são criados.

Para manter as mesmas configurações de segurança, é necessário migrar as configurações de segurança do WebSphere Application Server que podem ter sido configuradas para a versão 6.0.2.x. Para obter informações adicionais sobre como migrar suas configurações de segurança para a versão 6.2, consulte Migrando, Coexistindo e Interoperando - Considerações sobre Segurança no centro de informações do WebSphere Application Server Network Deployment, versão 6.1.

Diretórios stdin, stdout, stderr, de passivação e de trabalho

O local desses diretórios está geralmente no diretório de instalação de uma versão anterior. O local padrão para stdin, stdout e stderr é o diretório logs da raiz de instalação do WebSphere ESB versão 6.2.

As ferramentas de migração tentam migrar para diretórios de passivação e de trabalho existentes. Caso contrário, os padrões apropriados da versão 6.2 são utilizados.

Para obter informações adicionais sobre os diretórios de passivação, consulte Configurações do Contêiner EJB. Para obter informações adicionais sobre diretórios de trabalho, consulte Configurações de Definição de Processo.

Em um cenário de coexistência, a utilização de diretórios comuns entre versões pode criar problemas.

Portas de transporte

As ferramentas de migração migram todas as portas. As ferramentas registram um aviso de conflito de porta se uma porta já estiver definida na configuração. Você deve resolver quaisquer conflitos de porta antes de poder executar servidores ao mesmo tempo.

Se o parâmetro -portBlock for especificado no comando WBIPostUpgrade, um novo valor é designado para cada transporte migrado.

Para obter informações adicionais sobre o comando WBIPostUpgrade, consulte Utilitário de Linha de Comandos WBIPostUpgrade.

Para obter informações adicionais sobre cadeias e canais de transporte, consulte Cadeias de Transporte.

Você deve incluir manualmente entradas de alias de host virtual para cada porta. Para obter informações adicionais, consulte Configurando Hosts Virtuais.

Módulos da Web

O nível de especificação do J2EE (Java 2 Platform, Enterprise Edition) implementado no WebSphere ESB versão 6.0.x ou 6.1.x necessitou de alterações de comportamento no contêiner de Web para configurar o tipo de conteúdo. Se um gravador de servlet padrão não configurar o tipo de conteúdo, não somente o contêiner da Web não o utiliza mais como padrão, como o contêiner de Web retorna a chamada como "nula". Essa situação pode fazer com que alguns navegadores exibam tags resultantes do contêiner de Web incorretamente. Para evitar a ocorrência desse problema, a migração define a extensão IBM® autoResponseEncoding para "true" para módulos da Web à medida que migra aplicativos corporativos.


concept Tópico de Conceito

Termos de Uso | Feedback


Ícone de registro de data e hora Última Atualização: 01 julho 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cmig_vtv_configmap.html
Copyright IBM Corporation 2005, 2010. Todos os Direitos Reservados.
Este Centro de Informações foi desenvolvido com tecnologia Eclipse (http://www.eclipse.org).