Web Services Praktyczny przewodnik. Robert Nowak Vercom Sp z o. o.

Transkrypt

1 Web Services Praktyczny przewodnik Robert Nowak Vercom Sp z o. o. 21 września 2005

2 Spis treści 1 Web Services - tworzenie i użytkowanie Definicja Web Services Przykłady użycia Web Services Rozbudowa dotychczasowych aplikacji Pozyskanie informacji z Google Współpraca z bazą danych Księgarnia amazon.com BPEL - język zarządzania Web Services Podstawowe właściwości języka Podsumowanie ebxml - XML dla biznesu Protokół SOAP Opis protokołu Szkielet komunikatu SOAP Koperta (envelope) Nagłówek (header) Ciało (body) Błąd (fault) Przykładowa para komunikatów Format WSDL Przykładowy listing WSDL UDDI Web Services z wykorzystaniem Apache Axis Co to jest Axis Instalacja Wymagane oprogramowanie Pobranie Axisa Instalacja pakietu Opcjonalna instalacja parsera XML Użycie Axis 1.2 razem z WebLogic Ustawienie zmiennych systemowych Sprawdzenie instalacji Struktura katalogów Korzystanie z Axis Lista uruchomionych serwisów Dodawanie własnych serwisów Udostępnianie Web Services za pomocą plików JWS Rozbudowana metoda udostępniania Web Services Pisanie aplikacji serwera z wykorzystaniem Axis Użycie plików.jws Tworzenie kodu źródłowego

3 SPIS TREŚCI Udostępnianie klasy Łączenie się z Web Service za pomocą URL Testowanie udostępnionych metod Metoda zaawansowana Tworzenie kodu źródłowego Udostępnianie serwisu Pisanie aplikacji klienta z wykorzystaniem Axis Klient statyczny Generacja plików Java z WSDL Tworzenie kodu klienta Kompilacja kodu Uruchomienie klienta Kod klienta Klient dynamiczny Tworzenie kodu źródłowego Kod klienta Pliki do pobrania Tworzenie i korzystanie z Web Services w PHP Wstęp Wbudowany SOAP Instalacja Konfiguracja Tworzenie serwera Tworzenie klienta PEAR SOAP Instalacja Tworzenie serwera Klient Pliki do pobrania Web Services z użyciem Eclipse Web Tools Platform Wstęp Użyte komponenty Instalacja Web Tools Platform Programowanie Web Services z użyciem WTP Tworzenie nowego projektu Tworzenie Web Service z klas Javy (bottom-up WS) Tworzenie Web Service z pliku WSDL (top-down WS) Tworzenie klienta Web Service przy pomocy WTP Klasa wykorzystująca wygenerowany kod klienta (klient statyczny) Web Service na zdalnym serwerze (eksport projektu do pliku WAR) Testowanie WS używając Web Services Explorer Testowanie Web Service za pomocą URL Pliki do pobrania Web Services i Googletworzenie klienta Wstęp Użycie dostarczonych bibliotek Klient Java Klient w PHP Pliki do pobrania

4 SPIS TREŚCI 3 6 Dodatki Słowniczek XML J2EE

