Aplikacje WWW. Cel zajęć. Celem zajęć jest zapoznanie się z technologią usług sieciowych w aplikacjach WWW.

Transkrypt

1 Laboratorium z przedmiotu Aplikacje WWW - zestaw 08 Cel zajęć. Celem zajęć jest zapoznanie się z technologią usług sieciowych w aplikacjach WWW. Wprowadzenie teoretyczne. Rozważana w ramach niniejszych zajęć tematyka stanowi wprowadzenie do tworzenia stron opartych o usługi sieciowe WebService. Aby ze zrozumieniem zrealizować zadania, przewidziane do wykonania w ramach zajęć laboratoryjnych, należy zapoznać się z następującymi zagadnieniami: dyrektywa WebService, atrybuty WebServiceBinding, WebMethod, WebService w ASP.Net. 1. Dyrektywa WebService W plikach.aspx występowała w pierwszym wierszu dyrektywa Page. Usługa sieciowa posiada dyrektywę WebService: <%@WebService Language= C# CodeBehind=... Co to takiego? Kilka firm wspólnie podjęło decyzję o stworzeniu specyfikacji niezależnej od platformy, mającą na celu zwiększenie elastyczności, wymienialności i bezpieczeństwa infrastruktury sieciowej, ogólnie określane jako WS-*(np. WS-I Web Service Interperability Organization), pełna lista platform obejmuje: WS-Policy, WS-ReliableMessaging, WS-Addresing, WS-Security. Czym się to charakteryzuje? Nie posiada interfejsu użytkownika oraz widzalnych komponentów, ale wszelka struktura plikowa i architektura jest identyczna jak podczas tworzenia zwykłej strony internetowej. Podobieństwa do zwykłego pliku.aspx obejmują takie rzeczy jak: Pełną implementację platformy.net oraz CLT z architekturą obiektową i wszystkimi podstawowymi bibliotekami klas i dostępu do danych. Prawie identyczne struktury plików i kodu. Wszystkie pliki kodu źródłowego zapisane są w postaci zwykłego tekstu. Duże możliwości konfiguracyjne, globalne lub w zakresie aplikacji. Dyrektywa WebService jest wymagana przy tworzeniu dowolnej usługi sieciowej, jej składani składa się z: Language określa jezyk programowania wykorzystany w usłudze sieciowej(c#, VB, JS), jest on wymagany(gdy nie zostanie on podany, kompilator zadecyduje o typie języka na podstawie rozszerzenia pliku). Class określa nazwę klasy implementującą usługę sieciową. Jest on wymagany. Wskazana klasa może być umieszczona zarówno w oddzielnym pliku ukrytego kodu jak również wewnątrz bloku skryptu w pliku.asmx. CodeBehind określa nazwę pliku kodu źródłowego, który implementuje klasę WebService, jeśli ta klasa nie zostanie umieszczona wewnątrz pliku usługi sieciowej(.asmx) lub zostanie ręcznie skompilowana i umieszczona w podkatalogu bin katalogu głównego aplikacji. Debug dla wartości true usługa sieciowa zostanie skompilowana z włączonym trybem debugowania, domyślnie jest ustawiona wartość false. 2. Atrybut WebServiceBinding Jest to wiązanie, jakie zostało zdefiniowane przez Web Services Description Language(WSDL) i pełni rolę interfejsu dla usługi sieciowej definiuje określony zbiór operacji. Sama klasa WebService posiada już wiązania domyślne, a atrybut WebServiceBinding umożliwia podłączenie pod projekt innych napisanych, stworzonych na potrzeby projektu. Atrybut ten wywodzi się z klasy WebServiceAttribute. Tak jak to było wcześniej wspomniane klasa WebService posiadać może wiele wiązań, czyli atrybutów WebServiceBinding określających wiązania. Każdy z nich może posiadać atrybut Name, jeżeli nie to atrybut będzie zastosowany względem wiązania domyślnego. Właściwości atrybutu WebServiceBinding ConformsTo Specyfikacja WS-I, względem której wiązanie deklaruje zgodność(1.0, 2.0, 3.0 ). 1

