Integracja architektury IT – model SOA z dedykowaną warstwą integracyjną

Model z dedykowaną warstwą integracji to alternatywny sposób realizacji koncepcji SOA. Z poniższego artykułu dowiesz się:

• Jakie są zalety i możliwości tego rozwiązania?
• Z jakimi wadami i ograniczeniami będziesz się musiał zmierzyć?
• Kiedy stosować SOA z dedykowaną warstwą integracyjną?

---

Charakterystyka SOA z dedykowaną warstwą integracyjną w obszarze udostępnianych usług jest bardzo podobna do rozwiązania SOA z bezpośrednią komunikacją. To co odróżnia ten wariant od pozostałych rozwiązań, to zastosowanie dedykowanego komponentu, który fizycznie realizuje przepływy danych pełniąc rolę „pośrednika” między systemami/źródłami danych. Powyższy model skupia się na maksymalnej centralizacji i uwspólnianiu informacji w całej architekturze IT organizacji. Stosowany komponent integracyjny zbiera informacje o sposobie połączenia wszystkich systemów w organizacji i kompleksowo obsługuje wymianę danych między nimi. Dzięki centralizacji oraz reużywalności, możliwa jest globalna obsługa logowania, błędów i transakcyjności, co jest ogromną zaletą tego podejścia w porównaniu do przybliżanych wcześniej koncepcji integracyjnych.

Najpopularniejszą – choć nie jedyną – klasą komponentu pełniącego obecnie opisaną rolę jest szyna usług (ang. Enterprise Service Bus), której zastosowanie daje szerokie możliwości w różnych aspektach integracji. ESB jest narzędziem do realizacji koncepcji SOA, poprzez umożliwienie skomunikowania się systemów w organizacji, z wykorzystaniem usług w sposób efektywny.

YouTube Video to embed
https://www.youtube.com/watch?v=VHzWswQNtgk

Zalety i możliwości rozwiązania

• Elastyczność warstwy integracyjnej – możliwość realizacji logiki biznesowej, łączenia danych z poszczególnych źródeł i przeprowadzania modyfikacji struktur danych, bez konieczności zajścia modyfikacji po stronie usług udostępniających dane z systemów źródłowych.
• Reużywalność – wytworzone i umiejscowione na platformie integracyjnej, przetestowane i skonfigurowane komponenty, realizujące wymianę danych między systemami, mogą być wykorzystywane wielokrotnie przez różnych odbiorców, co znacząco ogranicza koszty.
• Eliminacja uzależniania się od dostawców systemów – niektóre zmiany po stronie mechanizmów przekazujących dane (np. transformacje) mogą być dokonywane w warstwie integracyjnej, bez konieczności modyfikacji interfejsów udostępnianych przez systemy źródłowe.
• Efektywność implementacji mechanizmów integracyjnych – sprawdzone platformy bazują na popularnych technologiach charakteryzujących się dużą liczbą pomocniczych bibliotek, co znacznie skraca czas tworzenia działających rozwiązań.
• Łatwiejsze utrzymanie infrastruktury oraz wsparcie podmiotów korzystających z udostępnianych interfejsów – dzięki możliwości zastosowania wspólnych, ustandaryzowanych polityk logowania oraz narzędzi do monitorowania dostępnych „z paczki”.
• Możliwość skorzystania z gotowych narzędzi dostarczanych wraz z platformą integracyjną – np. konektory i biblioteki potrafiące obsługiwać komunikację za pomocą określonych protokołów i źródeł danych lub umożliwiające połączenie ze znanymi systemami.
• „Lżejsze” i mniej skomplikowane systemy w architekturze – nie muszą zawierać skomplikowanego kodu, wytworzonego na potrzeby zajścia procesów integracyjnych – środek ciężkości przesunięty jest na centralną platformę.
• Stosowanie standardów i propagacja dobrych praktyk w zakresie integracji w całej organizacji – każdy odbiorca danych z innego systemu musi skorzystać z dobrze opisanych usług, udostępnionych w platformie.

Wady i ograniczenia

• Wdrożenie w infrastrukturze IT platformy integracyjnej wiąże się z koniecznością jej poznania, rozwijania oraz utrzymywania, co wiąże się z potrzebą dostępu do odpowiednich kompetencji w organizacji lub poza nią.
• W przypadku bardzo dużego natężenia prac koniecznych do realizacji po stronie warstwy integracyjnej, zespół za to odpowiedzialny może stać się tzw. „wąskim gardłem” w organizacji, tj. limitować czasowo konieczne do dostarczenia komponenty, łączące systemy (mimo gotowości obu systemów, konieczna jest praca do wykonania na platformie integracyjnej).
• Obsługa zmian w platformie a regresja – każda modyfikacja dokonana w mechanizmach integracyjnych powinna pociągać za sobą przetestowanie wszystkich przepływów danych, co może generować dodatkowe koszty. Aby temu zapobiec, należy kłaść duży nacisk na zastosowanie narzędzi CI (ang. continous integration) oraz pokrycie mechanizmów testami automatycznymi.
• Platforma = SPOF – platforma integracyjna może stać się pojedynczym punktem awarii w infrastrukturze przedsiębiorstwa (ang. single point of failure), czyli w przypadku jej usterki przestają działać procesy integracyjne. Aby temu zapobiec, należy stosować rozwiązania zapewniające tzw. wysoką dostępność warstwy integracyjnej (ang. HA – high availability), dzięki której, w przypadku awarii jednej instancji platformy, automatycznie uruchamia się druga Zapewni to ciągłość międzysystemowej wymiany danych.
• W przypadku bardzo restrykcyjnych wymagań dotyczących wydajności, dodanie przejściowego podmiotu, przez który musi przejść komunikat z systemu źródłowego do docelowego, może okazać się problemem (wymaga to dodatkowych narzutów czasowych). Rozwiązania klasy ESB są jednak bardzo dobrze skalowalne i dobranie odpowiednich parametrów sprzętowych w większości przypadków wystarcza do zapewnienia pożądanej wydajności.

Czy jest to rozwiązanie dla mojej organizacji?

Bilans zysków i strat wynikających z zastosowania usług SOA i dedykowanego komponentu integracyjnego, uzasadnia ten kierunek rozwoju architektury IT. Należy jednak wspomnieć o dwóch scenariuszach, w których to rozwiązanie nie spełni swojej roli:

Jedynymi przypadkami, w których ta koncepcja zdaje się nie być odpowiednią są sytuacje, gdzie:

• Scenariusz 1: w organizacji funkcjonuje niewielka liczba systemów, które mają się ze sobą komunikować z wykorzystaniem nieskomplikowanych mechanizmów i w perspektywie najbliższych kilku lat nie pojawi się konieczność rozbudowy połączeń międzysystemowych (nowe systemy, bardziej skomplikowane mechanizmy);
• Scenariusz 2: w infrastrukturze występuje potrzeba budowy zaawansowanej platformy integracyjnej podzielonej na warstwy, które w zależności od granularności i szczegółowości danych z systemu źródłowego, oraz specyfiki odbiorcy danych (system, aplikacja, użytkownik), dane zostaną udostępnione w sposób bezpieczny i adekwatny.