Bezpieczna wymiana danych XML, modularność i łatwa integracja z aplikacjami biznesowymi to najważniejsze zalety usług Web. Wiele wskazuje na to, że niedługo Web Services staną się jedną z najpopularniejszych metod tworzenia rozwiązań informatycznych.

Namiastkę Web Services już teraz można znaleźć w Internecie. Serwisy internetowe często korzystają z zewnętrznych mechanizmów, gromadzących dane statystyczne o użytkownikach, a proste strony WWW niejednokrotnie połączone są z zewnętrznymi, specjalizowanymi serwisami, gromadzącymi wyniki ankiet czy służącymi do prowadzenia dyskusji. Popularne są także mechanizmy, umożliwiające wykorzystywanie znanych wyszukiwarek internetowych do przeszukiwania zawartości konkretnych witryn WWW. Usługi Web mają uprościć integrację tych mechanizmów, a jednocześnie sprawić, by nie ograniczała się ona tylko do serwisów internetowych, ale także systemów ERP i narzędzi analitycznych.

Podstawy usług Web

Idea usług Web opiera się na prostym mechanizmie: dowolnej aplikacji lub urządzeniu podłączonemu do sieci IP można zdalnie wydawać polecenia przy użyciu komunikatów "opakowanych" w XML i przesyłanych poprzez protokół HTTP. Wystarczy, by taka aplikacja bądź urządzenie zostały wyposażone w minimalny serwer HTTP i najprostszy parser XML. Od tego momentu aplikacja lub urządzenie mogą samodzielnie dostarczać różnego rodzaju usługi. Ze strony klienta wymagane jest tylko, by był w stanie formułować komunikaty HTTP POST oraz by potrafił zinterpretować odpowiedź serwera.

Niemałe znaczenie dla popularyzacji usług Web ma fakt, że oprogramowanie serwera WWW jest dostępne dla wielu różnych urządzeń. Przykładowo, Microsoft opracował wersję IIS dla komputerów PocketPC, a także dla każdego systemu Windows z serii Embedded. Sun prowadził przez pewien czas prace nad miniaturowym serwerem Brazil, który teoretycznie miał być osadzany w dowolnych urządzeniach, np. AGD i samochodach. Istnieje także wiele rozwiązań open source, które pozwalają osadzić mini- serwer WWW bezpośrednio w aplikacji.

Mydło z definicją

Najczęściej wykorzystywanym standardem wywoływania usług Web jest SOAP (obecnie przygotowywana jest wersja 1.2). Równocześnie prowadzone są prace nad bardziej rozbudowaną infrastrukturą ebXML, jednak w tym przypadku nie ma jeszcze nawet publicznie dostępnych, wzorcowych implementacji bibliotek.

SOAP (Simple Object Access Protocol) to standard definiujący sposób przesyłania żądań wywołania funkcji i otrzymywania wyników z wykorzystaniem plików XML. Definiuje on specjalną strukturę dokumentu, w którym można zawrzeć nazwę wywoływanej usługi, a także standardowy sposób określania jej parametrów.

Z założenia usługi Web mają być proste w użyciu. Oprócz standardu do komunikacji został opracowany mechanizm, który pozwala opisywać interfejs usługi - czyli sposób, jak należy sfor- mułować żądanie SOAP. WDSL (Web Service Description Language) zawiera zarówno informacje techniczne (typ parametrów itp.), jak i słowny opis interfejsu usługi. Dzięki temu do skorzystania z usługi nie są konieczne konsultacje z jej autorem - wystarczy zastosować standardowy opis opublikowany w sieci.

Odrębnym zagadnieniem jest mechanizm wyszukiwania usług Web, realizujących określone funkcje. Opiera się on na standardzie UDDI (Universal Discovery Description and Integration), dzięki któremu dostawca usługi publikuje informacje w specjalnym repozytorium, zgodnie z wybranym systemem klasyfikacyjnym, np. branżowym. Klient może poszukiwać usług Web, które oprócz tego, że są samosklasyfikowane, to dodatkowo mają taki sam interfejs dostępowy. W ten sposób, zakładając pewną standaryzację (a przejawy takiej są już widoczne np. w systemach autoryzacji kart kredytowych), można łatwo zmienić jednego dostawcę usług na innego, konkurencyjnego. Algorytmy wyszu- kiwania interfejsów określa standard DISCO towarzyszący UDDI.

Wiele spraw do załatwienia

W koncepcji usług Web, nawet na obecnym stadium ich rozwoju, ujawniają się pewne problemy.

Programista używający obiektów COM, EJB czy CORBA może wybrać jeden z dwóch trybów pracy aplikacji. Może zdecydować, że podczas komunikacji z obiektem będą przechowywane informacje o stanie sesji lub też, że obiekt nie będzie ich przechowywał. Tymczasem w Internecie, docelowym środowisku Web Services, utrzymanie informacji o sesji czy też stanie klienta oraz związana z tym synchronizacja danych są bardzo kosztowne. Dlatego też pierwsze specyfikacje wykorzystywane przy wywołaniach usług Web w ogóle nie zajmowały się problemem "stanu" połączenia. Oczywiście niemal każde ramy aplikacyjne, ułatwiające pisanie usług Web, dysponują pewnymi mechanizmami, pozwalającymi zachować stan. Niemniej przechowywanie stanu sesji wymusza inną architekturę aplikacji i znacznie komplikuje pracę programistom (zwłaszcza architektom systemu).

