Architektura zorientowana na usługi (SOA)

menu icon

Architektura zorientowana na usługi (SOA)

Odkryj SOA (architekturę zorientowaną na usługi), która jest ważnym etapem rozwoju procesów programowania i integracji aplikacji.

Czym jest SOA (architektura zorientowana na usługi)?

W ramach SOA, czyli architektury zorientowanej na usługi, definiowana jest metoda przygotowania komponentów oprogramowania do ponownego użytku za pomocą interfejsów usług. Te interfejsy wykorzystują wspólne standardy komunikacyjne w taki sposób, aby mogły być szybko włączone do nowych aplikacji bez konieczności przeprowadzania za każdym razem głębokiej integracji.

Każda usługa w architekturze SOA obejmuje integrację kodu i danych w celu zrealizowania kompletnego, dyskretnego zadania biznesowego (np. sprawdzenia środków klienta, obliczenia miesięcznej raty kredytu czy przetworzenia wniosku o kredyt hipoteczny). Interfejsy usług zapewniają luźne powiązania, co oznacza, że można je wywoływać z niewielką lub żadną wiedzą na temat sposobu implementacji integracji. Usługi są przekazywane za pomocą standardowych protokołów sieciowych — takich jak SOAP (Simple Object Access Protocol)/HTTP lub JSON/HTTP — do przesyłania wniosków o odczyt lub zmianę danych. Usługi są publikowane w sposób, który umożliwia programistom ich szybkie znajdowanie i ponowne wykorzystywanie do tworzenia nowych aplikacji.

Usługi te można budować od podstaw, ale często są one tworzone poprzez wykorzystanie funkcji ze starszych systemów interfejsów typu rekord jako usługa.

Dlatego SOA stanowi ważny etap trwającej od kilku dekad ewolucji metod programowania i integracji aplikacji. Przed powstaniem architektury SOA pod koniec lat dziewięćdziesiątych, łączenie aplikacji z danymi lub funkcjami znajdującymi się w innym systemie wymagało złożonej integracji typu punkt z punktem. Taką integrację programiści musieli odtworzyć, częściowo lub w całości, w każdym nowym projekcie programistycznym. Przekazywanie tych funkcji za pośrednictwem SOA eliminuje potrzebę każdorazowego odtwarzania takiej zaawansowanej integracji.

Warto zauważyć, że chociaż SOA i nowsze architektury mikrousług mają wiele wspólnych elementów, są jedynie luźno powiązane. W rzeczywistości funkcjonują na różnych poziomach, co omawiamy w dalszej części tego artykułu.

Czym jest ESB?

ESB, czyli magistrala usług korporacyjnych, stanowi wzorzec, na podstawie którego scentralizowany komponent realizuje integrację w systemach zaplecza, a następnie udostępnia te integracje pod postacią interfejsów usług. Magistrala realizuje funkcje translacji modeli danych, głębokiej łączności, routingu oraz potencjalnie tworzenia wielu żądań, a także udostępnia to wszystko na interfejsie pojedynczej usługi w celu ponownego wykorzystania przez nowe aplikacje. Wzorzec ESB jest zazwyczaj wdrażany przy użyciu specjalnie zaprojektowanego środowiska i narzędzi integracji dostosowanych do wyżej wymienionych funkcji, aby zagwarantować maksymalną wydajność.

Teoretycznie architekturę SOA można zaimplementować bez magistrali ESB, ale właściciele aplikacji musieliby w takim przypadku znaleźć indywidualny sposób na wyeksponowanie interfejsów usług, co wymaga wiele pracy (nawet jeśli interfejsów można użyć ponownie) i stwarza duże wyzwania związane z konserwacją w przyszłości. W praktyce magistrale ESB uważa się za tak nieodłączny element wdrażania architektury SOA, że oba te terminy są czasami używane zamiennie, co tworzy pewne zamieszanie.

Więcej informacji na temat magistrali ESB znajduje się w części „Wprowadzenie do magistrali usług korporacyjnych (ESB)”.

Zalety architektury SOA

W porównaniu ze starszymi architekturami SOA oferuje przedsiębiorstwu znaczące korzyści, takie jak:

  • Większa sprawność biznesowa i krótszy czas wprowadzenia produktu do dystrybucji: skuteczność tworzenia aplikacji przy użyciu interfejsów usług do wielokrotnego użytku, zamiast ponownego przepisywania i ponownej integracji w każdym nowymi projekcie, pozwala programistom znacznie szybciej budować aplikacje w ramach nowych możliwości biznesowych.
  • Umiejętność wykorzystywania tradycyjnych funkcji na nowych rynkach: dobrze zaprojektowana architektura SOA pomaga programistom łatwo wydobywać funkcje „zamknięte” na jednej platformie obliczeniowej lub w jednym środowisku, a następnie rozszerzać je na nowe środowiska i rynki. Na przykład wiele firm używało SOA do przenoszenia funkcji z systemów finansowych opartych na środowisku mainframe do sieci, pozwalając klientom korzystać z procesów i informacji wcześniej dostępnych tylko po bezpośredniej interakcji z pracownikami firmy lub partnerami biznesowymi.
  • Lepsza integracja działalności handlowej ze środowiskiem IT: w architekturze SOA usługi można definiować w kategoriach biznesowych (np. „wygeneruj wycenę biznesową” albo „oblicz wskaźnik ROI z inwestycji na sprzęt”). Dzięki temu analitycy biznesowi mogą skuteczniej współpracować z programistami, aby pozyskiwać ważne informacje — na przykład jaki jest zakres procesu biznesowego dla danej usługi albo jakie będą handlowe skutki modyfikacji procesu — dzięki którym można osiągać lepsze wyniki.

