Synkrona scenarier med HTTP, TCP eller Named-Pipe

Det här avsnittet beskriver aktiviteter och överföringar för olika synkrona scenarier för begäran/svar, med en enda trådad klient, med HTTP, TCP eller namngivet pipe. Mer information om begäranden med flera trådar finns i Asynkrona scenarier med HTTP, TCP eller Named-Pipe .

Synkron begäran/svar utan fel

I det här avsnittet beskrivs aktiviteter och överföringar för ett giltigt synkront scenario för begäran/svar med en trådad klient.

Klient

Upprätta kommunikation med tjänstslutpunkt

En klient konstrueras och öppnas. För vart och ett av dessa steg överförs den omgivande aktiviteten (A) till aktiviteten "Construct Client" (B) respektive "Open Client" (C). För varje aktivitet som överförs till pausas den omgivande aktiviteten tills det finns en överföring tillbaka, dvs. tills ServiceModel-koden körs.

Göra en begäran till tjänstslutpunkten

Den omgivande aktiviteten överförs till en "ProcessAction"-aktivitet (D). I den här aktiviteten skickas ett begärandemeddelande och ett svarsmeddelande tas emot. Aktiviteten avslutas när kontrollen återgår till användarkod. Eftersom det här är en synkron begäran pausas den omgivande aktiviteten tills kontrollen returneras.

Stänga kommunikationen med tjänstslutpunkten

Klientens nära aktivitet (I) skapas från den omgivande aktiviteten. Detta är identiskt med nytt och öppet.

Server

Konfigurera en tjänstvärd

ServiceHosts nya och öppna aktiviteter (N och O) skapas från den omgivande aktiviteten (M).

En lyssnaraktivitet (P) skapas från att öppna en ServiceHost för varje lyssnare. Lyssnaraktiviteten väntar på att ta emot och bearbeta data.

Ta emot data på tråden

När data kommer till tråden skapas en "ReceiveBytes"-aktivitet om den inte redan finns (Q) för att bearbeta mottagna data. Den här aktiviteten kan återanvändas för flera meddelanden i en anslutning eller kö.

Aktiviteten ReceiveBytes startar en ProcessMessage-aktivitet (R) om den har tillräckligt med data för att skapa ett SOAP-åtgärdsmeddelande.

I aktivitet R bearbetas meddelanderubrikerna och activityID-huvudet verifieras. Om den här rubriken finns är aktivitets-ID:t inställt på ProcessAction-aktiviteten. annars skapas ett nytt ID.

ProcessAction-aktivitet (S) skapas och överförs till när anropet bearbetas. Den här aktiviteten avslutas när all bearbetning som är relaterad till det inkommande meddelandet har slutförts, inklusive körning av användarkod (T) och sändning av svarsmeddelandet om tillämpligt.

Stänga en tjänstvärd

ServiceHosts stängningsaktivitet (Z) skapas från den omgivande aktiviteten.

I <A: name> är A en genvägssymbol som beskriver aktiviteten i föregående text och i tabell 3. Name är ett förkortat namn på aktiviteten.

Om propagateActivity=truehar processåtgärden för både klienten och tjänsten samma aktivitets-ID.

Synkron begäran/svar med fel

Den enda skillnaden med föregående scenario är att ett SOAP-felmeddelande returneras som ett svarsmeddelande. Om propagateActivity=trueläggs aktivitets-ID:t för begärandemeddelandet till i SOAP-felmeddelandet.

Synkron enkelriktad utan fel

Den enda skillnaden med det första scenariot är att inget meddelande returneras till servern. För HTTP-baserade protokoll returneras fortfarande en status (giltig eller ett fel) till klienten. Detta beror på att HTTP är det enda protokollet med en semantik för begäran-svar som är en del av WCF-protokollstacken. Eftersom TCP-bearbetningen är dold från WCF skickas ingen bekräftelse till klienten.

Synkron enkelriktad med fel

Om ett fel uppstår när meddelandet bearbetas (Q eller senare) returneras inget meddelande till klienten. Detta är identiskt med scenariot "Synkron enkelriktad utan fel". Du bör inte använda ett enkelriktad scenario om du vill få ett felmeddelande.

Duplex

Skillnaden med de tidigare scenarierna är att klienten fungerar som en tjänst, där den skapar aktiviteterna ReceiveBytes och ProcessMessage, liknande de asynkrona scenarierna.