5 Rozdział 1 Web Services - tworzenie i użytkowanie 1.1 Definicja Web Services Web Services to zbiór standardów stworzony w celu wspierania wymiany informacji za pomocą sieci. Standardy te tworzą abstrakcyjną warstwę, znajdującą się ponad systemami operacyjnymi czy też językami programowania, umożliwiając porozumiewanie się aplikacji bez kłopotania się o szczegóły implementacyjne. Format i sposób wymiany komunikatów między serwisami jest dokładnie określony za pomocą standardów W3C ( Każdy serwer posiada dodatkowo reguły określające sposób komunikacji z nim (stosowane zabezpieczenia, adres właściwego serwisu) oraz listę udostępnianych metod wraz z argumentami i zwracanymi typami. Wszystko to jest opisane za pomocą dokumentu WSDL (1.4). Inne komputery współpracują z Web Service na zasadach określonych w tym dokumencie, używając komunikatów, które mogą być zawarte w kapsułce SOAP (1.3), lub też stosować format REST. Komunikaty są zazwyczaj przekazywane z wykorzystaniem protokołu HTTP. Ich budowa opiera się o XML (6.1.1), z możliwymi połączeniami z innymi standardowymi dokumentami sieciowymi. Aplikacje stworzone w różnych językach programowania, działające na różnych platformach sprzętowych i programistycznych mogą dzięki Web Services komunikować się ze sobą poprzez sieć tak łatwo jakby działo się to pomiędzy lokalnymi procesami (rysunek 1.1). Ta przenośność jest możliwa dzięki użyciu otwartych standardów, które tworzą OASIS razem z W3C. Stanowi ona o wielkiej sile Web Services, które powoli zdają się przejmować prym w komunikacji między aplikacjami sieciowymi. 1.2 Przykłady użycia Web Services Web Services służą znacznemu usprawnieniu współpracy na linii klient-serwer. W prosty sposób udostępniają usługi, jak również potrafią się z nimi łączyć i z nich korzystać. Można by powiedzieć że to żadna nowość i byłaby to prawda. Mamy strony WWW które przekazują informację, kanały RSS itp. Web Services nie są czymś rewolucyjnym jeśli chodzi o cel istnienia, jednak sposób ich pracy stanowi wielki krok w stronę ułatwienia i ustandaryzowania współpracy serwisów. Ich zastosowania są bardzo szerokie - można z nich z powodzeniem korzystać wszędzie tam gdzie potrzebna jest komunikacja w celu pobrania danych Rozbudowa dotychczasowych aplikacji Wyobraźmy sobie przykładową firmę, gdzie ze względu na niezawodność, serwer z najnowszymi danymi firmowy ma zostać uruchomiony na bazie danych PostgreSQL. Jednak wszystkie wcześniejsze dane są w aplikacji napisanej w.net i umieszczone w bazie danych MSSQL. Stworzenie komunikacji między aplikacją.net a Javową jest trudną sprawą, a jej wypracowanie zajęłoby miesiące. Bez użycia Web Services byłaby to trudna sytuacja, jednak dzięki nim, możliwe jest eleganckie i nowoczesne rozwiązanie: serwer MSSQL pozostaje na swoim miejscu, a na platformie.net uruchomionej 4

6 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 5 Rysunek 1.1: Idea Web Services na tym samym komputerze, zostaje udostępniony Web Service, wstawiający funkcje dostępu do MSSQL. Powstaje też aplikacja napisana w języku Java. Łączy się ona z bazą PostgreSQL, a także z Web Service.NET u. Z tej aplikacji korzysta klient. Oto schemat tej struktury:

7 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 6 Rysunek 1.2: Integracja.NET z Java Prześledźmy typowe wykorzystanie: użytkownik korzysta z aplikacji napisanej w Javie: wybiera z menu potrzebne mu informacje (1). Aplikacja analizuje dane i widzi, że potrzebuje danych z obu baz danych. Łączy się więc z Web Service udostępnionym przez.net i przekazuje mu żądanie (2). Web Service uruchamia odpowiednie procedury.net, który pobiera z bazy MSSQL odpowiednie wiadomości (3, 4). Dane zostają odesłane do Javy (5). Następnie pobierane są informacje z PostgreSQL (6,7), następuje ich przetworzenie i klient dostaje wynik (8). Jak widać, integracja przebiegła całkiem sprawnie. Ktoś mógłby stwierdzić, że to samo można by uzyskać innymi sposobami. To prawda, ale jak już napisano wcześniej, pochłonęłoby to dużo pracy i czasu. A my, dzięki zastosowaniu Web Services, możemy bez trudu przenieść naszą architekturę na następny poziom:

8 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 7 Rysunek 1.3: Integracja.NET z Java - Internet Uzyskaliśmy teraz podział na dwie maszyny: jedna z zestawem.net - MSSQL, druga J2EE - PostgreSQL. Powyższy rozdział na dwa komputery połączone tylko przez Internet staje się możliwy dzięki sile Web Services. Powstaje pytanie: po co ryzykować i kazać użytkownikowi pracować na serwerze? Po raz kolejny korzystamy z Web Services: Rysunek 1.4: Rozbudowa współpracy.net z Java przez Internet Kolejna korzyść wydaje się być naturalna: użytkowników może być teraz wielu, każdy z nich może pracować niezależnie i równocześnie.

9 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 8 Myślę że ten akapit dobrze zaprezentował potencjał drzemiący w Web Services Pozyskanie informacji z Google Do tej pory, chcąc na przykład wykorzystać wyniki wyszukiwania zwracane przez Google, należało parsować kod HTML. Odpowiedzią na zapytanie bała cała strona HTML. Pojedyncza pozycja (którą trzeba również wyłowić z innych) wygląda następująco: <a href=" cd ::płytycd na Emuzyka.pl.</a><table border="0" cellpa dding="0" cellspacing="0"><tbody><tr><td style="width: 37em;" clas s="j">strona główna? płyty cd? 1,2, 3... Partnerem działu płyty cd na emuzyka.pl jest Startuj z emuzyka.pl? Stare dzwonki zabronione! ... - 44k - 13 IX <a class="fl"href=" /search?q=cache:HsLTXekgOLMJ: +&hl=pl">kopia</a>-<aclass="fl"href="/search?hl=pl&lr=&amp ;q=related: strony </a> - <aclass="fl"cg_filter=" ript:void(0);">filter</a>  Zamieńmy to może w bardziej czytelną postać:  <a href=" płyty cd::płytycdna Emuzyka.pl. </a> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td style="width: 37em;" class="j"> Strona główna? płyty cd? 1, 2, 3... Partnerem działu płyty cd na emuzyka.pl jest Startuj z emuzyka.pl? Stare dzwonki zabronione! ... k - 13 IX <a class="fl" href=" q=cache:hsltxekgolmj: +p%c5%82yty+cd+&hl=pl">kopia </a> - <a class="fl" href="/search? hl=pl &lr=

10 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 9 &q=related: Podobne strony </a> - <a class="fl" cg_filter=" href="javascript:void(0);"> Filter </a>  Teraz z tego kodu należało wyciągnąć potrzebne nam dane - np. URL ( Nawet gdy już stworzono odpowiedni program, należało się liczyć z tym, że każda zmiana w formacie wyszukiwania spowoduje konieczność uaktualnienia. Chcąc ułatwić współpracę, Google stworzył i udostępnił własny Web Service: Google APIs. Teraz cały kod odpowiedzialny za wykonanie zapytania i otrzymania URL wygląda następująco (język PHP): $soapclient = new SoapClient( ); $odpowiedz = $soapclient-> dogooglesearch(key, płyty CD, 0, 10, true, countrypl, false, lang_pl,, ); $obecnyadres = $odpowiedz->resultelements[$x]->url; W zmiennej $obecnyadres mamy już w tej chwili adres którego szukamy. Niezależnie od przyszłych zmian w strukturze odpowiedzi, metoda ta zadziała. Za pomocą Google APIs można wykonać naprawdę wiele rzeczy - na przykład program do sprawdzania pozycji naszej strony w rankingu. Szerzej o tym programie oraz o Google APIs w rozdziale Współpraca z baza danych Ciekawszy przykład użycia to współpraca między komponentami tej samej aplikacji. Przykładowo serwer Web Services znajduje się na maszynie z bazą danych a klientem jest aplikacja w Javie. Zwyczajowo serwer musiał mieć udostępniony interfejs dostępu do bazy, a klient odwoływać się bezpośrednio do niego, przesyłając zapytania. Nie jest to zbyt bezpieczne, wymaga też implementacji dużej części obsługi w kliencie. Używając Web Services, aplikacja łączy się z serwerem za pomocą prostego kodu (Java), nie martwiąc się o szczegóły: Result res = new Result(); res = service.getksiazki(tytul, mincena, makscena); System.out.println("Tytul ksiazki numer " + x + " to " + res.gettytul() + " a cena " + res[x].getcena(); Zauważmy, że klient nie musi (a jeśli serwer nie zechce to nie może) wiedzieć jakiego typu bazę danych wykorzystano, czy też w jakim języku programowania napisano aplikację - jedyną interesującą go rzeczą jest odpowiedź na jego pytanie. Jeśli dodać do tego możliwość zabezpieczenia usługi za pomocą zaawansowanych technik (szyfrowanie całości i części przesyłanych komunikatów), otrzymujemy to, czym Web Services miały być: nową metodą sprawnej i bezpiecznej komunikacji między aplikacjami.

11 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE Księgarnia amazon.com Jeden z największych sklepów internetowych amazon.com również postanowił udostępnić swoje usługi z apomocą Web Services. Zostało to entuzjastycznie przyjęte przez osoby związane z serwisem. Wydawcy książek otrzymali narzędzie do monitorowania sprzedaży swoich i konkurencyjnych wydawnictw. Do tej pory wiele firm zbierało statystyki ręcznie (co przy dużej ilości sprzedawanych pozycji wymagało dużego nakladu pracy) albo też parsując HTML (o parsowaniu HTML napisano w punkcie 1.2.2). Jednocześnie właściciele stron internetowych otrzymali możliwość sprzedawania towarów amazon.com bezpośrednio ze swojego serwisu. Mając do dyspozycji Amazon Web Services, mogą w prosty sposób stworzyć kompleksową ofertę obejmującą na przykład tylko dział sprzedaży pokrywający się z tematyką strony. Odwiedzający mogą przeglądać taką ofertę, a nawet wyszukiwać wewnątrz niej. Za każdy zakupiony przedmiot, Amazon płaci odpowiednią marżę właścicielowi serwisu przez który dokonano transakcji BPEL - język zarzadzania Web Services BPEL, Business Process Execution Language jest językiem programowania opartym na XML. Jego zadaniem jest umożliwienie sprawnego i skoordynowanego przeprowadzenia transakcji ze jednym lub więcej Web Services. Co najważniejsze - serwisy te mogą być asynchroniczne i równoległe Podstawowe właściwości języka BPEL prezentuje logikę odmienną od języków takich jak C++ czy Java. Języki te służą do tworzenia programów, w których czas wykonywania pojedynczych zadań jest krótki (są one uruchamianie, wykonują swoją, zazwyczaj lokalną, pracę, a następnie kończą działanie). BPEL jest językiem wysokopoziomowym ze zdolnością wykonywania tranzycji stanów. Oznacza to, że system składa się z pewniej liczby (być może nieskończonej) stanów w których może się znaleźć oraz reguł przejść między nimi. W praktyce oznacza to, że jest nim możliwa obsługa asynchronicznych komunikatów, czy też wprowadzenie reguły ACID. Asynchroniczne komunikaty w uproszczeniu są to wiadomości na które oczekujemy nieznaną, ale skończoną ilość czasu. Przykładowo aplikacja wysyłająca wniosek o pożyczkę do banku w końcu otrzyma w końcu odpowiedź (zakładając niezawodność banku i transmisji), ale może ją otrzymać dopiero po kilku dniach. Nasza aplikacja zmieni wtedy stan na odpowiedni do sytuacji, przechodząc na przykład do wcześniej ustalonego zakupu posiadłości za pożyczone pieniądze w razie udzielenia kredytu, lub do wynajęcia mieszkania w razie odmowy. Nazwa reguły ACID jest skrótem od angielskich słów Atomicity (atomowość), Consistency (spójność), Isolation (izolacja), Durability (trwałość). Są to ważne zasady wzięte z dziedziny baz danych gwarantujące zachowanie poprawności przetwarzanych danych. Cztery żądania reguły oznaczają: atomowość - dana czynność jest wykonana cała, albo w ogóle. Jeśli zażądamy skopiowania danych z dysku A na dysk B, albo zostaną skopiowane wszystkie dane, albo żadne. Nawet jeśli połowa plików będzie zapisana już na dysku A gdy wydarzy się awaria, kopiowanie zostanie cofnięte, a dane usunięte. spójność - jeśli system był zgodny z określonymi regułami przed operacją, po operacji będzie również zgodny izolacja - jeśli dwa lub więcej procesów wykonuje się równocześnie, każdy działa osobno. Przykład: jeśli oba korzystają z jednej zmiennej, każdy z nich widzi jej własną wersję, zmieny wykonane w procesie A nie zmienią zmiennej w procesie B. Istnieją jednak tak zwane poziomy izolacji, gdzie niektóre założenia są modyfikowane. trwałość - dane są poprawne przez cały czas. Nawet jeśli wskutek awari wykonana zostanie tylko część operacji, co może spowodować powstanie niepoprawnego stanu, system będzie potrafił określić dokładnie w którym miejscu nastąpiła awaria i podjąć odpowiednie kroki Obecnie dostępne są już narzędzia, które pozwalają na tworzenie schematów przepływu obsługi w języku BPEL za pomocą technologii przeciągnij i upuść.

12 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE Podsumowanie Podsumowując, dzieki językowi BPEL jesteśmy, jak w powyższym przykładzie banku, połączyć wiele osobnych serwisów (składanie wniosków, obsługa przelewów pieniędzy, agencja wynajmu nieruchomości, pośrednik zakupu posiadłości) w jedną logicznie powiązaną całość. Dodatkowo otrzymujemy takie mechanizmy jak definiowanie współbieżności, zarządzanie zdarzeniami i wyjątkami czy też mainpulacja strukturami. Plugin pozwalający dodanie obsługi języka BPEL do Eclipse znajduje się pod adresem ebxml - XML dla biznesu ebxml, electronic business XML jest rodziną standardów XML tworzonych przez OASIS i UN/CEFACT których celem jest dostarczenie otwartej i opartej o XML infrastruktury która umożliwi światową wymianę informacji biznesowej w niezależny od systemu operacyjngo, bezpieczny i sprecyzowany sposób. Standard został zbudowany na podstawie wieloletnich doświadczeń biznesu elektronicznego, tak by w możliwie najprostszy sposób pokryć wymagania rozwijającego się przemysłu. Jedną z ciekawszych propozycji języka jest tworzenie profilu firmy, a następnie automatyczne znajdywanie partnera biznesowego z odpowiadającym nam profilem. 1.3 Protokół SOAP Komunikacja między serwerem a klientem odbywa się za pomocą protokołu SOAP. Specyfikacja standardu SOAP znajduje się pod adresem Tutaj wyjaśnimy tylko pokrótce czym jest SOAP i przedstawimy przykładowy komunikat SOAP i odpowiedź na niego Opis protokołu SOAP jest to protokół służący do wymiany informacji w zdecentralizowanym, rozproszonym środowisku. Używa technologii XML aby zdefiniować rozszerzalną platformę pozwalającą na wymianę komunikatów za pomocą różnych standardowych protokółów (np. HTTP). Platforma z założenia jest niezależna od języka programowania i innych szczegółów implementacyjnych. Protokół SOAP składa się z trzech głównych części: koperty (envelope) która określa szkielet opisujący co znajduje się w komunikacie i jak go przetwarzać, zbioru reguł kodujących potrzebnych do rozszyfrowania typów danych (również złożonych) zdefiniowanych wewnątrz aplikacji, reguł dotyczących wywoływania zdalnych procedur i odczytu odpowiedzi. Bardziej ludzko można by powiedzieć, że SOAP jest językiem jakim porozumiewają się Web Services, zbudowanym na podstawie języka XML (6.1.1), co umożliwia jego uniezależnienie do użytych systemów operacyjnych czy też języków programowania. Jego budowa jest określona przez standardy, a ich zachowanie gwarantuje poprawną wymianę informacji. Omówmy teraz dokładnie budowę komunikatu SOAP Szkielet komunikatu SOAP Ogólny szkielet prezentuje się następująco: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header>

13 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE naglowek </soap:header> <soap:body>......glowna czesc komunikatu <soap:fault>......bledy, o ile wystapily </soap:fault> </soap:body> </soap:envelope> Opiszemy teraz jego kolejne fragmenty Koperta (envelope) Element wymagany. Koperta to główna część komunikatu SOAP, inne elementy jak nagłówek czy ciało są jej potomkami. Koperta definiuje dokument XML jako komunikat SOAP. Składnia: <?xml version="1.0"?> <soap:envelope... Tresc komunikatu... </soap:envelope> Atrybut xmlns:soap (opcjonalny) wskazuje przestrzeń nazw (schemat według jakiego decydujemy się budować komunikat, w przykładzie podano standardowy zestaw dla SOAP 1.2 zdefioniowany przez W3C, ale możliwe jest defioniowanie własnych dokumentów). Składnia: xmlns:soap="url" Atrybut encodingstyle (obowiązkowy) służy do definicji typów danych używanych w dokumencie. Ten atrybut może pojawić się w każdym elemencie komunikatu i zostanie zastosowany w tym elemencie i wszystkich jego podelemnetach. Komunikat SOAP nie ma domyślnej wartości tego atrybutu, dlatego należy go podać przynajmniej raz, w głównym elemencie. Składnia: soap:encodingstyle="url" Prawidłowo zdefiniowane atrybuty to przykładowo: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" Tresc komunikatu... </soap:envelope>

14 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 13 Nazwa next none ultimatereceiver własna Wykonywanie Musi być wykonany przez wszystkie węzły Nikt nie może tego wykonać Końcowy węzeł nie może tego wykonać reguły określone w URL Tablica 1.2: Wykonanie poszczególnych ról Nagłówek (header) Element opcjonalny. Nagłówek zawiera wiadomości określające dodatkowe właściwości komunikatu. Mogą to być na przykład elementy dotyczące bezpieczeństwa czy też reguły przetwarzania ciała. Jeśli podano nagłówek, musi zostać wpisany jako pierwszy na liście potomków koperty. Przykład: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header>... Dane naglowka... </soap:header> </soap:envelope> Atrybut actor (opcjonalny) (w SOAP wersja 1.2 role) określa odbiorcę, a właściwie wykonawcę danego elementu. Komunikaty SOAP mogą podróżować przez sieć, przechodząc po drodze przez wiele węzłów (komputerów). Atrybut actor określa kto ma go (element nagłówka) wykonywać: Nazwa next none ultimatereceiver własna Pełna nazwa " " " Tablica 1.1: Nazwy ról w SOAP Składnia: soap:actor="uri" Przykład nagłówka z elementem actor: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m="

15 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 14 soap:actor=" 234 </m:trans> </soap:header> </soap:envelope> Atrybut mustunderstand (opcjonalny) określa, czy element w którym go użyto jest obowiązkowy czy opcjonalny do przetworzenia. Jeśli atrybut jest ustawiony, a odbiorca nie zrozumie użytego elementu, zostanie przerwane przetwarzanie i zwrócony zostanie błąd. Przykładowy komunikat wraz z nagłówkiem wygląda następująco: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m=" soap:mustunderstand="1">234</m:trans> </soap:header> </soap:envelope> zapis m:trans oznacza metodę Trans obiektu m. Składnia: soap:mustunderstand="0 1" Atrybut encodingstyle (opcjonalny): wyjaśniony w punkcie Ciało (body) Element obowiązkowy. Ciało komunikatu zawiera wszystkie informacje, które końcowy odbiorca powinien otrzymać. Jego przetwarzanie może być uwarunkowane za pomocą nagłówka. Przykład ciała komunikatu: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <m:pobierzecene xmlns:m=" <m:nazwa>jablko</m:nazwa> </m:pobierzcene> </soap:body> </soap:envelope> Odpowiedź na ten komunikat powinna wyglądać następująco: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body>

16 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 15 Element <faultcode> <faultstring> <faultactor> <detail> Opis kod identyfikujący błąd opis błędu informacja o węźle który spowodował błąd szczegóły błędu Tablica 1.3: Elementy komunikatu fault <m:pobierzceneodpowiedz xmlns:m=" <m:cena>1.90</m:cena> </m:pobierzceneodpowiedz> </soap:body> </soap:envelope> Bład (fault) Element opcjonalny. Ta część komunikatu zawiera opis ewentualnych błędów. Jest potomkiem elementu Body, nie Envelope. Komunikat błędu wygląda następująco: <soapenv:envelope> <soapenv:body> <soapenv:fault> <faultcode>ns1:client</faultcode> <faultstring>wykonano niepoprawna operacje</faultstring> <detail> <ns2:hostname>webservices</ns2:hostname> </detail> </soapenv:fault> </soapenv:body> </soapenv:envelope> Przykładowa para komunikatów Zobaczmy teraz przykładową parę komunikatów SOAP. Klient wysyła argument <host xsi:type="xsd:string"> gdzie host to nazwa argumentu, xsi:type to atrybut typu String o wartości inotel.pl do funkcji getip(). W zamian oczekuje czegoś bardziej skomplikowanego: struktury Adres, która składa się z nazwy zadanego hosta i jego adresu IP (obliczony na serwerze). Komunikat klienta wygląda następująco: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:ns1=" xmlns:xsd=" xmlns:xsi=" xmlns:soap-enc=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <ns1:getip> <host xsi:type="xsd:string">

17 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 16 inotel.pl </host> </ns1:getip> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Częścią przenoszącą dane jest <SOAP-ENV:Body>. Metoda którą wywołujemy to getip (<ns1:getip>). Widać tam argument host typu String (<host xsi:type="xsd:string">) i wartości inotel.pl. Serwer odpowiada: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:ns1=" xmlns:xsd=" xmlns:soap-enc=" xmlns:xsi=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <ns1:getipresponse> <getipreturn xsi:type="soap-enc:struct"> <nazwa xsi:type="xsd:string"> inotel.pl </nazwa> <adres xsi:type="xsd:string"> </adres> </getipreturn> </ns1:getipresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Tutaj również informacja zawarta jest w części <SOAP-ENV:Body>. Dostajemy strukturę składającą się z nazwy i adresu IP, czyli to czego oczekiwaliśmy. Jak widać znając XML, można z łatwością odczytać (przynajmniej podstawowe) komunikaty SOAP. 1.4 Format WSDL WSDL (Web Services Description Language, jest dokumentem XML(6.1.1) opisującym udostępnione przez serwer Web Services. Udostępniając listę dostępnych metod, ich argumenty (w tym złożone typy danych) i zwracane typy, w prosty sposób definiuje schemat komunikacji na linii klient-serwer. Dzięki rozszerzalności WSDL pozwala opisywać procedury i ich formaty niezależnie od protokołów użytych do przekazywania danych. W chwili obecnej większość aplikacji oferuje automatyczne generowanie pliku WSDL, jednak przydatność jego odczytania jest bardzo pomocna Przykładowy listing WSDL Spróbujmy odczytać przykładowy plik WSDL. Cały listing niepoprzerywany komentarzami znajduje się w punkcie <?xml version="1.0" encoding="utf-8"?> Określenie wersji standardu XML (1.0) i kodowania znaków dokumentu (utf8).

18 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 17 <wsdl:definitions targetnamespace=" xmlns:apachesoap=" xmlns:impl=" xmlns:intf=" xmlns:soapenc=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" Powyższy fragment to zdefiniowanie podstawowych informacji na temat samego dokumentu, a także przestrzeni nazw w jakiej znajdują się zmienne i metody wymienione dalej.  Komentarz generatora. <wsdl:message name="getiprequest"> <wsdl:part name="host" type="xsd:string"/> </wsdl:message> <wsdl:message name="getipresponse"> <wsdl:part name="getipreturn" type="xsd:string"/> </wsdl:message> Są to opisy dwóch komunikatów: getiprequest i getipresponse. Pierwszy z komunikatów służy do wywołania metody getip, a drugi definiuje odpowiedź tej metody. Nazwy które się tu pojawiają, nie są obowiązkowe. Powiązanie komunikatu z metodą widać w dalszej części dokumentu. Każdy z tagów opisujących komunikat zawiera określenie związanych z nim danych. W przypadku getiprequest jest to String o nazwie host. Łącząc się z serwerem, klient wysyła dokument SOAP, w którym podana jest właśnie nazwa tego komunikatu, a także argument o tej nazwie. Klient dowiaduje się o jej istnieniu właśnie z pliku WSDL. W przypadku getipresponse odczytujemy, że po wykonaniu metody getip serwer odeśle nam komunikat z łańcuchem znaków. Możliwe jest również stosowanie złożonych typów danych. Korzysta się wtedy z dodatkowych definicji typów. <wsdl:message name="helloresponse"> <wsdl:part name="helloreturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="hellorequest"> </wsdl:message> Tutaj widzimy prostą metodę nie przyjmującą parametrów. Zwróćmy uwagę, że kolejność definiowania komunikatów nie jest ważna w obrębie nadrzędnego tagu. <wsdl:message name="podzielresponse"> <wsdl:part name="podzielreturn" type="xsd:float"/> </wsdl:message> <wsdl:message name="podzielrequest"> <wsdl:part name="a" type="xsd:int"/> <wsdl:part name="b" type="xsd:int"/> </wsdl:message> Metoda podzielrequest przyjmuje dwa parametry typu int, zwraca jeden float. <wsdl:porttype name="helloworld">

19 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 18 Port type to nazwany zbiór abstrakcyjnych operacji i powiązanych z nimi abstrakcyjnych komunikatów. Nazwa portu jest unikalna w obrębie dokumentu. <wsdl:operation name="getip" parameterorder="host"> <wsdl:input message="impl:getiprequest" name="getiprequest"/> <wsdl:output message="impl:getipresponse" name="getipresponse"/> </wsdl:operation> Tutaj pojawia się wspomniane wyżej powiązanie komunikatów z metodami. Widać wyraźne zaznaczenie, jak nazywa się metoda którą wywołujemy, jej parametry oraz który komunikat jest wejściowy, a który wyjściowy. <wsdl:operation name="hello"> <wsdl:input message="impl:hellorequest" name="hellorequest"/> <wsdl:output message="impl:helloresponse" name="helloresponse"/> </wsdl:operation> <wsdl:operation name="podziel" parameterorder="a b"> <wsdl:input message="impl:podzielrequest" name="podzielrequest"/> <wsdl:output message="impl:podzielresponse" name="podzielresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="helloworldsoapbinding" type="impl:helloworld"> Ta część opisuje szczegółowo sposób łączenia metod zdefiniowanych wyżej z właściwym serwisem. <wsdlsoap:binding style="rpc" transport=" Określony zostaje styl wymiany komunikatów na RPC (remote procedure call, zdalne wywołanie procedury). Styl ten polega na tym, że komunikacja odbywa się na zasadzie wysłania pojedynczej procedury do wykonania i otrzymanie odpowiedzi. Innym, bardziej rozbudowanym, sposobem jest document oriented communication, gdzie zakłada się wykonanie całego przesłanego dokumentu XML, opisującego kolejne metody do wywołania. <wsdl:operation name="getip"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="getiprequest"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:input> <wsdl:output name="getipresponse"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:output> </wsdl:operation> Tutaj znajdują się wiadomości na temat rodzajów komunikatów i standardów według których mają być budowane. <wsdl:operation name="hello"> <wsdlsoap:operation soapaction=""/>

20 ROZDZIAŁ 1. WEB SERVICES - TWORZENIE I UŻYTKOWANIE 19 <wsdl:input name="hellorequest"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:input> <wsdl:output name="helloresponse"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="podziel"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="podzielrequest"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:input> <wsdl:output name="podzielresponse"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="helloworldservice"> <wsdl:port binding="impl:helloworldsoapbinding" name="helloworld"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> Korzystając z wyżej zdefiniowanych elementów, możemy stworzyć ostatni, najważniejszy fragment WSDL. Z tagu <wsdl:service> klient dowiaduje się wszystkiego o serwisie, czyli adres pod który ma kierować zapytania (adres serwera) i jak ma je budować. </wsdl:definitions> Jak widać, dokument WSDL jest po prostu zbiorem definicji metod i danych zapisanym w języku pochodnym od XMLa. 1.5 UDDI UDDI, Universal Description, Discovery, and Integration (uniwersalny opis, odkrywanie i scalanie) UDDI jest niezależnym od platformy, opartym o język XML (6.1.1) rejestrem umożliwiającym odnajdywanie i scalanie aplikacji biznesowych z całego świata poprzez internet. Każdy może dodać swoją usługę do katalogu, tak by inni mogli ją odnaleźć, lub też skorzystać z juz zamieszczenych roziwąznań.

Pokazać jeszcze