Service Oriented Architecture – SOA

Czym jest usługowe podejście do architektury (Service Oriented Architecture), dlaczego SOA jest takie ważne ? Co chmura obliczeniowa ma wspólnego z SOA ? Jak to jest z mikroserwisami i SOA.

Wprowadzenie

Koncepcja usługowego podejścia do architektury powstała już dosyć dawno, wyklarowanie jej nastąpiło około 2006 roku (niestety nie pamiętam dokładnie). Pomimo iż w większości przypadków kojarzona jest z domeną integracyjną (w której najlepiej się sprawdza i najłatwiej ją wykorzystać) to w rzeczywistości odnosi się do całości architektury (wszystkich jej obszarów). Niestety koncepcja została dosyć szybko zawłaszczona i wykrzywiona przez dostawców platform integracyjnych bo stanowiła doskonałe podłoże dla marketingu.

Jedną z głównych przyczyn dlaczego większość wdrożeń SOA było nieudanych był fakt iż skupiano się głównie na tym co producenci oprogramowania mogli zaoferować, czyli platformach integracyjnych, podczas gdy głównym elementem koncepcji są zagadnienia związane z nadzorem (tzw. Governance). Udane wdrożenie SOA to 20% technologii i 80% zarządzania architektura, czyli SOA governance.

Koncepcja Service Oriented Architecture

SOA, czyli Architektura Usługowo Zorientowana (trudno się to tłumaczy) jest to koncepcja na poziomie architektury logicznej, która zakłada budowanie i zarządzanie całością architektury IT jako zestawem usług o wzajemnych relacjach. Usługa jest reprezentacją powtarzalnej czynności biznesowej posiadającej zdefiniowane wejście i wyjście. Usługa:

• może składać się z innych usług – wykorzystywać je w swoim działaniu
• jest samowystarczalna
• jest „czarną skrzynką” dla jej konsumentów

Kluczem w sukcesie wdrożenia SOA jest zapewnienie odpowiedniego nadzoru architektonicznego i zbudowanie efektywnego modelu operacyjnego.

W koncepcji potrzebujemy więc udostępniać usługi, do czego można wykorzystać przeróżne rozwiązania technologiczne, od zwykłych serwerów aplikacyjnych do rozbudowanych platform integracyjnych, ale to jest zaledwie początek drogi do sukcesu.

Drugim, ważniejszym elementem jest stworzenie odpowiedniego nadzoru architektonicznego, który zapewni budowanie usług zgodnych z SOA. Nadzór ten musi zostać na stałe umieszczony w krwioobiegu firmy, tak aby wszelkie działania związane z tworzeniem i modyfikacją usług podlegały nadzorowi. Procesy w firmie muszą działać tak, aby już w momencie tworzenia koncepcji rozwiązania brane były pod uwagę pryncypia SOA. Najlepiej jest aby w firmie funkcjonowało centrum kompetencyjne zajmujące się zarządzaniem usługami. Z jednej strony takie centrum powinno zajmować się doskonaleniem procesu nadzoru, z drugiej strony wspierać pracę związane z projektowaniem nowych rozwiązań.

W tym wszystkim nie można zapominać o konieczności zarządzania całym cyklem życia usługi, więc nie tylko samo zaprojektowanie nowych usług czy modyfikacja istniejących, ale również maksymalne ułatwienie reużywania tego co wcześniej było zbudowane (czyli zapewnienie dostępu do wiedzy o tym co już jest, lub co jest planowane do wdrożenia w najbliższym czasie). I tak samo nie można zapominać o aspekcie wycofywania usług już więcej nie potrzebnych lub zastąpionych. Ważnym elementem jest więc katalog usług (Service Catalog), gdzie powinna znajdować się zebrana wiedza o wszystkich usługach, ich funkcjonalnościach, przetwarzanych informacjach czy planowanym cyklu życia (tak aby nie rozwijać usług planowanych do wyłączenia).

Pryncypia dla Service Oriented Architecture

Pryncypia w świecie architektury są drogowskazem pozwalającym nam na orientację w przestrzeni i weryfikację czy podążamy we właściwym kierunku. W przypadku SOA możemy również wskazać zestaw pryncypiów, pamiętając, że pozostawiają one pewną swobodę w sposobie ich realizacji. Należy trzymać się bardziej ducha pryncypiów a nie ich litery.

Standaryzacja opisów usług (Standardized Service Contract)

Wszystkie usługi powinny być opisywane w ten sam jednolity sposób dzięki czemu łatwo będzie je ze sobą porównywać i wybierać te, które pasują do naszego rozwiązania. Dzięki szablonowi opisu usługi łatwo będzie definiować nowe usługi mając wiedzy o tym jak się powinno je opisywać. Taki kontrakt usługi powinien jednoznacznie definiować co usługa przyjmuje na wejściu, jakie informację zwraca i jaką realizuje funkcjonalność (ale bez informacji o sposobie realizacji).

Luźne powiązanie (Loose Coupling)

