Proces dostarczenia usług w architekturze SOA
Model funkcjonowania działów IT w firmach, widziany z lotu ptaka, jest dosyć prosty. IT pełni rolę czysto służebną, tj. ma za zadanie dostarczać rozwiązania informatyczne zaspokajające pewne potrzeby, tudzież kaprysy osób odpowiedzialnych za rozwój biznesu. Przedstawiciel biznesu zgłasza więc do działu IT zapotrzebowanie na nowe oprogramowanie wraz z szeregiem wymagań, które odnoszą się do tego, jak dana aplikacja ma wyglądać i funkcjonować i tym samym uruchamia odpowiedni proces analizy. Przeważnie wybrany zostanie ktoś odpowiedzialny za realizacje tych wymagań, tj. kierownik projektu. Jeśli realizowana aplikacja nie jest trywialna to z pewnością będzie ona wymagała interakcji z istniejącymi w firmie systemami, czy to finansowymi, sprzedażowymi, magazynowymi czy jakimikolwiek jeszcze innymi. W organizacji opartej na architekturze zorientowanej na usługi (tj. SOA) powinno się dążyć do tego, aby osoba odpowiedzialna za realizację zadania zdefiniowanego przez biznes mogła się skupić na tymże, komunikując światu zewnętrznemu – z którym realizowana aplikacja potrzebuje się komunikować – jedynie pewne niezbędne minimum, tj. czego ona od tego świata zewnętrznego chce. A chce ona od niego, aby wykonał na żądanie pewne określone zadania, tj. mówiąc innym językiem, aby udostępnił pewne usługi. Z punktu widzenia wspomnianego kierownika projektu szczególnie korzystne byłoby, gdyby mógł się on ograniczyć do sporządzenia listy usług, które muszą mu być dostarczone przez systemy zewnętrzne dla umożliwienia realizacji jego zadania. Lista ta staje się punktem wyjścia do uruchomienia nowego procesu zarządzania (ang. governance) architekturą SOA – procesu dostarczenia usług.
Proces dostarczenia usług składa się z kilku zasadniczych kroków. W pierwszym kroku zespół który ma za zadanie dostarczyć usługi przeprowadza wstępną analizę wymagań klienta – klient występuje tu w rozumieniu osoby która zgłasza zapotrzebowanie na usługi. Mając nakreślony w sposób ogólny wymagany zakres funkcjonalny i informacyjny dla każdej usługi należy ustalić, czy usługa o podobnym zakresie funkcjonalnym już istnieje, czy jest to usługa zupełnie nowa. Należy tutaj podkreślić, że osoby odpowiedzialne za dostarczenie usługi powinny podjąć wysiłek nakierowania żądań swego klienta na właściwe tory, jeśli stawiane przez niego wymagania nie wpisują się w dotychczas znane i realizowane schematy. Może zdarzyć się bowiem, że dekompozycja funkcjonalności aplikacji na usługi została wykonana nie prawidłowo i wymagana jest korekta. W szczególności, może zdarzyć się, że istnieje usługa o odpowiednim znaczeniu funkcjonalnym ale posługująca się innym zakresem informacyjnym. Jest to wyraźny sygnał, że należy podjąć wysiłek uspójnienia procesów biznesowych i używanego modelu danych. Należy pamiętać o tym, że usługi powinny odpowiadać pewnym operacjom mającym sens z punktu widzenia prowadzonego biznesu i należy dbać o utrzymanie spójności znaczeniowej usług z funkcjami biznesowymi.
Proces analizy – analizy prowadzącej do porozumienia obydwu stron, tj. klienta i dostawcy usług – nakreślony w powyższym akapicie koniec końców prowadzi do ustalenia się pewnej listy usług, z pośród usług istniejących, które mogą być użyte bez zmian, listy usług które są na tyle podobne, że wymagają jedynie pewnego dostosowania oraz listy usług zupełnie nowych, które muszą być zaimplementowane od podstaw. Usługi powinny być implementowane w oparciu o technologie które ściśle separują specyfikację usługi od jej implementacji; wymóg ten spełniają usługi sieciowe oparte o standardy SOAP i WSDL. Umożliwia to i promuje podział procesu wykonania usługi na fazę opracowania interfejsu i fazę implementacji. Dostawca usług w pierwszej fazie tworzy i przedstawia do akceptacji klientowi kontrakt usługi w postaci pliku WSDL a dopiero potem przechodzi do implementacji. Możliwość ustalenia interfejsu przed wykonaniem usługi ma ogromne znaczenie dla skrócenia czasu implementacji całego rozwiązania – zespół implementujący aplikację nie musi bowiem oczekiwać ze swoimi pracami na wykonanie całości pracy przez dostawcę usług. Aplikacja kliencka może być w pełni zaimplementowana nawet przed dostarczeniem implementacji tych usług. Warunkiem niezbędnym dla prawidłowej realizacji procesu jest jak widać postawienie definicji usługi, wyrażonej jako dokument WSDL, ponad jej konkretną implementację, która jest rzeczą wtórną. Co prawda dla programisty implementującego usługi na platformie Java EE (i innych analogicznych) kuszącym jest, aby pracę zacząć od implementacji usługi i na jej podstawie w sposób automatyczny wygenerować plik WSDL (obecna technologia sprawia że jest to łatwe), jednak jest to podejście nie celowe z globalnego punktu widzenia.
Podejście w którym zaczyna się od wytworzenia definicji WSDL – w przeciwieństwie do podejścia w którym na podstawie implementacji pliki WSDL generuje się automatycznie – ma szereg zalet. Specyfikacje w postaci dokumentów WSDL mogą być wykorzystane jako element kontraktu pomiędzy dostawcą a klientem tam gdzie zachodzi potrzeba utrzymywania stosunków formalnych, tj. otrzymania formalnej akceptacji projektu usług przed rozpoczęciem fazy realizacji. Kolejnym powodem dla którego warto w pierwszej kolejności opracować definicję usługi w postaci pliku WSDL jest możliwość przygotowywania testów usług równolegle z ich implementacją, na podstawie samego WSDLa. Warto taki tryb pracy uczynić standardem, niezależnie od niuansów i specyfik poszczególnych projektów. Korzyści staną się jeszcze większe i bardziej widoczne, jeśli pliki WSDL budowane będą w oparciu o globalne, kanoniczne typy danych.
W artykule „JAX-WS i Maven 2 w podejściu Contract First Development” opisałem w jaki sposób implementować usługi w takim podejściu z wykorzystaniem technologii oferowanych przez platformę Java EE 5.
