Migrando uma Configuração de Gateway de Serviços da Web do Versão 5.1

No WebSphere Application Server Versão 5.1, o gateway de serviços da web era um componente separado com sua própria interface com o usuário. Nas versões mais recentes do produto, o gateway esta integrado nos serviços da Web ativados por barramento de integração de serviço e reimplementado como um mecanismo para estender e vincular serviços de entrada e de saída. Use um script de comando wsadmin para migrar uma configuração de gateway existente de um servidor de aplicativos da Versão 5.1 para um servidor de aplicativos ou cluster em uma versão mais recente.

Antes de Iniciar

Considere se terá que migrar os gateways existentes:
  • WebSphere Application Server Versão 5.0 não é mais suportado, portanto, você deve migrar quaisquer gateways existentes que estejam em execução em servidores de aplicativos do Versão 5.0 para serem executados nos servidores de aplicativos no nível atual do produto.
  • Os gateways de serviço da web em execução no WebSphere Application Server Versão 5.1 podem, sujeitos a determinadas restrições, coexistir com as instâncias de gateway em execução nos servidores de aplicativos da Versão 7.0 ou posterior servidores de aplicativos.
  • A Versão 7.0 ou posterior pode conter servidores de aplicativos da Versão 5.1, Versão 6 e Versão 7.0 ou posterior servidores de aplicativos.
Para obter mais informações, consulte Coexistência: Preservar ou Migrar um Gateway Versão 5.1.

É possível migrar um gateway da Versão 5.1 que está em uso de produção sem parar o gateway; os aplicativos do solicitante podem ser comutados para utilizar a nova configuração do gateway enquanto o gateway da Versão 5.1 existente continua em execução.

Sobre Esta Tarefa

O procedimento de migração usa um aplicativo gateway Versão 5.1 cuja configuração foi exportada para um arquivo XML, e usa o arquivo XML exportado para configurar as mesmas funções de gateway em um único servidor de aplicativos ou cluster da versão mais recente. Para isso, você exporta a configuração de gateway de Versão 5.1, em seguida, executa um script para migrar a configuração exportada para uma nova instância de gateway em um servidor de aplicativos ou cluster existente na versão mais recente.

A configuração da Versão 5.1 é migrada da seguinte forma:
  • Como parte do processo de migração, uma instância do gateway é criada automaticamente.
  • Os serviços de gateway, serviços de destino e referências UDDI são migrados diretamente.
  • As definições no gateway das rotinas de tratamento JAX-RPC e das listas de rotina de tratamento também são migradas. Certifique-se de que as classes de rotina de tratamento subjacentes estejam disponíveis no tempo de execução.
  • As designações de serviços de gateway a canais específicos são substituídas por designações equivalentes a pares de listener específicos de porta de entrada e terminal (porque, nas versões mais recentes as funções de um canal são compartilhadas entre um listener de terminal e uma porta de entrada). Qualquer uso de um canal do Apache SOAP é migrado para um listener de nó de extremidade SOAP sobre HTTP e uma porta de entrada.
  • Os filtros existentes não são migrados. O uso dos filtros foi descontinuado no Versão 5.1.1 e o suporte para filtros foi removido da Versão 7.0. A função anteriormente desempenhada por filtros agora é executada por uma combinação de manipuladores JAX-RPC e mediações do barramento de integração de serviços.
  • Os clientes de serviços da Web que são gerados do WSDL para o serviço de destino, em vez do serviço de gateway, são sinalizados por padrão nas versões mais recentes como um erro.
  • Se você usou o WSDL de serviço de gateway Versão 5.1 para gerar os seus clientes de serviço da Web e a ligação e o estilo de codificação do WSDL não for literal do documento, após a migração para uma versão mais recente, você deve gerar novamente stubs de cliente, usando o novo WSDL de serviço de gateway.
  • As ligações do WS-Security são migradas como ligações que estão em conformidade com a especificação WS-Security Draft 13. Entretanto:
    • A versão final (1.0) da especificação WS-Security (implementada no WebSphere Application Server Versão 6) não é compatível com a versão Draft 13 e, portanto, o uso do WS-Security Draft 13 foi reprovado no WebSphere Application Server Versão 6. O uso do Rascunho 13 do WS-Security foi descontinuado e ele só deve ser usado para permitir o uso continuado de um aplicativo cliente de serviços da Web que está sendo gravado na especificação do Rascunho 13 do WS-Security.
    • Os objetos de ligação do WS-Security são migrados apenas se o processo de migração for executado na máquina em que o servidor de destino está sendo executado no caso de um servidor independente ou na máquina em que o gerenciador de implementação está sendo executado em uma configuração de implementação de rede.
    • Apenas os objetos de ligação do WS-Security que são utilizados por um Serviço de Gateway ou configuração do WS-Security de Serviço de Destino são migrados. Quaisquer objetos de ligação que você cria, mas não utiliza, não são migrados. Exemplo: Se você possui uma configuração do WS-Security que faça referência a um objeto Signing Information e o objeto Signing Information fizer referência ao Trust Anchor, o objeto Signing Information e o objeto Trust Anchor serão migrados juntamente com a configuração do WS-Security que faz referência a eles.