2 EmitConformanceClaims Location Name Namespace Dla wartości true, wiązanie będzie wysyłało żądanie zgodności, gdy będzie opublikowany opis WSDL. Położenie, w którym zdefiniowano wiązanie. Domyślnie jest to adres URL do bieżącej usługi sieciowej. Nazwa wiązania. Przestrzeń nazw powiązana z wiązaniem. Ważnymi elementami z punktu widzenia debugowania jakie posiada ta kontrolka to metody AllowCustomErrorsRedirect, która mówi co zrobić z błędem który się pojawi; Metoda AssyncPostBackErrorMessage przesyła ustalona wcześniej treść błędu do przeglądarki, na wypadek jakiś problemów w trakcie pracy. 3. Atrybut WebMethod Jeżeli chcemy udostępnić usłudze sieciowej pewną funkcjonalność w postaci metod, których jednocześnie nie ma domyślnie stworzonej w usłudze sieciowej WebMethod, skorzystamy z WebMethod. Metoda taka/funkcja powinna spełniać jednak pewne warunki: powinna być publiczna oraz powinna posiadać atrybut WebMethod umieszczony przed deklaracją metody np. [WebMethod] public bool getczyjestpelny(uint wartoscparametru) Atrybut ten posiada właściwości, które są używane w celu konfiguracji zachowania określonej metody sieciowej o składni: [WebMethod(NazwaWlasciwosci=wartosci)] Oczywiście NazwaWartosci musi być prawidłową nazwą wartości, wymienioną w tabeli poniżej. Własności atrybutu WebMethod BufferResponse CacheDuration Description EnableSession Domyślnie ASP.Net buforuje całą odpowiedź na żądanie, jednak czasem to nie jest optymalne dla większych pakietów danych. Wtedy ustawiając wartość własności na false spowoduje wysyłanie danych w postaci pakietów po 16KB. Usługi sieciowe, tak jak zwykłe strony WWW, buforować mogą zwracane klientowi wyniki. Własność ta określa, w ciągu ilu sekund po początkowym żądaniu będzie wysłana buforowana strona w odpowiedzi na kolejne żądanie. Do metody można dołączyć opisujący ją ciąg znaków, opis ten będzie pojawiał się na stronie pomocy usługi sieciowej, kiedy testowana będzie ta usługa. Dla wartości true powoduje włączenie stanu sesji dla danej metody sieciowej domyślnie false. MessageName Rozwiązuje problem przeciążania metod w usługach sieciowych nie można tego robić. 2

3 Własność ta eliminuje dwuznaczności przy wywoływaniu metody, lub metod o takich samych nazwach. Własność ta pozwala na przypisanie każdej metodzie unikalnego aliasu i kiedy zostanie wywołana przeciążona metoda, wówczas zostanie użyta właściwość MessageName, a nie nazwa metody. TransationOption Metody sieciowe mogą korzystać z transakcji gdy zostały one zapoczątkowane wcześniej nie może być tzw. obiektem głównym. Własność ta określa, czy metoda powinna, czy nie rozpocząć transakcję. Rozpoczęcie to wartości: Requied i RequiresNew. 4. Atrybut WebService Pozwala na dołączenie do usługi sieciowej dodatkowych informacji jest to atrybut opcjonalny. Jego składnia to: [WebService(NazwaWlasciwosci=wartosci)] Przy czym NazwaWlasnosci musi być poprawną nazwą jedne z wymienionych niżej własności: Description Name Namespace Pozwala na dołączenie opisu do usługi sieciowej, będzie się on pojawiał na stronie pomocy sieciowej t trakcie testowania usługi sieciowej. Domyślnie, jest to nazwa klasy implementującej usługę sieciową. Atrybut ten pozwala na zmianę tej nazwy. Każda usługa sieciowa posiada powiązana ze sobą przestrzeń nazw XML. Usługa sieciowa jest opisana za pomocą dokumentu WSDL, który jest zdefiniowany w XML u. Zadanie 1. Proszę zrealizować aplikację WWW, która powinna odznaczać się następującymi cechami: Aplikacja ma zawierać usługę WWW, umożliwiającą przeliczanie wartości temperatury w skali Celsjusza na skalą Fahrenheita (i odwrotnie). Następnie należy zaimplementować aplikację WWW, która będzie służyła do przeliczania wartości temperatur pomiędzy podanymi skalami. Aplikacja ta ma wykorzystywać metody umieszczone w utworzonej wcześniej usłudze WWW. Aby zrealizować zadanie należy wykonać następujące kroki: Proszę w swoim katalogu utworzyć projekt strony WWW. Następnie w oknie Solution Explorer proszę o kliknięcie prawym przyciskiem myszy na nazwę utworzonego projektu i o wybranie opcji Add New Item -> Web Service. Następnie proszę o kliknięcie prawym przyciskiem myszy na utworzony plik WebService.asmx, wybranie opcji Set As Start Page i uruchomienie utworzonego projektu. W celu zapoznania się z zasadami działania przykładowej usługi WWW proszę kliknąć link Hello World, a następnie przycisk wywołujący metodę. Po wykonaniu powyższego podpunktu proszę o implementację własnych usług WWW, umożliwiających przeliczanie temperatury. 3

