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ą

Generative AI in healthcare
26.03.2024

Gen AI w ochronie zdrowia / Czy nadchodzi rewolucja?

AI

Czy naszym lekarzem pierwszego kontaktu zostanie wkrótce pracownik medyczny obsługujący zaawansowany chatbot AI? A może, wzorem dzisiejszych internautów próbujących diagnozować się z „doktorem Google”, samodzielnie sprawdzimy stan zdrowia z jednym z wielu specjalistycznych chatbotów? Nie wiemy dokładnie, jak rozwinie się gen AI w...

Rozwiązania omnichannel
19.03.2024

Rozwiązania omnichannel w 2024

Omnichannel

Wdrożenie strategii omnichannel wymaga uporządkowania i przemyślenia wielu aspektów biznesu. Jedną z kluczowych decyzji będzie wybór odpowiednich rozwiązań dla omnichannel. O jakich jednak rozwiązaniach mówimy? W tym poradniku zebraliśmy najpopularniejsze rozwiązania omnichannel, które pomogą Ci stworzyć Twoją unikalną układankę...

System PIM Best Practices
12.03.2024

System PIM / Najlepsze praktyki

Product Information Management

Jeśli chcesz w pełni wykorzystać możliwości systemu PIM nie wystarczy go po prostu wdrożyć. Być może wyzwanie stanowi duża liczba produktów, a może rozproszone zasoby cyfrowe? Niezależnie od tego, czy jesteś menedżerem produktu szukającym sposobów na oszczędność czasu, czy liderem biznesowym dążącym do poprawy efektywności...

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>