Nota:
  • A migração assume que os endereços da Web externos para os serviços migrados estão inalterados. Essa suposição é baseada na expectativa de que esses endereços estejam associados a um servidor da Web e não com a máquina na qual o gateway está hospedado e de que o nome do host e o número da porta para esses endereços não sejam, portanto, afetados. Se em sua configuração o endereço da web externo apontar para a máquina de gateway, modifique a configuração do listener terminal após a conclusão do processo de migração.
  • Você pode usar o WebSphere Application Server Network Deployment para migrar para um servidor único sendo executado sob um dos perfis de configuração (servidor independente ou gerenciador de implementação). No entanto, é recomendável migrar para um único servidor em execução em um perfil do gerenciador de implementação. Se você migrar para um perfil de servidor independente, não poderá usar o console administrativo para modificar subsequentemente a sua configuração de gateway.
  • Os serviços da Web ativados pelo barramento da integração de serviços validam as mensagens do serviço da Web mais completamente do que como é feito no WebSphere Application Server Versão 5.1. Como resultado, alguns aplicativos clientes que utilizam pedidos ou respostas malformados (em que partes da mensagem estão nomeadas incorretamente) e que funcionam ao utilizar a Versão 5.1 agora são identificados como malformados. Para obter as etapas a serem executadas para resolver o problema, consulte Serviços da Web Acionados por Barramento: Restrições Conhecidas.

Para migrar uma configuração de gateway existente de um servidor de aplicativos da Versão 5.1 para a capacidade de gateway em um servidor de aplicativos ou cluster em uma versão mais recente, conclua as seguintes etapas:

