Protokół SOAP łączy odmienne aplikacje

W architekturze sieci przedsiębiorstw zaczyna dominować model rozproszony, w którym inteligencja jest lokowana w urządzeniach i komputerach tworzących sieć, a nie jak dotąd centralnie - w jednym systemie. Dzieje się tak, ponieważ pojawiają się różnorodne urządzenia, wyposażone w rozmaite języki i systemy operacyjne obsługujące tysiące aplikacji.

W architekturze sieci przedsiębiorstw zaczyna dominować model rozproszony, w którym inteligencja jest lokowana w urządzeniach i komputerach tworzących sieć, a nie jak dotąd centralnie - w jednym systemie. Dzieje się tak, ponieważ pojawiają się różnorodne urządzenia, wyposażone w rozmaite języki i systemy operacyjne obsługujące tysiące aplikacji.

Protokół SOAP łączy odmienne aplikacje

Jak to działa?

Aby te urządzenia efektywnie i wydajnie współpracowały, należy użyć wspólnego dla nich języka. Jednym z wcześniej opracowanych, obecnie dominującym jest protokół SOAP (Simple Object Application Protocol).

Protokół ten definiuje dwie struktury opracowane przez W3C (World Wide Web Consortium). Pierwsza z nich opisuje sposób kodowania danych przy użyciu zbioru zdefiniowanych typów danych. Jeśli zbiór ten jest nieodpowiedni, to użytkownik może zdefiniować własne typy danych.

Druga opisuje ogólny format komunikatów protokołu SOAP. Definiuje również wbudowane sposoby rozszerzenia formatu komunikatu do obsługi aplikacji tworzonych na zamówienie. Opracowywana przez W3C specyfikacja protokołu SOAP definiuje również, jak używać protokołu HTTP do wysyłania i odbierania komunikatów SOAP. Chociaż komunikaty te można przesyłać korzystając z dowolnego protokołu, to jednak w większości aplikacji wykorzystuje się protokół HTTP.

Teoretycznie protokołu SOAP można użyć do przekazywania pomiędzy dwiema aplikacjami prawie wszystkich rodzajów danych. W praktyce używa się RPC (Remote Procedure Calls). W przypadku kodowania RPC SOAP jest protokołem typu żądanie/odpowiedź.

Aplikacja koduje żądanie RPC w komunikacie SOAP i wysyła je do zdalnego systemu. Żądanie identyfikuje wymaganą operację i definiuje jej parametry. W odpowiedzi zdalny system wysyła komunikat zwrotny SOAP, który zawiera wynik operacji.

Protokół SOAP, opierając się na XML, jest niezależny zarówno od języka, jak i od platformy. Obie aplikacje można napisać w różnych językach i uruchomić w środowisku różnych systemów operacyjnych.

SOAP ma wiele zalet wynikających z alternatywnych sposobów kodowania wywołań RPC. Otwartość języka XML oraz ogólna dostępność analizatorów jego składni ułatwiają pisanie aplikacji używających protokołu SOAP.

Stosowane w wywołaniach RCP tradycyjne kodowanie XDR (External Data Representation) nie jest wykorzystywane nigdzie poza RPC. Z tego względu kodery XDR nie są dostępne na wielu platformach. Wezwanie RMI (Remote Method Invocation) jest powiązane z językiem Java i nie może być używane, jeśli w sieci są aplikacje nie obsługiwane przez ten język.

Protokół SOAP ma przejrzystą konstrukcję i łatwo się go stosuje. Do wywołań RPC można również wykorzystać specyfikację CORBA (Common Object Request Broker Architecture), ale jest to protokół trudny do użycia - wprost zabójczy dla aplikacji typu RCP. CORBA ma również trudności z przenikaniem przez zapory ogniowe, ponieważ nie używa HTTP jako swojego protokołu transportowego. Para XML-RPC była prekursorem protokołu SOAP. Chociaż jest bardzo użyteczna dla prostych aplikacji RPC, to brak jej elastyczności SOAP. XML-RPC nie dopuszcza używania typów danych definiowanych przez użytkownika, komunikaty XML-RPC nie mogą być rozszerzane do obsługi specyficznych aplikacji.

Protokół SOAP ma jednak kilka wad. Kodowanie danych protokołu SOAP jest mało wydajne. Komunikaty są kodowane w formie tekstu, co sprawia, że są nieefektywne. Ponadto komunikaty te wykorzystują więcej pasma niż równoważne komunikaty binarne. Po przyjęciu komunikaty SOAP muszą być przekształcane do postaci binarnej, by aplikacja mogła na nich działać. Do rozwiązania tego problemu opracowujący aplikacje mogą używać gotowych analizatorów składni XML. Pociąga to za sobą konieczność włączenia tych analizatorów do aplikacji, co prowadzi do rozbudowania tych ostatnich i zwiększenia obciążenia CPU.

Jeśli od aplikacji nie wymaga się niezależności od platformy i jeżeli nie ma ograniczeń na pasmo, to użycie protokołu SOAP może nie być najlepszym rozwiązaniem. Jednak protokół ten staje się wszechobecny na wielu różnych platformach. Jeśli więc przewidujemy rozpowszechnianie aplikacji na wielu różnych platformach, to SOAP jest najlepszy wyborem.


TOP 200