SOAP jest propozycją standardu komunikacji za pośrednictwem Internetu w aplikacjach rozproszonych. Zaletą rozwiązania Microsoftu jest prostsza implementacja niż w DCOM czy IIOP.

Przy tworzeniu aplikacji rozproszonych jednym z podstawowych zadań projektantów jest zaplanowanie komunikacji różnych fragmentów systemu. Komunikacji, czyli tak naprawdę sieci, jaką informacja będzie przesyłana, i sposobu "pakowania" komunikatów. Obecnie naturalną tendencją są próby wykorzystania do tego celu Internetu.

Nie dla firewalla

Protokół HTTP pozwala na swobodną wymianę danych w Internecie. W tym przypadku wymiana informacji oznacza wysyłanie przez przeglądarkę żądania do serwera, który w odpowiedzi tworzy odpowiednią stronę HTML. Nie jest to jednak taka wymiana danych, jakiej potrzebują aplikacje rozproszone - klient nie może "wywołać procedury" i czekać na wynik.

W związku z tym pojawiło się kilka standardów, które wykorzystują internetowy protokół TCP/IP do zdalnego wywoływania procedur - IIOP/CORBA czy Microsoft DCOM. Oba wykorzystują cechę TCP/IP, która pozwala na użycie różnych portów do przesyłania pakietów. Jednak obecnie większość przedsiębiorstw jest podłączonych do Internetu za pośrednictwem specjalnych programów chroniących wewnętrzne sieci m.in. firewall. Ochrona polega np. na blokowaniu transmisji odbywającej się przy użyciu innych portów niż jest to niezbędne. Gdy zachodzi potrzeba uruchomienia aplikacji opartej na standardzie CORBA, administrator musi pozwolić, by firewall przepuszczał komunikację dodatkowymi portami, co powoduje, że sieć staje się bardziej podatna na ataki z zewnątrz. Rozwiązaniem tego problemu ma być SOAP (Simple Object Access Protocol) - zaproponowany przez Microsoft standard przesyłania żądań wywołania funkcji i otrzymywania wyników za pośrednictwem sieci internetowej. SOAP przesyła informacje w postaci tekstowej, stosując ten sam protokół HTTP, co przeglądarka. Komunikat jest kodowany za pomocą języka XML.

Prosta komunikacja

SOAP to dwa komunikaty - żądanie wywołania funkcji i odpowiedź (wynik działania danej funkcji). Z punktu widzenia aplikacji, program korzystający z SOAP "opakowuje" żądanie wywołania funkcji w standardowy pakiet typu HTTP POST (lub M-POST). Jest to żądanie typu text/xml zgodne z internetowymi regułami RFC. Przy użyciu składni XML, następuje odwołanie do konkretnego obiektu i jego metody, a także przekazanie parametrów. W odpowiedzi klient otrzymuje wynik sformatowany przy użyciu XML.

W standardzie SOAP w zasadzie są zdefiniowane wszystkie potrzebne typy danych (liczby, łańcuchy znaków, w tym UNICODE, typy określające datę i czas). Microsoft proponuje ciekawy sposób rozwiązania problemu z przekazywaniem dużych struktur danych czy olbrzymich tablic. SOAP pozwala, by przy wywołaniu funkcji zostały określone np. tylko niezerowe elementy tablicy czy wykorzystane elementy struktury. W ten sposób przez Internet są przekazywane tylko niezbędne informacje.

SOAP pozwala zarówno na komunikację, gdzie wymagane jest potwierdzenie, jak i na pracę asynchroniczną, gdy do serwera wysyłane jest żądanie, a klient później otrzymuje wynik.

XML i bezpieczeństwo

Dzięki temu, że do kodowania komunikatów wykorzystano XML, została ułatwiona współpraca między różnymi produktami. Jest możliwość, by wywołanie określonej funkcji zostało przekształcone w nieco inne żądanie i w rzeczywistości wywołano nowszą wersję np. z dodatkowymi parametrami.

XML pozwala jednocześnie, by SOAP był zupełnie oddzielony od modelu obiektowego (w zasadzie nie jest wymagane, by aplikacja korzystała z obiektów). W rzeczywistości konieczne jest tylko zaprojektowanie odpowiedniej hierarchii wewnątrz aplikacji. SOAP nie nakłada w tym zakresie prawie żadnych ograniczeń. Nic nie stoi na przeszkodzie, by komunikat zawierał definicję modelu, czyli by był w pewnym sensie "samoopisującym się" komunikatem! Pozwala to na efektywną współpracę SOAP i technologii BizTalk (standard obsługi dokumentów XML proponowany przez Microsoft - CW 40/99).

Komunikacja w SOAP opiera się na przesyłaniu tekstu za pomocą standardowego portu HTTP. Toteż nie jest konieczne odblokowywanie dodatkowych portów czy stosowanie innych zabezpieczeń niż te, które są na co dzień używane w serwerach WWW. Co więcej, ze względu na to, iż SOAP korzysta z HTTP, serwer może przekierować żądanie wywołania funkcji w inne miejsce, a serwer proxy może przyspieszać komunikację.

Przyszłość DCOM i SOAP

Obecnie dostępna jest specyfikacja SOAP 0.9. Mimo że inicjatywa wyszła ze strony Microsoftu, to nad SOAP pracuje wiele różnych firm. W swoich aplikacjach wykorzystują go m.in. DevelopMentor (powstał Perl, który może korzystać z tego standardu), Rogue Wave i wielu producentów związanych z technologią CORBA, gdzie do komunikacji między zdalnymi obiektami zamiast IIOP będzie wykorzystywany znacznie prostszy SOAP.

Zarówno IIOP, jak i DCOM są bardziej rozbudowanymi technologiami niż SOAP. Ta ostatnia pozwala przesyłać żądania. DCOM/IIOP ma ponadto wbudowane mechanizmy zdalnego tworzenia i usuwania obiektów, pewne elementy automatycznego zwalniania pamięci czy, co najważniejsze, programiści korzystający z tych technologii mają możliwość zapamiętania stanu klienta po stronie serwera. W SOAP serwer nie zbiera danych o kliencie.

DCOM i IIOP pozwalają na utworzenie "nierozerwalnego" połączenia między zdalnymi obiektami. W pewnym sensie jest to ich wadą, ponieważ znaczna część kodu aplikacji to fragmenty poprawnie obsługujące sytuacje, gdy komunikacja między obiektami zostanie przerwana. Niewątpliwą zaletą SOAP jest łatwość implementacji tego protokołu, co nie wymaga zbyt dużych nakładów pracy programisty. Microsoft planuje w pakiecie narzędziowym Visual Basic 7.0 wprowadzić gotowe narzędzia do korzystania z SOAP. Jednak nie należy oczekiwać, że Microsoft zrezygnuje z rozwoju technologii DCOM. SOAP i DCOM raczej się uzupełniają, a są przeznaczone dla innego rodzaju aplikacji.