Nadchodzi zmierzch ery tworzenia aplikacji opartych na komponentach i mechanizmach komunikacji, związanych z konkretnym dostawcą i określonym, wypromowanym przez niego, środowiskiem programistycznym.

Usługi Web są rewelacyjną infrastrukturą do tworzenia aplikacji "z klocków". Tak jak standardy komponentów pozwoliły zmienić sposób organizacji aplikacji i zwiększyć ich skalowalność (dzięki zastosowaniu dowolnej liczby serwerów aplikacyjnych), tak usługi Web mogą całkowicie zmienić sposób komunikacji między poszczególnymi elementami rozwiązań informatycznych.

Czego brakuje w SOAP?

Obecnie dosyć dobrze ustandaryzowane są podstawowe protokoły - wywoływania usług (SOAP), ich opisu (WSDL) i do przeszukiwania repozytoriów (UDDI i DISCO). Trwają prace nad autoryzacją (użytkownika i serwera), mechanizmem licencjonowania usług, a także dynamicznego przekierowywania komunikatów SOAP, tak by można było określić dokładną ścieżkę przesyłania pakietów. Pod koniec października br. Microsoft opublikował specyfikację kilku protokołów (w dużym stopniu już zaimplementowaną w .NET Framework), które realizują wymienione usługi.

WS-Routing to protokół pozwalający przesyłać komunikat SOAP nie tylko poprzez HTTP, ale w niemal dowolny sposób (np. przez TCP/UDP). Standard określa, jak przechować w dokumencie informacje o drodze przesyłania pakietu i jak powinna wyglądać ścieżka powrotna. Obsługuje on m.in. komunikaty z potwierdzeniem odbioru, konwersację peer-to-peer, a także specjalny typ wywołania usługi Web, w którym przetwarzanie trwa bardzo długo.

WS-Referral pozwala określić zasady routingu, a także zdefiniować, co dokładnie oznacza w przypadku usługi Web najkrótsza czy najtańsza ścieżka. Protokół dynamicznie wybiera optymalną ścieżkę.

Web Services Security Language (WS-Security) to propozycja mechanizmu osadzania w komunikacje SOAP informacji identyfikujących użytkownika. Nie określa on algorytmów kryptograficznych, podaje natomiast, w jaki sposób można opisać wykorzystywany algorytm. Przykładowe implementacje pozwalają korzystać z biletów Kerberos i certyfikatów X.509. Dokumenty są podpisywane przy użyciu standardu W3C XML Signature. Wykorzysty- wany jest także standard W3C XML Encryption do kodowania poufnych fragmentów komunikatu. Dzięki WS- -Security może okazać się zbędne stosowanie protokołu HTTPS do przesyłania pakietów SOAP.

Microsoft opracował także standard, pozwalający zaimplementować w usługach Web taki sam mechanizm licencjonowania, jak w komponentach COM. Wykorzystując specyfikację WS-License, można osadzić specjalne znaczniki informujące o wykupieniu licencji. Jest ona zaprojektowana w taki sposób, że bez trudu można np. wprowadzać wiele różnych poziomów licencjonowania (także ograniczonych czasowo).

Rozszerzane są również możliwości wyszukiwania usług Web. Microsoft i IBM opracowały standard pozwalający analizować, jakie usługi Web są udostępnione przez określoną witrynę Web. UDDI to katalog branżowy usług. WSDL pozwala opisać usługę. WS-Inspection określa, w jaki sposób przedstawić wszystkie usługi, które są zaimplementowane na witrynie.

Przed HailStorm

Microsoft niedawno opublikował wstępny zestaw usług składających się na inicjatywę HailStorm.

.NET My Services pozwalają m.in. na przechowywanie informacji o użytkowniku, listów elektronicznych, kalendarzy, kontaktów i dokumentów. Wraz z profilem użytkownika może być zapisanych wiele dodatkowych informacji - ustawienia aplikacji, dodatkowe usługi wykorzystywane przez użytkownika.

Ciekawym pomysłem jest usługa .NET Alerts - mechanizm, który powiadamia użytkownika o określonych zdarzeniach (przyjście e-maila, dostępność określonego towaru, nadesłanie faktury przez kooperanta). Mechanizm powiadamiania jest elastyczny - od strony programisty sprowadza się do określenia poziomu ważności komunikatu. Odbiorca decyduje, w jakiej formie zostanie przyjęta wiadomość - czy to będzie komunikat na pulpicie, SMS, e-mail. Serwis może współpracować z MSN Messenger.

Usługi .NET My Services będą dostępne za pośrednictwem wywołań SOAP (a także będą umieszczone w repozytorium UDDI).

