Budowa nowoczesnej architektury SOA przy wykorzystaniu szyny usług

Założenia stojące za architekturą SOA (architekturą zorientowaną na usługi) były i są jak najbardziej słuszne i solidne. Niestety, to sposób ich implementacji często zawodzi, powodując porażkę projektów i frustrację u menadżerów – szczególnie tych odpowiedzialnych za budżet. Natomiast idea architektury usługowej może z powodzeniem być fundamentem filozofii stojącej za integracją systemów i aplikacji, a nowoczesna szyna usług – o ile będzie to rozwiązanie zapewniające zwinność i elastyczność – wielokrotnie udowodniła swoją skuteczność.


Wprowadzenie – kilka słów o architekturze usługowej 

Architektura usługowa (Service Oriented Architecture – SOA) została uznana zarówno za nowoczesne i elastyczne podejście do budowy połączeń aplikacji w przedsiębiorstwach, jak i bardzo kosztowne i czasochłonne we wdrażaniu. Niespełnione oczekiwania przy realizacji licznych projektów mających na celu budowę architektury SOA, spowodowały wiele frustracji i rozczarowań. Niejedna firma odrzuciła szynę usług jako rozwiązanie integracyjne po takiej próbie lub nawet kilku próbach. 

Rozwiązanie, jakie Unity Group proponuje swoim klientom wyrażającym potrzeby integracji systemów, to odmienny sposób myślenia o SOA i szynie usług. Zamiast postrzegać ESB jako kosztowne „pudełka”, które przedsiębiorstwo kupuje, warto zacząć rozważać wybór rozwiązania przez pryzmat pryncypiów i wzorców prawidłowej integracji, szczególnie z perspektywy architektury IT. Innymi słowy, rozważając integrację systemów IT i wybór stosownych rozwiązań i partnerów, należy pamiętać o SOA, gdyż jest to istotny kamień milowy w budowie architektury i realizacji wzorców integracyjnych. 

Założenia SOA są wciąż słuszne 

Kluczowym założeniem architektury SOA było i jest projektowanie oraz budowanie architektury IT przedsiębiorstwa w oparciu o usługi, a nie o całe aplikacje. W takiej architekturze kluczowe jest budowanie komponentów (usług), czyli niewielkich, separatywnych części oprogramowania, realizujących konkretną funkcję i, co bardzo istotne, które są reużywalne dla innych aplikacji i systemów. W takim modelu zorientowanym na usługi rolą dewelopera jest głównie tworzenie nowych aplikacji poprzez łączenie zestawów usług, a nie budowanie całych aplikacji od zera. W założeniu i praktyce eliminuje to powtarzalność funkcjonalności w aplikacjach w architekturze, a tym samym zmniejsza czas niezbędny do realizacji. Jako przykład można podać aplikację bankową (zrealizowaną w architekturze SOA) uczestniczącą w procesie udzielania kredytów. Składałyby się ona m.in. z usług sprawdzania statusu kredytowego, usług kalkulujących odsetki i usług związanych z danymi klientów. 

Zgodnie z teorią, SOA powinna rozbijać masywne „silosy” logiki biznesowej i danych, które najczęściej gromadzone są w osobnych aplikacjach. Te zestawy logiki i danych mogą istnieć w oprogramowaniu lokalnym lub w chmurze, w aplikacjach SaaS, itp. W modelowej formie, SOA powinna umożliwiać interoperacyjność pomiędzy wszystkimi elementami logiki biznesowej i źródłami danych poprzez integrację, co z kolei skutkuje przyspieszeniem i ułatwieniem automatyzacji procesów biznesowych. 

To zorientowane na usługi podejście do architektury ma wiele zalet:

  • Dzięki większej elastyczności zbudowanych w ten sposób systemów informatycznych i oprogramowania procesów biznesowych, przedsiębiorstwa mogą reagować na zmiany znacznie szybciej i wydajniej.
  • Łatwiejsze staje się np. wprowadzanie innowacji do nowych produktów, tak aby zachować konkurencyjność i budować przewagę rynkową.
  • Dzięki wdrożeniu architektury SOA przedsiębiorstwa mogą zredukować nadmiarowość i złożoność często występujące w starszych systemach (legacy), zoptymalizować koszty IT związane z utrzymaniem i aktualizacjami oraz zwiększyć produktywność zespołów IT, czyniąc projektowanie oprogramowania bardziej intuicyjnym.

Można z przekonaniem rzec, iż idee SOA nie są złe. Po prostu liczne próby wdrożeń nie spełniły tej obietnicy. 

Proponowane podejście do SOA – szyna usług 

