Web Services do usług

Usługi WWW są nie tylko uniwersalną technologią komunikacji między dowolnymi systemami informatycznymi, ale pozwalają także inaczej podejść do konstrukcji samych aplikacji. Umożliwiają tworzenie prawdziwych Smart Clients - aplikacji, które oferują bogaty interfejs użytkownika, pracę offline oraz proste mechanizmy do komunikacji z warstwą serwerową.

Usługi WWW są nie tylko uniwersalną technologią komunikacji między dowolnymi systemami informatycznymi, ale pozwalają także inaczej podejść do konstrukcji samych aplikacji. Umożliwiają tworzenie prawdziwych Smart Clients - aplikacji, które oferują bogaty interfejs użytkownika, pracę offline oraz proste mechanizmy do komunikacji z warstwą serwerową.

Usługi WWW to temat modny od kilku lat. Mają ułatwiać integrację systemów, składanie ich z klocków dostarczanych przez różnych producentów, ale mimo dobrze zdefiniowanej warstwy komunikacyjnej programista wciąż ma trochę pracy.

Usługa WWW to zwykła funkcja dostępna za pośrednictwem protokołów internetowych. Dokładniej, żądanie wywołania przesyłane jest przy użyciu protokołu HTTP (stosowanego w aplikacjach WWW do komunikacji serwera z przeglądarką). Drugi związany z Web Services protokół - SOAP - jest standardem określającym, jak w XML zakodować żądanie, parametry przekazywane do procedury i jak odebrać wynik (.NET 2.0 obsługuje SOAP 1.1 oraz 1.2). Duża zaleta usług WWW to w zasadzie powszechna zgoda dotycząca standardów. Usługę działającą w Windows można wykorzystać z poziomu aplikacji napisanej w Javie, aplikacja działająca w systemie Unix może współpracować z kodem .NET itp. Niestety, na razie ta zgoda dotyczy tzw. Basic Profile, czyli podstawowego stosu usług WWW, definiującego w zasadzie tylko komunikację (to i tak dużo w porównaniu z innymi technologiami). Mechanizmy bardziej zaawansowane (np. podpisy cyfrowe) są dostępne jako pakiety rozszerzeń.

Usługi WWW mają jeszcze jedną bardzo pożyteczną cechę. Zdefiniowany został język Web Service Description Language, który opisuje wymagania danej usługi, tzn. dokładnie definiuje, jakie dane należy podać, aby wywołać określoną funkcję i jak zostanie zapisany wynik. W.NET usługa WWW dostępna jest za pośrednictwem pliku .asmx. Jeżeli wywołamy go z parametrem WSDL: http://localhost/WSPayment/Service.asmx?WSDL, to zobaczymy opis wszystkich usług (metod) udostępnianych za pośrednictwem danego adresu URL. Ten sam mechanizm pozwala automatycznie generować tzw. klasy proxy, potrzebne do wywoływania usług WWW.

Są także mechanizmy wyszukiwania, np. serwery UDDI czy w prostszej wersji pliki .disco, które pozwalają odszukać potrzebne usługi na podstawie opisów, nazw czy np. wymaganej formy WSDL. Teoretycznie aplikacja kliencka może nawet nie być związana z określonym adresem URL, pod którym znajduje się usługa WWW, ale na przykład dynamicznie wyszukiwać najtańszą ofertę realizacji danego zadania, i to pod warunkiem, że usługa ma taki sam interfejs dostępowy.

W VS.NET jest specjalny projekt o nazwie ASP.NET Web Service. Po dodaniu nowego projektu (niech folder nazywa się WSPayment) automatycznie wygenerowany zostanie plik Service.asmx oraz szkielet głównej klasy usługi.

W pliku .asmx jest tylko informacja, że kod obsługujący stronę znajduje się w oddzielnym pliku:

<%@ WebService Language="C#"

CodeBehind="~/App_Code/Service.cs"

Class="Service" %>

Natomiast szkielet usługi WWWW to po prostu klasa z odpowiednimi atrybutami. Obowiązkowo trzeba dodać atrybut WebService, a warto też podać sensowną przestrzeń nazw, która będzie identyfikować usługę, i określić zgodność z profilem - w tym wypadku podstawowym.

Drugi ważny atrybut to WebMethod, który określa, że dana publiczna metoda będzie dostępna jako usługa WWW. I to już wszystkie zmiany niezbędne do przekształcenia klasy w całkowicie funkcjonalną usługę:

Publikacja na lokalnym serwerze IIS

Publikacja na lokalnym serwerze IIS

[WebService(Namespace =

"http://WSPayment.org/")]

[WebServiceBinding(ConformsTo =

WsiProfiles.BasicProfile1_1)]

public class

Service : System.Web.Services.WebService

{

public Service () { }

[WebMethod]

public int Add(int a1, int a2)

{

return a1 + a2;

}

}

Po naciśnięciu [F5] zostanie uruchomiona przeglądarka internetowa z testową stroną, pozwalającą wywołać funkcję WWW - tu o nazwie Add - i podać dwa parametry.

Równie łatwo można skorzystać z takiej usługi, ale warto najpierw udostępnić ją pod stałym adresem URL, np. na lokalnym serwerze IIS (serwer WWW dostarczany z Visual Studio startuje na różnych portach i trzeba by bardzo często zmieniać adres, który wywołuje klient).

Dodanie referencji do opublikowanej usługi WWW na lokalnym serwerze IIS.

Dodanie referencji do opublikowanej usługi WWW na lokalnym serwerze IIS.

Po skompilowaniu projektu można wybrać opcję Publish, po czym, używając przycisku obok pola Target Location, utworzyć nową aplikację IIS o nazwie WSPayment, następnie wybrać ją i wgrać tam daną usługę WWW (po wybraniu URL można zaakceptować domyślne ustawienia w oknie Publish Web Site).

W tym momencie można już dodać referencję do usługi WWW (podobnie jak w wypadku zwykłych referencji do bibliotek systemowych czy innych pakietów .NET). Wybieramy Add Web Reference, po czym podajemy adres URL danej usługi - tu: http://localhost/WSPayment/Service.asmx (bo pod tym adresem opublikowaliśmy usługę).

Gdy dodamy taki URL, powstanie odpowiedni parametr konfiguracyjny aplikacji - w Settings automatycznie dodawana jest składowa o nazwie WSClientWin_localhost_Service.

Dodanie referencji do usługi WWW to w rzeczywistości wygenerowanie rozbudowanego obiektu proxy, pośredniczącego w konstrukcji pakietu SOAP. Dzięki temu w aplikacji klienckiej można napisać:

localhost.Service s = new localhost.Service();

int result = s.Add(1, 2);


Zobacz również