Tworzenie Serwisów Sieci WWW

Tworzenie serwisów sieci
WWW

W poprzednim rozdziale przedstawione zostały sposoby tworzenia komponentów
wykorzystywanych w aplikacjach ASP.NET. Z komponentów tych moŜna korzystać za
pośrednictwem Internetu, aby zapewnić moŜliwości funkcjonalne stronom ASP.NET. Co się
jednak stanie, jeśli będziemy chcieli udostępnić te komponenty bez konieczności korzystania z
nich za pośrednictwem stron ASP.NET?

Serwisy sieci WWW są nowym sposobem uruchamiania aplikacji. Dzięki wykorzystaniu XML-a
oraz innych standardowych technologii serwisy sieci WWW umoŜliwiają aplikacjom oraz
komponentom na porozumiewanie się z innymi aplikacjami, niezaleŜnie od miejsca w którym są
uruchamiane.

W tym rozdziale poznasz zasady tworzenia serwisów sieci WWW. Są one rewolucyjnym
sposobem myślenia o aplikacjach internetowych i stanowią niezwykle waŜne zagadnienie dla
programistów ASP.NET. W kolejnym rozdziale dowiesz się, jak moŜna wykorzystywać serwisy
sieci WWW we własnych aplikacjach.

W tym rozdziale omówione zostaną następujące zagadnienia:

•

Czym są serwisy sieci WWW.

•

Jak działają serwisy sieci WWW.

•

Kiedy naleŜy ich uŜywać.

•

Sposoby tworzenia serwisów sieci WWW.

•

Sposoby tworzenia serwisów sieci WWW przy wykorzystaniu istniejących obiektów
biznesowych.

Sposób działania WWW w nowym uj

ciu

Gdy na początku niniejszej ksiąŜki zaczynałeś swoje spotkanie z ASP.NET, poznałeś podstawowy
sposób działania sieci WWW — chodzi konkretnie o model operacji Ŝądanie – odpowiedź. Klient
(na przykład, przeglądarka WWW) przesyła na serwer Ŝądanie dotyczące wybranej strony, a
serwer, w odpowiedzi, przesyła klientowi tę stronę.

Później poznałeś rozwiązania programistyczne związane z siecią WWW. ASP.NET oraz inne
technologie pozwalające na wykonywanie określonych czynności w momencie odebrania Ŝądania.
Udostępniając na serwerze moŜliwości programistyczne, moŜna zwracać dane w sposób
dynamiczny. Choć ASP.NET rozszerza ten model o mechanizm działania sterowany zdarzeniami,
to jednak podstawowa zasada działania WWW pozostaje taka sama — wciąŜ jest to Ŝądanie i
odpowiedź.

Strony ASP.NET udostępniają interfejs, pozwalający uŜytkownikom na interakcję z witryną
WWW. Poza tym interfejsem, zapewne pod postacią obiektów biznesowych, moŜe się kryć
potęŜna logika działania aplikacji. Ale co moŜna zrobić jeśli moŜliwości funkcjonalne jednej
aplikacji są tak potęŜne, Ŝe inni programiści chcą korzystać z nich w swoich aplikacjach? Albo co

zrobić jeśli ktoś chce wykorzystać moŜliwości funkcjonalne, lecz nie moŜe uŜyć interfejsu
uŜytkownika; co moŜe się zdarzyć, na przykład, gdy pracuje z poziomu wiersza poleceń? Jak
moŜna wykorzystać model Ŝądanie – odpowiedź w takich sytuacjach?

To całkiem proste. Przeanalizuj sposób w jaki strony ASP.NET wykorzystują obiekty biznesowe.
OtóŜ uŜywają one metod i właściwości tych obiektów do wykonywania określonych operacji, a
obiekty mogą, lecz nie muszą zwracać informacji. W rezultacie strona wysyła Ŝądanie wykonania
pewnych czynności, a następnie czeka na otrzymanie wyników.

Dlaczego inna aplikacja nie mogłaby wykorzystywać obiektów w taki sam sposób — wysłać
Ŝą

danie przez Internet i poczekać na otrzymanie wyników? Idea ta została zilustrowana na rysunku

16.1. Sam pomysł jest bardzo prosty, choć aŜ do tej pory nie istniała Ŝadna technologia, która
pozwoliłaby na jego realizację.

A oto nieco bardziej praktyczny przykład — jedna witryna WWW powinna być w stanie przesłać
Ŝą

danie do innej witryny i poczekać na odpowiedź. Pierwsza z witryn mogłaby wykorzystywać

metody i właściwości udostępniane przez drugą. Pomysł ten został zilustrowany na rysunku 16.2,
na przykładzie witryny prezentującej notowania giełdowe. UŜytkownik przesyła Ŝądanie do
witryny WWW, która z kolei przesyła Ŝądanie do witryny obsługującej operacje giełdowe. Druga
z witryn zwraca odpowiednie informacje pierwszej witrynie, która moŜe je zaprezentować w
dowolnej formie.

Prezentacja serwisów sieci WWW

Nowe określenie

Zanim poznasz serwisy sieci WWW warto określić czym jest normalny „serwis”. Gdy ktoś
wykonuje dla Ciebie jakąś czynność, to świadczy na Twoją rzecz pewną usługę. Na przykład, na
pewno jeździsz na stację benzynową aby zatankować lub naprawić samochód. Te usługi świadczy
stacja benzynowa i znajdujący się przy niej warsztat, dzięki czemu nie musisz samemu
wykonywać określonych czynności. Wyobraź sobie co by było, gdyby kaŜdy posiadacz
samochodu musiał mieć własny dystrybutor z paliwem. Bez wątpienia nie byłaby to idealne
rozwiązanie. Na pewno chodzisz takŜe do restauracji, które świadczą usługi gastronomiczne. Są to
wszystko zadania, które moŜesz wykonać samodzielnie, choć moŜesz nie mieć ochoty tego robić.
A zatem usługa (

serwis

) jest dodatkową operacją świadczoną przez pewną osobę lub firmę, dzięki

której nie musisz samodzielnie wykonywać określonych czynności.

Dokładnie tym samym są serwisy sieci WWW. Witryna WWW moŜe udostępniać takie serwisy, z
których mogą korzystać uŜytkownicy a nawet inne witryny WWW. Wyobraź sobie portal, który
prezentuje informacje lokalne i ogólnokrajowe, prognozę pogody, serwis sportowy oraz stronę
zawierającą informacje wybrane przez uŜytkownika. Serwis udostępniany przez ten portal, polega
na gromadzeniu, przetwarzaniu i zapisywaniu informacji pochodzących z wielu róŜnych źródeł.
Niemniej jednak, jeśli portal nie dysponuje ogromnym budŜetem oraz rzeszą pracowników, to
gromadzenie i tworzenie aktualnych informacji dla wszystkich tych działów jest niemal
niemoŜliwe.

Jednak portal moŜe wykorzystać inne rozwiązanie — uŜyć treści pochodzącej z innych witryn
zapewniając jedynie mechanizm ich prezentacji. W takim przypadku wciąŜ będzie on udostępniał
usługi dla swych uŜytkowników lecz jednocześnie jego działanie będzie zaleŜne od usług
udostępnianych przez inne witryny.

Rozwiązanie takie jest bardzo często wykorzystywane w witrynach informacyjnych. Na przykład,
Polska Agencja Prasowa udostępnia taki serwis, z którego mogą korzystać wydawcy gazet.
Następnym razem gdy będziesz czytać gazetę, poszukaj w niej doniesień dostarczanych przez
PAP. Zostały one pobrane właśnie z tego serwisu.