4 Podpowiedź: Przykładowe metody: Po implementacji metod, proszę o uruchomienie projektu i ich przetestowanie. Następnie proszę o otworzenie nowej instancji środowiska Visual Studio (UWAGA, nie zamykamy poprzedniej instancji!) i o utworzenie w nim nowego projektu strony WWW Po wykonaniu tej operacji, proszę o kliknięcie prawym przyciskiem myszy nazwy nowego projektu w oknie Solution Explorer i wybranie opcji Add Service Reference. W nowo otwartym oknie proszę o wpisanie adresu usługi: [nazwa_pliku_usługi].asmx, następnie wybranie usługi przeliczającej temperaturę i zmianę nazwy przestrzeni nazw zgodnie z poniższym rysunkiem: 4

5 Po wykonaniu powyższej czynności w oknie Solution Explorer pojawi się dodana usługa: Aby móc korzystać z dostępnych metod usługi, w pliku Default.aspx.cs należy zdefiniować następujący obiekt: Przykładowe wywołanie metody usługi WWW: Następnie proszę o stworzenie aplikacji, wykorzystującej stworzoną usługę. Przykładowy wygląd aplikacji: 5

6 Przy ocenie zadania główny nacisk będzie kładziony na: Wykonanie wszystkich założeń ujętych w treści zadania. Wygląd aplikacji (wykorzystanie CSS). Prawidłowe działanie aplikacji. Sposób implementacji. Zadanie 2. Proszę zrealizować aplikację WWW, która powinna odznaczać się następującymi cechami: Aplikacja ma stanowić usługę WWW, umożliwiającą odczytanie na podstawie podanej daty kto w danym dniu obchodzi imieniny (i odwrotnie). Na lokalnym serwerze ma zostać umieszczona baza danych zawierająca daty imienin. Usługa WWW ma wykorzystywać tę bazę jako źródło informacji. Następnie należy zaimplementować aplikację WWW, która będzie wykorzystywała stworzoną usługę (wyświetlając kto obchodzi imieniny w podanym dniu, jak również wyświetlając w jakich dniach imieniny obchodzi osoba o podanym imieniu) Aplikacja powinna także umożliwiać dodanie nowych imion wraz z datami do bazy. Aby zrealizować zadanie należy wykonać następujące kroki: Proszę o utworzenie tabeli Imieniny o podanej strukturze: Następnie proszę o wypełnienie tabeli przykładowymi danymi według formatu: Po wykonaniu tej czynności proszę o utworzenie usługi WWW zgodnej z założeniami zadania. 6

7 Przykładowe metody usługi: Następnie proszę o uruchomienie i przetestowanie usługi. Następnie proszę o implementację aplikacji WWW wykorzystującej zaimplementowaną usługę. Aplikacja powinna także umożliwiać dodanie nowych imion do bazy. Przy ocenie zadania główny nacisk będzie kładziony na: Wykonanie wszystkich założeń ujętych w treści zadania. Wygląd aplikacji (wykorzystanie CSS). Prawidłowe działanie aplikacji. Sposób implementacji. Zadanie do domu. Proszę zrealizować aplikację WWW, która powinna odznaczać się następującymi cechami: Aplikacja ma stanowić rozszerzenie zadania pierwszego. Do istniejących metod usługi WWW należy dodać metody umożliwiające przeliczanie temperatur w skali Kelvina na skalę Celsjusza i Fahrenheita (i odwrotnie). Należy zmodyfikować aplikację WWW, w celu umożliwienia użytkownikowi określenia w jakiej skali jest podana temperatura (Celsjusza, Fahrenheita czy Kelvina), a na jaką skalę ma zostać ona przeliczona. Aplikacja WWW przy przeliczaniu wartości temperatur ma wykorzystywać metody usługi WWW. Zagadnienia, które należy uznać za przyswojone w trakcie zajęć. Po zajęciach będzie obowiązywać praktyczna znajomość: Implementacja usług WWW. Wykorzystanie istniejących usług WWW w aplikacjach internetowych. Publikacja usług WWW. Tworzenie wirtualnego katalogu na serwerze IIS. 7

