Kontrakt
Det här avsnittet visar hur du definierar och implementerar WCF-kontrakt (Windows Communication Foundation). Ett tjänstkontrakt anger vad en slutpunkt kommunicerar med omvärlden. På en mer konkret nivå är det ett uttalande om en uppsättning specifika meddelanden ordnade i grundläggande mönster för meddelandeutbyte (Parlamentsledamöter), till exempel begäran/svar, enkelriktat och duplex. Om ett tjänstkontrakt är en logiskt relaterad uppsättning meddelandeutbyten är en tjänståtgärd ett enda meddelandeutbyte. En åtgärd måste till exempel Hello uppenbarligen acceptera ett meddelande (så att anroparen kan meddela hälsningen) och kanske eller inte returnerar ett meddelande (beroende på åtgärdens artighet).
Mer information om kontrakt och andra grundläggande WCF-begrepp finns i Grundläggande Begrepp för Windows Communication Foundation. Det här avsnittet fokuserar på att förstå tjänstkontrakt. Mer information om hur du skapar klienter som använder tjänstkontrakt för att ansluta till tjänster finns i WCF-klientöversikt. Mer information om klientkanaler, klientarkitektur och andra klientproblem finns i Klienter.
Översikt
Det här avsnittet innehåller en övergripande konceptuell orientering för att utforma och implementera WCF-tjänster. Underavsnitt ger mer detaljerad information om detaljerna i design och implementering. Innan du utformar och implementerar ditt WCF-program rekommenderar vi att du:
Förstå vad ett tjänstkontrakt är, hur det fungerar och hur du skapar ett.
Förstå att kontrakt anger minimikrav som körningskonfigurationen eller värdmiljön kanske inte stöder.
Tjänstkontrakt
Ett tjänstkontrakt är en instruktion som innehåller information om:
Gruppering av åtgärder i en tjänst.
Signaturen för åtgärderna när det gäller meddelanden som utbyts.
Datatyperna för dessa meddelanden.
Platsen för åtgärderna.
De specifika protokoll och serialiseringsformat som används för att stödja lyckad kommunikation med tjänsten.
Ett inköpsorderkontrakt kan till exempel ha en CreateOrder åtgärd som accepterar indata från orderinformationstyper och returnerar information om lyckade eller misslyckade, inklusive en orderidentifierare. Det kan också ha en GetOrderStatus åtgärd som accepterar en orderidentifierare och returnerar orderstatusinformation. Ett servicekontrakt av den här typen skulle ange:
Att inköpsorderkontraktet bestod av
CreateOrderochGetOrderStatusåtgärder.Att åtgärderna har angett indatameddelanden och utdatameddelanden.
De data som dessa meddelanden kan innehålla.
Kategoriska instruktioner om den kommunikationsinfrastruktur som krävs för att bearbeta meddelandena. Den här informationen omfattar till exempel om och vilka säkerhetsformer som krävs för att upprätta en lyckad kommunikation.
För att förmedla den här typen av information till program på andra plattformar (inklusive icke-Microsoft-plattformar) uttrycks XML-tjänstkontrakt offentligt i XML-standardformat, till exempel WSDL (Web Services Description Language) och XML-schema (XSD). Utvecklare för många plattformar kan använda den här offentliga kontraktsinformationen för att skapa program som kan kommunicera med tjänsten, både för att de förstår språket i specifikationen och eftersom dessa språk är utformade för att möjliggöra interoperation genom att beskriva de offentliga formulär, format och protokoll som tjänsten stöder. Mer information om hur WCF hanterar den här typen av information finns i Metadata.
Kontrakt kan dock uttryckas på många sätt, och även om WSDL och XSD är utmärkta språk för att beskriva tjänster på ett tillgängligt sätt, är de svåra språk att använda direkt – i vilket fall som helst är de bara beskrivningar av en tjänst, inte implementeringar av tjänstkontrakt. Därför använder WCF-program hanterade attribut, gränssnitt och klasser både för att definiera strukturen för och för att implementera en tjänst.
Det resulterande kontraktet som definieras i hanterade typer kan konverteras (kallas även exporterat) som metadata – WSDL och XSD – när det behövs av klienter eller andra tjänstimplementerare, särskilt på andra plattformar. Resultatet är en enkel programmeringsmodell som kan beskrivas med offentliga metadata för alla klientprogram. Informationen om de underliggande SOAP-meddelandena, till exempel transport och säkerhetsrelaterad information, kan lämnas till WCF, som automatiskt utför de nödvändiga konverteringarna till och från tjänstkontraktstypsystemet till XML-typsystemet.
Mer information om hur du utformar kontrakt finns i Designa tjänstkontrakt. Mer information om hur du implementerar kontrakt finns i Implementera tjänstkontrakt.
Dessutom ger WCF också möjlighet att utveckla tjänstkontrakt helt på meddelandenivå. Mer information om hur du utvecklar tjänstkontrakt på meddelandenivå finns i Använda meddelandekontrakt. Mer information om hur du utvecklar tjänster i icke-SOAP XML finns i Samverkan med POX-program.
Förstå kravhierarkin
Ett tjänstkontrakt grupperar åtgärderna. anger den parlamentsledamot, meddelandetyper och datatyper som dessa meddelanden har. och anger kategorier av körningsbeteende som en implementering måste ha för att stödja kontraktet (till exempel kan det kräva att meddelanden krypteras och signeras). Själva tjänstekontraktet anger dock inte exakt hur dessa krav uppfylls, bara att de måste vara det. Vilken typ av kryptering eller hur ett meddelande har registrerats är upp till implementeringen och konfigurationen av en kompatibel tjänst.
Observera hur kontraktet kräver vissa saker i implementeringen av tjänstkontraktet och körningskonfigurationen för att lägga till beteende. Den uppsättning krav som måste uppfyllas för att exponera en tjänst för användning bygger på föregående uppsättning krav. Om ett kontrakt ställer krav på implementeringen kan en implementering kräva ännu fler konfigurationer och bindningar som gör att tjänsten kan köras. Slutligen måste värdprogrammet även ha stöd för alla krav som tjänstkonfigurationen och bindningarna lägger till.
Den här processen med additiva krav är viktig att tänka på när du utformar, implementerar, konfigurerar och är värd för ditt WCF-tjänstprogram (Windows Communication Foundation). Kontraktet kan till exempel ange att det måste ha stöd för en session. I så fall måste du konfigurera bindningen för att stödja det avtalsmässiga kravet, annars fungerar inte tjänstimplementeringen. Eller om din tjänst kräver integrerad Windows-autentisering och finns i Internet Information Services (IIS), måste webbprogrammet där tjänsten finns ha integrerad Windows-autentisering aktiverad och anonym support inaktiverad. Mer information om funktionerna och effekten av de olika programtyperna för tjänstvärdar finns i Värd.