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

id

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

id

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

ę

d

ą

umieszczane w nagłówkach HTTP.

Oto przykład:

<form method="get">

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

ś

ci

istniej

ą

cych typów danych. Protokół SOAP u

ż

ywany jest wył

ą

cznie w przypadkach, gdy trzeba

przesyła

ć

takie elementy jak polecenia b

ą

d

ź

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.

1

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

2

3

Imports System.Web.Services

4

5

public Class Calculator : Inherits WebService

6

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

7

intB As Integer) As Integer

8

Return(intA + intB)

9

End Function

10

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

mo

ż

e zdefiniowa

ć

dowoln

ą

ilo

ść

klas, jednak tylko jedna z nich mo

ż

e by

ć

u

ż

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:

1

<s:element name="Add">

2

<s:complexType>

3

<s:sequence>

4

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

5

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

6

</s:sequence>

7

</s:complexType>

8

</s:element>

9

<s:element name="AddResponse">

10

<s:complexType>

11

<s:sequence>

12

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

13

</s:sequence>

14

</s:complexType>

15

</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.

1

<?xml version="1.0" ?>

2

<disco:discovery

3

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

4

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

5

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

6

</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

ę

ki

temu procesowi s

ą

w stanie dowiedzie

ć

si

ę

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

).

1

Imports System

2

Imports System.Data

3

Imports System.Data.OleDb

4

Imports System.Web.Services

5

6

Namespace ASPNETDK

7

8

Public Class DatabaseService : Inherits WebService

9

private objConn as OleDbConnection

10

private objCmd as OleDbCommand

11

12

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

13

string) as DataSet

14

try

15

objConn = new OleDbConnection("Provider=" & _

16

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

17

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

18

dim objDataCmd as OleDbDataAdapter = new _

19

OleDbDataAdapter(strSelect, objConn)

20

21

Dim objDS as new DataSet

22

objDataCmd.Fill(objDS, "tblUsers")

23

return objDS

24

catch ex as OleDbException

25

return nothing

26

end try

27

end function

28

29

<WebMethod()> Public Function ExecuteNonQuery(strQuery _

30

as string) as Boolean

31

try

32

objConn = new OleDbConnection("Provider=" & _

33

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

34

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

35

objCmd = new OleDbCommand(strQuery, objConn)

36

objCmd.Connection.Open()

37

objCmd.ExecuteNonQuery

38

objCmd.Connection.Close()

39

return true

40

catch ex as OleDbException

41

return false

42

end try

43

end function

44

45

End Class

46

47

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

i

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.

1

<%@ 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

i

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

Je

ś

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

i

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

do

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.