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.
