Dela via


Exchange-protokoll för kontext

I det här avsnittet beskrivs det protokoll för kontextutbyte som introducerades i Windows Communication Foundation-versionen (WCF) .NET Framework version 3.5. Med det här protokollet kan klientkanalen acceptera en kontext som tillhandahålls av en tjänst och tillämpa den på alla efterföljande begäranden till den tjänsten som skickas via samma klientkanalinstans. Implementeringen av protokollet för kontextutbyte kan använda någon av följande två mekanismer för att sprida kontexten mellan servern och klienten: HTTP-cookies eller ett SOAP-huvud.

Protokollet för kontextutbyte implementeras i ett anpassat kanallager. Kanalen kommunicerar kontexten till och från programskiktet med hjälp av en ContextMessageProperty egenskap. För överföring mellan slutpunkter serialiseras värdet för kontexten antingen som en SOAP-rubrik på kanallagret eller konverteras till eller från meddelandeegenskaperna som representerar en HTTP-begäran och ett HTTP-svar. I det senare fallet förväntas ett av de underliggande kanalskikten konvertera egenskaperna http-begäran och svarsmeddelande till respektive från HTTP-cookies. Valet av den mekanism som används för att utbyta kontexten görs med hjälp av ContextExchangeMechanism egenskapen på ContextBindingElement. Giltiga värden är HttpCookie eller SoapHeader.

På klienten kan en instans av en kanal fungera i två lägen baserat på inställningarna för kanalegenskapen . Enabled

Läge 1: Kanalkontexthantering

Det här är standardläget där Enabled är inställt på true. I det här läget hanterar kontextkanalen kontexten och cachelagrar kontexten under dess livslängd. Kontext kan hämtas från kanalen via kanalegenskapen IContextManagerGetContext genom att anropa metoden. Kanalen kan också förinitieras med specifik kontext innan den öppnas genom att anropa metoden på kanalegenskapen SetContext. När kanalen har initierats med kontext kan den inte återställas.

Följande är en lista över invarianter i det här läget:

  • Alla försök att återställa kontexten med SetContext efter att kanalen har öppnats kommer att generera en InvalidOperationException.

  • Alla försök att skicka kontext med hjälp av ContextMessageProperty i ett utgående meddelande genererar en InvalidOperationException.

  • Om ett meddelande tas emot från servern med en specifik kontext, när kanalen redan har initierats med en specifik kontext, resulterar detta i en ProtocolException.

    Anmärkning

    Det är lämpligt att ta emot en inledande kontext från servern endast om kanalen öppnas utan någon uttrycklig kontextuppsättning.

  • Detta ContextMessageProperty i inkommande meddelande är alltid null.

Läge 2: Programkontexthantering

Det här är läget när Enabled är inställt på false. I det här läget hanterar kontextkanalen inte kontexten. Det är programmets ansvar att hämta, hantera och tillämpa kontext med hjälp av ContextMessageProperty. Alla försök att anropa GetContext eller SetContext resulterar i en InvalidOperationException.

Oavsett vilket läge som väljs stöder klientkanalfabriken mönster för meddelandeutbyte som IRequestChannel, IRequestSessionChannel och IDuplexSessionChannel.

I tjänsten ansvarar en instans av kanalen för att konvertera kontexten som tillhandahålls av klienten på inkommande meddelanden till ContextMessageProperty. Meddelandeegenskapen kan sedan nås av programlagret eller andra kanaler längre upp i anropsstacken. Tjänstkanalerna tillåter också att programskiktet anger ett nytt kontextvärde som ska spridas tillbaka till klienten genom att koppla ett ContextMessageProperty till svarsmeddelandet. Den här egenskapen konverteras till SOAP-huvudet eller HTTP-cookien som innehåller kontexten, vilket beror på bindningens konfiguration. Lyssnaren för tjänstkanalen stöder IReplyChannel, IReplySessionChannel och IReplySessionChannel mönster för meddelandeutbyte.

Protokollet för kontextutbyte introducerar en ny wsc:Context SOAP-rubrik som representerar kontextinformationen när HTTP-cookies inte används för att sprida kontexten. Schemat för kontextrubriken tillåter valfritt antal underordnade element, var och en med en strängnyckel och stränginnehåll. Följande är ett exempel på en kontextrubrik.

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

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

</Context>

När du är i HttpCookie läget, anges cookies med hjälp av SetCookie rubriken. Cookienamnet är WscContext. Värdet för cookien är Base64-kodningen för wsc:Context rubriken. Det här värdet omges av citattecken.

Värdet på kontexten måste skyddas från ändringar under överföringen av samma anledning som WS-Addressing-rubriker skyddas – rubriken används för att avgöra var begäran ska skickas i tjänsten. wsc:Context-huvudet måste därför vara digitalt signerat eller signerat och krypterat antingen på SOAP-nivå eller transportnivå när bindningen erbjuder kapacitet för meddelandeskydd. När HTTP-cookies används för att sprida kontext bör de skyddas med hjälp av transportsäkerhet.

Tjänstslutpunkter som kräver stöd för kontextutbytesprotokollet kan göra det explicit i den publicerade principen. Två nya principkontroller har införts för att representera kravet på att klienten ska stödja protokollet för kontextutbyte på SOAP-nivå eller för att aktivera STÖD för HTTP-cookie. Genereringen av dessa påståenden i tjänstens policy styrs av värdet för ContextExchangeMechanism-egenskapen enligt följande:

  • För ContextSoapHeadergenereras följande försäkran:

    <IncludeContext
    xmlns="http://schemas.microsoft.com/ws/2006/05/context"  
    protectionLevel="Sign" />  
    
  • För HttpCookiegenereras följande försäkran:

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

Se även