Alternatywa dla SOA

Wyniki najnowszej ankiety przeprowadzonej wśród firm, które zaadaptowały rozwiązania wykorzystujące koncepcję architektury zorientowanej na usługi (Service-Oriented Architecture – SOA), wykazują, że rozwój SOA utknął w fazie oczekiwań – uważa Ann Thomas Manes, analityk w Burton Group (Midvale, USA).

„Twierdzę, że w większości firm architektura SOA nie sprawdza się” – napisała badaczka w swoim blogu. W dodatku w większości podmiotów, które zaangażowały się w tę koncepcję, „jeszcze nie udowodniono, w jaki sposób architektura ta przynosi jakiekolwiek korzyści biznesowi”.

Z architekturą SOA wiązano nadzieje, które pierwotnie miała spełnić koncepcja integracji aplikacji przedsiębiorstwa (Enterprise Application Integration – EAI). Spodziewano się jednak dodatkowej wartości dla biznesu, niemożliwej do zrealizowania w przypadku zastosowania EAI.

Produkty wszystkich największych dostawców platform korporacyjnych, takich jak IBM, BEA Systems, Microsoft, Oracle i SAP, do określania rodzajów znaczników autoryzacji wykorzystują komunikaty SOAP, deskryptory usług WSDL i specyfikację WS-Security. Dlatego rosły nadzieje, że usługi internetowe (Web services) przyniosą obiecywane korzyści z rozwiązań opartych na architekturze SOA.

Tymczasem coroczna ankieta przeprowadzona przez Forrester Research (Cambridge, USA) ujawniła, że idea SOA nie rzuciła biznesmenów na kolana. Do końca 2007 r. wdrażano lub planowano wdrożyć rozwiązanie oparte na architekturze SOA w dwóch trzecich badanych firm. Gdy jednak temat miał wyjść poza fazę programów pilotażowych i projektów grup roboczych, zaledwie niecałe 25% firm uznało, że wdroży tę architekturę jako standardowe, ogólnofirmowe rozwiązanie.

SOA w przebraniu

Złożoność koncepcji SOA wywołała gwałtowną reakcję rynku. Co najmniej 80% odnoszących się do niej standardów zatwierdziły lub mają zatwierdzić organizacje normalizacyjne, takie jak OASIS czy W3C. W gąszczu standardów łatwo dostrzec pokrywające się specyfikacje, np. SAML i WS-Federation, dotyczące tożsamości federacyjnej i stosowane przez różne grupy dostawców w rozmaitych konfiguracjach. Kolejną przeszkodą jest konieczność tworzenia poprawnych komunikatów SOAP, czyli zapewnienia zgodności składni nagłówków z określonymi standardami.

Nic więc dziwnego, że wobec trudności ze specyfikowaniem komunikatów SOAP dostawcy zdecydowali się opracować „specyfi- kację kompatybilności” WS-Interoperability do kontrolowania, czy określone komunikaty usług sieciowych mogą być wymieniane między platformami różnych dostawców. Podobne trudności z porozumiewaniem się oprogramowania przez lata dawały się we znaki użytkownikom sieci biznesowych wykorzystujących koncepcję elektronicznej wymiany danych EDI.

Wobec tego rodzaju problemów pewna grupa dostawców postanowiła promować rozwiązania alternatywne, polegające na ukryciu techniki usług internetowych albo na powrocie do podstawowych technik internetowych.

Na przykład świadcząca usługi informatyczne firma StrikeIron oferuje dane do realizacji takich usług, jak kontrola wiarygodności kredytowej Dun & Bradstreet, kontrola przestrzegania ustawy U.S. Patriot Act, korekta adresów z całego świata, kontrola ważności adresów e-mail, informacja o podatku obrotowym według kodu pocztowego oraz wywiad gospodarczy dla klientów i partnerów biznesowych.

Grupa firm software’owych postanowiła promować rozwiązania alternatywne, polegające na ukryciu techniki usług internetowych albo na powrocie do podstawowych technik internetowych

Wprawdzie klienci StrikeIron korzystają z tych usług na zasadzie usług internetowych, ale nie muszą modyfikować architektury swoich systemów. Wystarczy, że zainstalują w nich interfejs API do pobierania danych albo wtyczkę programu Microsoft Excel w celu przesyłania danych do wewnętrznych arkuszy kalkulacyjnych.

– Nasza oferta jest przeznaczona dla firm, które nie wydadzą kilku milionów dolarów na zbudowanie platformy SOA – wyjaśnia David Linthicum, dyrektor generalny StrikeIron.

Podobne podejście, polegające na ukryciu „szwów” integracji, przyjął Infor – dostawca oprogramowania dla przedsiębiorstw produkcyjnych.

