Integracja architektury IT – model SOA w komunikacji bezpośredniej

Model bazujący na stworzeniu usług bez zastosowania dedykowanej warstwy integracyjnej, jest jednym z wielu wariantów realizacji koncepcji budowy architektury IT, bazującej na usługach SOA (Service Oriented Architecture). Z poniższego artykuły dowiesz się:

  • Jakie są zalety i możliwości tego rozwiązania?
  • Jaki jest jego potencjał i ograniczenia ?
  • Kiedy warto rozważyć scenariusz SOA w komunikacji bezpośredniej

Usługa w ujęciu SOA jest pojedynczym komponentem dostarczanym przez IT dla biznesu, wspierającym realizację określonego zadania, występującego w jednym lub więcej procesów biznesowych. Pojedyncza usługa korzysta najczęściej z wielu elementów infrastruktury IT: sieci, aplikacji, baz danych.

Usługi powinny być:

  • dobrze opisane,
  • uniwersalne,
  • niezależne od siebie,
  • dostępne,
  • użyteczne (dostarczające określonej funkcjonalności realizującej cel biznesowy).

Komunikacja w opisywanym modelu następuje między systemami w sposób bezpośredni (tutaj podobieństwo do koncepcji P2P), ale zorganizowany i ustandaryzowany za pomocą sztywno zdefiniowanych usług. Interakcja obsługiwana jest na zasadzie: żądanie usługobiorcy – odpowiedź usługodawcy z wykorzystaniem określonego protokołu komunikacyjnego.

Bardzo istotne jest, aby nie mylić usługi sieciowej (WebService) z usługą w rozumieniu SOA. Ta pierwsza to ustrukturyzowany i zdefiniowany za pomocą specjalistycznego języka opisu komponent programowy, niezależny od platformy oraz implementacji. Usługi sieciowe są najczęściej używaną realizacją usług w rozumieniu SOA, nie jest to jednak sposób jedyny.

Zalety i możliwości SOA w komunikacji bezpośredniej

  • Reużywalność usług, które pozwalają na powiązanie wielu systemów w sposób niezależny od siebie przy użyciu tzw. „luźnego powiązania” (ang. loosely coupled);
  • Łatwość utrzymania – implementacja pojedynczej usługi nie jest w żaden sposób zależna od innych usług, co w dużym stopniu ułatwia obsługę zbioru usług udostępnianych przez dany system (aktualizacja, dezaktywacja, monitorowanie);
  • Bliżej niezawodności – zdekomponowane elementy, wchodzące w skład opisywanej architektury są łatwiejsze do testowania i debugowania, niż masywne homogeniczne komponenty, realizujące wszystkie międzysystemowe transfery danych, składające się z dziesiątek tysięcy linii kodu;
  • Większa skalowalność oraz dostępność – możliwe jest równoległe uruchomienie wielu instancji tej samej usługi, co znacząco wpływa na jej czas dostępności oraz możliwości wydajnościowe;
  • Wyższa jakość oprogramowania w organizacji – przenoszenie środka ciężkości realizacji funkcjonalności na reużywalne usługi, udostępniane przez systemy, eliminuje redundantność tych funkcji w samych systemach, co skutkuje mniejszą liczbą błędów oraz większą spójnością danych wymienianych w organizacji
  • Niezależność od platform i technologii – usługi obsługujące wymianę danych między systemami są całkowicie niezależnie od technologii i framework’ów, w których zostały one wykonane.

Wady i ograniczenia

  • „Większe koszty początkowe, długoterminowe oszczędności” – wdrożenie opisywanej koncepcji wymaga gruntownej analizy biznesowej, w celu opracowania efektywnego podziału na usługi oraz ich implementację. W porównaniu do powiązania P2P, zwiększa koszty wdrożenia, ale w dalszej perspektywie inwestycja zwraca się dzięki łatwości obsługi zmian oraz dołączania kolejnych systemów.
  • Podczas każdej wymiany danych w ramach usługi ma miejsce kompleksowa walidacja wartości wszystkich parametrów komunikatu (sprawdzenie czy są zgodne z definicją), co generuje dodatkowe narzuty czasowe. W większości przypadków ów dodatkowy czas jest jednak pomijalny.
  • Trudności w zarządzaniu komunikatami wymienianymi w ramach usług – w przypadku dużej liczby usług w organizacji oraz wysokiej częstotliwości wymiany komunikatów mogą wystąpić problemy w zarządzaniu ścieżkami komunikacji.
  • Brak możliwości kompleksowego zarządzania usługami oraz monitorowania całej warstwy integracyjnej w jednym miejscu – każda integracja odbywa się bezpośrednio między systemami, wiec źródeł informacji jest tyle, ile połączonych systemów.

