SOA, obietnica wszystkiego

Promowanie SOA odbywa się w atmosferze braku zgody co do tego, czym dokładnie SOA jest i czemu głównie ma służyć. Co gorsza, architektury SOA, bez względu na ich definicje, stwarzają wiele całkiem nowych problemów.

Promowanie SOA odbywa się w atmosferze braku zgody co do tego, czym dokładnie SOA jest i czemu głównie ma służyć. Co gorsza, architektury SOA, bez względu na ich definicje, stwarzają wiele całkiem nowych problemów.

Co słychać? Zależy gdzie ucho przyłożyć. Tak wygląda, najkrócej rzecz ujmując, sytuacja firm poszukujących odpowiedzi na pytanie, czy SOA to coś właściwego dla nich. O rozlicznych zaletach SOA mówią wszyscy dostawcy infrastruktury informatycznej, jednak w trochę inny sposób: każdy z nich inaczej definiuje zakres architektury SOA, inaczej kreśli jej warstwy, inaczej rozkłada akcenty po stronie korzyści i inaczej unika trudnych pytań o koszty i problemy.

W związku z brakiem jednolitej wizji i definicji SOA bardziej świadomi, doświadczeni klienci korporacyjni stawiają dostawcom wymaganie standaryzacji. Niestety, także i na tym polu nie ma zgody między dostawcami. Począwszy od fundamentów technicznych, poprzez metody budowy środowisk, aż po mechanizmy zarządzania nimi - wszędzie mamy do czynienia z chórem wzajemnie niespójnych propozycji.

Niektórzy twierdzą, że wdrożenie architektury SOA w dowolnym kształcie i zakresie jest dla firmy lepsze, niż trwanie przy obecnych architekturach integracyjnych. Udowodnienie tak odważnej tezy firmom, które już poradziły sobie z podstawowymi problemami integracji, wcale nie jest pewne. Duże firmy nieraz były mamione obietnicami rozwiązania problemów integracyjnych i dobrze pamiętają, że lepsze częstokroć bywa wrogiem dobrego. A więc, co dalej?

Powtórka w nowej skórce

Wróćmy do początku, czyli genezy samej potrzeby integracji aplikacji. Miała ona być lekarstwem na niemożność wymiany danych między aplikacjami pochodzącymi od różnych producentów. Z biegiem czasu sama integracja stała się specyficzną warstwą aplikacyjną, umożliwiającą definiowanie procesów jako ciągów interakcji obejmujących funkcje wielu różnych aplikacji.

Czy dokładnie o to chodziło klientom? Czy tworzenie coraz bardziej zaawansowanych aplikacji integracyjnych, często wyręczających normalne aplikacje, ma być długookresowym remedium na skomplikowanie informatyki wspomagającej biznes? Skomplikowanie, dodajmy, powstałe w wyniku niechęci dostawców do standaryzacji. To pytania retoryczne, a jednak tak właśnie wygląda sedno propozycji większości firm oferujących przeróżne rozwiązania z dopiskiem SOA.

Dostawcy mówią: patrzcie, mamy tu piękną wizję, ale aby się ziściła, trzeba zainwestować w modyfikację aplikacji w taki czy inny sposób. Dopiero potem będzie można nimi wygodnie zarządzać, definiować, uruchamiać procesy itd. Szkopuł w tym, że w przypadku każdego z dostawców modyfikacja aplikacji wygląda inaczej, inna jest struktura komunikatów, inna logika sterująca nimi, inne narzędzia do definiowania procesów, inna "głębokość" zarządzania itd.

Innymi słowy, wracamy do punktu wyjścia, tyle że w warunkach znacznie większej komplikacji środowisk aplikacyjnych. Cóż bowiem z tego, że funkcjonalność tej czy innej aplikacji zostanie udostępniona za pośrednictwem usług Web? Usługa Web to tylko kolejna technologia wywołania określonej funkcji w aplikacji. Jeśli architektura SOA ma polegać na tym, że zamiast wywołań RPC stosowane będą komunikaty XML, z punktu widzenia skomplikowania integracji nic się nie zmieni - ani na jotę - za to na pewno wydane zostaną pieniądze.

Opór zdrowego rozsądku

Dla firm, które dopiero co nauczyły się wykorzystywać środowiska integracyjne oparte na brokerach komunikatów, usługi Web nie są dostatecznym powodem do kolejnej "wielkiej zmiany".

Inwestycje w nową architekturę usprawiedliwiają wielorakie korzyści na wielu poziomach - zwłaszcza gdy przyczyniają się do uproszczenia zarządzania procesami i poprawy ich efektywności. Brokery zapewniają automatyzację komunikacji i automatyzm konwersji danych "w locie" i w tym sensie spełniły oczekiwania klientów. Dla wielu z nich właśnie brokery będą sednem integracji jeszcze przez wiele lat.

Klienci nie spieszą się z wdrażaniem SOA nie tylko dlatego, że na razie nie widzą namacalnej wartości biznesowej istotnie większej niż to, co oferują brokery. Granicą biznesowej efektywności współczesnych środowisk integracyjnych nie jest taka czy inna technologia integracyjna, lecz to jak działają poszczególne aplikacje, jakie założenia leżą u ich podstaw. W zdecydowanej większości przypadków założenia te pochodzą z całkiem innej informatycznej epoki i firmy podskórnie czują, że budowanie nowej architektury na bazie dotychczasowych rozwiązań nie jest całkiem rozsądne.