Systemy tego typu nie były zbyt popularne na Internecie ze względu na problemy dotyczące,
między innymi, sposobów komunikacji poszczególnych serwisów. Wiele firm podejmowało próby
stworzenia własnych, opatentowanych systemów komunikacyjnych, które umoŜliwiłyby wymianę
informacji z serwisami; rozwiązania te są jednak przewaŜnie zbyt drogie i skomplikowane, aby
mogła z nich korzystać większość uŜytkowników Internetu. Występowały takŜe problemy innego

typu — związane ze strukturą systemów bezpieczeństwa wykorzystywanych na Internecie. Wiele
spośród tych specjalistycznych systemów komunikacyjnych miało powaŜne trudności z
przekazywaniem informacji przez zapory ogniowe, które zostały zaprojektowane w celu
blokowania nieupowaŜnionych transmisji sieciowych.

Serwisy sieci WWW dostępne w środowisku .NET stanowią rozwiązanie wymienionych powyŜej,
oraz wielu innych problemów. Serwis sieci WWW jest programowalnym obiektem
(przypominającym nieco obiekt biznesowy) udostępniającym moŜliwości funkcjonalne, z których
moŜna korzystać za pośrednictwem Internetu. Serwisy sieci Web działają, gdyŜ wykorzystują
standardowe technologie zapewniające moŜliwość wymiany informacji pomiędzy obiektami. Ani
specjalistyczne systemy ani opatentowane mechanizmy nie są konieczne do zapewnienia
poprawnego funkcjonowania serwisów sieci WWW. Jedynym niezbędnym elementem jest
połączenie z Internetem.

Działanie serwisów sieci WWW opiera się na załoŜeniu, Ŝe kaŜdy system oraz aplikacja moŜe
korzystać z protokołu HTTP (standardowego protokołu komunikacyjnego wykorzystywanego na
Internecie) oraz jest w stanie wykorzystywać informacje zapisane w języku XML (stanowiącym
standardowy sposób dostarczania danych za pośrednictwem Sieci). Serwisy sieci WWW
wykorzystują język XML do przesyłania poleceń oraz przesyłania danych do oraz z obiektów
dostępnych na serwerze. Aplikacje korzystające z tych danych i wysyłające polecenia, mogą być
tworzone w dowolnym języku, na komputerach o dowolnej architekturze i mogą być całkiem
proste lub bardzo złoŜone. Jedyna informacją jaką taka aplikacja musi posiadać, jest lokalizacja
serwisu sieci WWW (czyli jego internetowy adres).

Serwisy sieci WWW stanowią nowy poziom przetwarzania. Na tej samej zasadzie, która
pozwalała programistom gromadzić róŜne obiekty i na ich podstawie tworzyć aplikację, teraz
moŜna wykorzystać grupę serwisów działających w dowolnym miejscu i wykorzystać je w swojej
aplikacji. Dzięki serwisom sieci WWW róŜne platformy komputerowe mogą teraz bez przeszkód
wymieniać informacje, łącząc i zapewniając moŜliwość współpracy zupełnie niezaleŜnych
systemów działających w miejscach kuli ziemskiej.

Scenariusze wykorzystania serwisów sieci WWW

ZałóŜmy, Ŝe stworzyliśmy komponent udostępniający podstawowe funkcje obliczeniowe, takie jak
te, zaimplementowane w kalkulatorze przedstawionym w rozdziale 2., pt.: „Tworzenie stron
ASP.NET”. Przypominasz sobie zapewne, Ŝe kalkulator wykonuje podstawowe operacje
arytmetyczne. Na potrzeby innej witryny, działającej w innym miejscu kuli ziemskiej, został
stworzony komponent umoŜliwiający składanie zamówień dla sklepu z materiałami budowlanymi
i remontowymi. Zakładając, Ŝe oba te komponenty są serwisami sieci WWW, przezorny i sprytny
programista, moŜe je połączyć i wykorzystać do stworzenia witryny umoŜliwiającej
uŜytkownikom zaprojektowanie i obliczenie kosztów budowy lub remontu mieszkania lub domu.
Jeśli uŜytkownik będzie musiał określić wymiary i przeprowadzić obliczenia, będzie mógł
skorzystać z serwisu udostępniającego funkcje obliczeniowe. Po zgromadzeniu wszystkich
potrzebnych informacji, moŜe on złoŜyć zamówienie przy uŜyciu drugiego z serwisów. Wszystkie
te czynności mogą być wykonane z poziomu jednej aplikacji, a uŜytkownik nie musi wiedzieć
skąd pochodzą wykorzystywane moŜliwości funkcjonalne. Przykład ten został zilustrowany na
rysunku 16.3.

Serwisy sieci WWW mogą być wykorzystywane nawet przez aplikacje internetowe. Wyobraź
sobie witrynę zajmującą się handlem elektronicznym, która musi obliczać koszty wysyłki towarów
zamawianych przez uŜytkowników. W normalnym przypadku, witryna taka musiałaby posiadać
tabelę z aktualnymi informacjami na temat stawek usług kurierskich w zaleŜności od wielkości i
cięŜaru przesyłki, jej miejsca docelowego, priorytetu oraz wielu innych czynników. W przypadku
wykorzystania serwisów sieci WWW, witryna taka mogłaby przesłać odpowiednie „Ŝądanie”
bezpośrednio do witryny firmy kurierskiej uŜywając w tym celu poleceń zapisanych w języku
XML i bezzwłocznie otrzymać wyliczoną kwotę określającą kosz konkretnej przesyłki. Serwisy
WWW pozwalają na bardzo proste połączenie aplikacji, których połączenie nastręczyłoby
wcześniej bardzo duŜych problemów.

Model programistyczny serwisów sieci WWW

Jak juŜ wcześniej wspominałem, serwisy sieci WWW komunikują się przy wykorzystaniu języka
XML. Jednak jakie informacje są wymieniane?

Nowe określenie

Pierwszy wysyłany komunikat zazwyczaj wiąŜe się z procesem określanym jako „

odkrywanie

”,

który umoŜliwia klientowi odszukanie i zdobycie informacji na temat serwisu sieci WWW. Proces
ten wiąŜe się z wymianą komunikatów zawierających informacje opisujące moŜliwości
konkretnego serwisu sieci WWW. Klient musi znać te informacje, nim będzie w stanie skorzystać
z serwisu. Serwis informuje równocześnie klienta o innych rodzajach komunikatów jakie moŜna
do niego przesyłać.

Proces odkrywania nie musi być wykonywany. Na przykład, jeśli autorzy serwisu nie chcą, aby
ktokolwiek niepowołany mógł się dowiedzieć o jego istnieniu i moŜliwościach, mogą wyłączyć
obsługę tego procesu. Jest to jeden ze środków zabezpieczających, dzięki którym nie kaŜdy będzie
mógł korzystać z utworzonych serwisów sieci WWW.

Po fazie „odkrycia”, serwis powinien poinformować klienta o informacjach jakie spodziewa się
otrzymać (czyli o poleceniach, które akceptuje) oraz o postaci zwracanych danych. Ten etap musi
być koniecznie wykonany, gdyŜ dzięki niemu zarówno serwis jak i klient wiedzą jak mogą się
wzajemnie komunikować. Informacje wymieniane podczas tego etapu określane są mianem

opisu

serwisu sieci WWW

. W przypadku obiektów biznesowych programista zazwyczaj zawczasu wie

jaki polecenia obsługuje wykorzystywany obiekt (na przykład, na podstawie jego dokumentacji).
W zasadzie, opis serwisu sieci WWW jest dokumentacją tego serwisu zapisaną w języku XML.

I w końcu ostatni etap polega na wymianie pomiędzy klientem i serwisem, komunikatów
zawierających polecenia i wyniki; przy czym klient przesyła polecenia, a serwis odpowiedzi
zawierające wyniki. TakŜe w tym przypadku, wszystkie wymieniane informacje są zapisane w
języku XML. Cały ten proces został przedstawiony na rysunku 16.4.