Zastosowanie, kryteria wyboru modelu SOA

Podejście bazujące na usługach w komunikacji bezpośredniej różni się od metody Point-to-point koniecznością stworzenia usług zgodnie z opisanymi restrykcyjnymi wymaganiami. Jest dobrym kierunkiem integracyjnym dla przedsiębiorstwa, w którym:

  • wykorzystywanych jest kilka systemów, które nie muszą się ze sobą komunikować z bardzo dużą częstotliwością (setki komunikatów na sekundę),
  • systemy i źródła danych mogą się dostosowywać do usług udostępnionych przez inne systemy (w budowie danego systemu nie istnieją przeszkody implementacji mechanizmów korzystających z „obcych” interfejsów),
  • usługi konieczne do stworzenia nie są nadmiernie złożone, a w ich obrębie nie jest konieczna realizacja zaawansowanych transformacji danych,
  • jednorodność i „sztywność” usług, dostarczających danej wartości biznesowej w organizacji nie jest przeszkodą (przykładowo akceptowalne jest, że w całej infrastrukturze występuje tylko jedna usługa udostępniająca dane pracownika – nie może być ich więcej).

Model integracji bazujący na SOA nie jest rekomendowany, jeśli integrowane mają być systemy, które:

  • cechują się dużą spójnością ze względu na dostawcę lub technologię – w takiej sytuacji wdrażanie podejścia bezpośredniej komunikacji SOA nie będzie efektywne kosztowo. Jeżeli istnieją łatwe sposoby stworzenia ścieżek komunikacji pomiędzy systemami (np. gotowe interfejsy systemów od jednego dostawcy lub gotowe ścieżki komunikacji dostarczone przez dostawcę technologii) należy z nich skorzystać,
  • generują duży wolumen wymienianych danych bez ich przechowywania oraz swą główną funkcjonalność opierają na operowaniu na interfejsie graficznym (np. aplikacje służące do oznaczania punktów na mapach),
  • restrykcyjnie wymagają wymiany danych w trybie „real time”, tj. z minimalnymi czasami odpowiedzi synchronicznych usług,
  • działają w odseparowaniu i nie są gotowe na obsługę komunikacji sieciowej z innymi usługami z wykorzystaniem żądań i odpowiedzi.

Nasi eksperci
/ Dzielą się wiedzą

16.02.2021

Dlaczego warto realizować aplikacje mobilne w oparciu o usługi AWS?

Rozwiązania mobilne

Dzisiejsze aplikacje mobilne muszą spełniać wiele wymagań, szczególnie w obszarze wydajności, skalowalności i, oczywiście, opłacalności. Zdecydowanie potrzebna jest więc zaawansowana, wspierająca owe aplikacje infrastruktura.  Frontend aplikacji bazuje na sprzęcie użytkownika, jednak to nad backendem mamy największą kontrolę. Zarówno...

02.02.2021

7 objawów długu cyfrowego

Konsulting IT

Poprzedni artykuł poświęciliśmy rosnącemu znaczeniu długu cyfrowego – zwłaszcza w obliczu ostatnich wydarzeń. Tym razem skupimy się na powszechnych sygnałach, które mogą wskazywać na cyfrowe zadłużenie Twojej firmy lub konkretnych procesów. Bardzo możliwe, że obszary, których dotyka dług cyfrowy, stopniowo stały się częścią...

26.01.2021

Dług cyfrowy / cichy zabójca biznesów

Konsulting IT

Cześć biznesów mogła beztrosko działać offline – póki nie nadeszły okoliczności, które popsuły wszystkim nastroje. Ostatnie wydarzenia wyciągnęły na światło dzienne problem długu cyfrowego. Prosta, brutalna prawda na dziś: firmy i inne podmioty nagle znalazły się w rzeczywistości, która nie pozwala opierać działalności na...

Ekspercka wiedza
dla Twojego biznesu

Jak widać, przez lata zdobyliśmy ogromną wiedzę - i uwielbiamy się nią dzielić! Porozmawiajmy o tym, jak możemy Ci pomóc.

Napisz do nas

<dialogue.opened>