Rozdział 17.
Wykorzystanie i zabezpieczanie serwisów sieci WWW

W poprzednim rozdziale podane zostały wszystkie informacje konieczne do tworzenia serwisów sieci WWW — czym one są, dlaczego warto ich używać oraz jak należy je tworzyć. Także ten rozdział będzie poświęcony serwisom sieci WWW, lecz skoncentrujemy się w nim na sposobach wykorzystania serwisów za pośrednictwem stron ASP.NET.

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

• W jaki sposób korzystać z procesu odkrywania w celu zdobycia informacji o istniejących serwisach sieci WWW.

• Jak można generować klasy pośredniczące, zapewniające dostęp do serwisów.

• Jak implementować klasy pośredniczące na stronach ASP.NET.

• W jaki sposób można zabezpieczać serwisy przy użyciu nagłówków SOAP.

Wykorzystanie serwisów sieci WWW

W poprzednim rozdziale dowiedziałeś się w jaki sposób można używać serwisów sieci WWW do tworzenia usług, z których można korzystać za pośrednictwem Internetu. Na przykład, witryna może udostępniać pewien zbiór funkcji realizujących obliczenia finansowe. Kiedy taki serwis zostanie opracowany i udostępniony na witrynie, każdy będzie mógł ją odwiedzić i skorzystać z oferowanych możliwości funkcjonalnych.

Nowe określenie

Załóżmy, że twórca internetowej aplikacji bankowej chciałby wykorzystać dostępny serwis obliczeń finansowych, aby wykonać interesujące go kalkulacje dotyczące CD-ROM-ów. A zatem, tworzona przez niego aplikacja bankowa musi wykorzystać (innymi słowy — uzyskać dostęp i użyć) metody tego serwisu. Wykorzystanie serwisu sieci WWW oznacza po prostu użycie udostępnianych przez niego możliwości przez klienta. Użytkownicy witryny bankowej mogą używać funkcji kalkulatora nie wiedząc nawet kto je wykonuje.

Gdy odwiedzasz stację benzynową, jej obsługa świadczy Ci określone usługi. Korzystając z tych usług stajesz się automatycznie ich konsumentem. Możesz wykorzystać wszelkie usługi i zasoby udostępniane przez stację benzynową — dystrybutory paliwa, czas i pracę zatrudnionych na niej osób oraz wszelkie inne dobra, które można na niej kupić. (Oczywiście za usługi te trzeba zapłacić, jednak naszym przypadku nie ma to na razie znaczenia.) Wykorzystanie usług świadczonych przez stację benzynową umożliwia Ci uniknięcie konieczności posiadania własnego dystrybutora paliwa oraz naprawy i konserwacji samochodu.

Klienci korzystający z serwisów sieci WWW robią dokładnie to samo. Odwiedzają serwis i korzystają z zasobów, które udostępnia. Na przykład, Twój komputer mógłby korzystać z serwisu realizującego przetwarzanie tekstów. W takim przypadku, wszystkie jego możliwości funkcjonalne byłyby dla Ciebie dostępne, co oznacza, że nie musiałbyś kupować, ani instalować edytora tekstów.

Klientami używającymi serwisów sieci WWW mogą być niemal wszystkie aplikacje — komputery, strony ASP.NET lub nawet urządzenia przenośne, takie jak telefony komórkowe! W tym rozdziale skoncentrujemy się na zagadnieniach związanych z wykorzystaniem serwisów sieci WWW z poziomu stron ASP.NET.

Proces wykorzystania serwisu sieci WWW składa się z trzech etapów:

1. Zdobycia informacji o serwisie poprzez wykorzystanie mechanizmów odkrywania.

2. Stworzenia klasy pośredniczącej w dostępie do serwisu.

3. Użycia klasy pośredniczącej do wywoływania metod udostępnianych przez serwis.

Ostrzeżenie
Nie należy mylić klienta serwisu sieci WWW z klientem internetowym. Pierwszy z nich to aplikacja lub witryna WWW wykorzystująca usługi udostępniane przez serwis sieci WWW. Klientem internetowym nazywamy natomiast program służący do przeglądania zasobów Internetu — na przykład, przeglądarkę WWW. Klient serwisów sieci WWW korzysta z możliwości udostępnianych przez te serwisy, natomiast klient internetowy — z witryn WWW. Oba te klienty mają ze sobą bardzo niewiele wspólnego i zanim zaczniesz tworzyć klientów serwisów sieci WWW, powinieneś dobrze zrozumieć tę różnicę.

Zapewne przypominasz sobie, że odkrywanie jest procesem umożliwiającym klientom zdobywanie informacji o serwisach sieci WWW. Idąc do nowej restauracji, pierwszą rzeczą jaką robimy, jest przeglądnięcie menu i sprawdzenie jakie potrawy można zamówić. W ten sam sposób postępują programy korzystające z serwisów sieci WWW — zanim będą w stanie wykorzystać możliwości serwisu, muszą je określić.

Informacje te są dostępne jako opis serwisu sieci WWW (więcej na jego temat znajdziesz w poprzednim rozdziale). Przypominasz sobie zapewne, że opis ten jest plikiem XML wygenerowanym przez sam serwis. Klient używa tego pliku do określenia możliwości serwisu; można by rzecz, że analizując go czyta menu udostępnianych możliwości funkcjonalnych. Klient może także stworzyć własną kopię tego „menu”, która może mu się przydać w przyszłości.

Czy przypominasz sobie pliki .disco o których była mowa w poprzednim rozdziale? Są one tworzone wyłącznie po to, aby pomagać klientom serwisów sieci WWW. Pliki te zawierają połączenia z opisami serwisów sieci WWW udostępnianymi na serwerze, które z kolei pozwalają klientom na zdobycie informacji o sposobach wykorzystania serwisów. Warto zauważyć, iż klienty wcale nie muszą korzystać z plików .disco — jeśli znają adres opisu serwisu, mogą odwołać się bezpośrednie do niego.

Ciekawym etapem wykorzystania serwisów sieci WWW jest generacja klasy pośredniczącej. Oto analogia, która przedstawia przeznaczenie takiej klasy. Załóżmy, że chciałbyś pojechać do restauracji, ale nie masz ważnego prawa jazdy. Udaje Ci się jednak przekonać swoją matkę, aby zawiozła Cię do restauracji własnym samochodem. Można powiedzieć, że matka działa na Twoją rzecz, zawożąc Cię tam, gdzie samemu nie byłbyś w stanie się dostać. Innymi słowy, Twoja matka staje się pośrednikiem pomiędzy Tobą a restauracją.

W podobny sposób działają klienty używające serwisów sieci WWW. Wiedzą one, że gdzieś jest dostępny serwis, jednak nie mogą samodzielnie skorzystać z jego możliwości. Takie klienty potrzebują pomocy pośrednika, który będzie w stanie udostępnić im mechanizmy przesyłania danych do i z serwisu sieci WWW.

Wykorzystując serwis sieci WWW z poziomu stron ASP.NET, chcemy aby użycie jego możliwości było możliwie jak najprostsze. Nie chcemy zawracać sobie głowy przesyłaniem komunikatów XML, konwersją wykonywanych poleceń do odpowiedniego formatu ani pobieraniem zwracanych informacji. W optymalnym przypadku chcielibyśmy korzystać z serwisu sieci WWW jak gdyby było on obiektem biznesowym przechowywanym na lokalnym komputerze. A zatem chcielibyśmy, aby wykorzystanie serwisu sprowadziło się do utworzenia obiektu jakiejś klasy i posługiwania się jego metodami.

Właśnie do tego celu służy klasa pośrednicząca. Klasa ta znajduje się na komputerze użytkownika i zawiera wszystkie złożone mechanizmy konieczne do wymiany informacji z serwisem sieci WWW. Dzięki niej interakcja z serwisem może być realizowana w taki sam sposób jak wykorzystanie dowolnego innego obiektu. W rzeczywistości, klasa pośredniczące będzie zawierać metody i właściwości odpowiadające metodom i właściwościom udostępnianym przez serwis sieci WWW; nawet ich nazwy będą identyczne. A zatem, wiedząc jakie metody udostępnia serwis sieci WWW, będzie można wywołać odpowiednie metody klasy pośredniczącej. Proces wykorzystania klasy pośredniczącej został przedstawiony na rysunku 17.1.

