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ą

12.10.2021

Single Source of Truth (SSoT) / Sposób na dług technologiczny

E-Commerce

Zbędne powtórzenia, niedokładność i niekonsekwencja to problemy, których każda firma chce uniknąć. Ich obecność często wskazuje na błędny wybór (lub użytkowanie) technologii. Użyte we właściwy sposób, odpowiednio dobrane technologie powinny usuwać powtórzenia w procesach, zapewnić większą przejrzystość i całościowo poprawiać...

05.10.2021

Personalizacja w e-commerce / Solidne podstawy

E-Commerce

Kiedy rozmawiamy, personalizacja często dzieje się nieświadomie. Interakcja jest wtedy płynna, a na potrzeby klienta reagujemy w czasie rzeczywistym. Obsługa w sklepie może pokierować ludzi w odpowiednie miejsce po coś, czego właśnie potrzebują – to sekret wszystkich dobrych sprzedawców. Co z Internetem? Tam musimy się dostosować. Trendy...

28.09.2021

Black Friday Checklist/ Praktyczna lista kontrolna dla właścicieli portali E-commerce

E-Commerce

Każdego stresuje Black Friday, ale umówmy się, ci, których stresuje najmniej, to kupujący 😉 Za kulisami każdej wyprzedaży tego typu stoją całe działy IT, marketingu i wsparcia klienta, które muszą się dokładnie przygotować i obmyślić całą strategię działania. Nie wspominając już nawet o magazynie, logistyce i wszystkich następnych...

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>