Rozdział 16.
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ę.

Rysunek 16.1. Aplikacje powinny być w stanie prowadzić interakcję z serwisami sieci WWW w podobny sposób, jak strony ASP.NET korzystają z obiektów biznesowych

Opis rysunku

ASP.NET page — Strona ASP.NET

Send commnads — Przesyła polecenia

Business … — Obiekt biznesowy

Return data — Zwraca dane

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.

Rysunek 16.2. Serwisy sieci WWW pozwalają witrynom WWW na wykorzystanie możliwości funkcjonalnych innych witryn

Opis rysunku

User … — Użytkownik żąda informacji o „ACME”

Site 1 — Witryna WWW nr. 1

Site 1 receives request… — Pierwsza witryna WWW otrzymuje żądanie. Żąda informacji o „ACME” od witryny WWW nr. 2.

Witryna nr. 1 otrzymuje informacje i wyświetla je na stronie.

Site 2.… — Witryna WWW nr. 2 (operacje giełdowe)

Witryna nr. 2 otrzymuje żądanie, pobiera informacje dotyczące „ACME” z bazy danych i przesyła je z powrotem do witryny nr. 1.

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.

Rysunek 16.3. Pojedyncza aplikacja wykorzystująca wiele serwisów sieci WWW

Opis rysunku

Internet - Internet

Calculator service — Serwis sieci WWW zapewniający możliwości obliczeniowe

Shopping service — Serwis sieci WWW realizujący składanie zamówień

Calculate measurements — Obliczenie wymiarów

Place … — Złożenie zamówienia

Home design … — Aplikacja umożliwiająca projektowanie domu lub mieszkania

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.

Rysunek 16.4. Wykorzystanie serwisu sieci WWW wiąże się z jego „odkryciem”, pobraniem opisu oraz przesyłaniem poleceń

Opis rysunku

UWAGA!!!! wszystkie strzałki na rysunku powinny być skierowane w przeciwnym kierunku!!

1. Discovery — 1. Odkrycie

Application — Aplikacja

Web service — Serwis sieci WWW

What do you do? — Jakie są możliwości serwisu?

Description — Opis

2. Service description — Opis serwisu sieci WWW

What do you expect? — Czego serwis oczekuje?

3. Commands — Polecenia

Do this — Wykonaj to

Here are — Oto wyniki

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.

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

• <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ę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 "[Author:p8R] )>

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)[Author:p8R] . 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 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 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![Author:p8R]

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

2 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)

2 Dokument2

UWAGA! Nie wiem czy słusznie usunąłem dwukropek sprzed znaku równości, ale chyba tak, bo ma to być przykład błędnego zapisu, a w zapisie prawidłowym dwukropek jest. Poza tym sam komentarz autora sugeruje brak dwukropka. Natomiast co do drugiej części wyrażenia w nawiasach — ,_ Enable…:=False — pominąłem je, gdyż użyte w tym przypadku możliwości są opisywane dopiero przy okazji kolejnego przykładu (tuż nad tabelą 16.1). A zatem, aby nie zmuszać czytelników do zastanawiania się co to jest i skąd to się wzięło — wywaliłem to wyrażenie.

Szczerze mówiąc nie wiem o co autorowi chodzi, więc przetłumaczyłem to „dosłownie”. Przeglądnąłem opcje w IIS-ie i nie ma tam niczego co by przypominało to o czym autor pisze. Przypuszczam, że mogło mu chodzić o konieczność nadania folderowi w którym jest umieszczony serwis praw do wykonywania skryptów. Faktycznie, jeśli folder nie będzie miał tych praw, to serwis nie będzie działać. Proponuję zatem zamienić część zdania po „... sieci WWW musi” na: „posiadać prawo do wykonywania skryptów”. A drugi akapit ostrzeżenia zamienić na: „Wszystkie foldery, które pozwalają na wykonywanie stron ASP.NET będą także dawać możliwość uruchamiania serwisów sieci WWW.”

UWAGA !!!! Notatkę pominąłem celowo, gdyż umieszczone w niej informacje nie są prawdziwe!! Atrybut <WebMethod()> trzeba umieszczać na samym początku deklaracji funkcji, w przeciwnym przypadku nie da się skompilować pliku.

---