Na szczęście ASP.NET zapewnia niemal całą infrastrukturę konieczną do wykonania wszystkich
tych czynności. W końcu środowisko to jest w stanie obsługiwać Ŝądania i odpowiedzi, operować
na danych zapisanych w języku XML, korzystać z obiektów biznesowych — przez co doskonale
się nadaje do tworzenia serwisów sieci WWW.

Protokoły umo

liwiaj

ce korzystanie z serwisów

sieci WWW

JuŜ wiesz, Ŝe serwisy sieci WWW przesyłają dane i otrzymują polecenia przy uŜyciu
komunikatów zapisanych w języku XML. Konkretnie rzecz biorąc, dane XML są wykorzystywane
przy „odkrywaniu” serwisu oraz do jego opisania. Natomiast komunikaty zawierające polecenia
kierowane do serwisu nie muszą być zapisywane w języku XML. MoŜna je przesyłać przy uŜyciu
dwóch dodatkowych metod — Http-Get oraz Http-Post. Metody te są uŜywane przez strony
ASP.NET do przesyłania łańcuchów zapytań oraz informacji wpisywanych w polach formularzy.

Http-Get

Http-Get jest standardowym protokołem umoŜliwiającym klientom komunikację z serwerami przy
uŜyciu protokołu HTTP. To właśnie w ten sposób są zazwyczaj przesyłane Ŝądania dotyczące
stron WWW. Operację Http-Get moŜna sobie wyobrazić jako pobranie przez klienta strony z
serwera WWW. Ogólnie rzecz biorąc klient przesyła na serwer Ŝądanie HTTP dotyczące zasobu o
konkretnym adresie URL, a serwer w odpowiedzi zwraca odpowiedni kod HTML. Wszelkie
parametry konieczne do prawidłowego obsłuŜenia Ŝądania są dołączone do adresu URL jako, tak
zwany, łańcuch zapytania. Oto przykład:

http://www.serwer.com.pl/default.aspx?id=Chris&plec=M

Parametry

oraz

plec

są przesyłane na serwer jako dane wejściowe i zostają dopisane na końcu

adresu URL. Strona ASP.NET moŜe pobrać te wartości przy uŜyciu poniŜszego fragmentu kodu:

Request.Querystring("id")
Request.Querystring("plec")

Serwisy sieci WWW mogą wykorzystywać Ŝądania Http-Get i łańcuch zapytania do przesyłania
poleceń i zwracania wyników, zamiast komunikatów zapisanych w języku XML. Warto zwrócić
uwagę, Ŝe informacje przesyłane w ten sposób stanowią część adresu URL. Metoda ta ma jednak
ograniczone moŜliwości, gdyŜ umoŜliwia przesyłanie wyłącznie par nazwa-wartość.

Http-Post

Protokół ten przypomina Http-Get, lecz róŜni się od niego tym, iŜ informacje nie są przekazywane
w formie łańcucha zapytania, lecz zapisywane w nagłówkach Ŝądania HTTP. Gdy klient przesyła
Ŝą

danie przy uŜyciu tego protokołu, generuje on Ŝądanie HTTP zawierające dodatkowe informacje

zapisane w formie par nazwa-wartość. Serwer odbierając takie Ŝądanie musi je przetworzyć, aby
określić nazwy parametrów oraz ich wartości. Protokół ten jest najczęściej wykorzystywany przy
przesyłaniu formularzy HTML.

Na przykład, wyobraź sobie formularz HTML zawierający pola tekstowe o nazwach

oraz

plec

, którego kod przedstawiony został na poniŜszym przykładzie:

<form method="post">
  <input type="text" id="id">
  <input type="text" id="plec">

  <input type="submit" id="idSubmit" value="Wy

lij" />

</form>

W momencie wysyłania tego formularza przeglądarka pobiera wartości wprowadzone w polach
tekstowych i dopisuje je do nagłówków Ŝądania HTTP przesyłanych na serwer. Na serwerze,
wartości te moŜna pobrać przy uŜyciu poniŜszego fragmentu kodu:

Request.Form("id")
Request.Form("plec")

MoŜliwości tego protokołu, podobnie jak poprzedniego, ograniczają się jedynie do przesyłania par
nazwa-wartość.

Notatka
Zwró

uwag

e informacje podawane w polach formularzy mo

na przesyła

tak

e przy u

yciu

protokołu Http-Get. Aby to zrobi

, atrybutowi

METHOD

znacznika

<FORM>

nale

y przypisa

warto

ść

GET

. W tym przypadku, przy wysyłaniu formularza na serwer informacje podane w jego

polach zostan

dopisane do ła

cucha zapytania i nie b

umieszczane w nagłówkach HTTP.

Oto przykład:

SOAP

SOAP — prosty protokół dostępu do obiektów (ang: Simple Object Access Protocol) — jest
stosunkowo nowym standardem przesyłania informacji z klienta na serwer. W odróŜnieniu od
dwóch poprzednich protokołów, SOAP przesyła informacje w formie XML a nie przy uŜyciu
Ŝą

dań HTTP. Oznacza to, Ŝe przy jego uŜyciu moŜna przesyłać nie tylko proste pary nazwa-

wartość, lecz takŜe znacznie bardziej skomplikowane obiekty, takie jak złoŜone typy danych,
klasy, obiekty, itp.

Wysyłania komunikatów SOAP róŜni się nieco od sposobów przesyłania komunikatów do których
jesteśmy przyzwyczajeni. W przypadku uŜycia protokołu Http-Get informacje były przekazywane
w formie łańcucha zapytania, a w razie zastosowania protokołu Http-Post — poprzez przesyłanie
formularzy (przy czym informacje były zapisywane w nagłówkach Ŝądania HTTP). Protokół
SOAP takŜe przesyła dane przy wykorzystaniu HTTP, jednak jego działanie nie ogranicza się do
modelu Ŝądanie – odpowiedź. Za jego pomocą moŜna przesyłać dowolne komunikaty dowolnych

typów, niezaleŜnie od tego czy klient zaŜądał ich czy nie. Dzięki temu, protokół SOAP jest
niezwykle elastycznym medium przesyłu danych.

PoniewaŜ protokół ten bazuje na języku XML, moŜna go wykorzystywać do przesyłania
informacji za pośrednictwem WWW. Dane zapisane w języku XML to zwyczajny tekst, który
moŜna przesyłać dokładnie tak samo jak strony WWW, w tym takŜe poprzez zapory ogniowe.
SOAP jest standardowym protokołem wykorzystywanym przez serwisy sieci WWW do
komunikacji z klientami.

Notatka
Wiele osób mo

e si

pogubi

porównuj

c SOAP i XML. Je

li protokół SOAP jest tak

doskonałym sposobem przesyłania komunikatów, to dlaczego nie wykorzysta

go zamiast

XML? Ró

nica jednak polega na tym,

e XML słu

y do okre

lania formatu danych, podczas gdy

SOAP okre

la protokół u

ywany do ich przesyłania. Protokół SOAP wykorzystuje XML do

zapisu przesyłanych komunikatów. J

zyk XML jest idealnym sposobem przesyłania wi

kszo

istniej

cych typów danych. Protokół SOAP u

ywany jest wył

cznie w przypadkach, gdy trzeba

przesyła

takie elementy jak polecenia b

instrukcje.

Dlaczego warto u

ywa

serwisów sieci WWW?

Teraz kiedy juŜ wiesz czym są serwisy sieci WWW, moŜesz się zastanawiać dlaczego warto ich
uŜywać.

Spróbuj przypomnieć sobie świat 10 lub 15 lat temu, zanim pojawił się Internet. W tamtych
czasach systemu komputerowe były zupełnie niezaleŜnymi „bytami”, które nie dysponowały
Ŝ

