Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
SOA Design Patterns: State Messaging
W jaki sposób usługa bezstanowa może brać udział w interakcjach wymagających przechowywania stanu?

Rozwiązaniem (jednym z wielu możliwych) jest przesyłanie informacji o stanie w wymienianych przez usługę komunikatach. Tradycyjne rozwiązanie problemu polega na przechowywaniu stanu w instancji usługi. Jego słabą stroną jest blokowanie zasobów serwera (głównie pamięci) przez tymczasowo nieaktywne instancji usługi czekające na dalszy ciąg interakcji.

Jeśli nie możemy zrezygnować z przechowywania stanu (usługi nie da się koncepcyjnie "przemodelować" na bezstanową) warto rozważyć State Messaging. Jest to rozwiązanie problemu stanowości wymagające najmniejszego nakładu pracy (pozostałe to: State Repository, Stateful Services oraz Service Grid). Podejście to zakłada, że stan usługi jest dołączany do metadanych wymienianych komunikatów (zwykle są to nagłówki SOAP).

State Messaging może być zrealizowany w dwóch wariantach:
  • Tylko po stronie serwera. Klient usługi utrzymuje swój stan w pamięci. Serwer wykorzystuje komunikat odpowiedzi do przesłania do klienta swojego stanu. W następnym odwołaniu do usługi klient dołącza dane zwrócone przez nią poprzednio jako stan. Wariant ten może być elegancko zrealizowany za pomocą standardu WS-Addressing i koncepcji Endpoint Reference (EPR). EPR jest obiektem identyfikującym jednoznacznie punkt dostępowy do usługi i oprócz tradycyjnie rozumianego URL usługi pozwala na przekazania dowolnej liczby dodatkowych parametrów (reference parameters), które mogą zawierać stan usłgi.
  • Po stronie klienta i serwera. Ta technika zakłada, że także klient swój stan przesyła w komunikatach (zamiast przechowywać w pamięci). W tym wypadku nie można stosować WS-Addressing ze względu na jednokierunkową naturę EPR. Należy skorzystać ze specjalnie przygotowanych własnych nagłówków SOAP.

So far, so good. Czas na konsekwencje zastosowania. Istnieją trzy kwestie, które warto rozważyć zanim zastosujemy State Messaging:
  • Zagubienie jednego komunikatu powoduje utratę stanu całej dotychczasowej konwersacji i sprawia, że interakcję musimy rozpocząć od nowa.
  • Przesyłanie przez usługę swojego stanu do klienta naraża nas na niebezpieczeństwo ataków polegających na zmianie informacji o stanie przez złośliwego klienta. Należy rozważyć konieczność podpisywania i/lub szyfrowania tej informacji.
  • Przepustowość sieci musi być wystarczająca, aby przekazywać nie tylko same dane biznesowe, ale także dodatkowy ładunek w postaci informacji o stanie.

Opublikowane 7 lipca 2009 08:38 przez simon

Filed under: ,

Komentarze:

# Simon says... : SOA Design Patterns: State Messaging @ 7 lipca 2009 13:13

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

Komentarze anonimowe wyłączone