SOA i middleware

Architektura zorientowana na usługi (SOA) kojarzy się z zastosowaniem oprogramowania pośredniczącego nazywanego potocznie międzymordziem (ang. middleware). W poprzednim wpisie na temat SOA próbowałem na przykładzie opisać czym jest SOA w scenariusze z i bez ESB. W tym wpisie postaram się wyjaśnić jak middleware może pomóc przy budowaniu architektury zorientowanej na usługi.

Zdarza się, że przedsiębiorstwa inwestują w narzędzia middleware nie do końca wiedząc do czego i kiedy warto je stosować. Wiąże się to z kilkoma problemami: wiedza na temat integracji jest dosyć mało rozpowszechnioną dziedziną, a produkty oznaczone plakietką SOA oferują bardzo specyficzne metody według własnej filozofii. Temat SOA również rozumiany w środowisku informatycznym bywa w rożny sposób.

Wiele ciekawych i pożytecznych informacji dotyczących SOA znajduje się na stronach angielskiej wikipedii [1], bardzo polecam lekturę.

Obecnie dostępne na rynku oprogramowanie pośredniczące spełnia wiele pryncypiów SOA znacznie ułatwiając wprowadzenie SOA w przedsiębiorstwie. Oczywiście nie zawsze potrzeba stosować middleware by wdrażać SOA co przedstawiłem już w poprzednim wpisie.

Zastosowanie narzędzi middleware pozwala na:

• Ułatwienie integracji między systemami, szczególnie COTS (ang. Commercial off-the-shelf),
• Umożliwienie współdzielenia, a dokładniej współużytkowania usługi przez wielu klientów,
• Translacje modeli transportowych jednego systemu/domeny na drugi,
• Implementację wspólnej logiki poza systemami dziedzinowymi,

oraz aspekty niefunkcjonalne:

• Bezpieczeństwo – Implementację zabezpieczeń dostępu do usługi (terminacja HTTPS, uwierzytelnianie),
• Kontrola obciążenia – sterowanie przepływnością (ang. Throttling), rozłożenie obciążenia (ang. Load balancing),
• Monitorowanie – logowanie, notyfikowanie.

Middleware, a SOA

W ramach middleware głównymi komponentami najczęściej stosowanymi są:

• Szyna usług ESB (ang. Enterprise Service Bus),
• Serwer kolejek wiadomości (ang. Message Broker),
• Serwer przesyłania plików (ang. File Broker),
• Silnik procesów BPM (ang. Business Proces Management),
• Silnik reguł biznesowych BRM (ang. Business Rules Management),
• Serwer usług identyfikacyjnych IM (ang. Identity Management).

Zastosowanie powyższych komponentów daje w zestawie narzędzia do swobodnego integrowania systemów w przedsiębiorstwie, zarówno istniejących jak i nowo wdrażanych.
Integrując systemy należy pamiętać, że:

Głównym założeniem SOA jest umiejscowienie usługi, jako podstawowego elementu budulcowego.

Middleware nie musi służyć do budowania SOA, często oprogramowanie pośredniczące wykorzystywane jest do przekazywania komunikatów, w ramach wzorca integracyjnego, tzw. Message Oriented Middleware (MOM) [2].

ESB umożliwia w miarę prostą ekspozycję usług dla wielu klientów, translację i modelu danych, czy umiejscowienie usług adapterowych.

Wzorce integracyjne SOA z zastosowaniem ESB

Wiele już pisano i publikowano na temat wzorców integracyjnych – bardzo polecam lekturę Enterprise Integration Patterns Gregor Hohpe, Bobby Woolf [3], poniżej podaję te, które z mojego doświadczenia stosowane są najczęściej.

Podstawowe cegiełki budulcowe

Poniżej przedstawiam główne klocki, z których dalej przedstawię podstawowe wzorce budowania usług w oparciu o middleware.

      

Klient usługi (konsument) – oprogramowanie klienckie wywołujące usługę.