Rysunek 17.1. Klasa pośrednicząca działa jako „warstwa pośrednia” pomiędzy klientem a serwisem sieci WWW

Opis rysunku

Client - Klient

ASP.NET page — Strona ASP.NET

Proxy class — Klasa pośrednicząca

Send XML — Wysyła dane XML

Receive data — Odbiera dane

Web Service — Serwis sieci WWW

Klasa pośrednicząca jest generowana na podstawie informacji zawartych w opisie serwisu sieci WWW. Analizując go, klasa jest w stanie zdobyć wszelkie konieczne informacje na temat sposobu przesyłania poleceń oraz zwracanych wyników. Więcej informacji na ten temat znajdziesz w dalszej części rozdziału, pt.: „Wykorzystanie serwisów sieci WWW w stronach ASP.NET”.

Klient korzystający z serwisu sieci WWW może użyć klasy pośredniczącej także do wywoływania metod serwisu. Czynności te niczym się nie różnią od sposobów wywoływania metod dowolnych obiektów. Cały ten proces jest całkowicie niewidoczny dla użytkownika, a jego implementacja nie powinna przysporzyć programistom żadnych trudności. Czynności związane z wykorzystaniem serwisu sieci WWW zostały przedstawione na rysunku 17.2.

Rysunek 17.2. Wykorzystania serwisu sieci WWW jest procesem składającym się z trzech etapów

Opis rysunku

Client — Klient

Web Service — Serwis sieci WWW

1. … — 1. Analiza opisu serwisu

2. … — 2. Generacja klasy pośredniczącej

3. … — 3. Wykorzystanie metod serwisu za pośrednictwem klasy pośredniczącej

Proxy — Klasa pośrednicząca

Notatka
Serwisy sieci WWW są najczęściej używane przez strony WWW oraz inne serwisy sieci WWW. Wykorzystywanie serwisów sieci WWW przez zwyczajne aplikacje także nie należy do rzadkości.

Wykorzystanie serwisów sieci WWW w stronach ASP.NET

Już raz byliśmy użytkownikami serwisu sieci WWW. Oglądając opis serwisu oraz stronę opisu (patrz poprzedni rozdział) wykonaliśmy te same czynności, które wykonuje klient serwisu. Jedyna różnica polega na tym, iż my wywoływaliśmy je bezpośrednio, a nie przy użyciu klasy pośredniczącej.

W kolejnych trzech podrozdziałach zostaną opisane sposoby realizacji trzech etapów wykorzystania serwisu sieci WWW (odkrycia, generacji klasy pośredniczącej oraz implementacji) na stronach ASP.NET; przy czym do komunikacji z serwisem użyty zostanie protokół SOAP. Realizacja pierwszych dwóch etapów, wymaga wykorzystania narzędzi uruchamianych z poziomu wiersza poleceń systemu. Natomiast dzięki użyciu klasy pośredniczącej, trzeci etap wykorzystania serwisu — implementacja — niczym się nie różni od korzystania z obiektów biznesowych.

Proces odkrywania serwisu

Proces odkrywania serwisów dostępnych na wskazanej witrynie WWW można wykonać przy użyciu programu disco.exe. Program ten przeszukuje witryny WWW i zwraca kopie plików .disco dostępnych na danym serwerze. Te lokalne kopie plików .disco można następnie wykorzystać przy generacji klasy pośredniczącej.

Zobaczmy jak to wygląda w praktyce. Otwórz okno wiersza poleceń i przejdź do folderu c:\inetpub\wwwroot\aspnetdlakazdego\rozdzial17. Zakładam, że zgodnie z informacjami podanymi w poprzednim rozdziale stworzyłeś plik Calculator.disco i umieściłeś go w głównym folderze aplikacji aspnetdlakazdego. Jeśli tak, to w oknie wiersza poleceń wpisz następujące polecenie:

disco http://localhost/aspnetdlakazdego/rozdzial16/Calculator.disco

(Sposób użycia tego programu zostanie bardziej szczegółowo opisany w dalszej części tego rozdziału.) Program disco.exe wyświetla adresy URL plików .disco dostępnych na wskazanym serwerze (patrz rysunek 17.3).

Rysunek 17.3. Wyniki wykonania programu disco.exe

Domyślnie program ten generuje także dwa pliki o nazwach results.discomap oraz services.disco. Pierwszy z nich — results.discomap — zawiera informacje o wynikach wykonania programu. Można w nim znaleźć dane o plikach .disco odnalezionych na serwerze, oraz o położeniu ich lokalnych kopii. Drugi plik — services.disco — zawiera te same informacje co odnaleziony plik .disco. Oba te pliki są zapisane w języku XML, dzięki czemu łatwo można je odczytać i przeanalizować. Typowa zawartość pliku services.disco została przedstawiona na rysunku 17.4.

Rysunek 17.4. Plik XML services.disco wyświetlony w przeglądarce

Listing 17.1 przedstawia zawartość pliku results.discomap, w którym zostały zapisane szczegółowe informacje o wynikach realizacji procesu odkrywania.

Listing 17.1. Zawartość pliku results.discomap

• <?xml version="1.0" encoding="utf-8"?>

• <DiscoveryClientResultsFile

• xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

• xmlns:xsd="http://www.w3.org/2001/XMLSchema">

• <Results>

• <DiscoveryClientResult referenceType="System.Web.

• Services.Discovery.DiscoveryDocumentReference"

• url="http://localhost/aspnetdlakazdego/rozdzial16/

• Calculator.disco" filename="Calculator.disco" />

• </Results>

• </DiscoveryClientResultsFile>

Analiza

Powyższy plik zawiera wyniki wykonania procesu odkrywania przeprowadzonego na podanym serwerze. Interesujący nas fragment tego pliku został zapisany wewnątrz znaczników Results. Użyty w wierszu 4. atrybut referenceType określa typ analizowanego pliku. W naszym przypadku jest to dokument procesu odkrywania. Atrybut url określa natomiast adres odnalezionego pliku .disco. Kolejny atrybut — filename — podaje nazwę lokalnej kopii pliku .disco. Plik ten może zostać wykorzystany później, podczas generacji klasy pośredniczącej.

W wywołaniu programu disco.exe można użyć 6 parametrów; zostały one opisane w tabeli 17.1.

Tabela 17.1. Parametry wywołania programu disco.exe.

Parametr	Opis
/nologo	Zapobiega wyświetlaniu informacji o firmie Microsoft, generowanych przez ten program.
/nosave	Informuje, że wyniki wykonania procesu odkrywania nie powinny być zapisywane w pliku.
/out	Określa folder, w jakim mają zostać zapisane wyniki wykonania programu. Wartością domyślną tego parametru jest bieżący folder.
/username	Określa nazwę użytkownika jaką należy podać aby uzyskać dostęp do serwera.
/password	Określa hasło które zapewnia dostęp do serwera.
/domain	Określa nazwę domeny jakiej należy użyć by uzyskać dostęp do serwera.

Przedstawione poniżej przykładowe polecenie zapobiega wyświetlaniu informacji o firmie Microsoft i określa, że wyniki mają być zapisane w folderze c:\temp\disco:

disco /nologo /out:c:\temp\disco http://localhost/aspnetdlakazdego/Services.disco

Tworzenie klasy pośredniczącej

Zgodnie z tym co podałem wcześniej, klasa pośrednicząca pełni funkcję warstwy pośredniej pomiędzy serwisem sieci WWW a klientem który z tego serwisu chce skorzystać. Klasa ta zawiera wszelki możliwości funkcjonalne konieczne do przesyłania danych przez Internet, dzięki czemu programiści nie muszą implementować ich we własnym zakresie. Za chwilę przekonasz się, że klasa ta wygląda bardzo podobnie do pliku .asmx przechowywanego na serwerze, na którym działa serwis sieci WWW, różni się jednak od niego wywołaniami kilku metod.

