Synchrone scenario's met HTTP, TCP of Named-Pipe

In dit onderwerp worden de activiteiten en overdrachten beschreven voor verschillende synchrone aanvraag-/antwoordscenario's, met een client met één thread, met behulp van HTTP, TCP of benoemde pipe. Zie Asynchrone scenario's met HTTP, TCP of Named-Pipe voor meer informatie over aanvragen met meerdere threads.

Synchrone aanvraag/antwoord zonder fouten

In deze sectie worden de activiteiten en overdrachten beschreven voor een geldig synchrone aanvraag/antwoordscenario, met één threaded-client.

Klant

Communicatie met service-eindpunt tot stand brengen

Er wordt een client samengesteld en geopend. Voor elk van deze stappen wordt de omgevingsactiviteit (A) overgebracht naar respectievelijk een "Construct Client" (B) en "Open Client" (C). Voor elke activiteit waarnaar wordt overgedragen, wordt de omgevingsactiviteit opgeschort totdat er een overdracht is, dat wil gezegd, totdat ServiceModel-code wordt uitgevoerd.

Een aanvraag indienen bij service-eindpunt

De omgevingsactiviteit wordt overgebracht naar een 'ProcessAction'-activiteit (D). Binnen deze activiteit wordt een aanvraagbericht verzonden en wordt er een antwoordbericht ontvangen. De activiteit eindigt wanneer het besturingselement terugkeert naar de gebruikerscode. Omdat dit een synchrone aanvraag is, wordt de omgevingsactiviteit opgeschort totdat het besturingselement terugkeert.

Communicatie sluiten met service-eindpunt

De close-activiteit (I) van de client wordt gemaakt op basis van de omgevingsactiviteit. Dit is identiek aan nieuw en open.

Server

Een servicehost instellen

De nieuwe en open activiteiten van ServiceHost (N en O) worden gemaakt op basis van de omgevingsactiviteit (M).

Er wordt een listeneractiviteit (P) gemaakt op basis van het openen van een ServiceHost voor elke listener. De listeneractiviteit wacht op het ontvangen en verwerken van gegevens.

Gegevens ontvangen op de kabel

Wanneer gegevens binnenkomen op de kabel, wordt er een 'ReceiveBytes'-activiteit gemaakt als deze nog niet bestaat (Q) om de ontvangen gegevens te verwerken. Deze activiteit kan opnieuw worden gebruikt voor meerdere berichten binnen een verbinding of wachtrij.

Met de activiteit ReceiveBytes wordt een ProcessMessage-activiteit (R) gestart als er voldoende gegevens zijn om een SOAP-actiebericht te vormen.

In activiteit R worden de berichtkoppen verwerkt en wordt de activityID-header geverifieerd. Als deze header aanwezig is, wordt de activiteits-id ingesteld op de ProcessAction-activiteit; anders wordt er een nieuwe id gemaakt.

ProcessAction-activiteit (S) wordt gemaakt en overgebracht naar, wanneer de aanroep wordt verwerkt. Deze activiteit eindigt wanneer alle verwerking met betrekking tot het binnenkomende bericht is voltooid, inclusief het uitvoeren van gebruikerscode (T) en het verzenden van het antwoordbericht, indien van toepassing.

Een servicehost sluiten

De close-activiteit van ServiceHost (Z) wordt gemaakt op basis van de omgevingsactiviteit.

In <A: naam> is A een snelkoppelingsymbool waarmee de activiteit in de vorige tekst en in tabel 3 wordt beschreven. Name is een verkorte naam van de activiteit.

Als propagateActivity=trueprocesactie voor zowel de client als de service dezelfde activiteits-id heeft.

Synchrone aanvraag/antwoord met fouten

Het enige verschil met het vorige scenario is dat een SOAP-foutbericht wordt geretourneerd als antwoordbericht. Als propagateActivity=truede activiteits-id van het aanvraagbericht wordt toegevoegd aan het SOAP-foutbericht.

Synchrone eenrichting zonder fouten

Het enige verschil met het eerste scenario is dat er geen bericht naar de server wordt geretourneerd. Voor protocollen op basis van HTTP wordt nog steeds een status (geldig of fout) geretourneerd naar de client. Dit komt doordat HTTP het enige protocol is met een semantiek voor aanvraagantwoorden die deel uitmaakt van de WCF-protocolstack. Omdat TCP-verwerking is verborgen voor WCF, wordt er geen bevestiging naar de client verzonden.

Synchrone eenrichting met fouten

Als er een fout optreedt tijdens het verwerken van het bericht (Q of hoger), wordt er geen melding geretourneerd naar de client. Dit is identiek aan het scenario 'Synchrone eenrichting zonder fouten'. Gebruik geen eenrichtingsscenario als u een foutbericht wilt ontvangen.

Duplex

Het verschil met de vorige scenario's is dat de client fungeert als een service, waarin de ReceiveBytes- en ProcessMessage-activiteiten worden gemaakt, vergelijkbaar met de Asynchrone scenario's.