Procedimento

  1. Opcional: Remove quaisquer filtros de seu gateway da Versão 5.1.
    É possível migrar um gateway que contém filtros. No entanto, os filtros não trabalham em versões mais recentes; portanto, talvez você prefira removê-los da configuração antes da migração, concluindo as etapas a seguir:
    1. Verifique se o gateway da Versão 5.1 usa filtros. Para obter informações adicionais, consulte o tópico do WebSphere Application Server Versão 5.1: Listando e Gerenciando Filtros Implementados por Gateway.
    2. Remova todos os filtros. Para obter informações adicionais, consulte o tópico do WebSphere Application Server Versão 5.1: Removendo filtros do gateway de serviços da Web.
    Após a migração, é possível recriar as funções do filtro usando uma combinação de manipuladores JAX-RPC e mediações de barramentos de integração de serviços. Se você migrar um gateway de serviços da web que inclua um filtro de roteamento, será possível recriar as funções de filtro.
  2. Escolha um servidor ou cluster de destino que seja um único servidor ou cluster na versão mais recentes e faça parte de uma célula de implementação de rede.
  3. Configure o servidor ou cluster de destino como membro de um barramento de integração de serviços.
  4. Configure um repositório do Service Data Objects (SDO) no escopo da célula para o cluster ou servidor de destino.
  5. Se você estiver migrando quaisquer ligações EJB e desejar que elas continuem utilizando uma ligação codificada por RPC ou qualquer ligação diferente do literal de documento, inclua uma ligação do tipo correto no WSDL de ligação EJB. Esta etapa é necessária porque a ligação padrão do gateway da Versão 5.1 é codificada por RPC, enquanto nas versões posteriores a ligação padrão é documento literal.
  6. Certifique-se de que o servidor de aplicativos de origem (Versão 5.1) esteja em execução e, em seguida, utilize a interface com o usuário do gateway da Versão 5.1 para fazer backup da configuração de gateway do servidor de aplicativos da Versão 5.1 como uma configuração privada. Para obter informações adicionais, consulte o tópico do WebSphere Application Server Versão 5.1: Fazendo Backup de uma Configuração de Gateway.
  7. Opcional: Pare o servidor de aplicativos da Versão 5.1.
    Nota: Se você estiver migrando um gateway que esteja em uso na produção, mantenha o gateway da Versão 5.1 executando até que a configuração de gateway na versão mais recente esteja concluída e, em seguida, comute os aplicativos solicitantes para usar a nova configuração de gateway enquanto o gateway do Versão 5.1 existente continua em execução. Entretanto, nenhuma das versões do gateway precisa estar em execução simultaneamente e é provável que você tenha que parar o servidor de Versão 5.1 antes de iniciar o servidor ou o cluster na versão mais recente (por exemplo, se estiver instalando o servidor ou o cluster na versão mais recente como uma substituição direta para o servidor Versão 5.1, na mesma máquina e usando os mesmos números de porta).
  8. Inicie o aplicativo de destino ou cluster de destino na versão mais recente e, para um único servidor ou cluster em uma célula gerenciada, o gerenciador de implementação para a célula de destino.
  9. Verifique se todos os documentos WSDL que foram utilizados para definir os serviços de destino no servidor de aplicativos da Versão 5.1 estão disponíveis em seus locais determinados. Se o local do WSDL for uma referência de UDDI, verifique se o registro do UDDI referido está disponível.
  10. Opcional: Se o gateway que está sendo migrado utilizar as rotinas de tratamento e as listas de rotinas de tratamento JAX-RPC, certifique-se de que as classes de rotina de tratamento subjacentes estejam disponíveis no tempo de execução.
  11. Para migrar a configuração exportada para uma nova instância de gateway no servidor de aplicativos ou cluster na versão mais recente, conclua as etapas a seguir:
    1. Abra um prompt de comandos, em seguida, vá para o diretório app_server_root/util
    2. Execute o seguinte comando:
      [IBM i]Nota: [IBM i]O cliente de script wsadmin é executado do Qshell. [IBM i]Para obter informações adicionais, consulte Configurando o Qshell para Executar Scripts do WebSphere Usando o Script wsadmin.
      migratewsgw[AIX Solaris HP-UX Linux Windows][z/OS].ext -C=cell_name [-S=server_name -N=node_name] 
                          [-X=cluster_name] -B=bus_name 
                           -G=v5_gateway_configuration_file_name 
                          [-H=administration_hostname] [-A=administration_port] 
                          [-U=gateway_instance_name] [-P=object_prefix] 
                          [-username=WAS_user_ID -password=WAS_password]
      onde:
      • [AIX Solaris HP-UX Linux Windows][z/OS].ext é a extensão de arquivo .bat para um sistema Windows ou .sh para um sistema Unix ou Linux.
      • Os colchetes ("[ ]") indicam que um parâmetro ou conjunto de parâmetros é opcional em algumas circunstâncias.
      • server_name e node_name juntos (para um único servidor) ou cluster_name (para um cluster), define o servidor ou cluster para o qual a configuração de gateway é migrada.
      • cell_name, server_name e node_name (ou cluster_name), administration_hostname e administration_port juntos definem a conexão com o servidor de aplicativos (ou cluster) na versão posterior. server_name ou cluster_name especifica o nome do servidor de aplicativos ou cluster de destino no qual destinos de porta de saída e listeners do terminal são criados. Se você estiver migrando para um servidor ou cluster que faça parte de uma célula gerenciada, administration_hostname e administration_port definirão o nome do host e o número da porta de administração SOAP do gerenciador de implementação. Se você estiver migrando para um servidor que não faça parte de uma célula gerenciada, administration_hostname e administration_port definem o nome do host e o número da porta do servidor independente e são opcionais. Se forem omitidos, o comando assumirá que os valores pretendidos sejam localhost:8880 (ou seja, os valores padrão do WebSphere Application Server para um servidor independente).
        [IBM i]Nota: administration_hostname é obrigatória para a plataforma IBM i.
      • v5_gateway_configuration_file_name é o caminho completo e o nome de arquivo para o arquivo de configuração XML exportado do gateway privado da Versão 5.1.
      • bus_name e gateway_instance_name juntos definem a instância de gateway que você está criando neste barramento. O nome_da_instância_de_gateway será requerido apenas se você desejar criar mais de uma instância de gateway dentro desse barramento. Se você omitir esse parâmetro opcional, um nome padrão será criado.
      • prefixo_do_objeto é uma cadeia utilizada para prefixar os nomes dos objetos definidos pelo processo de migração. Se omitido, o URI do espaço de nomes (valor padrão urn:ibmwsgw) será utilizado para os serviços migrados.
      • WAS_user_ID e WAS_password serão obrigatórios se o servidor de aplicativos ou cluster de destino for protegido por senha.
  12. Opcional: Se os endereços da web externos para os serviços migrados forem alterados pelo processo de migração, modifique a configuração do listener terminal para atualizar esses endereços. Isso deve ser feito se os endereços da Web externos apontarem para a máquina do gateway em vez de para um servidor da Web e você tiver migrado o gateway para uma máquina diferente ou para uma porta diferente na mesma máquina.

O que Fazer Depois

Nota:
  • Se o gateway Versão 5.1 tiver usado filtros, recrie as funções do filtro usando uma combinação de manipuladores JAX-RPC e mediações de barramentos de integração de serviços.
  • Se a configuração de gateway incluir qualquer serviço de gateway que tenha vários serviços de destino, a configuração da Versão 5.1 pode ter utilizado um filtro de roteamento para escolher um serviço de destino específico. Se esse for o caso, você deverá ainda configurar seu gateway migrado para escolher um serviço e porta de destino por meio de uma mediação de roteamento.
  • Um gateway de serviços da Web em uma versão mais recente usa mais memória para processar uma mensagem, de modo que se você passar um anexo grande através do gateway migrado, talvez receba um erro de falta de memória na Java Virtual Machine. Para resolver esse problema, aumente o tamanho de heap da JVM.

Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twsg_coex_migrate
Nome do arquivo: twsg_coex_migrate.html