Świat jako usługa

WS-Policy to standard, który definiuje zasady działania usługi Web. Pozwala zdefiniować ciąg warunków i to, jakie parametry przyjmuje dany warunek. Równocześnie opracowane są specyficzne rozszerzenia, np. WS-SecurityPolicy, które określa, jak dana usługa Web rozumie bezpieczeństwo i czego wymaga od wywołującego. Ponieważ standard polis jest bardzo rozbudowany, konieczny jest mechanizm udostępniający metadane, które opisują dany zestaw zasad. Do tego celu został opracowany standard WS-MetadataExchange.

WS-Adressing (zastępuje WS-Routing i WS-Referral) pozwala przekierować wywołanie w zależności od pewnych warunków. Ponadto zapewnia model, w którym realny adres usługi Web może być prosto zmieniany bez konieczności wprowadzania żadnych modyfikacji w aplikacjach.

W trakcie prac WS-I okazało się, że w modelu usług Web nie da się uciec od mechanizmów "zdarzeń" przy konstrukcji aplikacji. WS-Eventing to opracowywany standard, który ma efektownie realizować model publikująco-subskrybujący (subskrybenci będą powiadamiani o zmianach komunikatem typu push).

Problem z przekazywaniem dużych porcji danych ma rozwiązywać SOAP Message Transmission Optimization Mechanism. Ten standard pozwala tak kodować komunikaty, by pakiety były rozbijane na fragmenty, które są składane dopiero w miejscu docelowym.

Większość specyfikacji WS-I wciąż występuje wyłącznie w postaci papierowej. Tak jest m.in. z WS-Security, który w zamyśle autorów ma kodować komunikaty i weryfikować podpis elektroniczny. Daleka jest droga do powstania konkretnych implementacji WS-Federation - specyfikacji, według której przedsiębiorstwa będą definiować wspólną domenę bezpieczeństwa, a obiektom należącym do danego zakresu przydzielać odpowiednie prawa.

Problemy występują także przy okazji dwóch innych zagadnień - pewności dostarczenia komunikatu i transakcji. Na ukończeniu są prace nad WS-Coordination, standardem, który ma pozwalać wybrać koordynatora transakcji rozproszonej.

Zdefiniowane są także dwa typy transakcji: WS-AtomicTransaction - krótkotrwała, atomowa transakcja, posługująca się semantyką przypominającą dwufazowy protokół potwierdzeń, oraz WS-BusinessActivity, będąca tak naprawdę długotrwałą operacją biznesową, która w przypadku wycofania musi mieć wykonany specjalny kod kompensujący. W przypadku operacji biznesowych Microsoft proponuje BizTalk Server, który pozwala w elegancki sposób "opakować" taką operację. Organizacja WS-I zatwierdziła język BPEL, który pozwala modelować procesy biznesowe, łącząc poszczególne usługi. Na marginesie warto dodać, że System.Transaction (prawdopodobnie część pakietu Visual Studio 2005) będzie realizować operacje zgodnie z semantyką protokołów WS-Tx.

Trudno jednoznacznie wskazać, które elementy ze standardów WS-I są już gotowe. Tak naprawdę wszystkie mają postać co najmniej propozycji specyfikacji. Jednak dla użytkowników najważniejsze są tzw. profile zawierające zestaw usług, na których można już budować aplikacje. Obecnie za gotowy do użytku można uznać profil podstawowy. Popularność zyskuje WS-Security (choć nie jest dostępny w niektórych implementacjach stosu usług Web).

Panuje pogląd, że w fazie eksperymentalnej są standardy: WS-Coordination, WS-Policy i BPEL (mimo że ten protokół jest już wykorzystywany w np. BizTalk 2004). Pozostałe protokoły to w zasadzie papierowe specyfikacje i wczesne bety implementacji.

Jak modelować?