Dostawcy przekonują, że "SOA nie polega na budowaniu wszystkiego od początku". Teoretycznie tak. Kto jednak zdecyduje się na wdrażanie nowej architektury jedynie na bazie przekonania, że "tak będzie lepiej"? Innej podstawy do wdrażania na razie nie ma, ponieważ udowodnienie obniżenia kosztów netto integracji istniejących aplikacji za pomocą środowisk SOA jest, delikatnie mówiąc, trudne. Z kolei uzyskanie znacząco większej elastyczności, niż w przypadku brokerów - znów, przy wykorzystaniu istniejących aplikacji - jest dla wielu firm "ezoteryczne", niewarte ryzyka na tym etapie rozwoju technologii.

Bardziej podejrzliwi dostrzegą, że argumentacja dostawców jest namawianiem do pilotaży, które pozwolą w przyszłości zabezpieczyć udział w rynku, sprowadzając merytoryczną siłę przyszłej oferty na drugi plan. Nie można też nie zauważyć innego aspektu całej sprawy. Rozwiązania zgodne z SOA są wyrazem koncepcji powstałych na bazie analiz własnych możliwości dostawców i celów, które sobie postawili.

Im więcej pilotaży SOA zdobędą, tym bardziej mogą argumentować, że ich wizja SOA jest słuszna. Oczywiście, to wcale nie musi być prawdą, ani z punktu widzenia konkretnego klienta, ani z punktu widzenia obiektywnej analizy celów architektury SOA.

W oczekiwaniu na postęp

Znaczące korzyści z wdrożenia architektur SOA można będzie uzyskać dopiero wtedy, gdy będziemy mieć do czynienia z jas-no zdefiniowanymi aplikacjami-usługami, nie zaś z jeszcze bardziej niż teraz kolorową mozaiką "realizujących wizję SOA". Ta droga jest bardziej trudna i długotrwała dla wszystkich, wymaga bowiem nowego spojrzenia na "komponentyzację" aplikacji. W większości przypadków oznacza to de facto wymianę aplikacji na nowe. Takie, których poszczególne funkcje będą znacznie bardziej "granularne", a jednocześnie zapewnią więcej możliwości konfiguracji.

W tym kierunku zamierza iść BEA Systems, co firma dobitnie podkreśliła na ostatniej konferencji BEA World. W tym samym kierunku zmierzać też będzie Oracle, jak wynika z zapowiedzi wygłaszanych na zakończonej niedawno konferencji Open World 2006. Oracle zaczął nawet posługiwać się terminem SOA 2.0. Całkiem możliwe, że pozostali gracze pod różnymi innymi nazwami zaczną wkrótce mówić o tym samym - i dobrze. Byle tylko dostawcy aplikacji wzięli sobie do serca potrzebę zmiany architektury produktów i przebudowali je w sposób pozwalający wykorzystać te nowe możliwości.

W międzyczasie dostawcy rozwiązań będą musieli też rozwiązać problem zarządzania konfiguracją i metadanymi w ramach całego środowiska SOA. W tym kierunku będą zapewne podążać rejestry UDDI. Być może równolegle powstaną mechanizmy synchronizujące się w rozproszeniu, albo coś pośredniego. Jeśli jednocześnie upowszechnią się i w pełni ustandaryzują mechanizmy komunikacji w dziedzinie przenoszenia kontekstu bezpieczeństwa i uwierzytelniania oraz zarządzania cyklem życia usług, będzie można mówić o postępie.

Za kilka lat być może wyklaruje się także to, co z punktu widzenia klientów dziś nie przedstawia się zbyt atrakcyjnie, a więc warstwa zarządzania usługami. Jako architektura znacznie bardziej skomplikowana na wielu poziomach niż wszystko to, co znamy dotychczas w dziedzinie integracji, SOA wymaga kompleksowych narzędzi, zarówno do zarządzania operacyjnego na poziomie usług, jak i biznesowego - na poziomie procesów. Popyt na rozwiązania SOA pojawi się wtedy, gdy dostawcy udowodnią, że zmiana procesów będzie prowadzić automatycznie do dostosowań w warstwie usługowej. To będzie wartość, za którą można będzie zapłacić.

SOA - lista braków

Dla większości firm architektura SOA to interesująca koncepcja, której nie ma jednak sensu realizować we własnym środowisku, dopóki nie będzie takiej konieczności biznesowej. Niechęć do szybkiego wdrażania architektur SOA wynika z wielu czynników, wśród których najważniejsze to:

  1. Brak spójnej definicji zakresu i celów - trudne do zdefiniowania i zmierzenia korzyści biznesowe.
  2. Wiele wzajemnie niekompatybilnych standardów - ryzyko nietrafionych inwestycji.
  3. Proponowanie zarządzania procesami, w sytuacji gdy istniejące aplikacje nie bardzo nadają się do budowy nowoczesnej architektury.
  4. Mechanizmy do zarządzania na bardzo wstępnym etapie rozwoju - zarówno w sensie koncepcji, jak i standaryzacji.
  5. Zbyt mały nacisk na automatyzację zarządzania metadanymi w ramach architektur SOA - za małe zaangażowanie w rozwiązanie palącego problemu klientów.