unity wiedza

Czas czytania: 6 minut

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 SaaSitp. 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 rzecz, 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, o którym więcej dowiesz się TUTAJ. 

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 wnoszą tzw. vendor lock 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, MavenJUnit, 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, a 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 kontaktu oraz zapoznania się z naszą ofertą. 

Wyrażam zgodę na przetwarzanie danych osobowych na zasadach określonych w polityce prywatności. Jeśli nie wyrażasz zgody na wykorzystywanie cookies we wskazanych w niej celach, w tym do profilowania, prosimy o wyłącznie cookies w przeglądarce lub opuszczenie serwisu. więcej

Akceptuj