Dela via

WCF-tjänster och ASP.NET

  • Artikel

I det här avsnittet beskrivs värdtjänsten för WCF-tjänster (Windows Communication Foundation) sida vid sida med ASP.NET och värd för dem i ASP.NET kompatibilitetsläge.

Värd för WCF sida vid sida med ASP.NET

WCF-tjänster som finns i Internet Information Services (IIS) kan finnas med . ASPX-sidor och ASMX-webbtjänster i en enda gemensam programdomän. ASP.NET tillhandahåller vanliga infrastrukturtjänster som AppDomain-hantering och dynamisk kompilering för både WCF och ASP.NET HTTP-körning. Standardkonfigurationen för WCF är sida vid sida med ASP.NET.

Screenshot showing WCF Services and ASP .NET: sharing state.

den ASP.NET HTTP-körningen hanterar ASP.NET begäranden men deltar inte i bearbetningen av begäranden som är avsedda för WCF-tjänster, även om dessa tjänster finns i samma AppDomain som det ASP.NET innehållet. I stället fångar WCF-tjänstmodellen upp meddelanden som är adresserade till WCF-tjänster och dirigerar dem genom WCF-transport-/kanalstacken.

Resultatet av modellen sida vid sida är följande:

  • ASP.NET- och WCF-tjänster kan dela AppDomain-tillstånd. Eftersom de två ramverken kan samexistera i samma AppDomain kan WCF också dela AppDomain-tillstånd med ASP.NET (inklusive statiska variabler, händelser och så vidare).

  • WCF-tjänster fungerar konsekvent, oberoende av värdmiljö och transport. Den ASP.NET HTTP-körningen är avsiktligt kopplad till IIS/ASP.NET-värdmiljön och HTTP-kommunikationen. Omvänt är WCF utformat för att fungera konsekvent i värdmiljöer (WCF beter sig konsekvent både inom och utanför IIS) och över transport (en tjänst som finns i IIS 7.0 och senare har konsekvent beteende över alla slutpunkter som exponeras, även om vissa av dessa slutpunkter använder andra protokoll än HTTP).

  • I en AppDomain gäller funktioner som implementeras av HTTP-körningen för ASP.NET innehåll men inte för WCF. Många HTTP-specifika funktioner i ASP.NET programplattform gäller inte för WCF-tjänster som finns i en AppDomain som innehåller ASP.NET innehåll. Exempel på dessa funktioner är följande:

    • HttpContext: Current är alltid null när den nås från en WCF-tjänst. Använd RequestContext i stället.

    • Filbaserad auktorisering: WCF-säkerhetsmodellen tillåter inte åtkomstkontrollistan (ACL) som tillämpas på .svc-filen för tjänsten när du bestämmer om en tjänstbegäran är auktoriserad.

    • Konfigurationsbaserad URL-auktorisering: På samma sätt följer WCF-säkerhetsmodellen inte några URL-baserade auktoriseringsregler som anges i System.Webs auktoriseringskonfigurationselement<>. De här inställningarna ignoreras för WCF-begäranden om en tjänst finns i ett URL-utrymme som skyddas av ASP.NET:s URL-auktoriseringsregler.

    • Utökningsbarhet för HttpModule: WCF-värdinfrastrukturen fångar upp WCF-begäranden när PostAuthenticateRequest händelsen utlöses och returnerar inte bearbetning till den ASP.NET HTTP-pipelinen. Moduler som kodas för att avlyssna begäranden i senare skeden av pipelinen fångar inte upp WCF-begäranden.

    • ASP.NET personifiering: Som standard körs WCF-begäranden alltid som IIS-processidentitet, även om ASP.NET är inställt på att aktivera personifiering med hjälp av system.web-identitetspersonifiering <="true"/> konfigurationsalternativ.

Dessa begränsningar gäller endast för WCF-tjänster som finns i IIS-programmet. Beteendet för ASP.NET innehåll påverkas inte av förekomsten av WCF.

WCF-program som kräver funktioner som traditionellt tillhandahålls av HTTP-pipelinen bör överväga att använda WCF-motsvarigheterna, som är värd- och transportoberoende:

Du kan också överväga att köra dina tjänster i WCF:s ASP.NET kompatibilitetsläge.

Värd för WCF-tjänster i ASP.NET kompatibilitetsläge

Även om WCF-modellen är utformad för att fungera konsekvent i värdmiljöer och transporter, finns det ofta scenarier där ett program inte kräver den här graden av flexibilitet. WCF:s ASP.NET kompatibilitetsläge är lämpligt för scenarier som inte kräver möjligheten att vara värd utanför IIS eller kommunicera via andra protokoll än HTTP, men som använder alla funktioner i ASP.NET webbprogramplattform.

