Korzystamy z profesjonalnych narzędzi takich jak Tibco, WebMethods, czasami Bea.

Co łączy wymienione produkty? Otóż wszystkie są rozwiązaniami z klasy EAI i … są płatne. Zdanie to usłyszałem w odniesieniu do Apache Service Mix, którym się interesuję. Wniosek z tej wypowiedzi jaki udało mi się wysnuć od razu stał się tematem tej noty, czyli jeśli coś nie jest komercyjne nie jest też profesjonalne. Tak jakby OSS był gorszym rozwiązaniem od kupienia licencji na pudełkowe rozwiązanie od jakiegoś producenta.

Trudno mi się z tym zgodzić ponieważ od początku swojej pracy obracam się w otwartym kodzie i niejeden raz korzystałem z wolnodostępnych narzędzi. Pamiętam jedną z sytuacji, gdzie w jednej z bardzo dużych międzynarodowych firm projekt przez pracowników był uważany za profesjonalny ponieważ był kupiony Oracle oraz licencja na jakiś przestarzały serwer. Kuriozalne, im więcej wydasz pieniędzy na licencję tym bardziej projekt jest profesjonalny. Klient dopiero wydając masę pieniędzy na licencję ma prawo powiedzieć, że kupił profesjonalny, będący na wysokim poziomie, produkt.

Zainspirowany tym wszystkim sięgnąłem do słownika języka polskiego PWN w poszukiwania hasła profesjonalny:

profesjonalny
1. będący specjalistą w jakiejś dziedzinie
2. uprawiany jako zawód
3. będący na wysokim poziomie w danej dziedzinie
4. spełniający wymagania profesjonalistów

Definicja słownikowa nie wspomina nic o pieniądzach, ale dodajmy ją w myśl pierwszego, zacytowanego zdania:
1. Jeśli chcesz być specjalistą w jakiejś dziedzinie musisz korzystać z komercyjnych rozwiązań.
3. Wysoki poziom w danej dziedzinie osiągniesz korzystając tylko z komercyjnych produktów.
4. Produkt jest profesjonalny jeśli spełnia wymagania profesjonalistów, a jednym z kryteriów doboru tego narzędzia zgodnie z punktem 1 jest płatność.

Czy zgadzacie się z takimi założeniami? Ja – w ogóle. Nie jestem maniakiem Open Source ani fanatykiem wolnego oprogramowania. Nie jestem też nadmiernym zwolennikiem komercyjnych rozwiązań, ale to co powinno być kluczowe dla każdego programisty a tym bardziej firmy świadczącej usługi programistyczne to szukanie skutecznego rozwiązania problemu a nie wydania pieniędzy.

Reasumując, moje zdanie to:

• Nie wszędzie pasuje OSS.
• Nie wszędzie konieczne są rozwiązania komercyjne.
• Nie zawsze nabycie produktu rozwiązuje wszystkie problemy. Czasami rodzi też nowe.

Warto zwrócić uwagę na to, że producenci oprogramowania czasami mamią i zarzucają nas całą masą marketingu, hasłami i wszelakimi buzzworld typu SOA, AJAX itp. podczas gdy rozwiązania oparte na OSS nie są reklamowane, a zdarza się sytuacje że mają funkcjonalność zbliżoną bądź nawet większą niż komercyjne.

Jakie jest, drodzy czytelnicy, wasze zdanie na temat – czy OSS może być profesjonalny? Co czyni produkt profesjonalnym?

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).