Na tym wykładzie omówię usługi Sieciowe, lepiej znane jako web services. Idea web services to bardzo interesujący przykład twórczego wykorzystania wielu znanych już od dawna pomysłów. Web services to po prostu ich kompozycja. Te idee to: zdalne wywołanie procedury (RPC = Remote Procedure Call), XML do zapisu komunikatów protokołu i HTTP (= HyperText Transfer Protocol) do transmisji Sieciowej. Web services są zatem realizacją starego już marzenia o totalnej interoperacyjności w środowisku heterogenicznym i to wykonaną za pomocą bardzo prostych środków (HTTP+XML).
Programista oczywiście nie musi sobie z tego w ogóle zdawać sprawy. Dysponuje po prostu bibliotekami i pniakami, które ukrywają przed nim te wszystkie mechanizmy i pozwalają wywoływać web services tak jakby to były lokalne procedury.
Omówię najpierw zasadę działania web services a potem przejdę do omówienia bibliotek do obsługi web services w Javie. Inne platformy (.NET, PHP) oczywiście też mają takie udogodnienia, które działają w bardzo podobny sposób.
Pojęcie "Web Service" w ogólności oznacza ideę rozproszonej aplikacji webowej.
Myślimy o komunikacji między aplikacjami poprzez internet. Słyszymy i czytamy w wielu miejscach:
"usługa brana z sieci".
"zorientowane na usługi podejście projektanckie bazujące na idei budowania aplikacji poprzez odkrywanie i udostępnianie serwisów sieciowych oraz integracji aplikacji na zasadzie just-in-time."
Jest to bardzo ogólna (i nieco bełkotliwa) definicja. Tysiąc rzeczy możemy nazwać web serwisem (przynajmniej pomijając to ostatnie: just-in-time). Niemniej jednak, kiedy się o tym mówi, to zazwyczaj ma się na myśli poniższe, konkretne podejście.
WS działa trochę jak RPC. Natomiast, co tu jest szczególne, to to, że będą się pojawiały metajęzyki opisu przesyłanych danych itd. Całość ma być przenośna i mocno ogólna. Chcemy skodyfikować zasady tworzenia luźno powiązanych systemów bazujących na rozproszonych usługach (w przeciwieństwie do pojedynczej implementacji).
Architektura opisuje trzy role: dostarczyciela serwisu, klienta serwisu oraz pośrednika. Obrazuje także trzy główne operacje: publikacji, wyszukiwania oraz wiązania.
Implementacja powinna pozwalać na zastosowanie wielowarstwowych mechanizmów bezpieczeństwa oraz udogodnienia umożliwiające konfigurowanie środowiska (np. mechanizmów autoryzacji, naliczania opłat itd.).
Chronologicznie i z grubsza dziać się ma tak:
Jest tu dość śliska sprawa dotycząca pośredników, rejestrów usług, centralizacji i czystości całego systemu - Microsoft w roli głównego powiernika informacji o wszystkich usługodawcach na świecie.
(Na szczęście) można też się u nikogo nie rejestrować, klient może po prostu podłączyć się i pracować z danym serwerem.
System zawsze używa XML. Prawie zawsze transmisja danych jest po HTTP.
Takie "bardziej" pełne rozwiązania będą używały: XML + HTTP + SOAP + WSDL + UDDI. I implementacja w Javie/J2EE.
SOAP to specyfikacja protokołu do wywoływania metod serwerów, serwisów, komponentów oraz obiektów. SOAP kodyfikuje wykorzystywane w praktyce zastosowanie XML oraz HTTP jako mechanizmów wywoływania metod. Specyfikacja SOAP określa kilka rodzajów nagłówków HTTP ułatwiających filtrację zaporom ogniowym i serwerom pośredniczącym. Definiuje także słownik znaczników XML wykorzystywanych do reprezentacji parametrów, zwracanych wartości oraz rzucanych przez metody wyjątków.
Najczęściej wykorzystuje HTTP. Ale nie musi.
Roboczy szkic (working draft) SOAP w wersji 1.2 - 9 lipca 2001.
Wbrew pozorom nie uważam, że jest to niemądre pytanie. Myślę, że jest coś na rzeczy w kwestii popularności XML (złośliwe), ale też jego tekstowości, ogólności, no i jest też kwestia wielu pniaków z CORBA itp. rzeczy - nałożenie tego na HTTP nie jest takie oczywiste.
Teksty marketingowe, których pełno, mówią też o problemach z bezpieczeństwem w tego typu systemach (kiepski argument), więc rzekomo z tego powodu wiele zapór ogniowych i serwerów pośredniczących blokuje przepływ tego typu informacji (równie kiepski - czemu nie można zrobić CORBA na porcie 80).
Prosty dokument SOAP z żądaniem ceny mydła:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope"
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
<env:Body>
<m:GetPrice xmlns:m="Some-URI">
<Item>Soap</Item>
</m:GetPrice>
</env:Body>
</env:Envelope>
|
Informacje o błędach przetwarzania zawarte są wewnątrz elementu Fault. Element musi pojawić się wewnątrz elementu Body i może wystąpić tylko raz w komunikacie SOAP.
Elementy zawarte wewnątrz Fault:
Kody błędów - faultcodes:
Przykładowy komunikat:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope"
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
<env:Body>
<env:Fault>
<faultcode>env:MustUnderstand</faultcode>
<faultstring>SOAP Must Understand Error</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
|
Zanurzenie w HTTP - żądanie:
POST /StockQuote HTTP/1.1
Host: www.stocksserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<env:Envelope
xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:GetStockQuote xmlns:m="Some-URI"
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
<symbol>SUNW</symbol>
</m:GetStockQuote >
</env:Body>
</env:Envelope>
|
Odpowiedź:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<env:Envelope xmlns:env=http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:GetStockQuoteResponse xmlns:m="Some-URI"
env:encodingStyle="http://www.w3.org/2001/06/soap- encoding">
<price>5.00</price>
</m:GetStockQuoteResponse>
</env:Body>
</env:Envelope>
|
SOAP jako, że używa HTTP jako protokołu transportu, jest bezstanowy.
Nie implementuje bezpieczeństwa. Transport przez HTTP pozwala jednak na zastosowanie SSL na poziomie aplikacji.
Pole SOAPAction nagłówka HTTP pozwala firewallom na filtrowanie komunikatów SOAP i np. zupełnie zabronić wywołań SOAP. Firewalle mogą filtrować pakiety SOAP bazując na nazwie obiektu, poszczególnej metody albo brać pod uwagę oba te kryteria.
Specyfikacja definiuje następnie język opisu interfejsu SOAP serwera zwany WSDL.
Format WSDL jest również XML.
Przypominam: po stworzeniu serwisu możemy opublikować jego opis i umieścić odwołanie do tego opisu w repozytorium (UDDI = Universal Description, Discovery and Integration) tak, aby umożliwić odnalezienie go przez potencjalnych użytkowników.
Wszystkie operacje w ramach Web Services (rejestracje, wyszukiwania, przekazywania danych) są realizowane konsekwentnie po protokole SOAP.
Kiedy ktoś zechce użyć danego serwisu, zagląda do odpowiedniego pliku w formacie WSDL i znajduje tam lokalizację serwisu, udostępniane funkcje oraz metody ich wywoływania.
Klient używa opisu w WSDL do sformowania żądania SOAP do żądanego serwisu.
Wydaje się, że najpopularniejsza w zastosowaniu jest Java. Mamy w niej API do XML: (Sun) JAXP (processing), JAXB (binding) , JAXM (messaging), JAXR (refistries) , JAX-RPC.
Istnieje szereg komercyjnych IDE do rozwijania web serwisów. Wśród nich mamy np. odpowiedni moduł VisualAge IBM (dawniej znany jako produkt stand-alone - WSDE - Web Services Development Environment).
Przy użyciu WSDE można łatwo zrobić sobie prosty web serwis, praktycznie nie znając szczegółów SOAP, WSDL, ani nawet XML. Dostarczamy narzędziu klasę typu JavaBean i wskazujemy metody, które chcemy udostępnić. WSDE generuje z tego gotowy do opublikowania opis interfejsu WSDL. Możemy teraz podpiąć ten interfejs do naszego serwera SOAP; jak również wygenerować sobie szkielet klienta; ściślej - klasę stanowiącą "proxy" zwykłe-wywołanie-metody tłumaczącą to na niższy poziom, czyli wywołania/odczyt wyniku SOAP.
Przykład: Dostarczamy klasę StockQuoteService (która będzie skądś wiedziała, jakie są kursy akcji - tu robi to ściągając je z xmltoday.com). IDE generuje opis WSDL, podłącza go pod servlet nasłuchujący/odpowiadający po SOAP na naszym serwerze oraz generuje kod klasy StockQuoteServiceProxy.
Przykład 2: Pod adresem http://www.google.com/apis możemy znaleźć opublikowany niedawno opis i przykłady użycia interfejsu SOAP udostępnionego przez Google.
Oto kod klienta (wywołujący bibliotekę rozmawiającą po SOAP, więc niespecjalnie ciekawy).
Na tym wykładzie omówiłem web services. Web service to usługa, którą można zdalnie wywołać, zwykle za pomocą transportu HTTP. Komunikaty wymieniane przy porozumiewaniu się z web service są zwykle zapisane w standardzie SOAP.
Programista zwykle nie musi w ogóle wiedzieć o tym wszystkim. On a czasem nawet automatyczne narzędzie może na podstawie opisów konkretnego web service w języku WSDL wygenerować odpowiednie pniaki (stubs), które przez swoje pośrednictwo sprawią, że wywołanie web service będzie w programie wyglądało tak jak wywołanie procedury lokalnej. Na wszystkich platformach wygląda to bardzo podobnie.
Opisy usług w WSDL mogą być gromadzone w repozytoriach UDDI.