Czym jest ESB

Jednoznaczne określenie terminu ESB nie jest łatwe, ponieważ wokół tego tematu rozpętana została burza marketingowa. Jedni uważają je za oś SOA (Service Oriented Architecture) inni jako zło konieczne w dużych instytucjach.

Dlatego pomijając teorię przejdźmy do najistotniejszych cech, jakie oferuje ESB, niezależnie od producenta oraz osoby definiującej pojęcie. Sam nie chciałbym wdawać się w dyskusję na temat postrzegania i ESB i SOA.

Źródło – CodePlex

Na załączonym wyżej obrazku widać typową strukturę logiczną w oparciu o ESB. Z lewej strony mamy komercyjne rozwiązanie – MQ Series firmy IBM, dalej idąc dołem, widzimy bazę danych, serwer pocztowy a na końcu mainframe. U góry natomiast pojawiają się klienci.

Ciąg dalszy

Na bazie tego obrazku można powiedzieć co nieco o tym, czym owa niebieska rurka symbolizująca ESB jest:

• Jest to z pewnością centralny rejestr usług firmy, dzięki któremu nie jest konieczne wiązanie aplikacji między sobą. Wiąże się je tylko i wyłącznie z jednym elementem – z magistralą.
• Kolejny ważny punkt, to most pomiędzy protokołami. W dobie, gdy wszyscy żyją już Web Services nie można zapomnieć o innych sposobach komunikacji – poczynając od poczciwej Corby po kolejki JMS czy też odczyt zasobów z FTP.
• Transformacja komunikatów to opcjonalna czynność, której nie widać na wyżej wymienionym obrazku. Jest ona wykonywana pod maską, wewnątrz magistrali, w zależności od potrzeb. W chwili gdy mamy komunikaty z systemu A do systemu B możemy wszystko sprowadzić do jednego uniwersalnego API danych.
• Inteligentny router informacji. Większość magistral ma coś wspólnego z pojęciem EIP, czyli Enterprise Integration Patterns. Jednym z tych wzorców jest Content Based Router, to znaczy w zależności od kształtu, zawartości komunikatu, nagłówka, fragmentu, czegokolwiek możemy odbijać komunikat w różnych kierunkach. Dalej z wzorców można wymienić Message Filter, Recipient List, Routing Slip, Wire Tap, Splitter, Resequencer itd.
• Integrator procesów biznesowych (bardziej marketingowo) – po pierwsze odwzorowanie usług magistrali do czynności biznesowych w organizacji a po drugie wsparcie dla procesorów reguł biznesowych (WS-BPEL).

Service Mix jako ESB

Mając zestaw wyżej wymienionych cech możemy przejść do omówienia projektu Apache Service Mix.
Może na początku kilka słów o tym, czym jest JBI, ponieważ pojawia się sam skrót, ale nie ma jego omówienia.
Otóż, JBI w rozwinięciu oznacza Java Business Integration. Jest to standard przyjęty w ramach Java Community Process w celu określenia norm budowania rozwiązań SOA (znów buzzword). Pomijając politykę wielkich korporacji oraz marketing przejdźmy do elementów, które standard ten określa:

Źródło Open ESB Starter Kit

• Typy komponentów:
  1. Service Engine (SE) – backend do obsługi zapytań.
  2. Binding Components (BC) – frontend, do nasłuchiwania w danym standardzie.
  3. Shared Libraries (SL) – kod współdzielony przez w/w komponenty.
  5. Service Assembly (SA) – zbiór usług rozumianych jako jedność przez magistralę (zwykle para BC+SE).
• Normalized Message Router – jest to serce rozwiązania opartego o JBI, ponieważ w nim są transportowane komunikaty. To on zapewnia przepływ informacji z komponentów bindujących do silników.
• Message Exchange Patterns – w oparciu o definicję dla SOAP JBI przewiduje następujące typy komunikatów:
1. In-Only – tylko wejście, usługa nie zwraca żadnej odpowiedzi
2. Rebust In-Only – zwrócony zostanie status po obsłudze zapytania bądź wyjątek.
3. In-Out – standardowa obsługa wejście-wyjście.
4. In Optional-Out – wejście z niewiążącą (nieobowiązkową) odpowiedzią.

Dostępnych jest kilka implementacji JBI:

• Open ESB
• Apache Service Mix
• FUSE ESB (na bazie Service Mix)
• Bostech Chain Builder ESB
• Mule
• JBoss ESB
• Fusion Middleware
• ActiveMatrix Service Bus

Service Mix od środka

Wewnątrz Service Mix jest spięciem kilku potężnych projektów, rozwijanych od dłuższego czasu, które zdobyły już renomę i popularność. Między innymi można wyróżnić:

• Pierwszy z tych projektów to Spring Framework, rozwijany od bodajże 2000 roku, z powodzeniem rywalizujący z architekturami opartymi o EJB. Spring jest nie tylko mechanizmem konfiguracyjnym ale również zbiorem bardzo dobrych komponentów umożliwiających szereg operacji (bazy danych, JMS, przetwarzanie wsadowe, Web Services etc).
• Drugi, bardzo ważny projekt to Active MQ. Największa i najpopularniejsza otwarta implementacja standardu JMS. Jest on używany wewnątrz Service Mix-a jako transporter komunikatów w Normalized Message Router jak i do obsługi końcówek JMS.
  – Wymieniony nieco niżej pod-projekt Active MQ to Camel. Jest to szkielet przeznaczony do tworzenia reguł routingu. Wspiera różnorakie transporty (HTTP, JMS, JBI, MS MQ itp.).
