Posts tagged SOA
SOA Design Patterns: Service Grid
Jul 7th
W jaki sposób infrastruktura przechowująca stan usług może być skalowana i zabezpieczona przed awarią?
Odpowiedzią na to pytania jest wzorzec Service Grid. Jego nazwa może być nieco myląca. Nie ma on bowiem nic wspólnego z gridami oraz raczej niewiele z usługami w klasycznym pojęciu SOA. Service Grid jest nazwą dla podejścia, w którym wiele instancji infrastruktury przechowującej stan usług jest równolegle aktywnych (zwykle na wilu fizycznych maszynach). Instancje te współdzielą między sobą informacje do nich przekazywane w ten sposób, że każda dowolna porcja danych jest przechowywana w wielu instancjach jednocześnie. Klient (usługa chcąca zapisać lub odczytać swój stan) odwołuje się do całości gridu za pomocą jednego (dowolnego) z węzłów. W przypadku jego awarii, może one odwołać się do któregokolwiek innego węzła.
Wzorzec ten jest szczególnie efektywny, jeśli zostanie wykorzystany jako część wspólnej dla wielu domen warstwy Utility (wzorzec Cross-Domain Utility Layer), ponieważ na bardzo duży potencjał skalowania poziomego.
Ponieważ dane są przechowywane w pamięci operacyjnej, a nie (jak w wypadku State Repository) na dysku, Service Grid oferuje stosunkowo dużą wydajność. Z drugiej strony, wadą tego wzorca jest zwiększony stopień skomplikowania całości architektury oraz potencjalnie wyższy koszt (z uwagi na konieczność zakupu sprzętu oraz licencji na oprogramowanie).
Jeśli chodzi o informacje praktyczne, to gotową do wykorzystania realizacją wzorca jest Microsoft Velocity. Erl nie podaje w swojej książce konkretnego przykładu wykorzystania podejścia Service Grid. Z pomocą jednak przychodzi, jak zwykle niezawodny Udi Dahan. W sekcji “Long-Running Processes” pokazuje na przykładzie przetwarzania “po kawałku” bardzo dużych komunikatów, w jaki sposób może się przydać State Repository.
SOA Design Patterns: State Messaging
Jul 7th
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.
SOA Design Patterns: Utility Abstraction
Jul 6th
Jest to wzorzec z grupy porządkujących logiczny warstwy inwentarza (?) [inventory] usług. Pozostałe dwa z tej grupy to Entity Abstraction i Process Abstraction.
Wszystkie trzy wzorce pomagają zidentyfikować różne grupy odpowiedzialności w “kandydatach na usługi”. Skutkuje to wydzieleniem współnych zakresów odpowiedzialności do nowych usług lub łączeniem usług odpowiadających za ten sam aspekt rozwiązania.
Utility Abstraction zajmuje się konkretnie funkcjonalnością wykorzystywaną we wszystkich fragmentach rozwiązania. Po angielsku ładnie mówi się na to “cross-cutting concerns”. Nie znam dobrego polskiego tłumaczenia. Przykładem usług z tej grupy może być np. logowanie zdarzeń.
W przypadku zastosowania wzoraca Domain Inventory warstwa usługowa może być albo osobna dla każdego inwentarza domeny, albo (przez zastosowania wrorca Cross-Domain Utility Layer) wspólna dla całej architektury SOA w przedsiębiorstwie.
Utility Abstraction sprawia problemy w fazie definiowania kontraktów usług, ponieważ nie dysponujemy gotowym biznesowym kontekstem, na którym moglibyśmy się oprzeć. Musimy od podstaw wymyśleć, co nasza warstwa powinna robić i na jakim poziomie szczegółowości to udostępniać.
Podczas podejmowania decyzji o wydzieleniu w swoim rozwiązaniu warstwy Utility należy rozważyć, czy w tym konkretnym wypadku koszty nie będą zbyt duże. Trzeba pamiętać, że wydzielenie funkcji, takich jak logowanie, jako usług (domyślnie Web Service) będzie miało znaczny wpływ na wydajność. Dlaczego założyłem, że usługi Utility mają być Web Service? Ano dlatego, iż wzorzec Canonical Protocol sugeruje, aby całość komunikacji w ramach jednego inventory odbywała się za pośrednictwem jednego protokołu.
Last but not least: zastosowanie Utility Layer/Abstraction często wiąże się z wykorzystaniem wzorca Service Agent, czyli agentów przechwytujących żądania i uruchamiających pewne metody warstwy usługowej. Jest to nic innego jak scentralizowana wersja dobrze znanych aspektów.
SOA Design Patterns: Direct vs Brokered Authentication
Jul 3rd
Natknąłem się na kolejną ciekawą parę wzorców. W odróżnieniu od poprzednio opisywanej, tym razem para ma charakter dwóch konkurencyjnych rozwiązań tego samego problemu.
To dla mnie interesująca nowość: do tej pory wzorce kojarzyły mi się z podejściem: problem – rozwiązanie (+ konsekwencje). W tym wypadku problem ma dwa równorzędne rozwiązania (przynajmniej tak wynika z lektury rozdziałów). No i wydaje mi się, że z tą równorzędnością jest problem…
Direct Authentication zakłada, że każda usługa przechowuje swoją własną bazę tożsamości klientów i jest odpowiedzialna za autentykowanie przychodzących żądań. Brokered Authentication polega na wydzieleniu osobnego podmiotu (usługi), której jedynym zadaniem jest generowanie “tokenów” potwierdzających tożsamość klienta. Token taki może być później użyty do dostępu do konkretnych usług.
Sekcja “Impacts” opisuje prawidłowo konsekwencje wykorzystnia obu podejść. Wadą pierwszego jest zwiększenie nakłądu administracyjnego na zarządzanie magazynami tożsamości dla każdej usługi. Wadą drugiego zaś – stwarzanie sytuacji z pojedynczym punktem awarii lub dostępu do całości systemu. Zastanówmy się jednak jaki jest “ciężar gatunkowy” tych negatywnych konsekwencji. Nasuwa mi się pytanie następujące: czy w środowisku SOA, gdzie, z definicji, ma współistnieć dziesiątki lub setki usług, wersja Direct nie powinna być traktowana jako anty-wzorzec? Kto o zdrowych zmysłach będzie w każdej usłudze przechowywał dane klientów osobno? Jak w ogóle w takim wypadku przekazać dane autentykujące do usług biorących udział w kompozycji? Dziwne to. Przynajmniej dla mnie.
SOA Design Patterns: Capability (Re)composition
Jul 3rd
To właściwie dwa wzorce: Capability Composition oraz Capability Recomposition.
Pierwszy z nich rozwiązuje problem usługi, która w celu wykonania swojego zadania potrzebueje logiki, która nie mieści się w jej zakresie odpowiedzialności. Aby problem rozwiązać, można poszerzyć zakres odpowiedzialności usługi, jednak prowadzi to do duplikacji logiki. Innym, lepszym i poprawnym, rozwiązaniem jest włączenie wywołania innej usługi jako elementu realizacji logiki tej pierwszej.
Właściwie wydaje się to zupełnie naturalne, przecież właśnie SOA zwykle kojarzy się z nieskończonymi łańcuszkami usług wywołujących się nawzajem.
Wzorzec Capability Composition nie jest jednak zwykłym agregowaniem usługi. To, co go wyróżnia to fakt, że usługi agregowane wywoływane są “zgodnie ze sztuką”, czyli np. za pośrednictwem oficjalnego kontraktu.
Capability Recomposition jest bardzo podobnym wzorcem. Tutaj też chodzi o składanie usług w celu rozwiązania dużego problemu. Różnica polega na tym, że Recomposition oznacza, że poszczególne usługi są zaprojektowane w taki sposób, że możliwe jest wykorzystywanie ich do rozwiązania wielu różnych problemów – mogą być elementami różnych, niezwiązanych ze sobą, procesów biznesowych.
Zakres możliwości wykorzystania wzorca Capability Recomposition w twojej architekturze usługowej jest dobrą miarą tego, jak dobrze zastosowałeś zasady (principles) SOA. Im lepiej, tym więcej możliwości wykorzystania CR, czyli ponownego użycia logiki usług.
