WEB SERVICES

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, rejstró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

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-a oraz HTTP jako mechanizmów wywoływania metod. Specyfikacja SOAP-a określa kilka rodzajów nagłówków HTTP ułatwiających filtrację firewall-om i proxy. Definiuje także słownik znaczników XML-owych 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.
http://www.w3.org/TR/soap12/

Czemu nie jakieś typu DCOM/CORBA, tylko coś nowego?

Wbrew pozorom nie uważam, że jest to kretyńskie pytanie. Myślę, że jest coś na rzeczy w kwestii popularności XML-a (złośliwe), ale też jego tekstowości, ogólności, no i jest też kwestia wielu stubów z CORBY 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 firewalli i serwerów proxy blokuje przepływ tego typu informacji (równie kiepski - czemu nie można zrobić CORBy na porcie 80).

struktura SOAP-komunikatu

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>

Ogólne zasady:

Obsługa błędów:

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>

Bezpieczeństwo

SOAP jako, że używa HTTP jako protokołu transportu, jest bezstanowy.

Nie implementuje bezpieczeństwa. Transport przez HTTP pozwala jednak na zastosowanie SSL-a 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.

Metajęzyk WSDL

Specyfikacja definiuje następnie język opisu interfejsu SOAP serwera zwany WSDL.

Format WSDL jest również XML-owy.

Przypominam: po stworzeniu serwisu możemy opublikować jego opis i umieścić odwołanie do tego opisu w repozytorium (UDDI, patrz dalej) 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-u do sformowania żądania SOAP do żądanego serwisu.

Implementacja

Wydaje się, że najpopularniejsza w zastosowaniu jest Java. Mamy w niej API XML-owe:
(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'a (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-a, WSDL-a, ani nawet XML-a. 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.

schemat generacji kodu przy użyciu WSDE.

Kod klienta (wywołujący bibliotekę rozmawiającą po SOAP, więc niespecjalnie ciekawy).

Informacje:

Jacek Fiok