Protocolo de troca de contexto
Esta seção descreve o protocolo de troca de contexto introduzido no Windows Communication Foundation (WCF) versão .NET Framework versão 3.5. 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 channel chamando o GetContext método. O canal também pode ser pré-inicializado com contexto específico antes de ser aberto chamando o SetContext método na propriedade channel. 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
SetContextdepois que o canal foi aberto lança um InvalidOperationExceptionarquivo .Qualquer tentativa de enviar contexto usando o ContextMessageProperty em uma mensagem de saída lança um InvalidOperationExceptionarquivo .
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 ProtocolExceptionarquivo .
Nota
É apropriado receber um contexto inicial do servidor somente se o canal for aberto sem qualquer contexto definido explicitamente.
A ContextMessageProperty mensagem de entrada é sempre nula.
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 chamada GetContext ou SetContext resulta em um InvalidOperationExceptionarquivo .
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 IReplyChannel, IReplySessionChannele padrões IReplySessionChannel de troca de mensagens.
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 no HttpCookie modo, os cookies são definidos usando o SetCookie cabeçalho. 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 trânsito pelo mesmo motivo pelo qual os cabeçalhos WS-Addressing são protegidos – o cabeçalho é usado para determinar para onde enviar a solicitação no serviço. Portanto wsc:Context , o cabeçalho deve ser assinado digitalmente ou assinado e criptografado no nível SOAP ou de transporte quando a associaçã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 torná-lo explícito 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 sobre o serviço é controlada pelo valor do ContextExchangeMechanism imóvel 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"/>