Klasa pośrednicząca generowana jest przy użyciu kolejnego programu — wsdl.exe. Program ten analizuje plik .discomap lub XML-owy opis serwisu dostępny bezpośrednio na serwerze i na ich podstawie tworzy klasę której metody idealnie odpowiadają metodom udostępnianym przez serwis sieci WWW. To podobieństwo metod serwisu i klasy pośredniczącej ma sprawić, że użycie tej klasy będzie możliwie niewidoczne. Strona ASP.NET korzystająca z serwisu może zostać stworzona w taki sposób, jak gdyby komunikowała się z nim bezpośrednio. Co więcej, program wsdl.exe generuje metody i używa atrybutów dzięki którym klasa pośrednicząca będzie w stanie przesyłać dane przez Internet.

Oczywiście klasę pośredniczącą można także stworzyć ręcznie, ale dlaczego mielibyśmy utrudniać sobie życie, skoro program wsdl.exe może ją wygenerować za nas? (Jeśli jednak jesteś zdecydowany by własnoręcznie napisać klasę pośredniczącą, to w dalszej części rozdziału znajdziesz informacje o wszelkich wymaganiach jakie musi ona spełniać.)

Notatka
Zwróć uwagę, że program wsdl.exe może bezpośrednio przeanalizować opis serwisu sieci WWW. Oznacza to, że jeśli znany jest adres URL tego opisu, to nie trzeba wcześniej korzystać z programu disco.exe.

Sprawdźmy jak to wygląda w praktyce. W oknie wiersza poleceń wpisz i wykonaj następujące polecenie:

wsdl /language:VB http://localhost/aspnetdlakazdego/rozdzial16/Calculator.asmx?WSDL

Postać wywołania tego programu zostanie opisana w dalszej części tego rozdziału. Jak na razie wystarczy abyś wiedział, że pierwszy parametr — /language — określa język w jakim ma zostać wygenerowana klasa pośrednicząca (w tym przypadku jest to język VB.NET). Drugi parametr wywołania programu określa adres URL opisu serwisu. (Adres ten poznaliśmy w poprzednim rozdziale, pt.: „Tworzenie serwisów sieci WWW”.)

Po wykonaniu programu w sposób przedstawiony na powyższym przykładzie, na ekranie pojawią się komunikaty o następującej postaci:

wsdl /language:VB http://localhost/aspnetdlakazdego/rozdzial16/ Calculator.asmx?WSDL

Microsoft (R) Web Services Description Language Utility

[Microsoft (R) .NET Framework, Version 1.0.2914.16]

Copyright (C) Microsoft Corp. 1998-2001. All rights reserved.

Writing file 'C:\Inetpub\wwwroot\aspnetdlakazdego\rozdzial17\Calculator.vb'.

Zwróć uwagę, że program wygenerował klasę języka VB.NET i zapisał ją w pliku Calculator.vb. Jest to nasza klasa pośrednicząca. Warto poświecić nieco czasu na przeanalizowanie utworzonego pliku. (Można go będzie znaleźć w tym samym folderze w którym został wykonany program wsdl.exe.) Kod naszej przykładowej klasy pośredniczącej został przedstawiony na listingu 17.2.

Listing 17.2. Wygenerowany plik Calculatro.vb.

• '-----------------------------------------------------------------------

• ' <autogenerated>

• ' This code was generated by a tool.

• ' Runtime Version: 1.0.2914.16

• '

• ' Changes to this file may cause incorrect behavior and will be lost if

• ' the code is regenerated.

• ' </autogenerated>

• '-----------------------------------------------------------------------

• Option Strict Off

• Option Explicit On

• Imports System

• Imports System.Diagnostics

• Imports System.Web.Services

• Imports System.Web.Services.Protocols

• Imports System.Xml.Serialization

• '

• 'This source code was auto-generated by wsdl, Version=1.0.2914.16.

• '

• <System.Web.Services.WebServiceBindingAttribute(Name:="CalculatorSoap", [Namespace]:="http://tempuri.org/")> _

• Public Class Calculator

• Inherits System.Web.Services.Protocols.SoapHttpClientProtocol

• <System.Diagnostics.DebuggerStepThroughAttribute()> _

• Public Sub New()

• MyBase.New

• Me.Url = "http://localhost/aspnetdlakazdego/rozdzial16/Calculator.asmx"

• End Sub

• <System.Diagnostics.DebuggerStepThroughAttribute(), _

• System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Add", Use:=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)> _

• Public Function Add(ByVal intA As Integer, ByVal intB As Integer) As Integer

• Dim results() As Object = Me.Invoke("Add", New Object() {intA, intB})

• Return CType(results(0),Integer)

• End Function

• <System.Diagnostics.DebuggerStepThroughAttribute()> _

• Public Function BeginAdd(ByVal intA As Integer, ByVal intB As Integer, ByVal callback As System.AsyncCallback, ByVal asyncState As Object) As System.IAsyncResult

• Return Me.BeginInvoke("Add", New Object() {intA, intB}, callback, asyncState)

• End Function

• <System.Diagnostics.DebuggerStepThroughAttribute()> _

• Public Function EndAdd(ByVal asyncResult As System.IAsyncResult) As Integer

• Dim results() As Object = Me.EndInvoke(asyncResult)

• Return CType(results(0),Integer)

• End Function

• End Class

Analiza

Powyższa klasa została automatycznie wygenerowana przez program wsdl.exe w celu ułatwienia czynności jakie należy wykonać aby skorzystać z serwisu sieci WWW. Należy zauważyć, iż w porównaniu z serwisem, klasa ta zawiera dwie dodatkowe metody oraz przeróżne atrybuty i właściwości. Wszystko to sprawia, iż jej kod jest stosunkowo trudny do przeanalizowania. Jednak nie przejmuj się, gdybyś nie był w stanie całkowicie go zrozumieć. Nie trzeba znać wszystkich jego tajników.

W wierszu 25. deklarowana jest klasa Calculator. Jak widać w jej deklaracji wykorzystany został atrybut WebServiceBindingAttribute dostępny w przestrzeni nazw System.Web.Services. Atrybut ten definiuje interfejs (czyli zbiór metod i właściwości), którego klasa musi używać. W rzeczywistości o atrybucie tym nie trzeba wiedzieć niczego więcej. (Jeśli jednak chciałbyś się czegoś o nim dowiedzieć, to zajrzyj do dokumentacji środowisk .NET.) Warto wiedzieć, że atrybut ten nie jest niezbędnie konieczny do poprawnego działania klas pośredniczących, niemniej jednak i tak jest on generowany automatycznie.

Klasa pośrednicząca dziedziczy po klasie SoapHttpClientProtocol (patrz wiersz 26.), która dostarcza metod pozwalających na wymianę informacji z serwisem Calculator przy wykorzystaniu protokołu SOAP.

W wierszu 29. zapisany został konstruktor klasy pośredniczącej. Konstruktor jest specjalną metodą używaną do inicjalizacji obiektów --> danej klasy[Author:p8R] . Konstruktor ten określa adres URL serwisu sieci WWW.

W wierszu 34. rozpoczyna się metoda, która nieco przypomina metodę Add serwisu sieci WWW stworzonego w poprzednim rozdziale. W definicji tej metody wykorzystywany jest atrybut SoapMethodAttribute, który dostarcza parametrów wykorzystywanych podczas wymiany danych pomiędzy klasą pośredniczącą a serwisem za pośrednictwem protokołu SOAP. W wierszu 37. metoda ta wywołuje metodę Invoke, która wywołuje odpowiednią metodę serwisu. Metoda ta wymaga podania dwóch argumentów. Pierwszym z nich jest nazwa wywoływanej metody serwisu a drugim — parametry jakie należy do niej przekazać. Wyniki wykonania tej metody są zapisywane w tablicy o nazwie results i zwracane (w wierszu 49.).

Kolejne dwie metody definiują asynchroniczny sposób komunikacji z serwisem sieci WWW. Więcej informacji na temat wykorzystania asynchronicznych metod znajdziesz w rozdziale 13., pt.: „Odczytywanie i zapisywanie plików na serwerze WWW”. Ogólnie rzecz, w przypadku wykorzystania metod asynchronicznych można jednocześnie wywołać metodę i wykonywać inny fragment kodu. Standardowe metody — nazywane także metodami synchronicznymi — nie pozwalają na równoczesne wykonywanie żadnych innych czynności — dalszy kod programu może być wykonywany dopiero po zakończeniu realizacji metody.

