Asynchronní scénáře využívající protokol HTTP, TCP nebo Named-Pipe

Toto téma popisuje aktivity a přenosy pro různé scénáře asynchronních požadavků a odpovědí s vícevláknovými požadavky pomocí protokolu HTTP, TCP nebo pojmenovaného kanálu.

Asynchronní požadavek nebo odpověď bez chyb

Tato část popisuje aktivity a přenosy pro scénář asynchronní žádosti a odpovědi s vícevláknovými klienty.

Aktivita volajícího se ukončí, když se beginCall a endCall vrátí. Pokud je voláno zpětné volání, vrátí se.

Volaná aktivita skončí, když se vrátí beginCall, endCall nebo když se vrátí zpětné volání, pokud bylo zahájeno z této aktivity.

Asynchronní klient bez zpětného volání

Šíření je povoleno na obou stranách pomocí protokolu HTTP.

Pokud propagateActivity=true, ProcessMessage označuje, do které aktivity ProcessAction se má přesměrovat.

V případě scénářů založených na protokolu HTTP se funkce ReceiveBytes vyvolá na první zprávu, která se má odeslat, a existuje po celou dobu života požadavku.

Šíření je na obou stranách zakázáno pomocí protokolu HTTP.

Pokud propagateActivity=false na jedné straně, ProcessMessage neindikuje, do které aktivity ProcessAction se má přenést. Proto se vyvolá nová dočasná aktivita ProcessAction s novým ID. Když se asynchronní odpověď shoduje s požadavkem v kódu ServiceModel, ID aktivity lze načíst z místního kontextu. Skutečnou aktivitu ProcessAction lze přenést s tímto ID.

V případě scénářů založených na protokolu HTTP se funkce ReceiveBytes vyvolá na první zprávu, která se má odeslat, a existuje po celou dobu života požadavku.

Aktivita akce procesu se vytvoří v asynchronním klientovi, když je propagateActivity=false volající nebo volaný a zpráva odpovědi neobsahuje hlavičku Akce.

Šíření je povoleno na obou stranách pomocí protokolu TCP nebo pojmenovaného kanálu.

V případě Named-Pipe nebo scénáře založeného na protokolu TCP se funkce ReceiveBytes vyvolá při otevření klienta a existuje po celou dobu trvání připojení.

Podobně jako na prvním obrázku, pokud je propagateActivity=true správně umístěn, ProcessMessage označuje, do které aktivity ProcessAction se má přenést.

Šíření je na obou stranách zakázáno pomocí protokolu TCP nebo pojmenovaného kanálu.

V případě Named-Pipe nebo scénáře založeného na protokolu TCP se funkce ReceiveBytes vyvolá při otevření klienta a existuje po celou dobu trvání připojení.

Podobně jako na druhém obrázku, pokud propagateActivity=false na kterékoliv straně, ProcessMessage neoznačuje, do které aktivity ProcessAction by se mělo přenést. Proto se vyvolá nová dočasná aktivita ProcessAction s novým ID. Když se asynchronní odpověď shoduje s požadavkem v kódu ServiceModel, ID aktivity lze načíst z místního kontextu. Skutečnou aktivitu ProcessAction lze přenést s tímto ID.

Asynchronní klient se zpětným voláním

Tento scénář přidá aktivity G a A’ pro zpětné volání a endCall, a jejich přenosy dovnitř/ven.

Tato část ukazuje pouze použití HTTP s propagateActivity=true. Další činnosti a přenosy se však vztahují také na ostatní případy (to znamená propagateActivity=false, pomocí TCP nebo Named-Pipe).

Zpětné volání vytvoří novou aktivitu (G), když klient zavolá kód uživatele, aby oznámil, že výsledky jsou připravené. Uživatelský kód pak volá endCall v rámci zpětného volání (jak je znázorněno na obrázku 5) nebo mimo zpětné volání (obrázek 6). Protože není známo, ze které uživatelské aktivity endCall pochází volání, je tato aktivita označena A’. Je možné, že A' může být identický nebo jiný než A.

Asynchronní server s zpětným voláním

Zásobník kanálu volá klienta při události Příjmu zprávy: trasování tohoto procesu se generuje přímo v aktivitě ProcessRequest.

Asynchronní požadavek nebo odpověď s chybami

Chybové zprávy se zobrazují během endCall. V opačném případě se aktivity a přenosy podobají předchozím scénářům.

Asynchronní One-Way s chybami nebo bez chyb

Klientovi se nevrátí žádná odpověď nebo chyba.