adnym dostępem do innych systemów. Aplikacje były projektowane w celu wykorzystania na

jednym komputerze i nie miały Ŝadnych moŜliwości dzielenia się i wspólnego korzystania z
informacji. TakŜe moŜliwości wymiany informacji wewnątrz firmy lub pomiędzy firmami przy
wykorzystaniu komputerów, były w tamtych czasach bardzo ograniczone. Nawet prywatne
wiadomości były przewaŜnie dostarczane ręcznie.

Internet całkowicie zmienił sposób komunikacji. Zmienił takŜe sposób tworzenia aplikacji.
Aktualnie bardzo trudno spotkać aplikacje, które w Ŝaden sposób nie wykorzystują jego
moŜliwości. Istnieje natomiast wiele aplikacji, takich jak internetowe komunikatory, w których
dostarczanie danych uŜytkownikom jest w całości zaleŜne od Internetu.

Kolejnym etapem zapewniania łączności pomiędzy uŜytkownikami, jest dostarczanie aplikacji za
pośrednictwem Internetu. JuŜ teraz firmy starają się łączyć tradycyjne aplikacje tak, aby tworzyły
ś

ciśle zintegrowane, wieloelementowe pakiety. Wziąwszy pod uwagę ilość wciąŜ uŜywanych

starych aplikacji, jest to ogromne i przeraŜające zadanie.

Serwisy sieci WWW udostępniają bardzo prosty mechanizm słuŜący do wzajemnej wymiany
informacji pomiędzy aplikacjami. UmoŜliwiają one współdzielenie komponentów i udostępniają
moŜliwości funkcjonalne, z których mogą korzystać wszyscy niezaleŜnie od swego połoŜenia.
Wyobraź sobie, Ŝe juŜ nigdy nie będziesz musiał instalować na swoim komputerze jakiegokolwiek
oprogramowania — wystarczy, Ŝe nawiąŜesz połączenie z Internetem i skorzystasz z
odpowiedniego serwisu.

Wszystko dobrze, ale w jaki sposób serwisy sieci WWW są w stanie poprawić metody tworzenia
aplikacji internetowych? Jednym ze sposobów jest ułatwienie wielokrotnego wykorzystywania
kodu. Przypomnij sobie, Ŝe jednym z powodów przemawiających za stosowaniem obiektów
biznesowych była moŜliwość wielokrotnego wykorzystywania kodu, bez konieczności jego
powtórnego tworzenia. Nawet logika rozgałęziania — czyli funkcje i procedury — ułatwiają
wielokrotne wykorzystywanie tego samego kodu (więcej informacji na ten temat znajdziesz w
rozdziale 3., pt.: „Stosowanie Visual Basic.NET”). Dzięki serwisom sieci WWW moŜna korzystać
z kodu napisanego przez inne osoby bez konieczności kopiowania i instalowania czegokolwiek. W
ten sposób moŜna zaoszczędzić czas i energię, i uprościć dodawanie nowych moŜliwości
funkcjonalnych do tworzonych aplikacji ASP.NET.

Kolejną cenną zaletą serwisów sieci WWW jest łatwość wdraŜania i utrzymania. Dzięki nim juŜ
nigdy nie będzie trzeba instalować własnych komponentów i aplikacji na wielu róŜnych systemach
komputerowych. Zamiast tego uŜytkownicy będą dysponować standardowym środowiskiem

zapewniającym moŜliwość korzystania z aplikacji — za pośrednictwem Internetu. Co więcej, w
razie konieczności wprowadzenia jakichś zmian, nie będzie trzeba udostępniać Ŝadnych poprawek
ani nowych wersji programów. W zupełności wystarczy wprowadzenie modyfikacji w jednym
miejscu — serwisie sieci WWW — a wszystkie korzystające z niego klienty automatycznie będą
mogły z nich skorzystać. (Chyba Ŝe usuniesz moŜliwości funkcjonalne od których zaleŜy działanie
tych klientów, gdyŜ w takim przypadku konieczna będzie ich modyfikacja. Niemniej jednak, w
obu przypadkach proces ten jest znacznie łatwiejszy z punktu widzenia programisty.)

Tworzenie serwisów sieci WWW

Tworzenie serwisów sieci WWW składa się z kilku etapów, do których moŜna zaliczyć
implementację moŜliwości funkcjonalnych oraz tworzenie opisu serwisu. W kolejnych częściach
rozdziału zostaną opisane poszczególne etapy tworzenia prostego serwisu sieci WWW.

Implementacja mo

liwo

ci funkcjonalnych

Pliki serwisów sieci WWW są w zasadzie zwyczajnymi plikami zawierającymi kod źródłowy
napisany w języku VB.NET, którym nadano rozszerzenie

.asmx

. Sam serwis jest natomiast

reprezentowany przez klasę potomną klasy

WebService

. Przykład bardzo prostego serwisu sieci

WWW został przedstawiony na listingu 16.1.

Listing 16.1.

Prosty serwis sieci WWW.

<%@ WebService Language="VB" Class="Calculator" %>

Imports System.Web.Services

public Class Calculator : Inherits WebService

<WebMethod()> Public Function Add(intA As Integer, _

intB As Integer) As Integer

Return(intA + intB)

End Function

End Class

Analiza

Zapisz powyŜszy kod w pliku o nazwie

Calculator.asmx

. Jak widać, w 1. wierszu powyŜszego

przykładu została umieszczona dyrektywa

WebService

; przypomina ona nieco dyrektywę

Page

lecz informuje, iŜ plik reprezentuje serwis sieci WWW. Dyrektywa ta umoŜliwia uŜycie znanego
juŜ atrybutu

Language

, który w naszym przypadku informuje, Ŝe serwis został napisany w języku

VB. Dyrektywa obsługuje takŜe inny atrybut —

Class

. Określa on nazwę klasy tworzonego

serwisu sieci WWW. I faktycznie, w wierszu 5. moŜna się przekonać, Ŝe nazwa klasy naszego
serwisu to

Calculator

. W dalszej części rozdziału poznasz interesujące i przydatne moŜliwości

tego atrybutu.

Następnie, w wierszu 3. jest importowana przestrzeń nazw

System.Web.Services

. Dzięki temu,

będzie moŜna korzystać ze wszystkich koniecznych klas i metod serwisów sieci WWW. Klasa
definiowana w wierszu 5. musi dziedziczyć po klasie

WebService

zdefiniowanej w przestrzeni

nazw

System.Web.Services

Notatka
W jednym pliku

.asmx

e zdefiniowa

dowoln

ilo

ść

klas, jednak tylko jedna z nich mo

e by

ywana jako serwis sieci WWW. Mo

e nim by

tylko ta klasa, której nazwa została podana w

dyrektywnie

WebService

umieszczanej na samym pocz

tku pliku.

Przeanalizujmy teraz jedyną metodę zdefiniowaną w klasie

Calculator

. Deklarację metody

Add

moŜna by uznać za całkiem standardową gdyby nie dwa wyróŜniające ją elementy. Po pierwsze
metoda ta musi zostać zadeklarowana jako publiczna (

public

); w przeciwnym razie klienty nie

będą w stanie uzyskać dostępu to tej metody serwisu.

Drugim czynnikiem wyróŜniającym metodę

Add

, jest wykorzystanie atrybutu

<WebMethod()>

który informuje ASP.NET, Ŝe metoda ta ma być dostępna dla innych aplikacji w formie serwisu
sieci WWW. Jest to niezwykle waŜny atrybut, który musi zostać podany jeśli klienty mają mieć
moŜliwość dostępu do tej metody. W dalszej części rozdziału, pt.: „Atrybut WebMethod”
atrybut ten zostanie omówiony bardziej szczegółowo.