– Nasi klienci nie zwracają się do nas specjalnie ze względu na architekturę SOA – mówi Jeremy Suratt, starszy kierownik marketingu produktów w Inforze. Specjaliści Infora obywają się bez standardów usług internetowych, takich jak specyfikacja formatu komunikatu SOAP czy protokół rozplanowania lub uszeregowania wielu usług w ramach przepływu pracy lub procesu BPEL. Zamiast tego stosują architekturę zarządzaną zdarzeniami, realizującą zapytania przez specyfikację REST – alternatywę prostszą od SOAP. W ramach specyfikacji REST stosunkowo proste żądania usług, podobne do kwerend baz danych, są przesyłane za pośrednictwem protokołu HTTP pod wskazany adres internetowy dostawcy usług. Dzięki temu rozwiązaniu usługi są traktowane jako zasoby.

Podobne podejście przyjął Amazon, udostępniając klientom swój szkielet zasobów obliczeniowych i usług e-commerce przez stosunkowo proste usługi oparte na specyfikacji REST. Takie usługi, jak zarządzanie fakturami i rachunkami, obsługa płatności, realizacja zamówień detalicznych, proste kwerendy w bazach danych czy kolejkowanie wiadomości, oferuje już coraz większa grupa niezależnych dostawców, a do bardziej zaawansowanych aplikacji udostępnianych na żądanie zalicza się oprogramowanie do pracy zespołowej i podstawowej obsługi sprzedaży czy aplikacje ERP i CRM.

Architektura ukierunkowana na Internet

Nawiązując do sukcesów usług Amazon Web Services, zaliczających się do nurtu „powrotu do podstaw”, analityk Gartner Group (Stamford, USA) Nick Gall ukuł termin „architektura ukierunkowana na Internet” (Web-Oriented Architecture – WOA). Termin odnosi się do zastosowania typowych technik internetowych do realizacji zadań w sposób przypominający koncepcję architektury SOA (Service-Oriented Architecture). Chodzi przecież o te same techniki, z których korzystają internauci, ręcznie komunikując się ze stronami internetowymi w celu ustanowienia automatycznych łączy.

Podobnie jak w technice Ajax wykorzystuje się skrypty JavaScript, XML i HTTP do tworzenia bogatych programów-klientów. Koncepcja WOA odpowiada za automatyzację komunikacji internetowej na bazie istniejących technik.

Oznacza to, że zamiast koperty SOAP (Simple Object Access Protocol) na adres URI (zasób informacyjny) lub URL jest wysyłany tzw. POX – tradycyjny komunikat XML. Natomiast do wyszukiwania zasobów URI na żądanie usługi REST służy – zamiast rejestru usług internetowych UDDI – zwykła wyszukiwarka internetowa.

„Dane są wszędzie, ale trudno je użytkować. Jeżeli są umieszczone w bardzo skomplikowanej strukturze, potrzebni są dobrzy programiści, żeby do nich dotrzeć”

Chris Marino, dyrektor generalny SnapLogic

Opcjonalnie w koncepcji WOA stosuje się podstawowy format wymiany danych JSON (JavaScript Object Notation), który podobnie jak XML może być odczytany przez użytkownika, a także łatwo zanalizowany i zrozumiany przez komputer. Jest to możliwe, ponieważ protokół HTTP obsługuje podstawowe działania przypominające operacje bazodanowe, takie jak get (pobierz dane), put (umieść dokument na innym serwerze internetowym), post (wstaw nowe dane) i delete (skasuj dane).

Jedną z firm, której specjalistom idea WOA szczególnie przypadła do gustu, jest One SnapLogic, założona przez weteranów z firmy Informatica. SnapLogic rozwija własną ofertę usług udostępniania danych, promowaną hasłem „Really Simple Integration” – „Naprawdę prosta integracja”.

Wykorzystując prosty serwer internetowy typu open source Apache Tomcat, użytkownicy łączą się z usługami dostępu do danych oznaczonymi ich własnym adresem URI. Jeżeli klient zdecyduje się udzielić zezwolenia na dostęp do określonych usług tylko wybranym pracownikom, wystarczy, że będzie kontrolował przydział dostępu do odpowiednich adresów URI dla poszczególnych użytkowników.

Kontrola dostępu nie jest zatem realizowana na siłę przez uwierzytelnianie usług internetowych lub standard tożsamości federacyjnej, ale przez wewnętrzny katalog lub systemy kontroli dostępu. A ponieważ metadane są indeksowane w standardzie HTML, mogą być przeszukiwane za pomocą Google lub dowolnej wyszukiwarki internetowej.

– Dane są wszędzie, ale trudno je użytkować. Jeżeli są umieszczone w bardzo skomplikowanej strukturze, potrzebni są dobrzy programiści, żeby do nich dotrzeć – tłumaczy dyrektor SnapLogic, Chris Marino. – Pojawienie się koncepcji Web 2.0 wykazało, że aby zapewnić sprawny dostęp do danych, warto wrócić do podstawowych technik internetowych.

Autor: Tony Baer, MBT USA