Scenariusze synchroniczne przy użyciu protokołu HTTP, TCP lub Named-Pipe

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 potoku nazwanego. Aby uzyskać więcej informacji na temat żądań wielowątkowych, zobacz Scenariusze asynchroniczne używające protokołu HTTP, TCP lub Named-Pipe.

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 tworzony 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żdej aktywności, do której następuje przeniesienie, aktywność środowiskowa jest zawieszona do momentu, gdy zostanie przywrócona, czyli do chwili wykonania kodu ServiceModel.

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

Aktywność środowiskowa jest przenoszona do aktywności "ProcessAction" (D). W ramach tego działania jest wysyłany komunikat żądania i odbierany jest komunikat odpowiedzi. Działanie kończy się, gdy kontrola wraca 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

Aktywność zamykająca klienta (I) jest tworzona na podstawie aktywności otoczenia. Jest to identyczne z nowym i otwartym.

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 poprzez otwarcie ServiceHost dla każdego odbiornika. Działanie odbiornika czeka na odbieranie i przetwarzanie danych.

Odbieranie danych za pomocą przewodu

Gdy dane docierają do sieci, zostanie utworzona akcja "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 zostanie ustawiony na działanie ProcessAction; w przeciwnym razie zostanie utworzony nowy identyfikator.

Działanie ProcessAction (S) jest tworzone i przekazywane do przetwarzania, gdy połączenie jest obsługiwane. 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>, A jest symbolem skrótu, który opisuje działanie w poprzednim tekście i w tabeli 3. Name to skrócona nazwa działania.

Jeśli propagateActivity=true akcja procesu zarówno na kliencie, jak i usłudze ma ten sam identyfikator aktywności.

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=true, identyfikator aktywności komunikatu żądania zostanie dodany do komunikatu o błędzie SOAP.

Synchroniczne One-Way 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.

Synchroniczne One-Way 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 "Synchroniczne One-Way bez błędów". Nie należy używać scenariusza One-Way, jeśli chcesz otrzymać komunikat o błędzie.

Mieszkanie dwupoziomowe

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.