SOA to styl myślenia o architekturze systemów i aplikacji. Idea zawierająca obietnicę łatwej integracji wielu aplikacji i wielokrotnego wykorzystania tych samych komponentów programowych. SOA nie zakłada wykorzystania żadnej konkretnej technologii i może być realizowana na wiele sposobów, co nie oznacza, że nie stwarza problemów podczas wdrożenia.

Idea SOA (Service Oriented Architecture) jest prosta: twórzmy aplikacje działające jak usługi. Dzięki temu możliwe będzie nieograniczone wykorzystywanie kodu i swobodne łączenie dowolnych aplikacji. Jest to łatwe jedynie w teorii - w praktyce potrzebne są zupełnie nowe narzędzia, metodyki projektowania. Tradycyjny model rozwoju oprogramowania biznesowego SOA stawia bowiem na głowie.

Programiści tworzą zwykle kod na podstawie zestawu dobrze zdefiniowanych wymagań. SOA zmusza natomiast do tworzenia ekosystemu usług, które ostatecznie mogą mieć wielu użytkowników, zarówno w obrębie firmy, jak i poza nią. Prawdziwym wyzwaniem związanym z SOA jest zdobycie wiedzy, gdzie i jak zacząć wyznaczanie zestawu ścisłych wymagań oraz umiejętna budowa uniwersalnych usług - takich, które będą oferować atrakcyjne wskaźniki ROI tu i teraz, a jednocześnie pozostaną podatne na dowolne zmiany w przyszłości.

Niektórzy twierdzą, że tworzenie oprogramowania w zgodzie z zasadami SOA to przede wszystkim stan umysłu, sposób myślenia o usługach informatycznych jako o usługach biznesowych. Pierwsze realizacje SOA pojawiły się, kiedy technologia XML nie była jeszcze popularna, a o standardach SOAP, WSDL czy WS-* prawie nikt nie słyszał.

Ludzie posiadający wizję tworzyli oprogramowanie biznesowe w ten sposób już dawno temu. Znajdowali oparcie w technologiach takich jak CORBA czy SGML. Wizję SOA z pewnością łatwiej zrealizować, dysponując odpowiednimi narzędziami. Od pewnego czasu problem polega jednak na tym, że powstało ich zbyt wiele.

Teorie ewolucji

Technologicznych źródeł SOA należy upatrywać w XML i usługach web. Nikt dzisiaj nie kwestionuje, że komunikaty XML to najlepsze rozwiązanie problemu niskopoziomowych, niezależnych od platformy usług, z których można tworzyć usługi wyższego poziomu wspierające funkcje biznesowe. Myliłby się jednak ten, kto sądziłby, że XML i usługi web wprowadzają ład i porządek do świata SOA. Jest wręcz przeciwnie. Liczba powstałych zaawansowanych standardów przyprawia o zawrót głowy.

IBM, Microsoft oraz inni dostawcy technologii zaproponowali w ostatnim czasie tak wiele standardów dla usług web, że wymyślono nawet osobny opisujący je termin: WS-*, gdzie zamiast "gwiazdki" można podstawić dowolny termin z bardzo długiej listy obejmującej m.in. Addressing, Eventing, Policy, Routing, Reliability, ReliableMessaging, SecureConversation, Security, Transaction czy Trust.

Dla wielu obserwatorów rosnąca liczba WS-standardów niepotrzebnie komplikuje sytuację. Proste formy komunikatów XML odniosły sukces w praktyce zanim powstał którykolwiek ze standardów WS-*. W amerykańskiej firmie Metratech już pod koniec lat 90. stworzono system billingowy zbudowany zgodnie z ideą SOA. Komunikaty wymieniane pomiędzy partnerami były modelowane w XML i transportowane z wykorzystaniem protokołu HTTP z szyfrowaniem SSL, czyli metody wykorzystywanej do dzisiaj w komunikacji pomiędzy usługami web. Podobne projekty były realizowane także w innych dużych przedsiębiorstwach.