Klasa pośrednicząca przedstawiona na powyższym przykładzie, zawiera wszelkie możliwości funkcjonalne konieczne do przesłania przez Internet żądania wykonania określonej metody serwisu, i to przy użyciu różnych protokołów (takich jak SOAP lub Http-Get). Dzięki niej, interakcja z serwisem sieci WWW może do złudzenia przypominać wykorzystania zwyczajnego obiektu biznesowego. Na szczęście klasy tej nie trzeba tworzyć ręcznie.

Program wsdl.exe ma kilka parametrów, dzięki którym można generować różnego rodzaju klasy pośredniczące. Oprócz parametrów podanych w tabeli 17.2, program ten akceptuje wszystkie parametry z tabeli 17.1 za wyjątkiem /nosave.

Tabela 17.2. Parametry programu wsdl.exe.

Parametr	Opis
/langauage	Język w jakim ma być wygenerowana klasa pośrednicząca. Językiem domyślnym jest C#.
/namespace	Przestrzeń nazw do której ma należeć generowana klasa pośrednicząca. Domyślnie jest stosowana globalna przestrzeń nazw.
/protocol	Protokół jaki ma być użyty do komunikacji z serwisem sieci WWW. Może to być SOAP, Http-Get oraz Http-Post; domyślnie stosowany jest protokół SOAP.

Podpowiedź
Wiele parametrów wywołania programów wsdl.exe oraz disco.exe ma skrócone formy zapisu. Na przykład, parametr /language można także zapisać jako /l. Więcej informacji na temat sposobu wykorzystania tych programów można uzyskać wydając polecenia wsdl.exe /? oraz disco.exe /?.

Poniższe polecenie tworzy klasę pośredniczącą zapisaną w języku VB.NET, należącą do podanej przestrzeni nazw i wykorzystującą protokół SOAP:

wsdl /l:VB /namespace:MyWebServiceConsumer /protocol:SOAP http://localhost/aspnetdlakazdego/rozdzial16/Calculator.asmx?WSDL

Implementacja klasy pośredniczącej

Już niemal jesteśmy gotowi do wykorzystania serwisu sieci WWW na stronie ASP.NET. Dysponujemy już klasą pośredniczącą, która będzie prowadzić wymianę danych z serwisem, jednak jeszcze nie możemy jej użyć. Przede wszystkim, należy tę klasę skompilować do postaci komponentu (biblioteki DLL), podobnie jak robiliśmy to w przypadku obiektów biznesowych. Oczywiście do kompilacji klasy wykorzystamy kompilator języka VB.NET (którym już powinieneś umieć się posługiwać). W wierszu poleceń wpisz następujące polecenie:

vbc /t:library /out:..\bin\CalculatorServiceClient.dll /r:System.dll /r:System.Xml.dll /r:System.Web.Services.dll Calculator.vb

Podpowiedź
Jeśli wydawane polecenie jest długie, skomplikowane i składa się z wielu elementów (tak jak w przypadku trzech ostatnich poleceń wykorzystujących programy disco.exe, wsdl.exe oraz vbc.exe) to czasami warto zapisać je w pliku wsadowym (.bat). Dzięki temu można uniknąć konieczności ciągłego wpisywania tego samego polecenia (lub poleceń).

Aby utworzyć plik wsadowy, stwórz zwyczajny plik tekstowy i nadaj mu rozszerzenie .bat, a następnie skopiuj do niego polecenia które chcesz wykonać, umieszczając każde z nich w osobnym wierszu. Dzięki temu, gdy uruchomisz ten plik, wszystkie zapisane w nim polecenia zostaną automatycznie wykonane.

Ostrzeżenie
Zauważ, iż podczas kompilacji klasy pośredniczącej może się pojawić kilka błędów związanych ze sposobem zapisu atrybutów metod. W takim przypadku przenieś te atrybuty i umieść je na samym początku definicji metody (przed słowem kluczowym Public oraz jej nazwą). Może się zdarzyć, iż dodatkowo będziesz musiał usunąć z definicji metody Add następujące właściwości: Use:=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.
Wrapped

Powyższe polecenie spowoduje skompilowanie klasy pośredniczącej i zapisanie jej w pliku DLL, który zostanie umieszczony w folderze \bin, czyli pamięci podręcznej komponentów .NET. Teraz będzie już można użyć tego komponentu na stronie ASP.NET, aby za jego pośrednictwem korzystać z serwisu sieci WWW. Przykład prostej strony ASP.NET korzystającej z serwisu sieci WWW został przedstawiony na listingu 17.3.

Listing 17.3. Użycie serwisu sieci WWW na stronie ASP.NET.

• <%@ Page Language="VB" %>

• <script runat="server">

• sub Page_Load(obj as object, e as eventargs)

• dim objCalc as new Calculator

• lblMessage.Text = objCalc.Add(1,5)

• end sub

• </script>

• <html><body>

• Wynikiem dodawania 1 + 5 jest liczba:

• <asp:Label id="lblMessage" runat="server"/>

• </body></html>

Analiza

Strona ASP.NET przedstawiona na listingu 17.3 jest bardzo prosta. W procedurze Page_Load rozpoczynającej się w wierszu 4. tworzony jest obiekt klasy Calculator (stworzonej przed chwilą klasy pośredniczącej). Obiekt ten reprezentuje nasz przykładowy serwis sieci WWW stworzony w poprzednim rozdziale. Sposób wykorzystania tego obiektu niczym się nie różni od sposobu bezpośredniego wykorzystania serwisu sieci WWW. Innymi słowy, gdyby udostępnić skompilowaną klasę pośredniczącą innemu programiście, to korzystając z tej klasy nie miałaby on pojęcia o tym, iż w rzeczywistości używa serwisu sieci WWW. Klasa ta jest bowiem używana w taki sposób, jak gdyby sama udostępniała metody serwisu.

W wierszu 7. wywoływana jest metoda Add, a w wierszu 13. wyniki jej wykonania zostają wyświetlone na stronie przy użyciu elementu sterującego Label. Tak naprawdę, w wierszu 7. wywoływana jest metoda Add klasy pośredniczącej; metoda ta pobiera dwie liczby całkowite i przesyła je przez Internet do metody Add serwisu sieci WWW. Dopiero ta metoda Add wykonuje faktyczne obliczenia. Następnie uzyskane wyniki są odbierane przez klasę pośredniczącą jako dane XML, konwertowane do odpowiedniego typu danych (w tym przypadku do liczby całkowitej) i zwracane. Z punktu widzenia programisty, klasa pośrednicząca pobiera argumenty, wykonuje obliczenia i zwraca wyniki.

Na rysunku 17.5 przedstawione zostały wyniki wykonania strony z listingu 17.3, wyświetlone w przeglądarce.

Rysunek 17.5. Wyniki wywołania metody serwisu sieci WWW

Powyższy przykład doskonale prezentuje piękno i elegancję wykorzystania klas pośredniczących. Dzięki użyciu takiej klasy nie musieliśmy wykonywać żadnych szczególnych czynności, aby skorzystać z metod serwisu sieci WWW. Konieczne czynności sprowadziły się do wywołania metody serwisu udostępniającej możliwości funkcjonalne z których chcieliśmy skorzystać. Możesz sądzić, że to dużo pracy jak na tak prostą stronę ASP.NET, lecz w rzeczywistości wszystko sprowadza się do wykonania trzech czynności — wykonania programu wsdl.exe w celu wygenerowania kodu klasy pośredniczącej, skompilowania go i umieszczenia w pamięci podręcznej komponentów .NET oraz stworzenia właściwej strony ASP.NET która wykorzysta możliwości funkcjonalne udostępniane przez serwis. (A jeśli ktoś wykona za nas pierwsze dwie czynności, to nasza rola sprowadzi się jedynie do stworzenia implementacji.) Jak widać znajomość i zrozumienie wyników procesu odkrywania oraz kodu klasy pośredniczącej nie ma większego znaczenia (no chyba, że chcesz samemu stworzyć tę klasę). A zatem, klasa pośrednicząca ukrywa wszystkie złożone możliwości funkcjonalne, dzięki niej, wystarczy kilka prostych wierszy kodu strony ASP.NET, aby wykonać bardzo złożone zadanie.