Till skillnad från standardkonfigurationen sida vid sida, där WCF-värdinfrastrukturen fångar upp WCF-meddelanden och dirigerar dem ut ur HTTP-pipelinen, deltar WCF-tjänster som körs i ASP.NET kompatibilitetsläge fullt ut i livscykeln för ASP.NET HTTP-begäran. I kompatibilitetsläge använder WCF-tjänster HTTP-pipelinen via en IHttpHandler implementering, på samma sätt som begäranden för ASPX-sidor och ASMX-webbtjänster hanteras. Därför fungerar WCF identiskt med ASMX med avseende på följande ASP.NET funktioner:

  • HttpContext: WCF-tjänster som körs i ASP.NET kompatibilitetsläge kan komma åt Current och dess associerade tillstånd.

  • Filbaserad auktorisering: WCF-tjänster som körs i ASP.NET kompatibilitetsläge kan vara säkra genom att koppla filsystemåtkomstkontrollistor (ACL: er) till tjänstens .svc-fil.

  • Konfigurerbar URL-auktorisering: ASP.NET:s URL-auktoriseringsregler tillämpas för WCF-begäranden när WCF-tjänsten körs i ASP.NET kompatibilitetsläge.

  • HttpModuleCollection utökningsbarhet: Eftersom WCF-tjänster som körs i ASP.NET kompatibilitetsläge deltar fullt ut i ASP.NET HTTP-begärandelivscykel kan alla HTTP-moduler som konfigurerats i HTTP-pipelinen fungera på WCF-begäranden både före och efter tjänstanrop.

  • ASP.NET Personifiering: WCF-tjänster körs med den aktuella identiteten för den ASP.NET personifierade tråden, vilket kan skilja sig från IIS-processidentiteten om ASP.NET personifiering har aktiverats för programmet. Om både ASP.NET personifiering och WCF-personifiering är aktiverade för en viss tjänståtgärd körs tjänstimplementeringen i slutändan med hjälp av den identitet som hämtas från WCF.

WCF:s ASP.NET kompatibilitetsläge aktiveras på programnivå via följande konfiguration (finns i programmets Web.config-fil):

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Det här värdet är standardvärdet false om det inte anges. Värdet false för anger att alla WCF-tjänster som körs i programmet inte körs i ASP.NET kompatibilitetsläge.

Eftersom ASP.NET Kompatibilitetsläge innebär att semantik för bearbetning av begäranden skiljer sig från WCF-standardinställningen kan enskilda tjänstimplementeringar styra om de körs i ett program som ASP.NET kompatibilitetsläge har aktiverats för. Tjänster kan använda för AspNetCompatibilityRequirementsAttribute att ange om de stöder ASP.NET kompatibilitetsläge. Standardvärdet för attributet är Allowed.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class CalculatorService : ICalculatorSession
{//Implement calculator service methods.}

I följande tabell visas hur inställningen för programomfattande kompatibilitetsläge interagerar med den enskilda tjänstens angivna supportnivå:

Inställning för programomfattande kompatibilitetsläge [AspNetCompatibilityRequirementsMode]

Inställning		 Observerat resultat
aspNetCompatibilityEnabled = "true" Required Tjänsten aktiveras.
aspNetCompatibilityEnabled = "true" Allowed Tjänsten aktiveras.
aspNetCompatibilityEnabled = "true" NotAllowed Ett aktiveringsfel uppstår när tjänsten tar emot ett meddelande.
aspNetCompatibilityEnabled = "false" Required Ett aktiveringsfel uppstår när tjänsten tar emot ett meddelande.
aspNetCompatibilityEnabled = "false" Allowed Tjänsten aktiveras.
aspNetCompatibilityEnabled = "false" NotAllowed Tjänsten aktiveras.

Kommentar

Med IIS 7.0 och WAS kan WCF-tjänster kommunicera via andra protokoll än HTTP. WCF-tjänster som körs i program som har aktiverat ASP.NET kompatibilitetsläge tillåts dock inte att exponera icke-HTTP-slutpunkter. En sådan konfiguration genererar ett aktiveringsfel när tjänsten tar emot sitt första meddelande.

Mer information om hur du aktiverar ASP.NET kompatibilitetsläge för WCF-tjänster AspNetCompatibilityRequirementsMode finns i exemplet ASP.NET Kompatibilitet .

Se även