SOAP — omówienie

Aaron Skonnard
DevelopMentor

marzec 2003 roku

Dotyczy:
   Architektura Global XML Web Services Architecture (GXA)
   Zdalne wywoływanie procedur (RPC)
   Specyfikacje SOAP 1.1 i SOAP 1.2
   Protokoły transportowe: TCP, HTTP, SMTP oraz MSMQ
   Rozszerzenia WSE (Web Services Enhancements 1.0 SP1 for Microsoft® .NET)
   Schematy XML

Streszczenie: SOAP zapewnia prostą, rozszerzalną i wszechstronną infrastrukturę do wymiany komunikatów XML, którą można wykorzystać przy definiowaniu wyższego poziomu protokołów warstwy aplikacji, umożliwiających większą interoperacyjność w rozproszonych środowiskach heterogenicznych.
Długość dokumentu — około 16 stron drukowanych.

Spis treści

Wprowadzenie
Wersje SOAP
Infrastruktura komunikacyjna
Rozszerzalność
Model przetwarzania
Wiązanie SOAP do różnych protokołów
Wiązanie do HTTP
RPC i kodowanie
Sposoby stosowania SOAP
Podsumowanie

Wprowadzenie

Wydaje się, że jeszcze wczoraj określenie SOAP kojarzyło się tylko z produktami chemii gospodarczej. Teraz większość programistów, gdy tylko usłyszy to słowo, od razu widzi oczami wyobraźni nawiasy trójkątne. SOAP to skrót od nazwy Simple Object Access Protocol (prosty protokół dostępu do obiektów). Kilka lat temu na pytanie o to, czym jest SOAP, uzyskalibyśmy zapewne odpowiedź, że „jest to technika umożliwiająca komunikację DCOM i CORBA (np. wywołania RPC) przez Internet”. Autorzy oryginalnej specyfikacji SOAP przyznają, że na początku koncentrowali się wyłącznie na „dostępie do obiektów”, jednak po pewnym czasie okazało się, że pożądane jest szersze zastosowanie SOAP. Dlatego specyfikacja szybko zaczęła obejmować bardziej ogólną infrastrukturę do przesyłania komunikatów XML.

Rozszerzenie obszaru zastosowań spowodowało małą niekonsekwencję związaną z występowaniem litery „O” w skrótowcu SOAP. Grupa rozwijająca SOAP 1.2 pozostała (jak na razie) przy nazwie SOAP (jak mogliby zmienić tak popularną nazwę?), ale zdecydowała, że skrótu nie należy rozwijać, ponieważ mogłoby to wprowadzać programistów w błąd. W obecnej oficjalnej definicji, jaką można znaleźć w najnowszej specyfikacji SOAP 1.2, nie ma nawet słowa o obiektach:

SOAP to prosty protokół, który ma służyć do wymiany ustrukturyzowanych informacji w zdecentralizowanym, rozproszonym środowisku. SOAP wykorzystuje technologie XML do definiowania rozszerzalnej infrastruktury komunikacyjnej określającej strukturę komunikatów, które mogą być wymieniane za pośrednictwem różnych protokołów. Infrastruktura ta ma być niezależna od wszelkich modeli programowania oraz innych semantyk, specyficznych dla poszczególnych implementacji.

Definicja ta naprawdę dobrze opisuje, czym SOAP jest teraz. SOAP definiuje sposób przekazywania komunikatów XML z punktu A do punktu B (ilustracja 1). Dokonuje tego, zapewniając bazującą na XML infrastrukturę komunikacyjną, która cechuje się:

1)      rozszerzalnością,

2)      możliwością zastosowania wielu różnych protokołów sieciowych,

3)      niezależnością od zastosowanego modelu programistycznego.

Każdej z tych cech przyjrzymy się bliżej w dalszej części dokumentu.

Ilustracja 1. Proste przekazywanie komunikatów SOAP

Pierwsza cecha — rozszerzalność SOAP — jest cechą bardzo ważną. Gdy skrót był rozwijany, litera „S” odpowiadała słowu „Simple” (prosty). Obserwując Internet mogliśmy nauczyć się, że prostota zawsze wygrywa z wydajnością lub puryzmem technicznym, a gdy w grę wchodzi interoperacyjność, to prostota jest wręcz nieodzowna. Dlatego prostotę postawiono jako jeden z głównych celów projektowych, na co dowodem jest brak w SOAP różnych funkcji systemów rozproszonych, takich jak bezpieczeństwo, ruting i wiarogodność. SOAP definiuje infrastrukturę komunikacyjną, do której takie funkcje mogą zostać w prosty sposób włączone jako warstwy rozszerzeń. Microsoft, IBM oraz inni producenci oprogramowania aktywnie pracują nad wspólnym zestawem rozszerzeń SOAP, które wzbogaciłyby standard o wiele najbardziej oczekiwanych funkcji. Inicjatywa ta nosi nazwę Global XML Web Services Architecture (GXA). Microsoft udostępnił już referencyjne wersje implementacji kilku specyfikacji składających się na architekturę GXA. Implementacje te dostępne są jako rozszerzenia Web Services Enhancements for Microsoft .NET (rozszerzenia WSE).