Problemów nastręcza precyzyjne określenie, czym jest "architektura zorientowana na usługi". Na prezentacjach Microsoftu została przedstawiona bardzo rozbudowana definicja - "zestaw polis, praktyk i bibliotek, które pozwalają wykorzystać funkcjonalność aplikacji w taki sposób, by można było z niej korzystać jako z zestawu usług, opublikowanych tak, by poziom szczegółowości był dostosowany do potrzeb konsumenta usługi. Publikowane elementy są niezależne od implementacji i stosują pojedynczy, standardowy interfejs". Tak naprawdę definicja ta określa "fasadę" nakładaną na aplikację. "Od środka" aplikacji usługa może być konstruowana po staremu jako aplikacja obiektowa. Posługując się językiem UML, można korzystać z komponentów i tworzyć model aplikacji. Jednak w takim przypadku pozostaje bardzo istotny problem: jak stworzyć kod obiektowy, który będzie dobrze współgrał z warstwą usług? Przy złej organizacji mogą się pojawić kłopoty nawet przy odwzorowaniu komunikatu na klasę realizującą usługę w programie...

Z punktu widzenia projektanta systemu informatycznego podstawowa różnica pomiędzy SOA a tradycyjnymi aplikacjami polega na tym, że w SOA transport komunikatu kosztuje. Innymi słowy - nie można zakładać - jak w przypadku komponentów (COM+, EJB) - że wołanie odbywa się niemal natychmiast. Usługi Web, do których są przesłane dane, znajdują się "gdzieś w sieci", a nie w szybkiej sieci lokalnej z obsługującym wszystkie żądania serwerem aplikacyjnym. W SOA żądanie musi być tak sformułowane, by koszt "opakowania" komunikatu i jego transmisji można pominąć w ogólnym rozrachunku. Ponadto SOA zakłada brak stanu - komunikat musi być kompletny, by w jednym żądaniu usługa otrzymała wszystko, co potrzebuje do wykonania zadania. Projektant powinien optymalizować aplikację tak, aby balansować między modularnością komunikatów a sumarycznym kosztem transportu potrzebnym do wykonania zadania.

Trzy widoki

W związku z rosnącą popularnością usług Web we współczesnych aplikacjach pojawił się nowy "widok". Okazało się, że trójwarstwowy schemat aplikacji - warstwy prezentacji, logiki biznesowej i danych - wymaga uszczegółowienia.

Ponieważ aplikacje obsługują różne urządzenia klienckie, rozbito warstwę prezentacyjną na część, która przygotowuje dane pobrane z logiki biznesowej do prezentacji, i część, która ostatecznie wyświetla dane na danej platformie. Jedną z platform jest... usługa Web.

Równocześnie obok warstwy danych pojawiły się moduły, które odpowiadają za komunikację z zewnętrznymi źródłami danych. W przypadku SOA aplikacja nie importuje danych z systemu zewnętrznego - komunikuje się, odbierając określone informacje czy wysyłając żądania.

Zaginiony model

W toku prac nad usługami Web praktycznie zaniechano rozwoju ciekawej funkcjonalności, która pozwalałaby łatwo integrować usługi.

Standard UDDI pozwala definiować tzw. branżowy tModel - czyli rodzaj kontraktu dla usług zaprojektowanych z myślą o poszczególnych gałęziach przemysłu. Teoretycznie aplikacja zamiast dowiązywać się bezpośrednio do usługi Web (czyli "pod" dany adres URL) może określić żądany tModel, po czym zażądać od wyszukiwarki UDDI, by ta znalazła odpowiednią usługę.

Niestety, w praktyce ten mechanizm nie sprawdził się. Po pierwsze, z wymianą usług zwykle wiąże się określony kontrakt biznesowy (konieczność zawarcia umowy), czego nie uwzględniał tModel. Po drugie, nie powstała specyfikacja branżowych standardów usług Web.

Dla porównania, technologia EDI przez kilkadziesiąt lat dorobiła się standardów, dzięki którym uzgadnianie formatów na ogół nie nastręcza problemów. W przypadku usług Web poszczególne systemy komunikują się przy użyciu XML, ale właściwe komunikaty (nawet dotyczące przekazywania tych samych dokumentów) są kodowane zupełnie inaczej.


TOP 200