Autoryzacja

Obecnie dostępny jest już - zrealizowany jako usługa Web - ogólnoświatowy system autoryzacyjny MS Passport (ma ok. 135 mln użytkowników). Może on być wykorzystywany w dowolnych witrynach internetowych i aplikacjach biurowych.

W momencie gdy użytkownik wchodzi na witrynę "uczestniczącą" w programie Passport, jest kierowany na spec- jalną stronę logowania .NET Passport. Jednocześnie jest przekazywany unikalny identyfikator witryny w systemie Passport. Wygląd strony logowania może być określony przez specjalne wzorce. Język komunikatów będzie automatycznie dostosowywany do ustawień komputera użytkownika.

Po zalogowaniu się użytkownik otrzymuje bilet i informacje o swoim profilu (te, które zgodził się przekazać witrynie). Serwer logowania generuje trzy "ciasteczka". Pierwsze zawiera bilet z identyfikatorem i znacznik czasu, drugie - profil. Zawartość trzeciego cookie zależy od serwisu internetowego. Informacje szyfrowane są przy użyciu algorytmu DES. Gdy użytkownik trafia na stronę będąc już wcześniej zalogowanym do .NET Passport, proces logowania jest niewidoczny. Użytkownik przekazuje bilet i dane o profilu do .NET Passport Manager, który odszyfrowuje informacje i udostępnia witrynie.

Obecnie Microsoft oferuje trzy wersje MS Passport SDK. Pierwsza jest dostosowana do Windows i rozwiązań .NET. Druga wersja pozwala korzystać z tego mechanizmu na serwerze IIS. Trzecia - Passport Manager 1.1 - działa na wielu innych platformach, m.in. Sun Solaris, AIX 4.3 i Linux.

Ciekawą funkcją .NET Passport jest Portfel - mechanizm pozwalający szybko dokonywać transakcji elektronicznych. W portfelu są przechowywane numer karty kredytowej użytkownika i informacje dotyczące preferowanego sposobu transportu towaru. Dane przekazywane do sklepu internetowego są zgodne ze standardem Electronic Commerce Modeling Language (ECML). Dane o zakupach nie są przechowywane w .NET Passport. Dzięki mechanizmowi Express Purchase na ekranie komputera nie są wyświetlane numer karty kredytowej ani adres odbiorcy.

Prace nad konkurencyjnym mechanizmem autoryzacyjnym prowadzi Sun. Różnica dotyczy sposobu przechowywania informacji. Project Liberty jest bazą federacyjną. Dane użytkownika są zarządzane (a także częściowo przechowywane) przez użytkownika. To on decyduje, która z wybranych przez niego organizacji dokona autoryzacji i w jaki sposób będą przekazywane dane firmom trzecim. Problem pojawia się jednak, gdy użytkownik chce alternatywnie korzystać z kilku urządzeń (np. PocketPC, laptopa i komputera domowego). W MS Passport dane są gro- madzone centralnie i dzięki temu są dostępne dla każdego urządzenia. W związku z tym użytkownik nie musi martwić się o ich każdorazową aktualizację. Nie wiadomo jak problem ten zostanie rozwiązany w bazie Sun Liberty. Nie wiadomo także, jak będzie wyglądał proces autoryzacji, gdy np. sklep internetowy "ufa" innemu centrum autoryzacyjnemu niż użytkownik.

Warto wspomnieć o rozwiązaniu Novella - SingleSignOn. W katalogu e-Directory są przechowywane wszystkie hasła i identyfikatory użytkownika, wykorzystywane na różnych witrynach. Po zalogowaniu się do systemu wystarczy, by użytkownik raz podał hasło, a system pilnuje, by automatycznie logować go na witrynie. Rozwiązanie Novella to swego rodzaju proteza, ale w wielu sytuacjach może uprościć korzystanie z serwisów internetowych.

SOAP, ebXML, COM, EJB, J2EE, CORBA...

Z punktu widzenia aplikacji usługa Web to nowa metoda wywoływania interfejsu obiektów i uruchamiania określonej funkcji. Kwestia, czy odwołanie następuje według algorytmów określonych w ebXML czy w SOAP, ma znaczenie drugorzędne; wywołanie może być obsłużone na poziomie elementów pośrednich między właściwym kodem obiektu napisanym w dowolnym języku a infrastrukturą usług Web. Oba standardy są podobne i nakładają bardzo podobne wymagania na aplikację. Niewykluczone że pojawią się biblioteki, które będą obsługiwać wywołania ebXML, SOAP, a także w starszym standardzie XML-RPC. Wszystkie te rozwiązania są oparte na tych samych podstawach - języku XML, służącym do zakodowania wiadomości, a także protokole HTTP do przesłania żądania na serwer i odebrania wyników. Dostępne są narzędzia, które potrafią połączyć nową infrastrukturę usług Web ze starszymi standardami.