Podsumowując, metoda która ma być dostępna dla klientów korzystających z serwisu musi zostać
zadeklarowana jako

Public

(publiczna) i musi uŜywać atrybutu

<WebMethod()>

Oglądnijmy teraz tę stronę przy uŜyciu przeglądarki WWW. Jej wygląd przedstawiony został na
rysunku 16.5.

Rysunek 16.5.

Wyświetlanie plików

.asmx

w przeglądarce WWW

To niezwykle interesujące! Co się stało z kodem naszego przykładowego serwisu sieci WWW? I
skąd się wziął sposób prezentacji wyświetlonej strony?

Podobnie jak strony ASP.NET, takŜe pliki

.asmx

są kompilowane w momencie obsługi

pierwszego dotyczącego ich Ŝądania. Następnie, przy obsłudze kaŜdego zgłaszanego Ŝądania
dotyczącego tego pliku, ASP.NET zwraca klientowi opis serwisu. A zatem, na rysunku 16.5,
zostały przedstawione informacje jakie uzyska klient po przesłaniu Ŝądania dotyczącego serwisu
sieci WWW. Informacje te są zapisywane w języku XML. Przekazana odpowiedź zawiera nazwę
klasy —

Calculator

— oraz jej publiczne metody i właściwości. Połączenie umieszczone w

prawym, górnym wierzchołku strony odwołuje się do niej samej, lecz dodatkowo w łańcuchu
zapytania przekazuje parametr

WSLD

http://localhost/aspnetdlakazdego/rozdzial16/Calculator.asmx?WSDL

Parametr ten informuje ASP.NET, iŜ uŜytkownik Ŝyczy sobie zobaczyć opis serwisu w formie
XML. Opis naszego przykładowego serwisu przedstawiony został na rysunku 16.6.

Rysunek 16.6.

Opis naszego przykładowego serwisu sieci WWW zapisany w formie

dokumentu XML

Jak się okazuje, to całkiem spory dokument XML jak na taki mały serwis. Plik XML zapisywany
jest w standardowym formacie określanym jako Service Description Language (w skrócie SDL —
język opisu serwisów); a jego przeznaczeniem jest udostępnienie klientom informacji o
moŜliwościach serwisu. W ogóle nie będziemy się zajmować tym plikiem, lecz jeśli go
przeglądniesz, to powinieneś zauwaŜyć kilka znajomych elementów. Na przykład, niemal na
samym początku pliku moŜna znaleźć następujący fragment kodu:

<s:element name="Add">

<s:complexType>

<s:sequence>

<s:element minOccurs="1" maxOccurs="1" name="intA" type="s:int" />

<s:element minOccurs="1" maxOccurs="1" name="intB" type="s:int" />

</s:sequence>

</s:complexType>

</s:element>

<s:element name="AddResponse">

<s:complexType>

<s:sequence>

<s:element minOccurs="1" maxOccurs="1" name="AddResult"
type="s:int" />

</s:sequence>

</s:complexType>

</s:element>

Analiza

Pierwszy z dwóch elementów przedstawionych w powyŜszym fragmencie kodu opisuje metodę

Add

oraz jej argumenty; natomiast drugi — odpowiedź generowaną przez tę metodę, stosownie

określoną jako

AddResponse

. Pozostała część pliku zawiera informacje dotyczące sposobów

wykorzystania tego serwisu przy uŜyciu protokołów Http-Get, Http-Post oraz SOAP.

Ponownie wyświetl nasz przykładowy serwis sieci WWW w klasycznej postaci, a następnie kliknij
połączenie

Add

i przekonaj się czym jeszcze ASP.NET moŜe Cię zaskoczyć. Wygląd strony

wyświetlanej po kliknięciu połączenia

Add

przedstawiony został na rysunku 16.7.

Rysunek 16.7.

Szczegółowy opis metody Add

Jak widać, serwisy sieci WWW składają się z wielu elementów. Strona przedstawiona na
powyŜszym rysunku nazywana jest

stroną opisu

; podaje ona wiele szczegółowy informacji na

temat metody, a nawet pozwala ją przetestować. Podaj dwie liczby całkowite w polach
wyświetlonego formularza i kliknij przycisk

Invoke

. Na ekranie pojawi się nowe okno

przeglądarki, w którym zostanie wyświetlona odpowiedź przedstawiona w formie kodu XML.
Odpowiedź o identycznej postaci otrzyma klient po wywołaniu tej metody serwisu sieci WWW.
Kolejne trzy części strony — SOAP, HTTP GET oraz HTTP POST — pokazują przykłady
wywołania metody

Add

przy uŜyciu tych trzech protokołów.

Strona opisu pozwala przetestować działanie serwisu sieci WWW. Warto zauwaŜyć iŜ dane do
metody Add są podawane w formularzu, a zatem sama metoda zostaje wywołana przy uŜyciu
protokołu Http-Post.

Umo

liwienie odkrywania serwisów sieci WWW

Odkrywanie jest procesem za pomocą którego aplikacja kliencka odnajduje serwis sieci WWW i
określa jego moŜliwości. Wszystkie niezbędne informacje są podawane przez opis serwisu, jednak
większość klientów nie będzie (ani nie powinna) znać nazwy pliku do którego naleŜy się odwołać,
aby uzyskać ten opis. A zatem, umoŜliwienie odkrywania serwisów sieci WWW oznacza
udostępnienie klientom połączeń do ich opisów.

Wykonanie procesu odkrywania jest moŜliwe dzięki plikom

.disco

udostępnianym na serwerze

WWW. Pliki te są dokumentami XML zawierającymi połączenia z opisami serwisów sieci WWW.

A zatem, za pośrednictwem tych plików, klient moŜe zdobyć więcej informacji dotyczących
dostępnych serwisów.

Stworzenie pliku

.disco

jest bardzo proste. Listing 16.2 przedstawia plik

.disco

dla naszego

przykładowego serwisu Calculator.

Listing 16.2.

Plik

.disco

dla serwisu Calculator.

<?xml version="1.0" ?>

<disco:discovery

xmlns:disco="http://schemas.xmlsoap.org/disco/"

xmlns:scl="http://schemas.xmlsoap.org/disco/scl">

<scl:contractRef ref="Calculator.asmx?WSDL"/>

</disco:discovery>

Analiza

Zapisz powyŜszy kod w pliku

Calculator.disco

. Jak widać powyŜszy plik jest bardzo prosty, gdyŜ

zawiera jedynie połączenie z opisem naszego przykładowego serwisu sieci WWW (w wierszu 5.).
Dodatkowe przestrzenie nazw określone przy uŜyciu znaczników

xmlns

wskazują adresy URL

dokumentów zawierających informacje o znacznikach których moŜna uŜywać wewnątrz
znaczników

scl

oraz

disco

. Innymi słowy, znaczniki

xmlns

zawierają połączenia ze

standardowymi definicjami znaczników

scl

oraz

disco

. Bez tych przestrzeni nazw nasza

aplikacja nie widziałaby co naleŜy zrobić z tymi dodatkowymi znacznikami.

Znacznik

disco:discovery

zawiera połączenia, których klient moŜe uŜyć jeśli chce zdobyć

więcej informacji na temat serwisu sieci WWW. Połączenia te mogą wskazywać inne pliki

.disco

lub opis serwisów. Połączenia wskazujące na pliki opisu serwisów są definiowane przy uŜyciu
znaczników

scl

. Przykład takiego znacznika, moŜna zobaczyć w 5. wierszu powyŜszego listingu.

Aby podać połączenie z innym plikiem

.disco

, naleŜy uŜyć następującego znacznika:

<disco:discoveryRef ref="adres" />

Jeśli zaŜądamy wyświetlenia tego pliku w przeglądarce, powinien się w nim pojawić ten sam plik
XML.

Notatka
Plik

.disco

