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.