Scenariusze synchroniczne z zastosowaniem protokołu HTTP lub TCP albo potoku nazwanego

W tym temacie opisano działania i transfery dla różnych scenariuszy synchronicznych żądań/odpowiedzi z klientem jednowątkowym przy użyciu protokołu HTTP, TCP lub nazwanego potoku. Aby uzyskać więcej informacji na temat żądań wielowątkowych, zobacz Scenariusze asynchroniczne używające protokołu HTTP, TCP lub Nazwanego potoku .

Synchroniczne żądanie/odpowiedź bez błędów

W tej sekcji opisano działania i transfery dla prawidłowego synchronicznego scenariusza żądania/odpowiedzi z klientem jednowątkowym.

Klient

Ustanawianie komunikacji z punktem końcowym usługi

Klient jest konstruowany i otwierany. Dla każdego z tych kroków działanie otoczenia (A) jest przenoszone do działania "Konstruuj klienta" (B) i "Otwórz klienta" (C) odpowiednio. Dla każdego przenoszonego działania otoczenia jest zawieszone do momentu ponownego przeniesienia, czyli do momentu wykonania kodu ServiceModel.

Wysyłanie żądania do punktu końcowego usługi

Działanie otoczenia jest przenoszone do działania "ProcessAction" (D). W ramach tego działania jest wysyłany komunikat żądania i odbierany jest komunikat odpowiedzi. Działanie kończy się po powrocie kontrolki do kodu użytkownika. Ponieważ jest to żądanie synchroniczne, działanie otoczenia zawiesza się do momentu zwrócenia kontrolki.

Zamykanie komunikacji z punktem końcowym usługi

Działanie zamknięcia klienta (I) jest tworzone na podstawie działania otoczenia. Jest to identyczne z nowymi i otwartymi.

Serwer

Konfigurowanie hosta usługi

Nowe i otwarte działania serviceHost (N i O) są tworzone na podstawie działania otoczenia (M).

Działanie odbiornika (P) jest tworzone na podstawie otwierania elementu ServiceHost dla każdego odbiornika. Działanie odbiornika czeka na odbieranie i przetwarzanie danych.

Odbieranie danych za pomocą przewodu

Gdy dane docierają do przewodu, zostanie utworzone działanie "ReceiveBytes", jeśli jeszcze nie istnieje (Q) w celu przetworzenia odebranych danych. To działanie można użyć ponownie dla wielu komunikatów w ramach połączenia lub kolejki.

Działanie ReceiveBytes uruchamia działanie ProcessMessage (R), jeśli ma wystarczającą ilość danych, aby utworzyć komunikat akcji PROTOKOŁU SOAP.

W działaniu R nagłówki komunikatów są przetwarzane, a nagłówek activityID jest weryfikowany. Jeśli ten nagłówek jest obecny, identyfikator działania jest ustawiony na działanie ProcessAction; w przeciwnym razie zostanie utworzony nowy identyfikator.

Działanie ProcessAction (S) jest tworzone i przenoszone do, gdy jest przetwarzane wywołanie. To działanie kończy się po zakończeniu całego przetwarzania związanego z komunikatem przychodzącym, w tym wykonywania kodu użytkownika (T) i wysyłania komunikatu odpowiedzi, jeśli ma to zastosowanie.

Zamykanie hosta usługi

Działanie zamknięcia hosta ServiceHost (Z) jest tworzone na podstawie działania otoczenia.

W <A: nazwa> to symbol skrótu opisujący A działanie w poprzednim tekście i w tabeli 3. Name to skrócona nazwa działania.

Jeśli propagateActivity=trueakcja procesu zarówno na kliencie, jak i usłudze ma ten sam identyfikator działania.

Synchroniczne żądanie/odpowiedź z błędami

Jedyną różnicą w poprzednim scenariuszu jest to, że komunikat o błędzie protokołu SOAP jest zwracany jako komunikat odpowiedzi. Jeśli propagateActivity=trueidentyfikator działania komunikatu żądania zostanie dodany do komunikatu o błędzie protokołu SOAP.

Synchroniczne jednokierunkowe bez błędów

Jedyną różnicą w pierwszym scenariuszu jest to, że żaden komunikat nie jest zwracany do serwera. W przypadku protokołów opartych na protokole HTTP stan (prawidłowy lub błąd) jest nadal zwracany do klienta. Dzieje się tak, ponieważ protokół HTTP jest jedynym protokołem z semantykami żądań odpowiedzi, która jest częścią stosu protokołu WCF. Ponieważ przetwarzanie TCP jest ukryte w programie WCF, żadne potwierdzenie nie jest wysyłane do klienta.

Synchroniczny jednokierunkowy z błędami

Jeśli podczas przetwarzania komunikatu (Q lub beyond) wystąpi błąd, żadne powiadomienie nie zostanie zwrócone klientowi. Jest to identyczne ze scenariuszem "Synchronous One-Way without Errors" (Synchroniczne jednokierunkowe bez błędów). Nie należy używać scenariusza jednokierunkowego, jeśli chcesz otrzymać komunikat o błędzie.

Dupleks

Różnica w poprzednich scenariuszach polega na tym, że klient działa jako usługa, w której tworzy działania ReceiveBytes i ProcessMessage, podobnie jak w scenariuszach asynchronicznych.