Dostawca usługi – system, bądź oprogramowanie dostarczające usługę.

Adapter – usługa upraszczająca i ułatwiająca dostęp do strony świadczącej usługę. Dobrym przykładem adaptera jest oprogramowanie umożliwiające dostęp przez http do systemów mainfraime takich jak HLR-y w telekomunikacji lub systemy księgowe w bankowości, które zazwyczaj udostępniają usługi w oparciu o telnet. Rolą adaptera w takm przypadku staje się no ogół utrzymanie puli połączeń i udostępnienie wygodniejszego interfejsu przez WebServices.

Usługa kanałowa – rodzaj usługi mającej na celu przystosowanie usługi współdzielonej do modelu transportowego i metody integracji preferowanej przez klienta. Bardzo istotne jest by pamiętać, że model danych parametrów wywołania usługi kanału powinien być zgodny z modelem klienta.

Usługa proxy – to usługa pośrednicząca realizująca podstawową obsługę techniczną oferowaną przez szynę usług (np. logowanie, uwierzytelnianie). Dobrym przykładem może być użycie usłgi proxy w celu wstrzyknięcia do komunikatów SOAP Header’a, którego wymaga dostawca usługi.

Usługa wewnętrzna – szyny usług, której głównym celem jest transformacja, kompozycja i wzbogacanie (ang. enrichment) realizacji usługi.

Usługa pośrednicząca (ang. Proxy)

Proste usługi pośredniczące pozwalają na użycie funkcjonalności szyny danych bez skomplikowanych transformacji komunikatów. Ten wzorzec głównie stosowany jest by móc użyć technicznych usług udostępnianych przez szynę (np. load balancing).

Rysunek 1. Proxy service

Usługa pośrednicząca z adapterem (ang. Proxy-adapter)

Usługa pośrednicząca może zostać użyta w połączeniu z adapterem. Usługa pośrednicząca uzupełnia adapter o funkcje techniczne udostępniane przez szynę usług.

Rysunek 2. Proxy-adapter service

Kanał-usługa-adapter (ang. Channel-service-adapter)

Jeżeli usługa posiada więcej niż jednego konsumenta można wydzielić kanał dla niego dedykowany dostosowując sposób wołania zgodnie z jego wymaganiami.

Rysunek 3. Klient – usługa – adapter

Usługa kompozytowa (ang. Composite)

Realizacja usługi kompozytowe wymaga wywołania kilku usług. Podstawowym problemem z usługą kompozytową jest obsługa transakcyjności.

Rysunek 4. Usługa kompozytowa z kanałem i adapterem

Kontekst biznesowy (ang. Business context)

Jest to wzorzec do zastosowania już na poziomie przesyłanych komunikatów. Komunikaty przesyłane pomiędzy systemami powinny zawierać sekcję zawierającą kontekst biznesowy. Kontekst biznesowy pozwala łatwiejsze pobranie brakujących danych (w poniższym przykładzie np. danych klienta po customerId) oraz jest bardzo pomocny w przeglądaniu logów. Jeżeli używamy SOAP to sekcja busnessContext może zostać umieszczona w SOAP Header.

<businessContext>
<customerId>CUST1101010101</customerId>
<orderId>ORD101010101</orderId>
<userId>USER123456789</userId>
</businessContext>

Kontekst techniczny (ang. Technical context)

Uzupełnieniem dla kontekstu biznesowego jest kontekst techniczny. W ramach kontekstu technicznego można przesłać dodatkowe dane podczas wywoałania usługi na odpowiednie przekierowanie komunikatów (np. odpowiedzi). Jeżeli używamy SOAP to sekcja technicalContext może zostać umieszczona w SOAP Header.

<technicalContext>
<callerId>CRM</callerId>
<correlationId>030B4A82-1B7C-11CF-9D53-00AA003C9CB6</correlationId>
<sessionId>1A530637289A03B07199A44E8D531427</sessionId>
<transactionId>1234-5678-9012-3456</transactionId>
<processInstanceId>PROC123456789</processInstanceId>
<test>true</test>
<timestamp>2014-08-19T17:50:34+00:00</timestamp>
</technicalContext>