Możliwym powodem wielu niepowodzeń wdrożeń architektury SOA było to, że zostały zainicjowane w sposób „odgórny”. Uruchamiano je jako pojedynczą, zmasowaną inicjatywę, obejmującą swym zasięgiem całą organizację. Podejście to, często było związane ze specyfiką dostawców oraz producentów rozwiązań (wielkie marki) i wymagały drogich, wieloletnich, wieloetapowych wdrożeń. Niejednokrotnie z udziałem rzeszy kosztownych konsultantów. Były niezwykle pracochłonne i czasochłonne, a zespół projektowy klienta często musiał się uczyć i wykorzystywać wdrażany produkt do ponownego zaprojektowania wszystkich istniejących systemów, a także zaprojektować nowe aplikacje zgodnie z zasadami SOA. Deweloperzy niekiedy musieli zastąpić swoje znane narzędzia, procesy, a także umiejętności i przekwalifikować się, aby dostosować no nowej rzeczywistości. Miało to negatywny wpływ na możliwość szybkiego wprowadzania innowacji i nadążania za tempem zmian. 

Innym sposobem podejścia do problemów, które adresuje SOA, jest lekka, open source’owa szyna usług (ESB), np. Mule ESB lub WSO2. Taka szyna może wspierać tworzenie i orkiestrację usług bez konieczności stosowania rozbudowanych pakietów oprogramowania integracyjnego (często z bardzo drogą licencją) lub np. komponentu infrastruktury, eliminując wysokie koszty początkowe implementacji SOA. Zamiast przeciągniętego w czasie okresu analizy i implementacji, ESB można wdrożyć i zacząć używać w bardzo krótkim czasie. Dzięki temu programiści mogą tworzyć używalne interfejsy z interfejsami API, stopniowo budując i rozwijając nową architekturę w oparciu o pryncypia SOA. Przykładem takiej architektury jest model API-Led Connectivity

Szyna usług umożliwia firmom sukcesywną adopcję SOA, bez konieczności rewolucji w architekturze. Ponieważ rekomendowane przez Unity Group rozwiązania są budowane zgodnie z otwartymi standardami (open source), dają one klientom dużą elastyczność w zakresie integracji szerokiej gamy systemów, usług chmurowych i aplikacji. W przeciwieństwie do wczesnych inicjatyw z obszaru implementacji SOA, ESB pokroju Mule czy WSO2, nie wprowadzają tzw. vendor locka, czy też nie narzucają ściśle określonego (często wygodnego dla producenta) wzorca integracji i docelowej architektury. Pod wieloma względami szyna usług realizuje to, co obiecują założenia SOA. 

Korzyści wynikające z zastosowania szyny usług 

Szyna usług doskonale nadaje się do projektów integracyjnych i może sprawić, że łączenie systemów będzie efektywne i szybkie. Istnieje jednak wiele innych komponentów składających się na nowoczesną architekturę dla dzisiejszych organizacji. Na przykład firmy, które chcą oprzeć integracje o API, będą potrzebowały sposobu na ich projektowanie, budowanie, zarządzanie i zabezpieczanie. Potrzebne są także mechanizmy, które pozwolą na realizację ciągłej integracji / ciągłego wdrażania (CI/CD). 

Zarówno Mule ESB, jak i WSO2 ESB oferują nie tylko niezawodną łączność między systemami, ale również pełne zarządzanie cyklem życia API na jednej platformie. Platformy te zostały zbudowane na potrzeby DevOps i zwinnego rozwoju z myślą o wykorzystaniu popularnych i uznanych narzędzi, używanych do ciągłej integracji i ciągłego wdrażania (CI / CD), tj. SCM, Maven, JUnit, Jenkins. W utrzymaniu szyny usług, a więc zapewnieniu ciągłości biznesowej, krytyczne są także aspekty monitorowania. Tu z pomocą przychodzą narzędzia wbudowane i dostarczone wraz z szyną usług przez producentów. Istnieje jednak możliwość (często rekomendowana przez Unity Group) wykorzystania dodatkowych rozwiązań zewnętrznych, takich jak ELK, które nierzadko są już znane i stosowane przez naszych klientów. 

Tak zunifikowana platforma integracyjna wykorzystująca zasady SOA i funkcjonalność szyny usług – wdrażana przez zaufanego i kompetentnego partnera – pozwala stworzyć zorientowaną na usługi architekturę IT. Zapewnia ona elastyczność i niezawodność po to, aby pozostać konkurencyjnymi w dzisiejszym otoczeniu.

Jeżeli chcesz dowiedzieć się więcej o architekturze SOA, koncepcji API-led oraz narzędziach do zarządzania cyklem życia API, zapraszamy do zapoznania się z naszą ofertą oraz kontaktu

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>