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ą

20.07.2021

E-commerce w wersji Mobile-First / Opcja czy wymóg?

E-Commerce

Mobile jest niewątpliwie najważniejszym kanałem, w który obecnie powinny inwestować e-sklepy. Nieustannie konkuruje on z tradycyjnymi przeglądarkami desktopowymi o zaangażowanie użytkownika. Warto zaznaczyć, że obecny stan technologii mobilnej pozwala na równie prawdziwe odczuwanie doświadczeń zakupowych klientów (Customer Experience), jak...

13.07.2021

Skuteczna sprzedaż w B2B / Sprawdzone praktyki z B2C

E-Commerce

Fakt jest taki: e-commerce przeżywa obecnie rozkwit, jakiego nie doświadczył jeszcze nigdy w historii. Chociaż wzrost e-handlu w sektorze B2B (business to business) jest nagły, to ten obszar i tak jest wielokrotnie marginalizowany. A to duży błąd, gdyż branża, która przede wszystkim opierała się na sprzedaży osobistej, obecnie bardziej niż...

06.07.2021

Design System vs Pattern Library, Style Guide / Jedyne Źródło Prawdy (SSOT)

Rozwiązania mobilne

W ostatnim czasie poruszyliśmy takie tematy, jak architektura headless-owa, procesy omnichannel i multiexperience oraz z jakieś pół tuzina dyskusji na temat obecnego stanu e-commerce. A to, na czym się najbardziej skupiamy, to przedstawienie sposobów na zoptymalizowanie i poprawę wydajności backend-u. Ale…ale użytkownicy nie mają...

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>