Kolejnym problemem związanym z infrastrukturą usług Web jest weryfikacja, czy dana transakcja rzeczywiście zakończyła się sukcesem (mówi się o tzw. cechach ACID, analogicznie do systemów bazodanowych). Opracowany przy okazji rozproszonych baz danych dwufazowy protokół potwierdzeń jest dosyć skuteczną metodą, pozwalającą wielu stronom transakcji określać, czy na pewno cała operacja zakończyła się powodzeniem. Implementacja tego typu rozwiązań nie jest zbyt złożona. Microsoft opracował specyfikację XLANG, dostępne są także inne rozwiązania typu XAML itp. Specjalny komitet pracujący nad ebXML zajmuje się zasadami zapewnienia spójności wywołań usług Web.

Niestety, komunikacja z użyciem protokołów opartych na XML nie jest oszczędna - w efekcie jest przekazywanych znacznie więcej informacji, niż gdyby zakodować je w innej postaci. XML jest językiem prostym, ale nie zwięzłym. Problem ten można wprawdzie rozwiązać na poziomie transmisji HTTP - podejmowane są próby kompresowania "w locie" pakietów HTTP, tak by do komputera klienta docierały w jak najbardziej zwięzłej postaci - jednak obecnie nie jest to powszechnie stosowane. Tylko nieliczne przeglądarki (zwykle open source) potrafią zinterpretować kompresowane transmisje HTTP. Dodatkowym argumentem przeciwko takiej kompresji jest fakt, że wymaga ona dodatkowej mocy obliczeniowej i tak obciążonych już serwerów WWW.

Kolejny problem jest związany z bezpieczeństwem. Uruchomienie usługi Web sprawia, że ruch przychodzący poprzez protokół HTTP powoduje two-rzenie nowych obiektów na serwerze. Dzięki możliwości tunelowania komunikatów XML za pomocą protokołu HTTP możliwe będzie uzyskanie w nie autoryzowany sposób dostępu do znacznie większej funkcjonalności systemów informatycznych firmy, niż to ma miejsce w przypadku klasycznych systemów internetowych, korzystających np. z architektury COM. Aby zapobiec ewentualnym nadużyciom, opracowywane są standardy dodatkowego, cyfrowego "podpisywania" przekazywanych komunikatów, co znacznie upraszcza autoryzację i identyfikację użytkowników.

Proces autoryzacji i identyfikacji może być również realizowany jako usługa Web. Microsoft udostępnił stosowne interfejsy do aplikacji Microsoft Passport - centralnej bazy zawierającej informacje o użytkownikach, która pozwala dowolnym serwisom identyfikować internautów. Alternatywne rozwiązanie - Liberty - zamierza udostępnić Sun, który rozpoczął prace nad bazą federacyjną, mającą docelowo umożliwić współpracę wielu równorzędnym centrom autoryzacyjnym. Na razie nie są publicznie dostępne szczegóły, a nawet specyfikacja tego projektu.

Wypracować wspólny język

Nie można przeceniać roli XML. Pozwala on co prawda tworzyć dokumenty wraz z opisem składni, ale semantykę obie strony komunikacji muszą określić oddzielnie (np. ustalając standardowe znaczenie pól komunikatów). Gdy strony stosują różne formaty, konieczne jest stworzenie "pośrednika", który będzie "odwzorowywał" pola dokumentów. W przypadku konwersji danych dostępne są narzędzia, które w prosty sposób pozwalają definiować schematy przepływu danych, np. Microsoft BizTalk 2000 czy w pewnym sensie DirXML Novella. Natomiast w przypadku usług Web problem polega na tym, że dwa najbardziej popularne standardy - ebXML i SOAP - są bardzo podobne, ale trudno jest dostatecznie szybko je "tłumaczyć".

Prace nad ebXML rozpoczęto znacznie później niż nad protokołem SOAP. W pracach bierze udział ponad 190 firm, nie licząc "mniejszych" członków komitetu; proces podejmowania decyzji jest bardziej skomplikowany niż w komitecie W3C (zajmującym się m.in. XML, HTML, XHTML i SOAP).

Można się obawiać, że ebXML podzieli losy innych standardów tworzonych na zasadzie "kompromisu" - CORBA czy SQL 3. Tak naprawdę nie ma serwera aplikacyjnego, który implementowałby pełny standard CORBA. Analogicznie, żaden serwer bazodanowy nie implementuje SQL 3. Producenci narzędzi i baz danych wybierają pewien podzbiór specyfikacji lub też rozszerzają go w miarę potrzeb. Programista nie uczy się "czystego" SQL-a, tylko np. T/SQL czy PL/SQL, po to by jego kwerendy działały szybko w danym środowisku.