Notatka
Zauważ, iż wykorzystanie klasy pośredniczącej nie wymaga importowania jakichkolwiek przestrzeni nazw. Być może przypominasz sobie, że ASP.NET automatycznie ładuje obiekty umieszczone w pamięci podręcznej komponentów .NET (czyli w folderze \bin; była o tym mowa w rozdziale 15., pt.: „Zastosowanie obiektów biznesowych”). A zatem, z klasy pośredniczącej można korzystać tak, jak gdyby stanowiła ona integralną część Twojej strony ASP.NET.

Inny przykład wykorzystania serwisu sieci WWW

Jak dotąd osiągnęliśmy już całkiem sporo. Wywoływanie metod obiektu przez Internet to nie byle co. Serwisy sieci WWW stwarzają wiele możliwości związanych z przetwarzaniem rozproszonym. Jednak przykład przedstawiony w poprzedniej części rozdziału był bardzo prosty. Obliczenia realizowane przez nasz przykładowy serwis sieci WWW równie dobrze mogły być wykonywane bezpośrednio przez stronę ASP.NET i nie wymagały wykorzystania żadnych złożonych typów danych.

A zatem przeanalizujmy inny przykład. Zapewne pamiętasz, że dzięki wykorzystaniu XML-a, serwisy sieci WWW mogą także zwracać informacje pobierane z baz danych. W poprzednim rozdziale stworzyliśmy serwis, który na podstawie przekazanego polecenia SQL może pobrać odpowiednie informacje z bazy danych. Spróbujmy użyć tego serwisu na stronie ASP.NET.

Tym razem pominiemy proces odkrywania serwisu i przejdziemy bezpośrednio do generacji klasy pośredniczącej. W oknie wiersza poleceń wykonaj następujące polecenie:

wsdl /language:VB /namespace:ASPNETDK http://localhost/aspnetdlakazdego/rozdzial16/Database.asmx?WSDL

Programu wsdl.exe używaliśmy już wcześniej, a zatem powyższe polecenie powinno wyglądać znajomo. Jego wykonanie spowoduje wygenerowanie kodu klasy pośredniczącej dla naszego serwisu i zapisanie go w bieżącym folderze. Ze względu na duże możliwości funkcjonalne tego serwisu, wygenerowana dla niego klasa pośrednicząca jest duża i złożona. Na szczęście w ogóle nie musimy się tym przejmować. Wystarczy że ją skompilujemy i wykorzystamy na stronie ASP.NET. Warto zwrócić uwagę, iż wygenerowana klasa pośrednicząca została umieszczona w przestrzeni nazw ASPNETDK. To sensowny i logiczny sposób grupowania własnych obiektów. Wygenerowany kod klasy pośredniczącej powinien wyglądać podobnie do przykładu przedstawionego na rysunku 17.6.

Rysunek 17.6. Wygenerowany kod źródłowy klasy pośredniczącej

Kolejnym krokiem będzie skompilowanie tej klasy na komputerze, na którym będzie wykonywana strona ASP.NET korzystająca z usług naszego serwisu. W tym celu należy posłużyć się następującym poleceniem:

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

Nie można zapomnieć o odwołaniu się do przestrzeni nazw System.Data! Klasa pośrednicząca korzysta bowiem z klas zdefiniowanych w tej przestrzeni nazw do wykonania konwersji zwróconych przez serwis danych XML do postaci obiektu DataSet, który będzie można wykorzystać na stronie ASP.NET. Ostatnią czynnością będzie stworzenie strony ASP.NET, która wykorzysta możliwości funkcjonalne udostępniane przez serwis sieci WWW. Jej kod przedstawiony został na listingu 17.4.

Listing 17.4. Wykorzystanie serwisu obsługującego bazę danych.

• <%@ Page Language="VB" %>

• <%@ Import Namespace="System.Data" %>

• <script runat="server">

• sub Submit(obj as object, e as eventargs)

• dim objService as new ASPNETDK.DatabaseService

• dim objDS as new DataSet

• objDS = objService.SelectSQL(tbQuery.Text)

• DataGrid1.DataSource = objDS

• DataGrid1.DataMember = "tblUsers"

• DataGrid1.Databind()

• end sub

• </script>

• <html><body>

• <form runat="server">

• Podaj zapytanie SQL:

• <asp:Textbox id="tbQuery" runat="server"/>

• <asp:Button id="btSubmit" runat="server"

• text="Wykonaj zapytanie"

• OnClick="Submit" />

• <p>

• <asp:DataGrid id="DataGrid1"

• runat="server" BorderColor="black"

• GridLines="Vertical" cellpadding="4"

• cellspacing="0" width="100%"

• Font-Name="Arial" Font-Size="8pt"

• HeaderStyle-BackColor="#cccc99"

• ItemStyle-BackColor="#ffffff"

• AlternatingItemStyle-Backcolor="#cccccc" />

• </form>

• </body></html>

Analiza

Powyższa strona ASP.NET jest niezwykle prosta. Jedyna, zdefiniowana na niej procedura nosi nazwę Submit. Gdy użytkownik poda w polu tekstowym zapytanie SQL i kliknie przycisk Wykonaj zapytanie, procedura ta tworzy nowy obiekt klasy pośredniczącej (patrz wiersz 6.). Pamiętasz zapewne, że klasa pośrednicząca została umieszczona w przestrzeni nazw ASPNETDK. To właśnie z tego powodu w definicji zmiennej objService została użyta pełna nazwa klasy. (W poprzednim przykładzie korzystającym z serwisu Calculator, klasa pośrednicząca nie została umieszczona w żadnej przestrzeni nazw, a zatem nie musieliśmy używać jej nazwy.)

W wierszu 9. wywoływana jest metoda SelectSQL. Powinna ona zwrócić wyniki w formie obiektu DataSet. Uzyskane informacje są następnie wiązane z elementem sterującym DataGrid (kod definiujący ten element rozpoczyna się w wierszu 25.). Wygląd strony po zadaniu pytania i wyświetleniu wyników został przedstawiony na rysunku 17.7.

Rysunek 17.7. Dane zwrócone przez serwis sieci WWW

Strona ASP.NET z listingu 17.4 może być położona na serwerze znajdującym w dowolnym miejscu kuli ziemskiej; jej położenie względem serwisu sieci WWW nie ma najmniejszego znaczenia — uzyskiwane wyniki zawsze będą takie same. Innymi słowy, strona ta może się znajdować na serwerze w Nowym Jorku, a serwis — na serwerze w Katowicach!

Nasz serwis sieci WWW może odbierać polecenia przesyłane z każdego miejsca Sieci, gdyż są one zapisywane w XML-u. XML to język tekstowy, a wszelkie mechanizmy zabezpieczające stosowane na Internecie zazwyczaj pozwalają na przesyłanie tekstu.

Dzięki serwisom sieci WWW programiści mogą wykorzystywać udostępnione im możliwości funkcjonalne w całkowicie dowolny sposób. (Ten czynnik odróżnia serwisy od stron ASP.NET, gdyż w przypadku wykorzystania stron, to ich autor określa dostępny interfejs użytkownika.) Posługując się naszym przykładowym serwisem sieci WWW, jeden programista może stworzyć internetową książkę adresową, a inny może użyć zwracanych informacji do przeprowadzenia badań demograficznych. Nasz serwis ogranicza się do zwracania danych, sposób ich użycia bądź prezentacji nie ma dla niego najmniejszego znaczenia.

Notatka
Przykłady przedstawione w tym rozdziale uwidaczniają wszelkie podobieństwa występujące pomiędzy serwisami sieci WWW i obiektami biznesowymi. Oba te narzędzia są wykorzystywane jako skompilowane obiekty, którymi następnie posługują się strony ASP.NET. Jedyna różnica pomiędzy nimi polega na tym, iż w przypadku zastosowania serwisów sieci WWW skompilowany obiekt może się znajdować na dowolnym komputerze podłączonym do Internetu. Za połączenie serwisu z aplikacją która korzysta z jego możliwości, odpowiada klasa pośrednicząca.

Zalecenia dotyczące wykorzystania serwisów sieci WWW