Należy dążyć do maksymalnej niezależności usług między sobą na poziomie implementacyjnym. Nie chodzi więc aby jedna usługa nie korzystała z innych w ramach swojej funkcjonalności, ale aby jej sposób działania nie był zależny od sposobu działania innych usług. Tak aby możliwe było całkowite przebudowanie usług bez konieczności modyfikacji usług korzystających.

Abstrakcja usług (Service Abstraction)

Usługi ukrywają / enkapsulują sposób realizacji swojej funkcjonalności (logikę działania). Do wykorzystania usługi nie jest potrzebna wiedza o tym jak usługa działa, bo istotne jest jakie funkcje realizuje.

Reużywalność usług (Service Reusability)

Przy projektowaniu usług należy brać pod uwagę aby poprzez odpowiednie dekompozycję logiki na poszczególne usługi zapewnić jak największą reużywalność otrzymanych usług.

Autonomia usług (Service Autonomy)

Musi być zapewniona autonomia poszczególnych usług, czyli muszą one mieć kontrolę nad logiką, którą enkapsulują.

Bezstanowość usług (Service Statelessness )

Idealną sytuacją jest gdy usługi są bezstanowe.

Wykrywalność usług (Service Discoverability)

Musi istnieć repozytorium / rejestr usług, który umożliwia ich wyszukiwanie i zawiera informacje o poszczególnych usługach.

Dekompozycja usług (Service Composability)

Należy unikać budowy zbyt skomplikowanych usług poprzez dekompozycję złożonych zagadnień na prostsze i dopiero wtedy ich implementację w usługach.

Interoperacyjność usług (Service Interoperability)

Usługa powinna wykorzystywać standardy umożliwiające wykorzystanie przez szerokie spektrum zróżnicowanych konsumentów

Poziomy dojrzałości Service Oriented Architecture

W obecnym złożonym świecie nie da się zachować podejścia zero-jeden, czyli dzielić na architektury zgodne z SOA i niezgodne. Dużo bardzo wartościowym podejściem jest określanie poziomu dojrzałości architektury w kontekście SOA. Dobrym przykładem takiego podejścia jest stworzony przez The Open Group SOA Integration Maturity Model (OSIMM).

Poziomy dojrzałości architektury IT w kontekście podejścia SOA są zwykle mniej więcej zgodne z poziomami rozwoju przedsiębiorstw, która rozpoczynają od silosów biznesowych, które później zaczynają integrować zmierzając do stanu końcowego zapewniającego modularyzację biznesu. Model dojrzałości świetnie się sprawdza w koncepcji SOA gdyż jest on mocno zorientowany na procesy zarządcze a one stanowią kluczowy wyznacznik udanej implementacji SOA.

Service Oriented Architecture – przykłady implementacji

ESB – Enterprise Service Bus

Najbardziej znany i podstawowym przykładem implementacji koncepcji SOA jest Korporacyjna Szyna Usług. ESB jest rozwiązaniem technologicznym, na którym są budowane i udostępniane usługi, czy też jak to jest obecnie modne API. W ramach tego podejścia jest najłatwiej zbudować rozwiązania zgodne z SOA, gdyż często platforma taka jest obudowana w dodatkowe moduły wspierające zarządzanie cyklem życia usług. Wyzwaniem przy takich rozwiązaniach jest wbudowanie nadzoru nad architekturą integracji w codzienne działania firmy, tak aby rozwiązania w projektach były tworzone od początku z uwzględnieniem pryncypiów, a nie dopiero na końcu projektu były próby ich dopasowania. Większość wdrożeń ESB jest niestety realizowana wyłącznie w obszarze technologicznym pomijając aspekt nadzoru, i dopiero później rozpoczyna się w bólach jego wykuwanie.

Chmura Obliczeniowa

Pomimo faktu, iż najczęściej koncepcję SOA stosuje się w podejściu horyzontalnym do architektury IT, to równie dobrze można ją zastosować wertykalnie. W takim przypadku pomiędzy poszczególnymi warstwami architektury IT tworzona jest relacja usługowa.

Mikroserwisy

W przypadku mikroserwisów ścierają się ze sobą skrajne poglądy. Jedni mówią, że mikroserwisy to SOA, inni rzucają hasło „SOA is dead, niech żyją mikroserwisy”. A rzeczywistość jest bardziej prozaiczna, można odpowiedzieć tak jak na większość zagadnień w obszarze architektury IT „To zależy”. Tak samo jak w przypadku ESB wszystko zależy od sposobu implementacji. Można zaimplementować mikroserwisy w zgodzie z koncepcją SOA, ale można je również zaimplementować bez jej przestrzegania. Trzeba pamiętać, że w SOA tylko 20% to technologia, pozostałe elementy to zarządzanie, nadzór, projektowanie, gdzie można to zrobić na wiele sposobów.

Podsumowanie

W artykule starałem się przekazać, że koncepcja SOA to nie jest rozwiązanie na poziomie technologi, ale w obszarze zarządzania architekturą. Pomimo, że finalnie trzeba to zaimplementować ważne jest jak usługi są projektowane, ale również aby właściwe były zarządzane w ramach całego cyklu życia.

Jeżeli po przeczytaniu są jeszcze jakieś rzeczy niezrozumiałe bądź niejasne to zapraszam do kontaktu lub pozostawienia komentarza.