• XBean jest fragmentem projektu Apache Geronimo (serwer aplikacyjny ze stajni Apache) przeznaczonym do tworzenia konfiguracji i zarządzania komponentami. Jest zbudowany w oparciu o Springa.
• Apache CXF jest stosunkowo nowym projektem, który jest używany poprzez Service Mix w celu obsługi zapytań SOAP (chociaż możliwe jest użycie innego komponentu).
• Apache ODE jest silnikiem reguł biznesowych w oparciu o WS-BPEL.
• JBoss Drools jest kolejnym procesorem reguł biznesowych. Może być użyty do routingu. Jest dostępny plugin pozwalający na łatwą pracę z tą technologią.

Możliwości Service Mix

Wyżej wymienione projekty są używane w Service Mix w celu uzyskania typowych funkcjonalności ESB:

• JMS, czyli obsługa kolejek
• WS-BPEL, obsługa reguł biznesowych
• Web Services przy pomocy CXF jak i modułu JSR-181
• Transformacje XSLT oraz XQuery (w oparciu o Saxona)
• File Drop to odczyt i zapis do plików dostępnych lokalnie jak i zdalnie (FTP)
• Obsługa protokołu XMPP pozwala na łatwą integrację z komunikatorami zbudowanymi w oparciu o Jabbera.
• Dostęp do poczty przy pomocy modułu servicemix-mail
• Komponenty programowe:
• Dają możliwość dopisania własnych “endpointów”, czyli implementacji docelowych usług bądź pośredników.
• Dodatkowe funkcjonalności (cache, rss, walidacja)
• Języki skryptowe (min Groovy)

ESB – dlaczego Open Source

Wybór Service Mix-a nie był podyktowany przypadkiem. Jest to bowiem najpopularniejsze tego typu rozwiązanie z otwartym kodem źródłowym. Co więcej, nie jest to projekt rozwijany przez osoby bez doświadczenia, pozostawiony bez wsparcia.
Otwarty kod ułatwia przede wszystkim adaptację tego rozwiązania do potrzeb organizacji a nie odwrotnie – organizacji do potrzeb magistrali. W razie potrzeb jesteśmy w stanie dopisać własne komponenty, obsługę mniej standardowych protokołów na bazie dostarczonych interfejsów czy to w Service Mix czy to w Camelu.
Przyjęte standardy gwarantują ciągłość rozwoju oraz ułatwiają integrację (JMX umożliwia łatwe podpięcie konsoli administracyjnej), podczas gdy J2EE Connector Architecture definiuje kontrakty (zarządzanie połączeniami, transakcjami, bezpieczeństwem).
Nie bez znaczenia jest również koszt, jaki organizacja ponosi w przypadku zdecydowania się na otwarte rozwiązanie. Rozpoczęcie prac z Service Mix-em kosztuje 0 PLN. Każdy, bez rejestracji, podawania jakichkolwiek danych może pobrać źródła albo gotowe dystrybucje i uruchomić je na swoim komputerze. W chwili gdy istnieje takie zapotrzebowanie, organizacja posiada kompetencje i skromny budżet to taka konfiguracja początkowo jest optymalna. Z biegiem czasu gdy zaistnieje konieczność wsparcia czy szkoleń to są one oferowane przez firmę IONA, która jest zaangażowana w rozwój Service Mix-a.

Service Mix a bezpieczeństwo

Większość, jeśli nie wszystkie rozwiązania w Javie, które wiążą się z kryptografią są oparte na JCA – Java Cryptography Architecture. Jest to zestaw interfejsów oraz ich implementacji zawierający implementację najpopularniejszych algorytmów kryptograficznych jak i API umożliwiające tworzenie własnych rozszerzeń (JCE).
Standard autoryzacji i uwierzytelniania w Javie to JAAS (Java Authentication and Authorization Service). W oparciu o niego jest budowanych większość rozwiązań związanych z bezpieczeństwem. Nawet największe alternatywy takie jak Acegi Security (obecnie Spring Security posiadają adaptery integrujące je ze standardem). Przy użyciu dostępnych interfejsów możliwe jest dostarczenie własnej implementacji usługi obsługującej autoryzację bądź uwierzytelnianie użytkowników/systemów.
Bezpieczeństwo usług sieciowych jest zależne od wybranego komponentu Service Mix. Pełne wsparcie dla WS-Security oferują komponenty zbudowane w oparciu o Apache CXF (szyfrowanie, podpisywanie komunikatów). Z innych standardów CXF wspiera także WS-Policy, WS-Addressing.
Szyfrowane połączenia są łatwe do uzyskania przy pomocy komponentu servicemi-http.
Dostępne zabezpieczenia na poziomie wirtualnej maszyny Javy to certyfikowanie (podpisywanie) kodu modułów oraz konfiguracja Security Managera (umożliwia wyłączenie dostępu do pakietów/klas/metod).