Sposób wykorzystania serwisu sieci WWW zależy od konkretnej sytuacji. Pamiętasz zapewne, że z serwisami można się komunikować przy użyciu trzech różnych protokołów —Http-Get, Http-Post oraz SOAP.

Najłatwiejsze w użyciu są pierwsze dwa protokoły, gdyż wymagają one podania jedynie adresu URL serwisu. W obu przykładach podanych w tym rozdziale użyty został protokół SOAP, który udostępnia znacznie bogatsze możliwości wykorzystywania serwisów.

Zastosowanie protokołu SOAP ma jednak jedną wadę. Być może zauważyłeś, że zapisywanie poleceń i danych w komunikatach protokołu SOAP jest raczej złożonym zadaniem (choć tworzenie klas pośredniczących, które udostępniają metody odpowiedzialne za komunikację z serwisami, jest na szczęście bardzo proste). Komunikaty przekazywane pomiędzy serwisami i ich klientami są dosyć duże, gdyż muszą one zawierać informacje dotyczące używanych schematów XML. W zależności od szybkości połączenia z Internetem jakim dysponuje klient, wielkość tych komunikatów może mieć wpływ na ogólną efektywność działania serwisu.

Innym sposobem wykorzystania serwisów sieci WWW jest zastosowanie protokołu Http-Get. Jeśli tylko znasz adres URL serwisu, nazwy jego metod oraz parametry ich wywołania, to bez problemu będziesz mógł bezpośrednio wywoływać udostępniane przez niego metody. Na przykład, poniższy adres URL umożliwia wykorzystanie metody Add serwisu Calculator:

http://localhost/aspnetdlakazdego/rozdzial16/Calculator.asmx/Add?intA=3&intB=5

Po adresie URL serwisu należy zapisać ukośnik oraz nazwę wywoływanej metody, a dalej — łańcuch zapytania zawierający przekazywane argumenty. W powyższym przykładzie, adres URL serwisu to:

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

Po nim, zostaje podana końcówka zawierająca nazwę metody oraz przekazywane do nie argumenty:

/Add?intA=3&intB=5

W momencie przesłania żądania skierowanego do zasobu o powyższym adresie, zostaną zwrócone informacje XML zawierające wyniki wykonania metody. W naszym przypadku wyniki będą miały postać:

<?xml version="1.0" encoding="utf-8" ?>

<int xmln="http://temuri.org/">8<int>

Z serwisów można także korzystać przy użyciu protokołu Http-Post. W tym przypadku, w atrybucie ACTION znacznika FORM należy podać adres URL serwisu oraz nazwę wywoływanej metody. Na przykład:

http://localhost/aspnetdlakazdego/rozdzial16/Calculator.asmx/Add

Jak widać, jest to adres URL serwisu z dopisanym znakiem ukośnika oraz nazwą metody. W momencie przesłania formularza, wartości jego pól zostaną wysłane do serwisu, który w odpowiedzi wygeneruje odpowiednie dane XML. Trzeba jednak pamiętać, aby nazwy pól formularza odpowiadały nazwom argumentów wywoływanej metody serwisu sieci WWW.

A zatem, której z powyższych metod należy użyć? Okazuje się, że wybór jest bardzo prosty. Jeśli serwis musi zwracać skomplikowane typy danych, na przykład obiekty DataSet, należy wykorzystać protokół SOAP. Informacji tego typu nie można bowiem przesyłać przy użyciu pozostałych dwóch protokołów.

Jeśli serwis nie musi zwracać skomplikowanych typów danych lub jeśli obciążenie łącza ma duże znaczenie dla klienta, to należy wykorzystać protokoły Http-Get lub Http-Post. Komunikują się one z serwisem przy wykorzystaniu mniejszej ilości danych, zapewniając tym samym lepszą efektywność działania.

Tak	Nie
Używaj protokołu SOAP jeśli przewidujesz, że będziesz potrzebować złożonych typów danych lub bogatych możliwości programistycznego dostępu do serwisu.	Nie używaj protokołu SOAP gdy czynnikiem o pierwszorzędnym znaczeniu jest obciążenie połączenia z Internetem. W takich sytuacjach należy skorzystać z protokołów Http-Get oraz Http-Post.

Zabezpieczanie serwisów sieci WWW

Często będziemy chcieli zabezpieczyć nasze serwisy sieci WWW. W końcu, nawet w dobie Internetu, gdy wszystko jest wspólne, są rzeczy które trzeba chronić. Załóżmy, że stworzyliśmy witrynę, której użytkownicy podają symbole interesujących ich akcji i mają dostęp do ich bieżącego kursu. Zazwyczaj bezpłatne witryny internetowe prezentują notowania opóźnione co najmniej o 15 minut, a zatem na pewno znalazłyby się osoby, które zgodziłyby się zapłacić za korzystanie z naszego serwisu. W takim przypadku wszelkie nieupoważnione wykorzystanie serwisu byłby ze wszech miar niewskazane.

Jak na razie przedstawiliśmy sposoby tworzenia ogólnie dostępnych serwisów sieci WWW. Każdy kto zna adres takiego serwisu może z niego skorzystać (bądź to za pośrednictwem pliku .disco, bądź też adresu URL). Na szczęście istnieją sposoby zabezpieczenie serwisu, tak aby dostęp do niego miały jedynie upoważnione osoby.

Czynności zabezpieczające serwisy polegają na wykorzystaniu protokołu SOAP (w zatem także języka XML) w celu przesyłania do serwisu stosownych poleceń, zawierających informacje konieczne do uwierzytelnienia klientów. Ponieważ informacje są przesyłane bezpośrednio do serwisu, może on zaimplementować mechanizmy uwierzytelniania w całkowicie dowolny sposób. Na przykład, weryfikacja danych użytkownika może być realizowana w oparciu o bazy danych.

Zanim zajmiemy się technicznymi szczegółami implementacji kontroli dostępu do naszego serwisu, chciałby przedstawić pewną analogię. Wyobraź sobie, że chciałbyś pójść do bardzo ekskluzywnej restauracji. Jej obsługa sprawdza tożsamość klientów zanim zostaną wpuszczenie do środka. Aby wejść do restauracji i skorzystać ze świadczonych w niej usług, trzeba wziąć ze sobą jakiś dokument, choćby prawo jazdy.

W celu przekazania informacji koniecznych do uwierzytelnienia klienta próbującego uzyskać dostęp do serwisu sieci WWW, zostaną wykorzystane nagłówki SOAP. Są to dodatkowe komunikaty XML zawierające dowolne informacje i dołączane do standardowych komunikatów przesyłanych podczas wymiany danych pomiędzy serwisem i klientem. Mechanizm ten może nieco przypominać posługiwanie się prawem jazdy. Choć dane są przesyłane protokołem SOAP, to stanowią całkowicie niezależne elementy. Nagłówki ten zostaną użyte do przekazania nazwy użytkownika oraz hasła dostępu, dzięki którym będziemy mogli określić który z klientów ma prawo dostępu do serwisu.

Aby przesłać nagłówek SOAP wystarczy stworzyć klasę potomną klasy System.Web.Services.Protocols.SoapHeader. Serwis sieci WWW może następnie wykorzystać tę klasę, aby zdobyć informacje konieczne do uwierzytelnienia klienta. Klasa nagłówka SOAP umożliwiająca przesłanie nazwy użytkownika i hasła została przedstawiona na listingu 17.5.

Listing 17.5. Prosta klasa nagłówka SOAP.

• Imports System.Web.Services

• Imports System.Web.Services.Protocols

• Namespace ASPNETDK

• Public Class Authenticator : Inherits SoapHeader

• Public Username As string

• Public Password As string

• End Class

• End Namespace

Analiza

Klasa Authentication przedstawiona na listingu 17.5 może zostać umieszczona w tym samym pliku, w którym znajduje się klasa serwisu sieci WWW. Zawiera ona jedynie dwie publiczne właściwości — Username oraz Password; zostaną one wykorzystane od przekazania informacji uwierzytelniających.

Każda klasa, którą chcemy zabezpieczyć powinna definiować obiekt klasy Authenticator. Będzie on używany do ograniczania dostępu do metod serwisu sieci WWW. Definicja każdej udostępnianej metody tego serwisu, oprócz atrybutu <WebMethod>, musi także zawierać atrybut <SoapHeader>:

Public Class DataBaseService

dim sHeader as Authenticator

...

--> <WebMethod(), SoapHeader("sHeader")> [Author:p8R] Public Function MojaMetoda()

as String

...

End Function

End Class

W drugim wierszy powyższego fragmentu kodu tworzony jest obiekt klasy Authenticator, który zostaje zapisany w zmiennej sHeader. Następnie, w definicji metody, został dodany atrybut SoapHeader zawierający nazwę obiektu klasy Authenticator. W ten sposób poinformowaliśmy ASP.NET, że metoda ta oprócz standardowej wymiany informacji powinna także oczekiwać przekazania nagłówka SOAP zawierającego informacje uwierzytelniające. Jeśli nagłówek ten nie zostanie otrzymany, to wszelkie komunikaty nadsyłane przez klienta zostaną odrzucone.

Stwórzmy praktyczny przykład wykorzystujący serwis obsługi bazy danych zaimplementowany w poprzednim rozdziale. W pierwszej kolejności zmodyfikujemy klasę serwisu sieci WWW, tak aby wykorzystywała nasz nagłówek SOAP. Zmodyfikowany kod klasy został przedstawiony na listingu 17.6.

Listing 17.6. Zabezpieczony serwis obsługi bazy danych (Database.vb).

• Imports System

• Imports System.Data

• Imports System.Data.OleDb

• Imports System.Web.Services

• Imports System.Web.Services.Protocols

• Namespace ASPNETDK

• Public Class Authenticator : Inherits SoapHeader

• Public Username as string

• Public Password as string

• End Class

• Public Class SecureDatabaseService : Inherits WebService

• private objConn as OleDbConnection

• private objCmd as OleDbCommand

• public sHeader as Authenticator

• <WebMethod(), SoapHeader("sHeader")> Public Function _

• SelectSQL(strSelect as string) as DataSet

• if sHeader is Nothing then

• throw new Exception("Blad: Niepoprawne logowanie!")

• end if

• if Authenticate(sHeader.UserName, sHeader.Password) _

• then

• 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 if

• end function

• private function Authenticate(strUser as string, _

• strPass as string) as boolean

• try

• dim intID as integer = 0

