Packaging

Jest to warstwa wymiany danych, która odbywa się poprzez TCP/IP na porcie 80 wykorzystując jak wyżej wspomniałem 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.

XML-RPC

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: 19980717T14: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.

POST /server.php
HTTP/1.0 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031031
Host: services.php.pl
Content-Type: text/xml
Content-length: 181
 <?xml version="1.0"?>
 <methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
  <param>
  <value>
  <i4>41</i4>
  </value>
  </param>
  </params>
 </methodCall>

Z tego przykładu można odczytać, że chcemy wywołać metodę getStateName obiektu examples z parametrem typu integer o wartości 41.

HTTP/1.1 200 OK
Connection: close
Content-Length: 158
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: services.php.pl XML-RPC server
 <?xml version="1.0"?>
 <methodResponse>
  <params>
  <param>
  <value>
  <string>South Dakota</string>
  </value>
  </param>
  </params>
 </methodResponse>

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.

Przyjrzyjmy się teraz implementacjom 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

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 "malych rozmiarow" 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.

Trzeba także zaznaczyć, ze SOAP wspierany jest min. przez Microsoft na platformie .NET i dlatego właśnie będzie się wciąż rozwijał i tak szybko nie umrze.

Przyjrzyjmy się jednak bliżej protokołowi SOAP.

Głównym elementem SOAP'a jest "blok wiadomości" - message. Zawiera on następujące elementy:

1. Element opakowania - envelope - identyfikuje on SOAP'a. Zawiera on także następujące przestrzenie nazw:
   • dla envelope: http://www.w3.org/2001/12/soap-envelope
   • dla kodowania: http://www.w3.org/2001/12/soap-encoding
2. Opcjonalnie nagłówek - header
3. Element ciała SOAP - body - znajdują się w nim wywołania jak i odpowiedzi serwera.
4. Opcjonalny element błędów - fault - dostarczający informacje o błędach, które powstały podczas przetwarzania wiadomości.

Przykład szkieletu SOAP'a znajduje się poniżej. Jak widać przypomina on trochę budowę strony XHTML.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
       

<soap:Header>
...
</soap:Header>
      
 

<soap:Body>
...
 <soap:Fault>
 ...
 </soap:Fault>
</soap:Body>
       

</soap:Envelope>

Przyjrzyjmy się teraz dokładniej poszczególnym elementom SOAP'a.

Envelope

Envelope jest głównym elementem SOAP'a. Definiuje on nam ten protokół. Zawiera on dwie przestrzenie nazw:

xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"

Jak pierwsza przestrzeń musi zawierać podane wyżej URI, tak druga (soap:encoding) nie może zawierać innego adresu niż ten z przykładu.

<?xml version="1.0"?>
 <soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 ...
 </soap:Envelope>

Header zawiera opis wiadomości SOAP. Jest on opcjonalny, lecz gdy już się pojawi musi on być pierwszym podelementem w elemencie envelope.

<env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
  <t:Transaction xmlns:t="http://example.org/2001/06/tx" env:mustUnderstand="true" >
  5
  </t:Transaction>
 </env:Header>

W przykładzie podany jest atrybut mustUnderstand. Ustawienie go na 1/true oznacza, że parser odpowiedzialny za przetworzenie headera musi rozpoznać ten element, w przeciwnym razie ma zwrócić błąd.

Body

Element body jest główną częścią SOAP'a, to tutaj podawane są "rozkazy" serwisowi jak i zwracane jego odpowiedzi.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
       

<soap:Body>
 <m:GetLoginName xmlns:m="http://php.pl/login">
 <m:Item>42</m:Item>
 </m:GetPrice>
</soap:Body>
       

</soap:Envelope>

W przykładzie widzimy, że wywołujemy metodę GetLoginName z parametrem 12.

Odpowiedź serwera SOAP może być następująca:

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
       

<soap:Body>
 <m:GetLoginNameResponse xmlns:m="http://php.pl/login">
 <m:LoginName>Seth</m:LoginName>
 </m:GetPriceResponse>
</soap:Body>
      
 

</soap:Envelope>

W odpowiedzi dostaliśmy wartość, która jest nazwą loginu dla podanego ID.

Fault

Element fault zawiera informacje o błędach. Jest on zawsze elementem body i może się pojawić tylko raz w "wiadomości".

Elementy fault zawiera następujące elementy:

• <faultcode> - kod błędu. Dostępne kody błędów to:
  • VersionMismatch ? błąd określający niepoprawną przestrzeń nazw w elemencie envelope
  • MustUnderstand - jeżeli ustawiliśmy w headerze wartość mustUnderstand na 1, a serwer nie rozpoznał nagłówków, zwracany jest właśnie ten błąd
  • Client - wiadomość SOAP wysłana od klienta była niepoprawna
  • Server - wystąpił błąd na serwerze, dlatego wiadomość nie mogła zostać obsłużona
• <faultstring> - tekst błędu
• <faultactor> - informacja o tym kto/co spowodowało błąd
• <detail> - szczegóły błędu

Implementacje w PHP

Przyjrzyjmy się niektórym implementacjom SOAP'a 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.

nuSOAP jest to dobrze udokumentowana implementacja, która cały czas się rozwija co dobrze wrózy 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.

Dlatego też jeżeli chcemy użyć Web Services do prostych zastosowań takich jak np. udostępnianie artykułów czy innych danych najlepiej użyć XML-RPC, a w poważniejszych zastosowaniach wymagających min. komunikacji z innymi aplikacjami wykorzystującymi SOAPa odpowiedź nasuwa się sama ;)