Share via


Utforma och implementera tjänster

Det här avsnittet visar hur du definierar och implementerar WCF-kontrakt. 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 (Windows Communication Foundation) 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.

Ö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 anger följande:

  • De åtgärder som ett kontrakt exponerar.

  • 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:

  1. Att inköpsorderkontraktet bestod av CreateOrder och GetOrderStatus åtgärder.

  2. Att åtgärderna har angett indatameddelanden och utdatameddelanden.

  3. De data som dessa meddelanden kan innehålla.

  4. 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 andra program på många plattformar (inklusive andra plattformar än Microsoft) 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 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 och är 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 en tjänst och för att implementera den.

Det resulterande kontraktet som definieras i hanterade typer kan exporteras som metadata – WSDL och XSD – när det behövs av klienter eller andra tjänstimplementerare. Resultatet är en enkel programmeringsmodell som kan beskrivas (med offentliga metadata) för alla klientprogram. Information om underliggande SOAP-meddelanden, transport och säkerhetsrelaterad information och så vidare kan lämnas till WCF, som utför nödvändiga konverteringar till och från tjänstkontraktstypsystemet till XML-typsystemet automatiskt.

Mer information om hur du utformar kontrakt finns i Designa tjänstkontrakt. Mer information om hur du implementerar kontrakt finns i Implementera tjänstkontrakt.

Meddelanden i förväg och i mitten

Det är enkelt att använda hanterade gränssnitt, klasser och metoder för att modellera tjänståtgärder när du används för RPC-metodsignaturer (Remote Procedure Call), där överföring av parametrar till en metod och mottagande av returvärden är den normala formen av begärandefunktioner från ett objekt eller annan typ av kod. Programmerare som använder hanterade språk som Visual Basic och C++ COM kan till exempel använda sina kunskaper om RPC-metoden (oavsett om de använder objekt eller gränssnitt) för att skapa WCF-tjänstkontrakt utan att ha problem med distribuerade objektsystem i RPC-stil. Tjänstorientering ger fördelarna med löst kopplad, meddelandeorienterad programmering samtidigt som RPC-programmeringens enkelhet och förtrogenhet bibehålls.

Många programmerare är mer bekväma med meddelandeorienterade programprogramprogramgränssnitt, till exempel meddelandeköer som Microsoft MSMQ, System.Messaging namnrymderna i .NET Framework eller att skicka ostrukturerad XML i HTTP-begäranden, för att nämna några. Mer information om programmering på meddelandenivå finns i Använda meddelandekontrakt, serviceprogrammering på kanalnivå och samverkan med POX-program.

Förstå kravhierarkin

Ett tjänstkontrakt grupperar åtgärderna. anger mönstret för meddelandeutbyte, 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 inte exakt hur dessa krav uppfylls, bara att de måste vara det. Typen av kryptering eller det sätt på vilket 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 ett 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 tjänsten kräver Windows-integrerad autentisering och finns i Internet Information Services (IIS) måste webbprogrammet där tjänsten finns ha Windows-integrerad autentisering aktiverat och anonym support inaktiverat. Mer information om funktionerna och effekten av de olika programtyperna för tjänstvärdar finns i Värdtjänster.

Se även