nie jest elementem koniecznym do zapewnienia poprawnego działania serwisu sieci

WWW. Je

li znany jest odpowiedni adres URL, to klienty mog

uzyska

bezpo

redni dost

p do

pliku serwisu. Odkrywanie dokumentów pomaga wył

cznie anonimowych klientom, które dzi

temu procesowi s

w stanie dowiedzie

o udost

pnianych serwisach sieci WWW.

Atrybut WebMethod

Serwis sieci WWW moŜe mieć metody, tak samo jak zwyczajna klasa lub obiekt biznesowy.
Jednak wyłącznie metody opatrzone atrybutem

WebMethod

(patrz wiersz 6. listingu 16.1) będą

dostępne dla klientów korzystających z serwisu. Przypomnij sobie, Ŝe wyłącznie publiczne
właściwości i metody obiektów biznesowych są dostępne dla stron ASP.NET, które uŜywają tych
obiektów; natomiast metody i właściwości prywatne są dostępne wyłącznie dla samego obiektu. W
analogiczny sposób atrybut

WebMethod

ogranicza moŜliwość dostępu, jedynie do wybranych

metod serwisu.

Metody, w których definicjach pojawił się atrybut

WebMethod

, nazywane takŜe metodami sieci

WWW, działają jak zwyczajne metody danej klasy. Mogą one prowadzić interakcję z obiektami

Session

oraz

Cache

ASP.NET (patrz rozdział 4., pt.: „Stosowanie obiektów ASP.NET w

językach C# i VB.NET” oraz 14., pt.: „Wykorzystanie ulepszonych mechanizmów obsługi
pamięci podręcznej ASP.NET”), podobnie jak stron ASP.NET dają moŜliwość buforowania
odpowiedzi (patrz rozdział 4.) oraz prowadzić wymianę informacji z bazami oraz innymi źródłami
danych. W zasadzie od zwyczajnych metod róŜnią się tylko pod jednym względem — moŜna z
nich korzystać za pośrednictwem Internetu.

To niezwykle waŜne. W końcu, metody są jednymi z najwaŜniejszych elementów klasy, gdyŜ to
właśnie one określają w jaki sposób uŜytkownicy będą z tych klas korzystać. Metody zawierające
w definicji atrybut

WebMethod

uwaŜają, Ŝe wszystkie, ogólnie pojęte programy, które je

wywołują, działają w sposób lokalny. Oznacza to, Ŝe nie ma Ŝadnej róŜnicy pomiędzy
wywołaniem takiej metody ze strony ASP.NET znajdującej się w tym samym folderze co plik

.asmx

, ani z serwera znajdującego się na drugim końcu świata. Atrybut

WebMethod

jest

kluczowym elementem zapewniającym moŜliwość wykorzystania serwisów sieci WWW; a zatem
przyjrzyjmy mu się dokładniej. Atrybut ten posiada wiele interesujących moŜliwości.
Reprezentuje on klasę

WebMethodAttribute

, która działa tak samo jak kaŜda inna klasa

rodowiska .NET i posiada swoje właściwości i metody. Oznacza to, Ŝe umieszczając w kodzie

poniŜszą deklarację metody z atrybutem

WebMethod

, de facto tworzona jest nowy obiekt klasy

WebMethodAttribute

<WebMethod()> Public Function Add(intA As Integer)

Przypisywanie wartości właściwościom tej metody odbywa się nieco inaczej niŜ to do czego
moŜesz być przyzwyczajony. Oto przykład:

<WebMethod(Description:="Dodaj dwie liczby ")> Public Function _
Add(intA As Integer,intB As Integer)

Właściwość oraz wartość podawane są w nawiasach bezpośrednio wewnątrz deklaracji funkcji.
NaleŜy zwrócić szczególną uwagę na znak dwukropka umieszczony przed znakiem równości —
oznacza on inicjalizację właściwości a nie podanie argumentu wywołania metody. W przypadku
uŜycia następującego kodu:

<WebMethod(Description="Dodaj dwie liczby ")>
Public Function Add(intA As Integer,intB As Integer)

W przypadku uŜycia powyŜszego fragmentu kodu, wyraŜenie

Description="Dodaj dwie

liczby "

zostałoby potraktowane jako nazwa zmiennej, która ma zostać uŜyta przy tworzeniu

obiektu

WebMethod

. Być moŜe poprawny sposób zapisu jest nieco dziwny, lecz przynajmniej

umoŜliwia on określanie wartości właściwości obiektów

WebMethod

. Aby określić wartości kilku

róŜnych właściwości, naleŜy je oddzielić od siebie przecinkami:

<WebMethod(Description:="Dodaj dwie liczby ", _
EnableSession:=False)> Add(intA As Integer, intB As Integer)

Właściwości jakich moŜna uŜywać w atrybucie

WebMethod

zostały opisane w tabeli 16.1.

Tabela 16.1.

Właściwości atrybutu WebMethod.

Właściwość

Opis

BufferResponse

Właściwość ta określa czy wyniki działania serwisu sieci WWW mają
być buforowane czy nie. Domyślną wartością tej właściwości jest

true

W tym przypadku wszystkie generowane odpowiedzi zanim zostaną
przesłane do klienta są buforowane na serwerze. Dane są przesyłane do
klienta w postaci niewielkich fragmentów.

W przypadku zwracania duŜych ilości informacji warto przypisać tej
właściwości wartość

false

, dzięki czemu dane będą przesyłane w

sposób ciągły, co zapewni nieco lepszą efektywność działania. We
wszelkich innych przypadkach właściwość ta zawsze powinna mieć
wartość

true

CacheDuration

Wyniki zwracane przez metody sieci WWW, tak samo jak strony
ASP.NET, moŜna przechowywać w pamięci podręcznej. Ta właściwość
podaje okres czasu (wyraŜony w sekundach) jaki odpowiedź powinna być
przechowywana w pamięci podręcznej. Domyślnie właściwość ta ma
wartość 0, co oznacza, Ŝe wyniki działania metody sieci WWW nie są
buforowane.

Jeśli właściwości tej zostanie przypisana jakakolwiek wartość większa od
zera, to wyniki wykonania metody zostaną zapisane w pamięci

podręcznej na podaną ilość sekund; a wszystkie kolejne odwołania do tej
metody nie będą powodowały jej wykonania, lecz spowodują pobranie
danych z pamięci podręcznej.

Z przechowywania wyników w pamięci podręcznej warto korzystać w
przypadkach gdy zwracanych jest duŜo informacji. Więcej sugestii i
informacji na temat uŜycia pamięci podręcznej znajdziesz w rozdziale 14.

Description

Ta właściwość umoŜliwia podanie opisu metody, która będzie
przekazywana klientom. Opis podany za jej pośrednictwem będzie takŜe
dostępny na stronie opisu serwisu sieci WWW. Domyślna wartość tej
właściwości to

String.Empty

EnableSession

Ta właściwość określa czy dla danej metody naleŜy włączyć sesję czy nie.
Jeśli sesja jest uŜywana (a tak się dzieje domyślnie) to w metodzie będzie
moŜna zapamiętywać dane przy uŜyciu obiektu

Session

. Jeśli jednak nie

ma konieczności zapisywania danych w zmiennych sesyjnych, to moŜna
wyłączyć tę opcję. Wyłączenie obsługi sesji umoŜliwia poprawienie
efektywności działania metody.

MessageName

Ta właściwość określa nazwę uŜywaną przez dane przesyłane do oraz z
serwisu sieci WWW do wywołania tej metody. Domyślnie nazwa ta
odpowiada nazwie metody sieci WWW.

Właściwość ta jest przewaŜnie stosowana w celu zapewnienia unikalności
nazw metod. Na przykład, jeśli dysponujemy dwiema przeciąŜonymi
metodami

Add