Przykłady architektury SOA

Do 2010 roku architekturę SOA aktywnie wprowadzały największe przedsiębiorstwa z praktycznie każdej branży. Oto przykłady:

  • Firma Delaware Electric wybrała architekturę SOA, aby zintegrować systemy, które wcześniej nie były ze sobą powiązane, co pomogło przedsiębiorstwu podnieść wydajność projektowania, a w efekcie zachować rentowność podczas pięcioletniego zamrożenia cen energii przez władze krajowe.
  • Firma Cisco wdrożyła architekturę SOA, aby zapewnić spójne środowisko zamawiania produktów we wszystkich kanałach poprzez udostępnienie procesów składania zamówień w modelu usługowym. Procesy te z kolei mogły być wprowadzane w witrynach działów Cisco, przejętych spółek oraz partnerów biznesowych.
  • Firma Independence Blue Cross (IBC) z Filadelfii wprowadziła architekturę SOA, aby różne podmioty obsługujące dane pacjentów — pracownicy obsługi klienta, lekarze, użytkownicy witryny IBC — korzystały z tych samych źródeł danych (stanowiących „jedyną, wiarygodną wersję informacji”).

Architektura SOA a mikrousługi

Specjaliści napisali tysiące opracowań, w których porównywali architekturę SOA z mikrousługami oraz opisywali niuanse związane z ich wzajemnymi relacjami. W rozumieniu niniejszego artykułu kluczowe różnice pomiędzy nimi to połączenie komponentów i zakres użytkowania:

  • Architektura SOA jest pojęciem o charakterze ogólnokorporacyjnym. Pozwala umieszczać istniejące aplikacje na luźno powiązanych interfejsach, z których każdy odpowiada funkcji biznesowej, co pozwala wykorzystać funkcje aplikacji właściwych dla danego obszaru przedsiębiorstwa w innych aplikacjach.
  • Architektura mikrousług jest pojęciem dotyczącym jednej aplikacji. Pozwala ona rozbijać na mniejsze fragmenty wewnętrzne komponenty poszczególnych aplikacji, aby można je było niezależnie zmieniać, skalować i nimi zarządzać. Nie definiuje ona sposobu komunikacji pomiędzy aplikacjami — w tym celu należy wykorzystać korporacyjny zakres usług interfejsu oferowanych w architekturze SOA.

Architektura mikrousług zyskała na znaczeniu wraz ze wzrostem popularności wirtrualizacji, przetwarzania w chmurze, metodyk programowania zwinnego oraz tworzenia i eksploatacji oprogramowania z wykorzystaniem DevOps. Większość korzyści związanych z mikrousługami wynika w tym kontekście z rozłączenia komponentów, co upraszcza i udoskonala niżej opisane elementy:

  • Sprawność i produktywność programisty: mikrousługi pozwalają programistom wprowadzać nowe technologie do jednej części aplikacji bez naruszania jej pozostałych części składowych. Każdy komponent może być modyfikowany, testowany i wdrażany niezależnie od innych, co przyspiesza cykle iteracji.
  • Skalowalność: mikrousługi pozwalają maksymalnie wykorzystać możliwość skalowalności w chmurze — każdy element można rozwijać niezależnie od innych, aby jak najszybciej reagować na potrzeby obciążeń i możliwie wydajnie wykorzystać zasoby obliczeniowe.
  • Odporność: efekt rozdzielenia sprawia też, że awaria jednej mikrousługi nie wpływa na pozostałe. Każda mikrousługa może spełniać własne wymogi dostępności bez narażania innych komponentów lub całej aplikacji na większe wymogi dotyczące dostępności.

Więcej informacji na temat różnic pomiędzy architekturą SOA a mikrousługami znajduje się w części „SOA a mikrousługi: jaka jest różnica?”.

Architektura mikrousług umożliwia udoskonalanie sprawności, skalowalności i odporności podczas projektowania aplikacji, ale tych samych technik można też użyć do integracji. Jest to ważne, ponieważ mocno scentralizowany wzorzec magistrali ESB i powiązanie z nim scentralizowanie zespołu specjalistów ds. integracji mogą z czasem przyczynić się do powstania wąskiego gardła. Podobnie jak w przypadku mikrousług możemy też potencjalnie rozbić magistralę ESB na precyzyjniejsze, bardziej zdecentralizowane integracje. Jest to jeden z podstawowych elementów związanych z integracją zwinną.

Architektura SOA i IBM Cloud

Gdy firma przenosi infrastrukturę IT do chmury hybrydowej, istnieje duże prawdopodobieństwo, że wystąpi konieczność modyfikacji różnych obciążeń, w tym również tych opartych na architekturze SOA, do postaci elastycznych modeli wdrażania w chmurze. IBM jest jednym z pionierów architektury SOA, a oferty i usługi oferowane w ramach IBM Cloud pozwalają wykorzystać potencjał architektury SOA i przenieść ją do chmury.

Wykonaj kolejny krok:

SOA pozwala tworzyć usługi nadające się do wykorzystania w rożnych kanałach bez względu na miejsce, w którym znajduje się podstawowa aplikacja lub baza danych, co pomaga organizacjom wykorzystać inwestycje oraz modernizować aplikacje podczas procesów wdrożenia chmury.

Załóż konto IBM Cloud już dzisiaj.