Druga cecha — SOAP może być stosowany z dowolnym protokołem transportowym, takim jak TCP, HTTP, SMTP lub nawet MSMQ (ilustracja 1). Jednak — aby zachować interoperacyjność — konieczne jest zdefiniowanie standardowych wiązań protokołów, które określałyby reguły dla każdego środowiska. Specyfikacja SOAP zapewnia elastyczną infrastrukturę do definiowania wiązań protokołów i jawnie definiuje wiązanie do protokołu HTTP, ponieważ protokół ten jest najszerzej stosowany.

Cecha trzecia — SOAP umożliwia stosowanie dowolnego modelu programistycznego i nie jest związany z RPC. Wielu programistów uważa, że SOAP to wykonywanie wywołań RPC do rozproszonych obiektów (ponieważ początkowo miał to być protokół „dostępu do obiektów”). Tak naprawdę podstawowy model SOAP jest bardziej podobny do tradycyjnych systemów przekazywania komunikatów, takich jak MSMQ. SOAP definiuje model jednokierunkowego przetwarzania pojedynczych komunikatów. Połączenie wielu komunikatów daje już wymianę komunikatów. Na ilustracji 1. przedstawiono proste jednokierunkowe przekazanie komunikatu, gdzie nadawca nie otrzymuje odpowiedzi. Odbiorca może jednak wysłać odpowiedź do nadawcy (jak pokazano to na ilustracji 2). SOAP umożliwia stosowanie dowolnej liczby wzorców wymiany komunikatów (message exchange pattern — MEP), a wzorzec żądanie/odpowiedź (request/response) to tylko jedna z wielu możliwości. Inne przykłady wzorców to: zaproszenie/odpowiedź (solicit/response — serwer wysyła zaproszenie a klient wysyła odpowiedź; jest to odwrotność standardowego wzorca żądanie/odpowiedź), powiadomienia (notification) oraz długa wymiana komunikatów pomiędzy systemami peer-to-peer.

Ilustracja 2. Wzorzec wymiany komunikatów żądanie/odpowiedź

Programiści często mylą wzorce wymiany komunikatów żądanie/odpowiedź i RPC, chociaż są one dosyć różne. RPC korzysta co prawda ze wzorca żądanie/odpowiedź, ale wymiana komunikatów żądanie/odpowiedź nie zawsze jest wymianą RPC. RPC to model programistyczny, umożliwiający programistom wywoływanie metod. RPC wymaga przetłumaczenia sygnatury metody na komunikaty SOAP. Ze względu na popularność RPC, specyfikacja SOAP uwzględnia stosowanie RPC wraz z protokołem SOAP (więcej na ten temat znajduje się w sekcji RPC i kodowanie dalej w tym artykule).

Charakteryzująca się tymi trzema głównymi cechami infrastruktura komunikacyjna SOAP umożliwia wymianę komunikatów XML w środowiskach heterogenicznych, w których problem interoperacyjności od dawien dawna stanowił ogromne wyzwanie.

Wersje SOAP

Od opublikowania pierwszej specyfikacji SOAP do szeroko implementowanej obecnej wersji SOAP 1.1 wiele rzeczy uległo zmianie, począwszy od małych szczegółów do dużych zmian ideologicznych. SOAP 1.1 został zgłoszony do konsorcjum W3C i opublikowany jako nota w maju 2000 roku. Status noty w konsorcjum W3C oznacza, że SOAP 1.1 nie jest niczym więcej niż dobrym pomysłem, ponieważ nie przeszedł rygorystycznych procesów kwalifikacji standardów internetowych, których spełnienie pozwoliłoby uzyskać status zalecenia. Mimo tego — ze względu na szerokie stosowanie zarówno przez dużych, jak i małych producentów — SOAP 1.1. jest de facto uznawany za standard.

Konsorcjum W3C wykorzystało notę SOAP 1.1 jako punkt wyjścia dla nowego zespołu XML Protocol Working Group, odpowiedzialnego za opracowanie kolejnej wersji SOAP, oznaczonej SOAP 1.2. SOAP 1.2 ma obecnie status kandydata na zalecenie, co oznacza, że jest w fazie implementacji i niewiele brakuje do ukończenia prac nad protokołem. Gdy SOAP 1.2 stanie się zaleceniem, to zapewne szybko uzyska wsparcie producentów.

Po wprowadzeniu SOAP 1.2 producenci powinni zadbać o to, by SOAP 1.1 nadal ...