WebSphere Virtual Enterprise, Version 6.1.1
             Sistemas Operacionais: AIX,, HP-UX, Linux, Solaris, Windows ,


Políticas de Serviço e de Roteamento

Dois tipos de políticas são aplicados a um pedido: roteamento e serviço. É possível criar políticas de roteamento para pedidos de HTTP e SOAP e criar políticas de serviço para pedidos de HTTP, IIOP, SOAP, JMS e SIP. Adicionalmente, as classes de trabalho podem conter regras de classificação para ambos os tipos de política, com exceção do JMS. As regras de classificação não são suportadas para classes de trabalho JMS.

Políticas de Roteamento Válidas

Tabela 1. Políticas de Roteamento
Política de Roteamento Descrição
permit:application_name

application_name é o nome do aplicativo a ser roteado com um especificador de edição opcional.

permitMM:application_name

application_name é o nome ao aplicativo a ser roteado com um especificador de edição opcional. O roteamento desta maneira permite que o pedido continue como normal. Note que o servidor deve estar no modo de manutenção.

permitsticky:application_name

A política de roteamento permitsticky é igual a política de roteamento permit, exceto que o On Demand Router (ODR) também mantém a afinidade de cliente-para-servidor para quaisquer pedidos futuros provenientes do mesmo cliente. Neste caso, o ODR inclui um cabeçalho SET-COOKIE na resposta, antes de enviar a resposta ao cliente.

A ação permitsticky significa que o ODR estabelece ativamente a afinidade entre o cliente e o servidor, se a afinidade ainda não foi estabelecida pelo aplicativo. O ODR realiza isso incluindo um SET-COOKIE: WSJSESSIONID=xx:serverID; path=webModuleContextRoot na resposta se:
  • A resposta ainda não tiver um SET-COOKIE que estabelecerá a afinidade do servidor, e
  • O pedido correspondente não indicar que a afinidade do servidor já foi estabelecida.
O ID do servidor é o identificador do servidor, e também é referido como ID do clone. O webModuleContextRoot é a raiz de contexto do módulo da Web para o qual o pedido foi mapeado.
permitstickyMM:application_name

Essa política de roteamento é igual a política de roteamento permit, exceto que o ODR também mantém a afinidade de cliente para servidor para quaisquer pedidos futuros provenientes do mesmo cliente. Neste caso, o ODR inclui um cabeçalho SET-COOKIE na resposta, antes de enviar a resposta ao cliente. Note que o servidor deve estar no modo de manutenção.

reject:HTTP_error_code

Essa política de roteamento faz com que o ODR rejeite o pedido e retorne o código de erro de HTTP especificado. Por exemplo, reject:503 retorna um erro 503 O Serviço Está Indisponível.

reject:URL

Com esta política de roteamento, o ODR redireciona o pedido para a URL especificada. A URL tem o padrão do protocolo://URI. Um exemplo de uma URL válida é http://w3.ibm.com.

Políticas de Serviço Válidas

As políticas de serviço válidas são a lista de nomes de classes de transação. A classe de transação refere-se a um única classe de serviço.




Tarefas relacionadas
Definindo uma Política de Serviço
Configurando o Modo de Manutenção
Ativando Edições Simultâneas
Validando uma Edição
Referências relacionadas
Operandos do Construtor de Subexpressão para Políticas de Roteamento e Serviço
Informações relacionadas
Regras para Tarefas Administrativas de Política de Roteamento do ODR
Regras para Tarefas Administrativas de Política de Serviço do ODR
Tópico de Referência    

Termos de Uso | Feedback

Última atualização: 24/09/2009 14h16min12s EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/odoe_task/rodrworkclass.html