, które róŜnią się typami pobieranych argumentów, to

dzięki właściwości

MessageName

moŜna im nadać unikalne nazwy.

Wartość tej właściwości musi być unikalna w obrębie danego serwisu
sieci WWW.

TransactionOption

Podobnie jak operacje na bazach danych, takŜe i wywołania metod sieci
WWW mogą być traktowane jako transakcje. Cały kod wykonywany
wewnątrz transakcji zostanie wykonany poprawnie, lub w ogóle nie
zostanie wykonany. Jeśli podczas wykonywania jednego z wierszy kodu
pojawi się błąd, to realizacja metody zostanie przerwana a wyniki
działania wszystkich wykonanych wiersz będą odtworzone. Więcej
informacji na temat transakcji znajdziesz w rozdziale 12., pt.:
„Zastosowanie zaawansowanych technik obsługi danych”.

Właściwość ta moŜe przyjmować następujące wartości:

Disabled

— metoda jest wykonywana bez wykorzystania transakcji;

NotSupported

— wykorzystanie transakcji nie jest moŜliwe;

Supported

— moŜna korzystać z transakcji, lecz metoda nie jest

wykonywana wewnątrz Ŝadnej transakcji;

Required

— uŜycie transakcji jest wymagane, naleŜy utworzyć nową

transakcję;

RequiresNew

— uŜycie transakcji jest wymagane, naleŜy utworzyć

nową transakcję.

TypeID

Unikalny identyfikator określający dany atrybut. Ta właściwość pomaga
w rozróŜnianiu atrybutów o identycznych typach.

Uruchamianie serwisów sieci WWW

Uruchomienie serwisu sieci WWW jest bardzo prostym zadaniem. PoniewaŜ wirtualna maszyna
CLR w całości zarządza aplikacjami ASP.NET, wystarczy jedynie skopiować wybrane pliki

.asmx

.disco

oraz potrzebne obiekty biznesowe do odpowiedniego folderu. Uruchamianie

aplikacji nigdy nie było prostsze!

Bardzo często w folderach zawierających serwisy sieci WWW tworzone są pliki konfiguracyjne

web.config

. Bardzo często twórcy serwisów będą chcieli wykorzystać jakieś mechanizmy

zabezpieczeń, które uniemoŜliwią niepowołanym osobom wykorzystanie efektów ich pracy.
Przykładowo, jeśli stworzyłeś serwis sieci WWW dla jakiejś firmy, to zapewne, będzie on
wykorzystywany przez nią do zarabiania pieniędzy. Gdyby wszyscy mieli nieograniczony dostęp
do tego serwisu, firma nigdy by nic nie zarobiła. Zabezpieczanie serwisów sieci WWW zapobiega
takim sytuacjom i pozwala na kontrolę dostępu do serwisu. Zagadnienia dotyczące zabezpieczania
serwisów sieci WWW zostaną omówione w kolejnym rozdziale.

Ostrze

enie

Folder w którym zostanie umieszczony serwis sieci WWW musi zosta

oznaczony jako folder

aplikacji Internet Information Servera (IIS). W przeciwnym razie, serwis nie b

dzie mógł by

wykonywany i nie b

dzie dost

pny dla klientów.

Wszystkie foldery, które pozwalaj

na wykonywanie stron ASP.NET s

folderami aplikacji IIS.

Tworzenie serwisów sieci WWW na
podstawie istniej

cych obiektów

biznesowych

Serwisy sieci WWW moŜna takŜe tworzyć na podstawie istniejących obiektów biznesowych,
dzięki czemu nie trzeba ponownie implementować wszystkich moŜliwości funkcjonalnych.
Niemniej jednak, aby wykorzystać obiekty biznesowe w serwisach sieci WWW trzeba je będzie
nieco zmodyfikować.

Zobaczmy zatem, jak naleŜy zmodyfikować obiekt biznesowy obsługujący bazę danych
(stworzony w poprzednim rozdziale), tak aby moŜna go było wykorzystać z serwisie sieci WWW.
Aby zamienić nasz obiekt biznesowy w serwis naleŜy wykonać trzy czynności: podać, Ŝe obiekt
ten jest klasą potomną klasy

System.Web.Services.WebService

, dodać atrybut

WebMethod

do deklaracji metod, które mają być udostępniane przez serwis oraz zastąpić wykorzystywany
obiekt

OleDbDataReader

obiektem

DataSet

, którego zawartość moŜna przekazać w formie

danych XML (w dalszej części rozdziału dokładniej opiszę to zagadnienie). Zmodyfikowana
wersja naszego obiektu biznesowego, nosząca teraz nazwę

DatabaseSerivce

, została

przedstawiona na listingu 16.4.

Listing 16.4.

Przekształcenie obiektu biznesowego Database do postaci serwisu sieci WWW

