Architektura zorientowana na usługi (ang. service oriented architecture), SOA stała się popularnym terminem pojawiającym się na wszelkich etykietach dostępnego oprogramowania klasy enterprise. Praktycznie każdy dostawca chwali się, że dostarcza produkty “zgodne z SOA”. Wiele firm dało się skusić na kupienie produktu oznaczonego znaczkiem SOA z myślą, że zainstalują taki produkt i będą od tego momentu “robić SOA”… No cóż, SOA to nie systemy, a podejście, które trzeba wdrożyć by czerpać z niego korzyści.
Głównymi zaletami wprowadzenia SOA jest harmonijny rozwój środowiska systemów w przedsiębiorstwie, dodatkowym atutem przemawiającym na korzyść wprowadzenia SOA jest możliwość ponownego użycia istniejących usług podczas wdrażania nowych funkcjonalności.
Niedawno na stronach Trzeciej Kawy pisałem o typowej architekturze systemów internetowych. Dziś postaram się zebrać trochę informacji o architekturze zorientowanej na usługi i o tym, jak praktycznie można zmierzyć się z takim podejściem do tworzenia systemów. Szereg informacji na temat referecyjnej architektury SOA można znaleść na stronach The OpenGroup [1].
Czym jest architektura zorientowana na usługi i jak robić SOA?
Cegiełką budowlaną architektury w SOA jest usługa – najlepiej uniwersalna, dostępna i użyteczna.
Posłużę się próbą tłumaczenia definicji z książki „Software engineering” rozdział 19 [2]:
„SOA to sposób budowy systemów, w których komponenty systemowe udostępniają samodzielne usługi uruchamiane w środowisku rozproszonym”
Przykładem usługi może być usługa złożenia zamówienia świadczona w kanale elektronicznym. W praktycznym podejściu, z jakim miałem do czynienia, wydzielono usługi biznesowe oraz techniczne. Usługi techniczne odpowiadają za realizację usługi biznesowej przy użyciu konkretnego systemu, procedury itp.
W celu lepszego zrozumienia tematu posłużmy się przykładem sklepu internetowego – usługa sprzedaży towaru lub funkcja biznesowa (ang. business capability) w kanale elektronicznym można dekomponować na szereg usług biznesowych, takich jak:
- rejestracja konta,
- uwierzytelnianie,
- złożenie zamówienia – wybór towaru (rezerwacja towaru),
- złożenie zamówienia – wybór metody płatności,
- złożenie zamówienia – wybór sposobu dostawy,
- realizacja zapłaty,
- kompletacja zamówienia – przygotowanie paczki,
- dostawa (w tym śledzenie przesyłki).
Powyższa lista usług może zostać zamodelowana jako proces biznesowy.
Wybierzmy usługę rejestracji i zobaczmy z jakich usług technicznych mogłyby się składać:
- submitForm,
- confirmProfileOperation,
- manageCustomer,
- manageCustomerProfile.
W SOA istotnym elementem są komponenty udostępniające usługę (ang. service provider) oraz wywołujące usługę (ang. service consumer), czasem wskazuje się również stronę inicjującą (ang. initiator). W kolejnym kroku określamy umiejscowienie usług w nowych lub istniejących systemach.
Usługa rejestracji konta klienta w elektronicznym kanale sprzedaży
Załóżmy, że internetowy kanał sprzedaży jest w przedsiębiorstwie nowym pomysłem, który do tej pory nie istniał, natomiast przedsiębiorstwo posiadało już system CRM, w którym świadczono usługę sprzedaży bezpośredniej. Firma nie posiada szyny danych ESB (ang. enterprise service bus) i integruje systemy w sposób bezpośrednich wywołań, czyli punkt-punkt (ang. point-to-point). Usługa rejestracji można przedstawić na diagramie koncepcji.
Rysunek 1. Diagram koncepcji usługi rejestracji
Każda ze strzałek na diagramie przedstawia przepływ danych i wywołanie usługi. Przebieg wywołania operacji wyglądałby następująco:
- Klient rejestruje konto na portalu w eShop poprzez wywołanie akcji formatki rejestracyjnej,
- eShop tworzy profil klienta (manageCustomerProfile z akcją “utwórz”) zawierający e-mail oraz hasło i wysyła e-mail z linkiem do potwierdzenia rejestracji na wskazany adres,
- eShop wywołuje usługę manageCustomer w CRM przekazując dane klienta z akcją utworzenia konta klienta z akcją “utwórz”,
- Klient wciska link potwierdzający akcję utworzenia profilu w eShop (confirmProfileOperation),
- eShop wywołuje manageCustomerProfile oraz manageCustomer w CRM z akcją update ustawiając konto jako aktywne.
Warto zauważyć, że powyższa rozwiązanie pozwala również obsłużyć przypadek (usługę) usunięcia konta, dla którego przebieg wywołań wyglądałby następująco:
- Klient wybiera na formularzu znacznik usunięcia konta i wywołuje akcję “usuń”,
- eShop wysyła e-mail do klienta z linkiem potwierdzającym zlecenie usunięcia,
- Klient klika potwierdzenie w wiadomości e-mail,
- eShop wywołuje manageCustomer w CRM zlecając usunięcie klienta akcją “usuń”,
- eShop wywołue manageCustomerProfile z akcją delete i wysyła maila z potwierdzeniem usunięcia konta do klienta.
Usługa wysyłki e-mail została celowo pominięta dla uproszczenia i mogłaby być opisana na osobnym diagramie.
SOA z ESB i BPM
Jeżeli przedsiębiorstwo dysponuje oprogramowaniem szyny usług, to może wykorzystać ją do integracji systemów z zastosowaniem usług nadających się do re-użycia.
Dodatkowym atutem jest posiadanie silnika procesów (ang. business processes management) oraz silnika reguł biznesowych (ang. business rule management), dzięki któremu można zbudować logikę w ramach integracji.
Rysunek 2. Diagram koncepcji usługi rejestracji – ESB/BPM
Na pierwszy rzut oka w rozpatrywanym przykładzie różnica w rozwiązaniu jest niewielka w stosunku do wersji bez ESB/BPM, jednakże pozwala na umiejscowienie logiki tworzenia konta klienta poza systemami, a co za tym idzie w miarę proste rozszerzenia np. dodanie kolejnego kroku, który tworzyłby konto klienta (np. w systemie fakturowania) oraz pozwala na udostępnienie usługi manageCustomer innym systemom, co pozwalałoby na przykład na utworzenie konta klienta (np. z systemu CRM). Dodatkową zaletą zastosowania szyny danych jest na przykład umożliwienie kolejkowania zleceń utworzenia konta do systemu CRM co poprawiłoby wydajność tworzenia konta itp.
W scenariuszu bez ESB/BPM też byłoby możliwe, aby usługa tworzenia konta wywoływana z innych systemów, ale wymagałoby dodatkowego udostępnienia usługi dla systemu CRM w systemie eShop.
Podsumowanie
Specjalnie nie poruszałem takich tematów, jak możliwe scenariusze integracji między systemami, SOA governance i inne, gdyż mógłby być to być materiał na zupełnie osobny artykuł. W powyższym przykładzie mam nadzieję, że udało mi się przedstawić główne założenia dotyczące budowania architektury zorientowanej na usługi na przykładzie sklepu internetowego i usługi rejestracji klienta. Jak widać zamodelowanie tak prostej usługi wymaga sporego wysiłku, ale wysiłek ten przekłada się na klarowny obraz architektury z pełnym zrozumieniem jej ograniczeń i możliwości. Co na ten temat myślicie? Jakie są wasze doświadczenia w budowaniu SOA?
Materiały:
[1] The OpenGroup “The SOA Book” http://www.opengroup.org/soa/source-book/soa/index.htm
[2] Ian Summmerville “Software Engineering” http://www.amazon.co.uk/Software-Engineering-Ian-Sommerville/dp/0137035152