• objConn = new OleDbConnection("Provider=" & _

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

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

• --> dim strSelect as string = "SELECT UserID FROM " & _

• "tblUsers WHERE Firstname = '" & strUser & _

• "' AND Lastname = '" & strPass & "'"[Author:p8R]

• objCmd = new OleDbCommand(strSelect, objConn)

• objCmd.Connection.Open()

• Dim objReader as OleDbDataReader

• objReader = objCmd.ExecuteReader

• do while objReader.Read

• intID = objReader.GetInt32(0)

• loop

• objReader.Close

• if intID <> 0 then

• return true

• else

• return false

• end if

• catch ex as OleDbException

• return false

• end try

• end function

• End Class

• End Namespace

Analiza

W wierszu 9. powyższego listingu rozpoczyna się deklaracja klasy nagłówka SOAP, który będzie wykorzystywany przy uwierzytelnianiu klientów. Jak widać klasa Authenticator dziedziczy po klasie SoapHeader. Obiekt tej klasy będzie przesyłany wraz ze wszystkimi informacjami wymienianymi pomiędzy klientem i serwisem sieci WWW. Klasa ta definiuje jedynie dwie, publiczne właściwości — Username oraz Password.

W wierszu 17. tworzony jest nowy obiekt klasy Authenticator reprezentujący nagłówek SOAP. Obiekt ten zostaje zapisany we właściwości sHeader. Będzie on zawierał informacje uwierzytelniające przekazane z klienta, na podstawie których określimy, czy dany klient może skorzystać z metod udostępnianych przez serwis sieci WWW.

Nowa wersja klasy serwisu nosi nazwę SecureDatabaseService; jej nazwa została zmieniona tylko po to, abyś łatwiej mógł rozróżnić obie wersje serwisu. W wierszu 19. rozpoczyna się kod metody SelectSQL; jak widać, znacznie się on różni od pierwotnej wersji tej metody znanej z poprzedniego rozdziału. Przede wszystkim, w deklaracji metody został umieszczony atrybut SoapHeader, któremu przypisywany jest obiekt nagłówka SOAP przechowywany we właściwości sHeader. Pozostała część deklaracji metody nie została zmieniona.

Pierwszą czynnością wykonywaną wewnątrz metody jest określenie czy w wywołaniu przesłanym przez klienta zostały podane informacje uwierzytelniające — nazwa użytkownika oraz hasło. Jeśli klient ich nie podał to właściwość sHeader będzie miała wartość nothing, co z kolei spowoduje zakończenie wykonywania metody. W takim przypadku, w wierszu 23., zgłaszany jest wyjątek (Exception) informujący klienta o pominięciu koniecznych informacji.

Notatka
Zgłaszanie wyjątku nie jest konieczne, gdyż nawet bez niego ASP.NET wygeneruje stosowny komunikat jeśli jakiś nagłówek nie zostanie przekazany. Komunikat generowany w takiej sytuacji został przedstawiony na rysunku 17.8.

Rysunek 17.8. W przypadku pominięcie nagłówka SOAP zostanie zgłoszony błąd.

Następnie, w wierszu 26., wywoływana jest metoda Authenticate. Przegląda ona bazę danych i sprawdza czy podany użytkownik ma prawo dostępu do metody. W przypadku poprawnego zweryfikowania danych użytkownika, metoda Authenticate zwróci wartość true, dzięki czemu będzie można wykonać główną część metody SelectSQL rozpoczynającą się w wierszu 28. Ten fragment kodu powinien wyglądać znajomo, gdyż nie zmienił się w porównaniu z poprzednią wersją serwisu. Wykonuje on podane polecenie SQL i zwraca obiekt DataSet.

Metoda Authenticate, której kod rozpoczyna się w wierszu 44., służy do uwierzytelniania użytkowników. Przegląda ona bazę danych sprawdzając czy nazwa użytkownika raz hasło podane w nagłówku SOAP opisują istniejącego użytkownika. --> W naszym przypadku nazwą użytkownika będzie jego imię, a hasłem — nazwisko.[Author:p8R] Jeśli użytkownik zostanie odnaleziony metoda zwraca wartość true, w przeciwnym przypadku, zwracana jest wartość false.

Teraz należy skompilować nową wersję serwisu przy użyciu następującego polecenia:

vbc /t:library /out:..\bin\ASPNETDK.dll /r:System.dll /r:System.Data.dll /r:System.Xml.dll /r:System.Web.dll /r:System.Web.Services.dll --> Database.vb[Author:p8R]

Kolejnym krokiem będzie stworzenie na serwerze pliku .asmx zawierającego wyłącznie dyrektywę WebService określającą nazwę klasy naszego nowego serwisu:

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

Zapisz ten plik pod nazwą SecureDatabaseSerivce.asmx. Kolejną czynnością jaką należy wykonać, jest stworzenie klasy pośredniczącej na komputerze klienta (w naszym przypadku zarówno klient jak i serwer będzie działać na tym samym komputerze). Klasę pośredniczącą można wygenerować przy użyciu następującego polecenia:

wsdl /language:VB /namespace:ASPNETDK.Clients http://localhost/aspnetdlakazdego/rozdzial17/SecureDatabaseService.asmx?WSDL

Zwróć uwagę, iż klasa pośrednicząca została umieszczona w nowej przestrzeni nazw — ASPNETDK.Clients. Cała nasza praca jest wykonywana na tym samym komputerze, a zatem użycie nowej przestrzeni nazw jest konieczne, aby uniknąć konfliktu nazw.

Analiza wygenerowanego kodu ujawni, że klasa pośrednicząca pobrała z serwisu dwie klasy — Authenticator oraz właściwą klasę serwisu. Aby uzyskać możliwość dostępu i wykorzystania metod serwisu, konieczne będzie użycie obu tych klas.

Ostatnią czynnością jaką należy wykonać jest kompilacja klasy pośredniczącej. W tym celu można się posłużyć poniższym poleceniem:

vbc /t:library /out:..\bin\ASPNETDK.Clients.dll /r:System.dll /r:System.Data.dll /r:System.Xml.dll /r:System.Web.dll /r:System.Web.Services.dll SecureDatabaseService.vb

Teraz pozostaje nam już tylko napisanie strony ASP.NET, która będzie korzystać z nowej wersji serwisu. Strona ta powinna pozwalać użytkownikom na podanie nazwy oraz hasła, jak również zapytania SQL, które ma zostać wykonane. Kod tej strony został przedstawiony na listingu 17.7.

Listing 17.7. Strona ASP.NET korzystająca z „bezpiecznej” wersji serwisu (SecureDatabaseService.aspx).

• <%@ Page Language="VB" %>

• <%@ Import Namespace="System.Data" %>

• <script runat="server">

• sub Submit(obj as object, e as eventargs)

• dim objService as new ASPNETDK.Clients.SecureDatabaseService

• dim sHeader as new ASPNETDK.Clients.Authenticator

• dim objDS as new DataSet

• sHeader.Username = tbUser.Text

• sHeader.Password = tbPass.Text

• objService.AuthenticatorValue = sHeader

• try

• objDS = objService.SelectSQL(tbQuery.Text)

• DataGrid1.DataSource = objDS

• DataGrid1.DataMember = "tblUsers"

• DataGrid1.Databind()

• catch ex as exception

• Response.Write("Nieprawidłowa nazwa użytkownika lub hasło")

• end try

• end sub

• </script>

• <html><body>

• <form runat="server">

• Nazwa użytkownika:

• <asp:Textbox id="tbUser" runat="server"/><br>

• Hasło:

• <asp:Textbox id="tbPass" runat="server"

• TextMode="password" /><p>

• Zapytanie SQL:

• <asp:Textbox id="tbQuery" runat="server"/>

• <asp:Button id="btSubmit" runat="server"

• text="Wykonaj"

• OnClick="Submit" />

• <p>

• <asp:DataGrid id="DataGrid1"

• runat="server" BorderColor="black"

• GridLines="Vertical" cellpadding="4"

• cellspacing="0" width="100%"

• Font-Name="Arial" Font-Size="8pt"

• HeaderStyle-BackColor="#cccc99"

• ItemStyle-BackColor="#ffffff"

• AlternatingItemStyle-Backcolor="#cccccc" />

• </form>

• </body></html>

Analiza

Jedyną metodą używaną w powyższej stronie ASP.NET jest metoda Submit, obsługująca kliknięcie przycisku Wykonaj. Tworzy ona dwa nowe obiekty — obiekt klasy pośredniczącej naszego serwisu oraz obiekt klasy Authenticator. Właściwościom tego drugiego obiektu przypisywana jest nazwa użytkownika oraz hasło podane w dwóch pierwszych polach tekstowych (patrz wiersze 11. i 12.). Następnie, obiekt ten przypisywany jest właściwości AuthenticatorValue obiektu klasy pośredniczącej. Dzięki temu, klasa ta wie już jakie informacje należy przesyłać do serwisu wraz z poleceniami.

W końcu, w bloku try wywoływana jest metoda serwisu, a zwrócone przez nią wyniki zostają związane z elementem sterującym DataGrid. Teraz wyświetl tę stronę w przeglądarce i w polach tekstowych podaj nazwę użytkownika, hasło oraz zapytanie SQL. (Pamiętaj, że w naszym przypadku nazwą użytkownika będzie jego imię, a hasłem — nazwisko.) Jeśli podane informacje będą poprawne (czyli jeśli będą reprezentowały użytkownika zapisanego w tabeli tblUsers), to na stronie wynikowe zostaną wyświetlone informacje pobrane z bazy danych (patrz rysunek 17.9).

Rysunek 17.9. Wyniki udanego wykonania metody nowej wersji serwisu

Jeśli jednak podane informacje o użytkowniku nie będą poprawne, to na samej górze strony zostanie wyświetlony stosowny komunikat — „Nieprawidłowa nazwa użytkownika lub hasło”. To właśnie z tego powodu użyliśmy bloku try — gdyby go nie było, to wywołanie metody zwróciłoby pusty obiekt DataSet. Próba związania go elementem sterującym DataGrid spowodowałaby zgłoszenie błędu. Wyniki nieudanej próby wykorzystania nowej wersji naszego przykładowego serwisu sieci WWW zostały przedstawione na rysunku 17.10.

Rysunek 17.10. Wyniki nieudanego wykonania metody nowej wersji serwisu

Nagłówki SOAP efektywnym i często stosowanym sposobem zabezpieczania dostępu do serwisów sieci WWW. W naszym przykładzie, informacje wykorzystywane przy uwierzytelnianiu żądań były pobierane z baz danych, w rzeczywistości proces uwierzytelniania może być realizowany w całkowicie dowolny sposób.

Wykorzystania nagłówków SOAP ma jednak pewną wadę. Otóż w przypadku wykorzystania nagłówków SOAP do przesyłania informacji o użytkowniku, będą one przekazywane przez Internet w postaci zwyczajnego tekstu zapisanego w formacie XML. Oznacza to, że łatwo można je przechwycić i odczytać. Jednym ze sposobów rozwiązania tego problemu jest zaszyfrowanie podanych przez użytkownika informacji, zanim zostaną przesłane oraz odpowiednie odszyfrowanie ich w serwisie sieci WWW. Omówienie zagadnień związanych z szyfrowaniem wykracza jednak poza ramy tematyczne niniejszej książki. Inne sposoby zabezpieczania aplikacji ASP.NET zostały opisane w rozdziale 21., pt.: „Zabezpieczanie aplikacji ASP.NET”.

To nie jest ASP!

Umożliwianie klientom dostępu do aplikacji internetowych nie jest nowością dla programistów ASP. Także we wcześniejszych wersjach tej technologii z chwilą uruchomienia aplikacji na serwerze, stawała się ona dostępna dla klientów. Jednak całkowicie nowym zagadnieniem jest wykorzystanie komponentów aplikacji przez Internet umożliwienie odwoływania się do nich przez inne aplikacje.

Nowością jest także możliwość zdalnego komunikowania się ze sobą różnych elementów tej samej aplikacji. Wcześniej obiekty biznesowe oraz strony ASP musiały się znajdować na tym samym komputerze (a przynajmniej na tej samej sieci). Technologia ASP.NET umożliwia, aby elementy te znajdowały się na dowolnych komputerach podłączonych do Internetu. W ten sposób ASP.NET pozwala na tworzenie prawdziwych, rozproszonych aplikacji.

Głównym czynnikiem, który przyczynił się ogromnego sukcesu serwisów sieci WWW było wykorzystanie protokołu SOAP do przesyłania poleceń i danych, zapisanych przy użyciu standardowego języka (takiego jak XML). Polecenia SOAP są w całości zapisywane w postaci tekstowej i dlatego mogą być przesyłane gdziekolwiek i to nawet przez zapory ogniowe.

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

2 Dokument2

Pomijam informacje podane w nawiasie, gdyż odwołują się one do Pytań i Odpowiedzi z poprzedniego rozdziału, które nie są tłumaczone (zresztą jak wszystkie działy Pytania i Odpowiedzi, patrz strategia książki).

Musi być zapisane w takiej kolejności inaczej przykład się nie skompiluje

Uwaga!! zmieniłem gdyż przy sprawdzaniu użytkowników wykorzystywane były oryginalnie dwie kolumny (username i password), które zostały stworzone w rozdziale dodatkowym, który nie był tłumaczony. Żeby wszystko było ok., trzeba by kazać czytelnikom zrobić te kolumny w bazie. Doszedłem do wniosku, że lepiej będzie nieco zmodyfikować kod przykładu, tak, żeby nie trzeba było korzystać z tych kolumn.

Uwaga!! dodałem gdyż przy sprawdzaniu użytkowników wykorzystywane były oryginalnie dwie kolumny (user i password), które zostały stworzone w rozdziale dodatkowym, który nie był tłumaczony. Żeby wszystko było ok., trzeba by kazać czytelnikom zrobić te kolumny w bazie. Doszedłem do wniosku, że lepiej będzie nieco zmodyfikować kod przykładu, tak, żeby nie trzeba było korzystać z tych kolumn.

Kompilacja pliku User2.vb pominięta celowo - nie ma go w tym folderze.

---