Asynkrona scenarier med HTTP, TCP eller Named-Pipe

Det här avsnittet beskriver aktiviteter och överföringar för olika asynkrona begärande-/svarsscenarier, med flertrådade begäranden med HTTP, TCP eller namngivet pipe.

Asynkron begäran/svar utan fel

I det här avsnittet beskrivs aktiviteter och överföringar för ett asynkront scenario för begäran/svar med flertrådade klienter.

Anroparaktiviteten avslutas när beginCall returnerar och endCall returnerar. Om ett återanrop anropas returneras återanropet.

Den anropade aktiviteten avslutas när beginCall returnerar, endCall returnerar eller när återanropet returneras om den anropades från den aktiviteten.

Asynkron klient utan återanrop

Spridning är aktiverad på båda sidor med HTTP

Om propagateActivity=trueanger ProcessMessage vilken ProcessAction-aktivitet som ska överföras till.

För HTTP-baserade scenarier anropas ReceiveBytes på det första meddelandet som ska skickas och finns under begärans livslängd.

Spridning är inaktiverad på båda sidor med hjälp av HTTP

Om propagateActivity=false på båda sidor anger ProcessMessage inte vilken ProcessAction-aktivitet som ska överföras till. Därför anropas en ny tillfällig ProcessAction-aktivitet med ett nytt ID. När det asynkrona svaret matchas med begäran i ServiceModel-koden kan aktivitets-ID hämtas från den lokala kontexten. Den faktiska ProcessAction-aktiviteten kan överföras till med det ID:t.

För HTTP-baserade scenarier anropas ReceiveBytes på det första meddelandet som ska skickas och finns under begärans livslängd.

En processåtgärdsaktivitet skapas på en asynkron klient när propagateActivity=false den anropar eller anropar, och när svarsmeddelandet inte innehåller ett åtgärdshuvud.

Spridning är aktiverad på båda sidor med hjälp av TCP eller namngivet rör

För ett scenario med namngivet rör eller TCP-baserat anropas ReceiveBytes när klienten öppnas och finns under anslutningens livslängd.

Liknar den första bilden, om propagateActivity=true, Anger ProcessMessage vilken ProcessAction-aktivitet som ska överföras till.

Spridning är inaktiverad på båda sidor med hjälp av TCP eller namngivet rör

För ett scenario med namngivet rör eller TCP-baserat anropas ReceiveBytes när klienten öppnas och finns under anslutningens livslängd.

På samma sätt som den andra bilden anger propagateActivity=false ProcessMessage inte vilken ProcessAction-aktivitet som ska överföras till på båda sidor. Därför anropas en ny tillfällig ProcessAction-aktivitet med ett nytt ID. När det asynkrona svaret matchas med begäran i ServiceModel-koden kan aktivitets-ID hämtas från den lokala kontexten. Den faktiska ProcessAction-aktiviteten kan överföras till med det ID:t.

Asynkron klient med återanrop

Det här scenariot lägger till aktiviteterna G och A för återanropet och endCall, och deras överföringar in/ut.

Det här avsnittet visar endast användning av HTTP med propagateActivity=true. De ytterligare aktiviteterna och överföringarna gäller dock även för de andra fallen (dvs propagateActivity=false. med hjälp av TCP eller Named-Pipe).

Återanropet skapar en ny aktivitet (G) när klienten anropar användarkod för att meddela att resultaten är klara. Användarkod anropar endCall sedan inom återanropet (som visas i bild 5) eller utanför återanropet (bild 6). Eftersom det inte är känt vilken användaraktivitet endCall som anropas från, är den här aktiviteten märkt A’. Det är möjligt att A kan vara identiskt med eller annorlunda än A.

Asynkron server med återanrop

Kanalstacken anropar klienten på Meddelande ta emot: spårningar för den här bearbetningen genereras i själva ProcessRequest-aktiviteten.

Asynkron begäran/svar med fel

Fel i felmeddelandet tas emot under endCall. Annars liknar aktiviteter och överföringar tidigare scenarier.

Asynkron enkelriktad med eller utan fel

Inget svar eller fel returneras till klienten.