8 Zagadnienia do samodzielnego zgłębienia dla dociekliwych. Osoby zainteresowane mogą dodatkowo zapoznać się z następującymi tematami: Ręczne tworzenie klienta. Zagadnienia do powtórzenia na następne zajęcia. Przed kolejnymi zajęciami należy powtórzyć następujące zagadnienia: Tworzenie kont użytkownika za pomocą ASP.NET. Dodawanie ról do kont. Uwierzytelnianie na bazie formularzy. Narzędzie Web Administrator Tool. Wybrane aspekty dotyczące implementacji z wykorzystaniem języka PHP. Omawiany język skryptowy nie jest tak dobrze rozwinięty jak ASP.NET. Nie posiada on niestety takich samych możliwości. Nie mniej jednak istnieją środowiska i firmy które na własną rękę stworzyły taki system. Cechą wspólną z ASP jest przetwarzanie plików XML owych. Powodem, dla których powstało Web Serices było stworzenie sposobu na komunikacje aplikacji między sobą, niezależnie od rodzaju platformy, na której pracują, oraz języka użytego w tworzeniu ich. Istnieją co prawda podobne systemy takie jak CORBA (Common Object Request Broker Architecture) czy DCOM (Distributed Component Object Model) jednak oferują one inny sposób komunikacji i wymiany danych. Nie "przechodzą" przez firewall'e bez uprzedniego ich skonfigurowania oraz nie oferują takiej elastyczności jak Web Services. Jednak tam gdzie liczy się wydajność są lepsze. Web Services to interfejs oferujący innym (klientom) uruchamianie dostępnych metod i zwracanie z powrotem wyników działania przez serwer WS (w dalszej części będę używał tego skrótu w odniesieniu do Web Services).?ądania są, w postaci specjalnie sformatowanego XMLa, wysyłane przez POST protokołem HTTP, a następnie wynik działania zwracany jest do użytkownika, także w postaci XMLa. WS dzielimy na trzy warstwy: Packaging Description Discovery Pierwszą omówioną warstwą jest Packaging. Jest to warstwa wymiany danych, która odbywa się poprzez TCP/IP na porcie 80 wykorzystując jak wyżej zostało wspomniane: protokół HTTP i XML jako źródło danych. Takie rozwiązanie ma tą zaletę, że przepuszcza je firewall bez potrzeby dodatkowej konfiguracji. Warstwa packaging pozwala na wymianę danych. Jednak, aby obie strony mogły zrozumieć je, muszą korzystać z ustalonych standardów. Istnieje kilka standardów tworzenia - pakowania - danych XMLowych. Najpopularniejszymi standardami są SOAP (Simple Object Access Protocol) oraz XML-RPC (XML-Remote Procedure Call). Jest jeszcze kilka innych standardów min. OPML (Outline Processor Markup Language), które jednak nie cieszą się taką popularnością jak dwa pierwsze. 8

9 Oprócz SOAP często spotykanego w zastosowaniu z JavaSctipt em i ASP o czym mowa wyżej, XML-RPC został zaprojektowany jako łatwy w implementacji i bardzo prosty system pakowania danych dla zdalnych procedur. Struktura XMLa jest na tyle prosta, że z łatwością można zorientować się w jej "przeznaczeniu". Jednak mimo swej prostoty oferuje kompleksowe wsparcie dla przekazywania złożonych struktur danych. Ciekawostką może być fakt, że dokumentacja zajmuje tylko siedem stron w porównaniu z dokumentacją SOAPa zajmującą czterdzieści. Typy danych jakimi dysponuje XML-RPC to: 32-bitowy integer - znaczniki: <i4> lub <int> Boolean - znacznik: <boolean> Znaki z tablicy ASCII - znacznik: <string> "Podwójnie precyzyjne" liczby zmienno-przecinkowe - znacznik: <double> Data i czas w formacie ISO 8601 (przykład: T14:08:55) - znacznik: <datetime.iso8601> Base64-encoded binary - znacznik: <base64> Struktury danych - znacznik: <struct> Tablice - znacznik: <array> Poniżej jest przykładowe zapytanie, jakie wysyłane jest do serwera WS w "czystej" postaci. Z tego przykładu można odczytać, że chcemy wywołać metodę getstatename obiektu examples z parametrem typu integer o wartości 41. 9