Dwa fakty miały wówczas kluczowe znaczenie. Sieć stanowiła proste środowisko integracyjne, którego status z czasem podniesiono do poziomu architektury i nazwano REST (Representational State Transfer). Po drugie, XML dostarczał uniwersalnego sposobu definiowania usług w terminach wywodzących się z treści danych, a nie z terminologii charakterystycznej dla języków programowania, czyli kodu przetwarzającego. Te dwa fakty łącznie były i są najważniejszymi elementami projektów SOA.

W jaki sposób doszło więc do stworzenia ogromnej liczby standardów z grupy WS-*? Jedna z teorii doszukuje się przyczyn tej sytuacji w działaniach największych dostawców technologii, którzy w bliskiej współpracy z największymi klientami i partnerami doprowadzili do takiego skomplikowania pojęciowego, w którym tylko oni mogą się poruszać. Nietrudno zauważyć, że tworzone standardy wybiegają daleko w przyszłość - poza potrzeby większości współczesnych użytkowników. Ich rozwój nie odbywa się w sposób naturalny, nie jest organicznym procesem sterowanym przez dobrze rozpoznane wymagania biznesowe. Patrick Gannon, prezes i dyrektor wykonawczy OASIS, ciała standaryzacyjnego, które koordynuje prace nad wieloma specyfikacjami WS-*, niechętnie przyznaje, że użytkownicy powinni byli w większym stopniu zostać zaangażowani w prace. I to od samego początku.

Niejasna wróżba

Z drugiej strony, nie brak opinii, że największe firmy branży IT sumiennie odrobiły lekcje z zakresu bezpieczeństwa, transakcji i niezawodnej komunikacji. XML spełnia tu rolę całkowicie elastycznego języka opisu obiektów, procesów i danych.

TN Subramaniam, dyrektor ds. technologii firmy RouteOne, która tworzy oprogramowanie do zarządzania kredytami w imieniu dilerów samochodowych, odczuł to na własnej skórze. Na pewnym etapie rozwoju firma podjęła decyzję o samodzielnym tworzeniu specyfikacji dla mechanizmów pojedynczego logowania. Pomysł szybko został zarzucony, po tym jak bliżej zapoznano się ze standardem SAML. Dilerzy powitali decyzję z ogromnym zadowoleniem, ponieważ wykorzystywane przez nich oprogramowanie firm Netegrity i Oblix obsługiwało SAML.

"Jakie są szanse, żeby pięciu architektów spotykających się od czasu do czasu przeanalizowało wszystkie możliwości? Czy nie lepiej zadanie to wykona komitet zajmujący się wyłącznie tym zadaniem, mający na dodatek poparcie dostawców?" - mówi TN Subramaniam.

Spór pomiędzy dwoma podejściami można sprowadzić do przeciwstawienia sobie implementacji oszczędnie korzystających ze standardów i takich, które czerpią z nich garściami, starając się jak najpełniej wykorzystać to, co w sobie niosą. Pierwszy scenariusz, nazwijmy go WS-mini, koncentruje się na szybkości, prostocie i sprawności. Koresponduje z takimi technologiami, jak REST, AJAX czy RSS. Wyznawcy drugiego poglądu, nazwijmy go WS-maxi, skupiają się na bezpieczeństwie, niezawodności i skalowalności.

Większość architektów oprogramowania biznesowego nie chce opowiadać się zdecydowanie po jednej ze stron. Są pragmatykami, którzy koncentrują się na wykonaniu zadania. Warto przyjrzeć się temu, w jaki sposób wykorzystują (lub nie) standardy dla usług web.

Bezpieczny kredyt

Chociaż kompleksowe wykorzystanie SSL w większości przypadków jest w stanie zaspokoić potrzeby RouteOne, firma preferuje bardziej szczegółowe podejście oferowane przez standard WS-Security. Przede wszystkim dlatego, że RouteOne wymaga cyfrowego podpisu na każdym wniosku kredytowym, który jest przesyłany za jej pośrednictwem. Ponadto cały proces musi przebiegać zgodnie z regułami zrozumiałymi przez partnerów biznesowych. WS-Security umożliwia definiowanie takich reguł.

