Nadzieja w usługach

Technologie określane ogólnie jako usługi sieciowe (web services) budzą nadzieję na zmianę podejścia do integracji systemów informatycznych.

Technologie określane ogólnie jako usługi sieciowe (web services) budzą nadzieję na zmianę podejścia do integracji systemów informatycznych.

Usługi sieciowe to wygodny sposób na integrację aplikacji w ramach jednej firmy. Technologia ta umożliwia bowiem wyodrębnienie istniejących w organizacji procesów biznesowych i udostępnienie ich w sieci jako zbioru usług, które można przeszukiwać i subskrybować. To także sposób na udostępnienie określonej logiki biznesowej firmowych systemów informatycznych na zewnątrz, tak aby dowolny system zewnętrzny mógł automatycznie wymieniać z nim dane wg jasno określonych zasad.

Mimo tych oczywistych zalet, usługi sieciowe nie stanowią remedium na wszystkie bolączki współczesnej informatyki. Ponadto ich praktyczne wykorzystanie niesie wiele dodatkowych kosztów i inwestycji.

Niby nic nowego... a jednak

Aplikacje rozproszone miały początki w koncepcji klient-serwer. Rozproszona warstwa kliencka inicjuje wykonanie zadań, scentralizowana warstwa serwerowa zaś przetwarza napływające żądania. Trzeba jednak pamiętać, jaka była geneza tej koncepcji - przetwarzanie klient-serwer miało minimalizować ryzyko powstawania wąskich gardeł, równoważąc obciążenia poszczególnych systemów. Stanowiło także krok w kierunku niezależności projektowania poszczególnych części aplikacji. Aby zapewnić systemom skalowalność i niezawodność, koncepcję klient-serwer wkrótce wzbogacono w dodatkową, trzecią warstwę. Tak powstała architektura trójwarstwowa obejmująca: warstwę prezentacji - interfejs użytkownika, warstwę środkową - zawierającą logikę biznesową oraz warstwę danych - bezpośrednio wykonującą polecenia płynące z warstwy logiki na danych.

Podstawą komunikacji między rozproszonymi częściami aplikacji jest zastosowanie zdalnie wywoływanych procedur RPC (Remote Procedure Call). W celu odciążenia programistów od "niskopoziomowych" zadań, takich jak konwersja danych czy odmienna kolejność adresacji bajtów w różnych systemach, pojawiła się nowa warstwa oprogramowania realizowana przez systemy zwane potocznie middleware. Oprogramowanie tego rodzaju pozwala programiście zapomnieć o różnicach między systemami operacyjnymi, umożliwiając mu skupienie się na wykorzystaniu ich funkcji w tworzonej aplikacji.

Programiści mają obecnie do wyboru praktycznie trzy technologie middleware: CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) oraz RMI (Remote Method Invocation). Każda z nich ma wady i zalety. Wszystkie działają na podobnych zasadach, a różnice między nimi wynikają z zakresu oferowanych przez nie funkcji i poziomu ich złożoności.

Efektem tych różnic jest konieczność ścisłego - w sensie technologicznym - powiązania aplikacji klienta z aplikacją serwerową. Z powodu różnic w protokołach wykorzystywanych do komunikacji, nie można - bez wykorzystania dodatkowych mechanizmów - w bezpośredni sposób wywołać usługi procedury DCOM z poziomu aplikacji klienckiej wykorzystującej mechanizm RMI. Dodatkowo oprogramowanie middleware jest zwykle wykorzystywane w rozwiązaniach intranetowych i wywoływanie usług aplikacji wewnętrznych poza siecią korporacyjną może być, choćby ze względów bezpieczeństwa, niemożliwe, chyba żeby uciec się do korzystania z dodatkowych mechanizmów tunelowania typu IPsec VPN lub SSL/TLS.

W stosunku do typowej architektury wielowarstwowej architektura usług sieciowych znacznie większy nacisk kładzie na wyszukiwanie - zarówno w sieci korporacyjnej, jak i Internecie - gotowych usług spełniających określone funkcje. Można wyodrębnić trzy kategorie komponentów: dostawcę usługi (service provider) - udostępniającego usługę sieciową; korzystającego z usługi (service requestor) - wykorzystującego usługę udostępnianą przez dostawcę; brokera usług (service broker) - umożliwiającego korzystającemu znalezienie żądanej usługi.

Podobnie jak aplikacje klient -serwer, usługi sieciowe umożliwiają wykonywanie operacji na systemach zdalnych. Podstawowa różnica leży jednak w wykorzystywanych przez nie protokołach komunikacji, sposobie udostępniania logiki aplikacji i zasadach wymiany danych. W przeciwieństwie do systemów middleware, które wykorzystują protokoły binarne, usługi sieciowe komunikują się za pomocą komunikatów/dokumentów XML przesyłanych za pośrednictwem protokołu HTTP. To bardzo istotna zmiana - protokół HTTP bardzo rzadko jest blokowany przez zapory ogniowe. Usługi sieciowe mogą również z powodzeniem korzystać z protokołu SMTP czy FTP.

W Web Services komunikacja i podstawowa logika są jasno określone przez formaty dokumentów XML wykorzystywanych przez usługi i protokoły warstwy aplikacyjnej: SOAP, WSDL i UDDI. Ze względu na to, że wszystko odbywa się w warstwie aplikacyjnej, usługi sieciowe nadają się do integracji środowisk heterogenicznych pod względem systemu operacyjnego, języka programowania, wewnętrznej struktury itd.