Partilhar via

Protocolo de troca de contexto

Esta seção descreve o protocolo de troca de contexto introduzido na versão 3.5 do .NET Framework do Windows Communication Foundation (WCF). Esse protocolo permite que o canal do cliente aceite um contexto fornecido por um serviço e o aplique a todas as solicitações subsequentes a esse serviço enviadas pela mesma instância do canal do cliente. A implementação do protocolo de troca de contexto pode usar um dos dois mecanismos a seguir para propagar o contexto entre o servidor e o cliente: cookies HTTP ou um cabeçalho SOAP.

O protocolo de troca de contexto é implementado em uma camada de canal personalizada. O canal comunica o contexto de e para a camada de aplicativo usando uma ContextMessageProperty propriedade. Para transmissão entre pontos de extremidade, o valor do contexto é serializado como um cabeçalho SOAP na camada de canal ou convertido para ou a partir das propriedades da mensagem que representam uma solicitação e resposta HTTP. Neste último caso, espera-se que uma das camadas de canal subjacentes converta as propriedades da solicitação HTTP e da mensagem de resposta de e para cookies HTTP, respectivamente. A escolha do mecanismo usado para trocar o contexto é feita usando a ContextExchangeMechanism propriedade no ContextBindingElement. Os valores válidos são HttpCookie ou SoapHeader.

No cliente, uma instância de um canal pode operar em dois modos com base nas configurações na propriedade do canal, Enabled.

Modo 1: Gerenciamento de contexto de canal

Este é o modo padrão onde Enabled está definido como true. Nesse modo, o canal de contexto gerencia o contexto e armazena em cache o contexto durante seu tempo de vida. O contexto pode ser recuperado do canal através da propriedade IContextManager chamando o método GetContext. O canal pode ser pré-inicializado com um contexto específico antes de ser aberto, chamando o método SetContext na propriedade do canal. Uma vez que o canal é inicializado com contexto, ele não pode ser redefinido.

Segue-se uma lista de invariantes neste modo:

  • Qualquer tentativa de redefinir o contexto usando SetContext após a abertura do canal lança uma InvalidOperationExceptionexceção.

  • Qualquer tentativa de enviar contexto usando o ContextMessageProperty numa mensagem de saída lança uma exceção InvalidOperationException.

  • Se uma mensagem for recebida do servidor com um contexto específico, quando o canal já tiver sido inicializado com um contexto específico, isso resultará em um ProtocolException.

    Observação

    É apropriado receber um contexto inicial do servidor somente se o canal for aberto sem qualquer contexto definido explicitamente.

  • O ContextMessageProperty na mensagem de entrada é sempre nulo.

Modo 2: Gerenciamento de contexto de aplicativo

Este é o modo quando Enabled está definido como false. Neste modo, o canal de contexto não gerencia o contexto. É responsabilidade do aplicativo recuperar, gerenciar e aplicar o contexto usando o ContextMessageProperty. Qualquer tentativa de ligar para GetContext ou SetContext resulta num InvalidOperationException.

Não importa qual modo seja escolhido, a fábrica de canais do cliente suporta IRequestChannel, IRequestSessionChannele padrões IDuplexSessionChannel de troca de mensagens.

No serviço, uma instância do canal é responsável por converter o contexto fornecido pelo cliente nas mensagens recebidas para o ContextMessageProperty. A propriedade message pode então ser acessada pela camada de aplicativo ou outros canais mais acima na pilha de chamadas. Os canais de serviço também permitem que a camada de aplicativo especifique um novo valor de contexto a ser propagado de volta ao cliente anexando um ContextMessageProperty à mensagem de resposta. Esta propriedade é convertida para o cabeçalho SOAP ou cookie HTTP que contém o contexto, que depende da configuração da ligação. O ouvinte do canal de serviço suporta padrões de troca de mensagens IReplyChannel, IReplySessionChannel, e IReplySessionChannel.

O protocolo de troca de contexto introduz um novo wsc:Context cabeçalho SOAP para representar as informações de contexto quando os cookies HTTP não são usados para propagar o contexto. O esquema de cabeçalho de contexto permite qualquer número de elementos filho, cada um com uma chave de cadeia de caracteres e conteúdo de cadeia de caracteres. Segue-se um exemplo de um cabeçalho de contexto.

<Context xmlns="http://schemas.microsoft.com/ws/2006/05/context">

<property name="myContext">context-2</property>

</Context>

Quando estiver no modo HttpCookie, os cookies são definidos através do cabeçalho SetCookie. O nome do cookie é WscContext. O valor do cookie é a codificação Base64 do wsc:Context cabeçalho. Este valor está entre aspas.

O valor do contexto deve ser protegido contra modificações durante o transporte pelo mesmo motivo pelo qual os cabeçalhos WS-Addressing são protegidos – o cabeçalho é usado para determinar para onde encaminhar a solicitação no serviço. Portanto, o cabeçalho wsc:Context deve ser assinado digitalmente ou assinado e encriptado no nível SOAP ou de transporte quando a ligação oferece capacidade de proteção de mensagem. Quando os cookies HTTP são usados para propagar o contexto, eles devem ser protegidos usando segurança de transporte.

Os pontos de extremidade de serviço que exigem suporte para o protocolo de troca de contexto podem explicitar isso na política publicada. Duas novas asserções de política foram introduzidas para representar o requisito para que o cliente ofereça suporte ao protocolo de troca de contexto no nível SOAP ou para habilitar o suporte a cookies HTTP. A geração dessas afirmações na política no serviço é controlada pelo valor da propriedade ContextExchangeMechanism da seguinte forma:

  • Para ContextSoapHeader, a seguinte asserção é gerada:

    <IncludeContext
xmlns="http://schemas.microsoft.com/ws/2006/05/context"  
protectionLevel="Sign" />

  • Para HttpCookie, a seguinte asserção é gerada:

    <HttpUseCookie xmlns="http://schemas.xmlsoap.org/soap/http"/>

Ver também