Jedna z metod polega na opakowaniu podpisanego wniosku w "kopertę" SOAP. Druga na potraktowaniu wniosku kredytowego jako załącznika do komunikatu SOAP. Ostatecznie partnerzy nie zgodzili się na zaakceptowanie jednej metody. Dlatego RouteOne stosuje obydwie. Nie jest to komfortowa sytuacja, ale firma woli mieć dwa standardy, niż nie mieć żadnego.

Po drugie, firma musi posiadać logi audytowe transakcji. Nie chce jednak szyfrować całości komunikacji, dlatego wykorzystuje akcelerator XML firmy DataPower, który selektywnie szyfruje wyłącznie najważniejsze z punktu widzenia bezpieczeństwa elementy wniosku kredytowego, np. numer Social Security. Dzięki temu, że WS-Security istnieje jako otwarty standard, akcelerator DataPower może bezpośrednio modyfikować ruch XML tworzony przez aplikację kredytową RouteOne. Co ważne, w każdej chwili urządzenie może zostać zastąpione innym, które tak samo wykona zadanie.

Gdy usługi komunikują się bezpośrednio (wiele, jeśli nie większość, wciąż tak działa), nie ma potrzeby definiowania reguł, które ułatwiają pośrednictwo pomiędzy usługami. Zwolennicy podejścia WS-mini - np. Amazon i eBay - wykorzystują usługi web w układzie punkt-punkt. W takim przypadku nie ma większej różnicy pomiędzy interfejsem API SOAP/WSDL a API REST. Nie powinno więc nikogo dziwić, że programiści, którzy mają do czynienia z obydwoma platformami, preferują REST. Niemniej, tam, gdzie konieczne jest wykorzystanie mechanizmu pośredniczącego w ruchu XML, SOAP i WSDL sprawdzają się lepiej.

TN Subramaniam jest pragmatykiem. Czysty XML przesyłany z wykorzystaniem protokołu HTTP bez WSDL odgrywa pewną rolę w wewnętrznych i zewnętrznych działaniach RouteOne. Stworzenie dedykowanego serwletu do pobierania komunikatów XML jest bardzo proste, dlatego ta metoda stosowana jest wszędzie tam, gdzie jest to możliwe. Niektórzy partnerzy zewnętrzni RouteOne stosują identyczne podejście. Firma nie może nakazać im, by robili to inaczej. Zamiast wymagać jednolitości, RouteOne odbiera przychodzący ruch, a następnie konwertuje go do SOAP i WSDL. W przyszłości ułatwi to wdrożenie zarządzania usługami za pomocą motoru reguł opartego na standardzie BPEL. Partnerzy, którzy nie mają interfejsów SOAP i WSDL, nie są jeszcze w niekorzystnej sytuacji, ale wkrótce może się to zmienić.

RouteOne korzysta zarówno z SAML, jak i WS-Security. Firma chciałaby także móc wykorzystać jakiś standard niezawodnej komunikacji. "Jeśli nie wysyłamy wiadomości, tracimy pieniądze" - mówi TN Subramaniam. Czerpiąc inspirację z ebXML (e-business XML) oraz JMS (Java Message Service), firma wyspecyfikowała - i wraz z partnerami obecnie z niego korzysta - mechanizm, który gwarantuje uporządkowane i niezawodne dostarczanie wiadomości. Firma wolałaby jednak, żeby było inaczej. Trzyma mocno kciuki za organizację OASIS, która pracuje nad połączeniem dwóch w dużej mierze dublujących się standardów: WS-Reliability oraz WS-ReliableMessaging. "Chciałbym mieć jedną spójną specyfikację - wtedy mógłbym zrezygnować z obecnego niestandardowego mechanizmu" - twierdzi Subramaniam.