Identyfikator korelujący correlationId służy do skojarzenia odpowiedzi asynchronicznej systemu, zazwyczaj jest to generowany automatycznie przez system zlecający lub odbierający wywołanie.

Dodatkowymi identyfikatorami możliwymi do zastosowania, to identyfikator sesji użytkownika, transakcji dla identyfikacji kilku spiętych ze sobą jedną transakcją operacji oraz procesu dla identyfikacji wszystkich zawołanych usług w ramach jednego procesu przetwarzania.

Osobiście jestem przeciwnikiem stosowania wszelkich dodatkowych identyfikatorów niezwiązanych bezpośrednio z logiką systemów, gdyż tego typu techniczne funkcjonalności powinny być zapewnione przez systemy.

Pewnym ciekawym wytrychem jest wprowadzenie flagi informującej o tym, że wywyołanie usługi ma charakter testowy (flaga test), co pozwala testować odpoweidź usługi bez wpływu na dane w systemie (test odpowiedzi na komunikat).

Usługi mapowań identyfikatorów

Mapowanie identyfikatorów pozwala na przetłumaczenie identyfikatora instancji lub klasy tego samego obiektu w jednym systemie na identyfikator obiektu w innym systemie. Na przykład identyfikator klienta w systemie eCare może mieć postać CUST001 natomiast w systemie bilingowym będzie miał odpowiednik ACC123. Identyfikator produktu w systemie CRM może mieć nazwę CLIR0001 a w systemie bilingowym 1234-CLIR, dlatego też powinien istnieć słownik potrafiący przetłumaczyć jeden identyfikator na drugi.

Bezpieczeństwo

Z pragmatycznego punktu widzenia często wystarczającymi zabezpieczeniem jest zastosowanie protokołu HTTPS+Basic authentication, oczywiście można pokusić się o bardziej skomplikowane rozwiązania zaprzęgające do użycia SAML2, czy Kerberos, ale to zależy od konkretnego produktu jakim dysponujemy.

Na poziomie przesyłanych danych możliwym podejściem jest zastosowanie WS-Security, jednak nie będzie to zupełnie za darmo, gdyż szyfrowanie skutkuje mniejszą przepustowością.

Poglądowa architektura dla integracji on-line

Na rysunku 4 znajduje się poglądowy schemat architektury integracji on-line dla przedsiębiorstwa. Kolorami oznaczono strefy bezpieczeństwa odzwierciedlające również poziom zaufania do ruchu w sieci produkcyjnej. Zastosowanie zewnętrznej szyny integracyjnej (ESB EXTERNAL) pozwala na zastosowanie wzorca fasady.

Rysunek 4. Poglądowy diagram architektury środowiska z zastosowaniem szyny danych

Szyna wewnętrzna udostępnia usługi w ramach integracji między systemami, ale możliwa jest też komunikacja point-to-point, jednak powoduje to ściślejsze powiązanie systemów.

Podsumowanie

Middleware bywa postrzegany jako zbędne i trudne narzędzie i można się bez niego obejść, jednak jeżeli wdrażamy w dużym przedsiębiorstwie architekturę zorientowaną na usługi może stać się jedynym rozsądnym narzędziem, które przyjdzie Ci z pomocą. Czyżby prawdziwym jest stwierdzenie, że każdy ma takie SOA na jakie sobie zasłużył?

Materiały

[1] SOA, http://en.wikipedia.org/wiki/Service-oriented_architecture

[2] MOM, http://en.wikipedia.org/wiki/Message-oriented_middleware

[3] Enterprise Integration Patterns, http://books.google.pl/books/about/Enterprise_Integration_Patterns.html?id=dH9zp14-1KYC, http://www.eaipatterns.com/