10 Jak widać odpowiedź jest podobna do żądania. Prostota XML-RPC jest jej główną zaletą, dlatego właśnie jest to dobre rozwiązanie w budowaniu pierwszych prostych WS-ów. Implementacje XML-RPC w PHP. IXR jest to bardzo ułatwiająca prace implementacja. Została tak zaprojektowana, aby osoby znające powierzchownie WS mogły bez problemu poradzić sobie z napisaniem serwera jak i klienta WS. Posiada udogodnienia takie jak łatwa konwersja typów PHP do postaci XML-RPC czy też możliwość tworzenia własnych rozszerzeń. IXR w pełni obsługuje XML-RPC. Wspiera także wielokrotne wywołania system.multicall oraz inne rozszerzenia. phpxmlrpc zostało napisane przez samych twórców XML-RPC - Useful Inc. - co od razu sugeruje pełne wsparcie standardu. Zaletami implementacji są jej duże możliwości. Dostarcza wiele elementów niezbędnych w tworzeniu WS jednak dla mniej wtajemniczonych użytkowników może nastręczać problemów na przykład w podawaniu typów zmiennych czy korzystania z dostępnych obiektów. phprpc - dysponująca możliwościami wykraczającymi poza zwykłe wysyłanie i odbieranie rządań i odpowiedzi. XML-RPC Client/Server (K. Devense) - zestaw funkcji umożliwiające w łatwy sposób stworzenie klienta i serwera XML-RPC. ez xmlrpc - klasa do obsługi XML-RPC dostępna w ez Publish. SOAP jest to jak piszą twórcy: " lekki protokół, do łatwej wymiany dowolnego typu danych w zdecentralizowanym systemie. Oparty jest on o XMLa i składa się z trzech elementów: opakowania definiującego framework, opisującego wiadomość ( oraz to jak ją przetwarzać ), zestawu zasad kodowania opisujących instancje zdefiniowanych w aplikacji typów danych oraz konwencji dla prezentacji zdalnych wywołań procedur i odpowiedzi" Co do jego "małych rozmiarów" można dyskutować jednak jest to na pewno bogaty protokół dysponujący szeregiem pomocnych elementów niestety kosztem tego co w XML-RPC jest zaletą - przejrzystości i łatwości implementacji. Implementacje w PHP PHP-SOAP to rozwijająca się implementacja posiadająca jednak już sporo możliwości i łatwe API. Dokumentacja pozostawia wiele do życzenia, ale przykłady zastosowania tej implementacji pozwalają łatwo zrozumieć sposób budowania Web Services w oparciu o tą implementacje. 10

11 nusoap jest to dobrze udokumentowana implementacja, która cały czas się rozwija co dobrze wróży jej na przyszłość. Istnieje także lista mailowa, na której można zadawać pytania dotyczące nusoapa. Który protokół wybrać? Na to pytanie nie można odpowiedzieć jednoznacznie. Wszystko zależy od tego czym dysponujemy i do jakich celów chcemy użyć Web Services. XML-RPC to bardzo "łatwy protokół", który można szybko wdrożyć. Jest na tyle prosty, że czytając XMLa można z łatwością zrozumieć, jakie komunikaty wychodzą i wchodzą do/od serwera - przez co można łatwo debugować taki Web Service. Protokół jak wcześniej wspomniałem jest prosty, a więc i nie trzeba skomplikowanych algorytmów (skryptów) do jego obsługi. Mimo, że XML-RPC dysponuje dużymi możliwościami SOAP jest znacznie bardziej rozbudowany i pozwala na jeszcze więcej. Możemy min. tworzyć własne struktury danych. Zaletą jest też to, że w rozwój SOAPa zaangażował się Microsoft co na pewno przyczyni się do rozpropagowania tego protokołu. Web Services w PHP ogranicza się do pobrania odpowiedniego zestawu bibliotek przedstawionych powyżej zapoznania się z ich wymaganiami i standardami czyli podstawową obsługą i w końcu użycie dostarczonych funkcji i metod. Każdy framework PHP dla każdego standardu czy to XML-RPC czy SOAP posiada zaimplementowane praktycznie całą funkcjonalność. Przykładem może być PHP-SOAP przedstawiony poniżej: Pierwsza funkcja zawarta na tym listingu odpowiada za połączenie z bazą danych oraz wydobycie interesujących danych ceny. Cały problem zawarty jest później. Pierwsze to dołączenie pliku obsługi protokołu nusoap.php. Następnie stworzony jest obiekt serwera SOAP. W ustawieniach tego serwera, dla parametru WSDL ustalona zostaje nazwa tego serwera oraz jego przestrzeń pracy(przestrzeń nazw). Następnie zarejestrowana zostaje nowa funkcja(jej definicja jest na samej górze pliku przykładu) w przestrzeni serwera getstockquote odpowiednio przyjmująca parametr string i zwracająca liczbę. Ostatnim elementem jest ustawienie usługi http. 11

12 Istnieje już serwer, a więc jak wygląda klient? znacznie prościej: Pierwsze to dołączenie pliku nagłówka nusoap.php. Następnie stworzenie obiektu klienta oraz podaniu w konstruktorze adresu serwera z jakim ma się połączyć. Wydobycie ceny z serwera to wywołanie funkcji call z odpowiednim parametrem funkcji do wywołania na serwerze tutaj getstockquote. 12