Najnowsza wersja serwera aplikacyjnego AppCenter Borlanda obsługuje standard J2EE 1.3, a także odwołania z wykorzystaniem protokołu SOAP. Z kolei z AppCenter dobrze integruje się VisiBroker (serwer aplikacyjny CORBA) - wywołania HTTP mogą być przekładane na żądania kierowane do szyny IIOP. VisiBroker zawiera także most pozwalający połączyć taką hybrydę z komponentami COM+ czy DCOM. Przykład ten pokazuje, że można stworzyć serwer, który jest w stanie zapewnić obsługę każdego standardu komponentowego, a równocześnie pozwoli na bezproblemową integrację z usługami Web.

Wsparcie niemal przez każdego

Usługi Web (ogólniej - wymiana danych za pośrednictwem XML) są wspierane chyba już przez wszystkich producentów oprogramowania. XML jest na tyle elastycznym językiem, że pozwala zapisać dowolną informację. Dla niektórych firm (m.in. Suna) jest to tylko dodatkowy interfejs komunikacji z obiektami tworzonymi w Javie. Dla Microsoftu to strategiczna metoda komunikacji, która ma zastąpić inne rozwiązania. Już dziś coraz większa część komunikacji, nawet między serwerami .NET, jest kodowana przy użyciu XML.

Usługi Web do działania wymagają tylko stosu HTTP. Nic dziwnego, że pierwszą implementację protokołu SOAP przeprowadzono na darmowym serwerze WWW - Apache. Usługi Web można tworzyć w dowolnym języku, w którym pisane są skrypty CGI lub w językach typu PHP.

Delphi 6.0 jest pierwszym komercyjnym narzędziem, które zawiera kreator pozwalający szybko wygenerować szkielet usługi Web (przy założeniu, że do komunikacji będzie stosowany SOAP). Borland przygotowuje także wersję Kylix 2.0, która będzie mieć analogiczny mechanizm WebSnap dla rozwiązań linuxowych. Również narzędzia IBM VisualAge zawierają wsparcie dla SOAP (zarówno wersja dla Javy, jak i C++).

Microsoft od dawna oferuje narzędzia do tworzenia usług Web. Dostępny jest np. SOAP SDK 2.0, który pozwala na wykorzystywanie tego protokołu w C++, VB, a nawet w językach skryptowych, obsługiwanych przez Windows Scripting Host. Pakiet obsługuje SOAP 1.1, WSDL 1.1, a także mechanizmy przekazywania złożonych typów danych (w tym inteligentne pakowanie dużych i rzadkich tablic, tak by były przekazywane tylko niepuste komórki). Pozwala również na kodowanie wywołań typu RPC. Do Windows XP wbudowano mechanizmy traktujące tak samo usługi Web, jak tradycyjne obiekty COM. Pod koniec roku zostanie udostępnione nowe środowisko dla programistów - VS.NET, dzięki któremu z usług Web będzie można korzystać w jeszcze bardziej naturalny sposób, np. będzie dostępna wyszukiwarka gotowych obiektów oparta na UDDI.

Sun dopiero tworzy specyfikacje protokołów i ram aplikacyjnych do obsługi usług Web z poziomu Javy. Zapowia- da także dalsze prace nad standardem EJB/J2EE. IBM udostępnia własny framework dla Javy (dostosowany do serwera WebSphere) - Web Services Toolkit, który zapewnia obsługę UDDI4J (interfejsu do wyszukiwania usług), Proxy do SOAP, WSDL 1.0, a także zbiór narzędzi pozwalających automatyzować wiele żmudnych operacji.

Otwarty świat

Wydaje się, że powoli kończy się era tworzenia aplikacji opartych na komponentach i standardach komunikacji, związanych z określonym dostawcą czy środowiskiem. Oczywiście produkty oparte na EJB czy DCOM będą istnieć, ale w przypadku systemów integrujących różne aplikacje znacznie prościej będzie skorzystać z komunikacji między usługami Web.

Z czasem aplikacje będą tworzone z wykorzystaniem serwisów realizujących określone zadania (niekoniecznie dostępnych w sieci lokalnej przedsiębiorstwa). W efekcie, w przyszłości może zrodzić się zupełnie nowy rynek, na którym użytkownicy będą kupować abonament na dostęp do konkretnych usług.