Share via


Services ontwerpen en implementeren

In deze sectie wordt beschreven hoe u WCF-contracten definieert en implementeert. Een servicecontract geeft aan wat een eindpunt communiceert met de buitenwereld. Op een concreter niveau is het een verklaring over een reeks specifieke berichten die zijn ingedeeld in basispatronen voor het uitwisselen van berichten (MEP's), zoals aanvraag/antwoord, eenrichtings- en duplexberichten. Als een servicecontract een logisch gerelateerde set berichtenuitwisseling is, is een servicebewerking één berichtuitwisseling. Een Hello bewerking moet bijvoorbeeld duidelijk één bericht accepteren (zodat de beller de begroeting kan aankondigen) en een bericht wel of niet retourneert (afhankelijk van de beleefdheid van de bewerking).

Zie Basisconcepten van Windows Communication Foundation (Fundamental Windows Communication Foundation) voor meer informatie over contracten en andere kernconcepten van Windows Communication Foundation. Dit onderwerp is gericht op het begrijpen van servicecontracten. Zie wcF-clientoverzicht voor meer informatie over het bouwen van clients die servicecontracten gebruiken om verbinding te maken met services.

Overzicht

Dit onderwerp biedt een conceptuele oriëntatie op hoog niveau voor het ontwerpen en implementeren van WCF-services. Subonderwerpen bieden gedetailleerdere informatie over de specifieke kenmerken van het ontwerp en de implementatie. Voordat u uw WCF-toepassing ontwerpt en implementeert, wordt u aangeraden het volgende te doen:

  • Begrijpen wat een servicecontract is, hoe het werkt en hoe u er een kunt maken.

  • Begrijp dat contracten minimale vereisten hebben die runtimeconfiguratie of de hostingomgeving mogelijk niet ondersteunen.

Servicecontracten

Een servicecontract geeft het volgende op:

  • De bewerkingen die een contract beschikbaar maakt.

  • De handtekening van de bewerkingen in termen van berichten die worden uitgewisseld.

  • De gegevenstypen van deze berichten.

  • De locatie van de bewerkingen.

  • De specifieke protocollen en serialisatie-indelingen die worden gebruikt om succesvolle communicatie met de service te ondersteunen.

Een inkoopordercontract kan bijvoorbeeld een CreateOrder bewerking hebben die een invoer van ordergegevenstypen accepteert en geslaagde of mislukte informatie retourneert, inclusief een order-id. Het kan ook een GetOrderStatus bewerking hebben die een order-id accepteert en informatie over de orderstatus retourneert. Een servicecontract van dit type geeft het volgende op:

  1. Dat het inkoopordercontract bestond uit CreateOrder en GetOrderStatus bewerkingen.

  2. Dat de bewerkingen invoerberichten en uitvoerberichten hebben opgegeven.

  3. De gegevens die deze berichten kunnen bevatten.

  4. Categorische instructies over de communicatie-infrastructuur die nodig is om de berichten te verwerken. Deze details omvatten bijvoorbeeld of en welke vormen van beveiliging nodig zijn om een geslaagde communicatie tot stand te brengen.

Om dit soort informatie over te brengen naar andere toepassingen op veel platforms (inclusief niet-Microsoft-platforms), worden XML-servicecontracten openbaar uitgedrukt in standaard XML-indelingen, zoals WSDL (Web Services Description Language ) en XML Schema (XSD). Ontwikkelaars voor veel platforms kunnen deze informatie over openbare contracten gebruiken om toepassingen te maken die kunnen communiceren met de service, zowel omdat ze de taal van de specificatie begrijpen en omdat deze talen zijn ontworpen om interoperation mogelijk te maken door de openbare formulieren, indelingen en protocollen te beschrijven die de service ondersteunt. Zie Metagegevens voor meer informatie over hoe WCF dit soort informatie verwerkt.

Contracten kunnen op veel manieren worden uitgedrukt en hoewel WSDL en XSD uitstekende talen zijn om services op een toegankelijke manier te beschrijven, zijn ze moeilijk te gebruiken talen en zijn ze slechts beschrijvingen van een service, geen implementaties van servicecontracten. WCF-toepassingen maken daarom gebruik van beheerde kenmerken, interfaces en klassen om de structuur van een service te definiëren en deze te implementeren.

Het resulterende contract dat is gedefinieerd in beheerde typen, kan worden geëxporteerd als metagegevens (WSDL en XSD), indien nodig door clients of andere service-implementeerfuncties. Het resultaat is een eenvoudig programmeermodel dat kan worden beschreven (met behulp van openbare metagegevens) voor elke clienttoepassing. De details van de onderliggende SOAP-berichten, de transport- en beveiligingsgerelateerde informatie, enzovoort, kunnen worden overgelaten aan WCF, waarmee de benodigde conversies van en naar het servicecontracttypesysteem automatisch naar het XML-typesysteem worden uitgevoerd.

Zie Servicecontracten ontwerpen voor meer informatie over het ontwerpen van contracten. Zie Servicecontracten implementeren voor meer informatie over het implementeren van contracten.

Berichten vóór en midden

Het gebruik van beheerde interfaces, klassen en methoden voor het modelleren van servicebewerkingen is eenvoudig wanneer u wordt gebruikt voor het aanroepen van externe procedures (RPC)-methodehandtekeningen, waarbij parameters worden doorgegeven aan een methode en het ontvangen van retourwaarden de normale vorm is van het aanvragen van functionaliteit van een object of een ander type code. Programmeurs die beheerde talen zoals Visual Basic en C++ COM gebruiken, kunnen bijvoorbeeld hun kennis van de RPC-methode (of ze nu objecten of interfaces gebruiken) toepassen op het maken van WCF-servicecontracten zonder dat ze de problemen ondervinden die inherent zijn aan gedistribueerde objectsystemen in RPC-stijl. Servicestand biedt de voordelen van losjes gekoppelde, berichtgeoriënteerde programmering en behoudt tegelijkertijd het gemak en de bekendheid van de RPC-programmeerervaring.

Veel programmeurs zijn vertrouwder met berichtgeoriënteerde toepassingsprogrammeringsinterfaces, zoals berichtenwachtrijen zoals Microsoft MSMQ, de System.Messaging naamruimten in .NET Framework of het verzenden van ongestructureerde XML in HTTP-aanvragen, om er een paar te noemen. Zie Message Contracts, Programmeren op servicekanaalniveau en interoperabiliteit met POX-toepassingen voor meer informatie over programmeren op berichtniveau.

Inzicht in de hiërarchie van vereisten

Een servicecontract groept de bewerkingen; geeft het patroon voor de uitwisseling van berichten, berichttypen en gegevenstypen op die berichten; en geeft categorieën van runtimegedrag aan die een implementatie moet ondersteunen van het contract (het kan bijvoorbeeld vereisen dat berichten worden versleuteld en ondertekend). Het servicecontract zelf geeft niet precies aan hoe aan deze vereisten wordt voldaan, alleen dat ze moeten zijn. Het type versleuteling of de manier waarop een bericht wordt geregistreerd, is ingesteld op de implementatie en configuratie van een compatibele service.

Let op de manier waarop het contract bepaalde dingen van de implementatie van het servicecontract en de runtimeconfiguratie vereist om gedrag toe te voegen. Aan de set vereisten waaraan moet worden voldaan om een service beschikbaar te maken voor gebruik, is gebaseerd op de voorgaande set vereisten. Als een contract vereisten voor de implementatie maakt, kan een implementatie nog meer configuraties en bindingen vereisen waarmee de service kan worden uitgevoerd. Ten slotte moet de hosttoepassing ook eventuele vereisten ondersteunen die door de serviceconfiguratie en bindingen worden toegevoegd.

Dit proces voor additieve vereisten is belangrijk om in gedachten te houden bij het ontwerpen, implementeren, configureren en hosten van een WCF-servicetoepassing (Windows Communication Foundation). Het contract kan bijvoorbeeld opgeven dat het een sessie moet ondersteunen. Zo ja, dan moet u de binding configureren ter ondersteuning van die contractuele vereiste, anders werkt de service-implementatie niet. Of als voor uw service geïntegreerde Windows-verificatie is vereist en deze wordt gehost in Internet Information Services (IIS), moet voor de webtoepassing waarin de service zich bevindt geïntegreerde Windows-verificatie zijn ingeschakeld en anonieme ondersteuning is uitgeschakeld. Zie Hostingservices voor meer informatie over de functies en impact van de verschillende typen servicehosttoepassingen.

Zie ook