(

DatabaseService.vb

Imports System

Imports System.Data

Imports System.Data.OleDb

Imports System.Web.Services

Namespace ASPNETDK

Public Class DatabaseService : Inherits WebService

private objConn as OleDbConnection

private objCmd as OleDbCommand

<WebMethod()> Public Function SelectSQL(strSelect as _

string) as DataSet

try

objConn = new OleDbConnection("Provider=" & _

"Microsoft.Jet.OLEDB.4.0;" & _

"Data Source=C:\ASPNET\data\banking.mdb")

dim objDataCmd as OleDbDataAdapter = new _

OleDbDataAdapter(strSelect, objConn)

Dim objDS as new DataSet

objDataCmd.Fill(objDS, "tblUsers")

return objDS

catch ex as OleDbException

return nothing

end try

end function

<WebMethod()> Public Function ExecuteNonQuery(strQuery _

as string) as Boolean

try

objConn = new OleDbConnection("Provider=" & _

"Microsoft.Jet.OLEDB.4.0;" & _

"Data Source=C:\ASPNET\data\banking.mdb")

objCmd = new OleDbCommand(strQuery, objConn)

objCmd.Connection.Open()

objCmd.ExecuteNonQuery

objCmd.Connection.Close()

return true

catch ex as OleDbException

return false

end try

end function

End Class

End Namespace

W wierszu 4. importowana jest dodatkowa przestrzeń nazw —

System.Web.Services

Deklaracja umieszczona w wierszu 8. informuje, Ŝe klasą bazową naszego serwisu jest klasa

WebService

, zdefiniowana w przestrzeni nazw zaimportowanej w wierszu 4. Kolejną

modyfikacją wprowadzona w kodzie naszego obiektu biznesowego są atrybuty

<WebMethod()>

dodane do metod, które będzie udostępniał tworzony serwis. I w końcu, w metodzie

SelectSQL

obiekty

OleDbDataReader

OleDbCommand

zostały odpowiednio zastąpione obiektami

DataSet

oraz

OleDbDataAdapter

. I to wszystko. Teraz wystarczy ponownie skompilować plik

posługując się przy tym następującym poleceniem:

vbc /t:library /out:..\bin\ASPNETDK.dll /r:System.dll
/r:System.Data.dll /r:System.Web.Services.dll /r:System.Xml.dll
DatabaseService.vb ..\rozdzial15\User.vb

PowyŜsze polecenie kompiluje nowy plik

DatabaseService.vb

oraz plik

User.vb

z poprzedniego

rozdziału i generuje bibliotekę DLL o nazwie

ASPNETDK.dll

. W poleceniu zostały takŜe

wykorzystane dwie nowe biblioteki —

System.Web.Services.dll

oraz

System.Xml.dll

. Powód

wykorzystania pierwszej z nich jest chyba oczywisty; odwołanie do drugiej zostało uŜyte gdyŜ
zawiera ona metody konieczne do przesłania zawartości obiektu

DataSet

w formie danych XML.

Więcej informacji na temat kompilator język VB.NET znajdziesz w poprzednim rozdziale, pt.:
„Zastosowanie obiektów biznesowych”.

Notatka !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Teraz nowe obiekty powinny juŜ być zapisane w pamięci podręcznej komponentów .NET, gdzie
ASP.NET będzie w stanie je załadować i uŜyć. Teraz nadszedł czas, aby stworzyć plik

.asmx

który pozwoli klientom korzystać z naszego nowego obiektu. Został on przedstawiony na listingu
16.5.

Listing 16.5.

Plik

.asmx

umoŜliwiający wykorzystanie serwisu DatabaseService.

<%@ WebService Class="ASPNETDK.DatabaseService" %>

To naprawdę wszystko! Jedyną rzeczą jaką trzeba zrobić aby móc skorzystać z naszego nowego
serwisu sieci WWW, jest zmiana nazwy klasy. Teraz zapisz ten plik pod nazwą

Database.asmx

wyświetl go w przeglądarce. Na wyświetlonej stronie powinieneś przekonać się, Ŝe nasz serwis
udostępnia dwie metody —

SelectSQL

oraz

SelectNonQuery

Ostrze

enie

li w serwisie sieci WWW chcesz u

ywa

jakiegokolwiek prekompilowanego obiektu, to musi

on zosta

umieszczony w pami

ci podr

cznej komponentów .NET (czyli folderze

/bin

). W

przeciwnym bowiem razie ASP.NET nie b

dzie w stanie go odnale

źć

Kliknij połączenie z metodą

SelectSQL

i w testowym formularzu wyświetlonym na samym

początku strony wpisz następujące zapytanie SQL:

SELECT * FROM tblUsers

. Kliknij przycisk

Invoke

. Na ekranie powinno pojawić się nowe okno przeglądarki, a w nim nowa strona

przypominające tą przedstawioną na rysunku 16.8.

Rysunek 16.8.

Informacje zwrócone przez serwis DatabaseService

Dokument XML przedstawiony na rysunku 16.8 definiuje strukturę obiektu

DataSet

zwróconego

przez nasz serwis sieci WWW. Przeglądając dalszą część strony moŜna w niej znaleźć takŜe
faktyczne informacje pobrane z bazy danych. Klient który pobierze ten dokument, w razie
konieczności nie będzie miał Ŝadnych problemów z przekształceniem jego zawartości do postaci
obiektu

DataSet

Zwracanie informacji przez serwisy sieci
WWW

Jak pokazałem we wcześniejszej części rozdziału, serwisy sieci WWW mogą zwracać dane
przeróŜnych typów. MoŜliwość ta jest dostępna gdyŜ serwisy zostały stworzone na podstawie
technologii wykorzystującej język XML, stanowiący niezwykle potęŜne narzędzie reprezentacji
danych. Choć XML jest językiem tekstowym, wykorzystywany w nim system nazewnictwa typów
sprawia, Ŝe inne aplikacje nie mają większych problemów z określenie typów przesyłanych
informacji.

Oto przykład. Doskonale wiemy, Ŝe obiekty

DataSet

są reprezentowane w pamięci komputera

głównie jaki dane XML, a zatem nie trudno domyślić się, Ŝe obiekty te mogą być przesyłane w
formie dokumentów XML. Język XML jest takŜe w stanie reprezentować inne typy danych, takie
jak łańcuchy znaków, liczby całkowite, tablice, obiekty

DataTime

, itd. W tabeli 16.2 zostały

przedstawione róŜne typy danych, które mogą zwracać serwisy sieci WWW.

Tabela 16.2.

Typy danych, które mogą być zwracane przez serwisy sieci WWW.

Typ

Opis

Tablice

Serwisy sieci WWW są w stanie przesyłać tablice zawierające dane
dowolnych typów podanych w dalszej części tej tabeli, w tym: obiekty klas

DataSet

XmlNode

, podstawowe typy danych oraz klasy.

Klasy

Klasy posiadające publiczne właściwości.

Zbiory danych
(

DataSet

)

Informacje przechowywane w obiektach klasy

DataSet

są zapisane w

formie danych XML, a zatem serwisy sieci WWW nie mają Ŝadnych
problemów ich wykorzystaniem.

NaleŜy pamiętać, iŜ są to jedyne „zbiory danych” ADO.NET które moŜna
przesyłać. Obiekty klasy

DataReader

nie dają juŜ tych moŜliwości.

Typy podstawowe

Podstawowe typy danych to:

byte

Boolean

char

DateTime

Decimal

Double

GUID

int32

int64

uing16

uint32

uint64

oraz

XmlQualifiedName

Klasy

XmlNode

Obiekty klasy

XmlNode

środowiska .NET słuŜą do reprezentacji danych

XML w pamięci komputera. Więcej informacji na ten temat znajdziesz w
rozdziale 11., pt.: „UŜycie XML w ASP.NET”.

Serwisy sieci WWW mogą zwracać dane wszystkich typów przedstawionych w tabeli 16.2; jednak
ilość typów danych, których moŜna uŜyć w celu przekazania informacji

serwisu, jest znacznie

bardziej ograniczona.

W przypadku przekazywania poleceń i parametrów z klienta do serwisu przy wykorzystaniu
protokołu SOAP, moŜna stosować wszystkie typy danych podane w tabeli 16.2. Jest to moŜliwe
gdyŜ protokół ten bazuje na języku XML.

Jednak w przypadku przekazywania danych przy uŜyciu protokołów Http-Get lub Http-Post
dostępne moŜliwości ograniczają się do typów danych obsługiwanych przez te protokoły. Są to
wybrane typy podstawowe oraz tablice zawierające dane tych typów. Oba te protokoły pozwalają
wyłącznie na wysyłanie par nazwa-wartość, co automatycznie wyklucza moŜliwość przesyłania
bardziej złoŜonych struktur danych, takich jak klasy orz zbiory danych.

To nie jest ASP!

Serwisy sieci WWW są całkowicie nowym zagadnieniem wprowadzonym w technologii
ASP.NET. A zatem, jeśli jesteś programistą, który do tej pory uŜywał tradycyjnej technologii
ASP, to poznałeś coś zupełnie nowego. Niemniej jednak kluczowe załoŜenia związane z
wykorzystaniem serwisów sieci WWW, jak na przykład wzajemna komunikacja całkowicie
niezaleŜnych systemów, przypominają cele technologii COM (Component Object Model). (Więcej
informacji na temat obiektów COM znajdziesz w poprzednim rozdziale.)

Celem technologii COM było umoŜliwienie tworzenia aplikacji złoŜonych z róŜnych
komponentów. Dzięki temu, iŜ obiekty te komunikowały się przy wykorzystaniu protokołu COM,
moŜna je było tworzyć w róŜnych językach programowania. Jednak technologia ta miała jedno
powaŜne ograniczenie — moŜna ją było stosować tylko w systemach Windows.

Serwisy sieci WWW idą znacznie dalej, gdyŜ do komunikacji pomiędzy obiektami nie
wykorzystują Ŝadnych firmowych protokołów ani nie przesyłają informacji w sposób binarny.
Serwisy sieci WWW bazują wyłącznie na otwartych standardach, takich jak XML i HTTP.
Oznacza to, iŜ zapewniają one niczym nie ograniczone moŜliwości wzajemnego współdziałania
całkowicie niezaleŜnych systemów informatycznych.

Sam pomysł tworzenia aplikacji dostępnych i uŜywanych za pośrednictwem Internetu, nie jest
jednak całkiem nowy. Wcześniejsze próby jego realizacji, podobne do technologii COM,
bazowały na wykorzystaniu złoŜonych, opatentowanych standardów, które w powaŜnym stopniu
ograniczały moŜliwości ich zastosowania. Niezwykła efektywność serwisów sieci WWW wynika
z prostoty protokołu HTTP i języka XML.