Pomocne narzędzia

Trudno dziś znaleźć producenta narzędzi dla programistów, który nie wspierałby usług Web.

Borland oferuje wsparcie za pośrednictwem mechanizmu WebSnap - nakładek, które generują odpowiednie wrappery do wywoływania usług Web. Są to mechanizmy dostępne niemal w każdym pakiecie programistycznym Borlanda - od C++ Builder do Delphi.

Także w Visual Studio.Net Microsoftu można łatwo budować usługi Web. Wykorzystanie istniejących usług sprowadza się do zarejestrowania referencji wskazującej konkretny plik WSDL. Przekształcenie funkcji w usługę Web wymaga jedynie dopisania jednego atrybutu przy deklaracji.

Sun One (dawniej Forte) ma gotowe kreatory, które przekształcają komponenty Enterprise Java Beans w gotowe usługi Web. BEA Systems opracowała bardzo ciekawy mechanizm do definiowania tzw. pliki JWS oraz zbiór graficznych narzędzi, które umożliwiają rysowanie struktur całych pakietów usług Web i wizualnie łączenie ich z właściwym kodem. Równocześnie BEA oferuje mechanizmy, które ułatwiają tworzenie warstw separujących właściwą usługę Web lub wywołanie jej od logiki biznesowej - dzięki temu system w Javie zyskuje większą elastyczność.

Oficjalny standard określający sposób tworzenia usług Web w J2EE opracowano niedawno. Znacznie wcześniej lukę tę uzupełniły firmy programistyczne posługujące się Javą - producenci narzędzi i serwerów. Od dłuższego czasu dostarczają oni własne mechanizmy do tworzenia Web Services w Javie. Z wykorzystaniem usług Web nie ma problemu, bez względu na to, czy są napisane przy użyciu "czystego" J2EE 1.4 czy wewnętrznych rozszerzeń danego dostawcy serwera aplikacyjnego. Bazowe protokoły są dokładnie takie same.

Usługi Web są obecne nie tylko w narzędziach dla "koderów". Usługi oparte na XML są dostępne praktycznie w każdym narzędziu do integrowania systemów. Większość pakietów do tworzenia portali może korzystać i udostępniać usługi Web. Także z poziomu baz danych można łatwo definiować usługi Web, które pozwalają na zdalne wywoływanie procedur przechowywanych czy wręcz wywoływanie kwerend, które zwrócą wynik jako XML. Duża część systemów analitycznych business intelligence także udostępnia funkcjonalność w formie usług Web. Nawet pakiet Microsoft Office może je wykorzystywać - mogą one służyć do wypełniania arkusza kalkulacyjnego czy dostarczenia listy adresów do korespondencji seryjnej.

Także w świecie open source można znaleźć liczne przykłady wsparcia dla idei usług Web. Obsługa SOAP w serwerze WWW Apache jest dostępna od 1999 r. - praktycznie dowolny skrypt CGI, strona PHP czy inny język skryptowy mogą być wykorzystane do pisania usług Web. Niezależnie od tego mechanizmu pojawiło się wiele bibliotek do języków C++, Perl/Python, które umożliwiają odwołanie do gotowej usługi Web. Nawet w ramach projektu Harbour (CA-Clipper w wersji open source) są prowadzone prace mające na celu udostępnienie bibliotek do tworzenia i wykorzystywania usług Web.

Co ciekawe, czasami okazuje się, że łatwiej jest udostępnić usługę Web określonej aplikacji niż tworzyć interfejsy komunikacyjne przy użyciu "rodzimych" narzędzi dostarczanych przez producenta. Przykładowo, SAP dysponuje językiem BAPI, który pozwala na komunikację systemu wspomagającego zarządzanie z innymi aplikacjami. Okazuje się, że wysiłek konieczny do opracowania mechanizmu opartego tylko na BAPI jest znacznie większy, niż gdyby stworzyć "pośrednika" w Javie, który udostępni fragment funkcji SAP w formie usługi Web.

Już dzisiaj można zaryzykować stwierdzenie, że XML, SOAP, WSDL oraz usługi Web stały się uniwersalnym językiem, zrozumiałym na każdej platformie i przez każdy system operacyjny.

Panaceum na wszystkie bolączki?

Czy usługi Web zastąpią w niedalekiej przyszłości mechanizmy zdalnego wywoływania procedur? Na tak postawione pytanie można zdecydowanie odpowiedzieć - nie.

Obok wielu zalet, usługi Web mają liczne wady.

Podstawowa wada wynika z faktu, że usługi Web bazują na XML, który jest formatem tekstowym. Ta sama liczba całkowita, która binarnie może być zapisana przy użyciu 4 bajtów, w przypadku XML może mieć aż 10 czy 11 cyfr. Jeżeli doda się do tego niezbędne tagi, które określają rolę tej liczby w dokumencie (innymi słowy definiują strukturę XML), to okaże się, że plik XML zawierający wywołanie SOAP będzie kilkadziesiąt razy większy niż analogiczna struktura binarna. Warto także pamiętać, że zakodowanie tekstu w XML również wymaga mocy serwera. W związku z tym, jeżeli system ma wykonywać rozbudowane transakcje rozproszone, to rozsądniej jest pisać w technologii CORBA i C, ewentualnie C++. Specyfikacja CORBA jest bardzo rozbudowana, występują olbrzymie różnice w implementacjach różnych producentów, ale wady rekompensuje szybkość działania.

Tam, gdzie stawia się na szybkość komunikacji, usługi Web długo jeszcze nie znajdą zastosowania. Warto wspomnieć, że m.in. Borland prowadzi prace nad rozwiązaniem kompresującym pakiety SOAP, lecz tym sposobem uda się tylko zmniejszyć obciążenie sieci, a pozostanie problem "zakodowania" informacji w XML.

Usługi Web są ograniczone możliwościami protokołu HTTP. Rodzi to problemy związane z autoryzacją. Na obecnym stanie rozwoju tych usług można zabezpieczyć kanał komunikacyjny, natomiast brak standardów zabezpieczenia pakietu. Inny problem wynika z faktu, że HTTP jest protokołem bezstanowym. Klient wysyła żądanie do serwera, po czym otrzymuje odpowiedź. Jeżeli żądanie zostanie przesłane ponownie, usługa Web jest pozbawiona mechanizmów, które umożliwiłyby zidentyfikowanie, że żądanie pochodzi od tej samej osoby. Podobny problem występuje w sklepach internetowych, ale w przypadku usług Web jest on bardziej znaczący. Wielu programistów, zwłaszcza używających Javy czy piszących obiekty COM, jest przyzwyczajonych, że serwer "pamięta" klienta. Model programowania bez ścisłego połączenia z serwerem jest w oczywisty sposób bardziej skalowalny, ale znacznie komplikuje pracę programiście.

Na obecnym etapie rozwoju usługi Web nie wystarczą do zapewnienia współpracy B2B i elektronicznej wymiany dokumentów.

Są mechanizmem, który wiele zadań ułatwia, ale jeszcze nie można ich traktować jak panaceum na wszystkie problemy związane z integracją. Może stanie się tak w przyszłości, gdy upowszechnią się standardy biznesowe towarzyszące Web Services.