Epistoły od szablonu

W części, związanej z komunikatami, wymagania zgodności z profilem podstawowym są podzielone na trzy grupy. Pierwsza z nich dotyczy sposobu formatowania komunikatu i precyzuje takie zagadnienia, jak kodowanie tekstu komunikatu czy sposób przedstawienia informacji o błędach (atrybut soap:Fault), a także wykorzystania przestrzeni nazw (namespace).

Profil podstawowy WS-I ogranicza zestaw podelementów w ramach elementu soap:Fault tylko do tych, które są zdefiniowane w specyfikacji SOAP 1.1, czyli faultcode, faultstring, faultactor i detail. Ta sama zasada obowiązuje w przypadku wartości elementu faultcode - powinny być one ograniczone do tych, które są wymienione w specyfikacji.

Na potrzeby uszczegółowienia informacji o błędach, np. w celu poinformowania o wyjątku, który wystąpił podczas obsługi żądania, WS-I nie zaleca stosowania notacji "kropkowej". Zamiast niej sugeruje używanie elementu detail, do którego można dodawać własne atrybuty i elementy. Lista ograniczeń w dziedzinie komunikatów jest dłuższa. Komunikat nie powinien np. zawierać deklaracji DTD lub instrukcji przetwarzania (Processing Instructions). Ponadto atrybut soap:Envelope komunikatu nie powinien zawierać żadnych elementów typu "potomek" umieszczonych po atrybucie soap:Body.

Drugi podrozdział wymagań w dziedzinie komunikatów zawiera wymagania co do sposobu przetwarzania komunikatu. Precyzuje, jak mają być przetwarzane nagłówki i sposób obsługi błędów. Profil podstawowy wymaga, aby przed rozpoczęciem przetwarzania komunikatu usługa sprawdziła wszystkie jego obowiązkowe nagłówki, tj. takie, których atrybut soap:mustUnderstand ma wartość 1. W przypadku wystąpienia nagłówka obowiązkowego, którego usługa Web nie jest w stanie zinterpretować, profil podstawowy wymaga wygenerowania i wysłania do usługi inicjującej komunikatu o błędzie. W tym przypadku dalsza obróbka żądania musi być zaniechana oraz musi być wysłany komunikat o błędzie.

Wymagania z trzeciej części precyzują wykorzystanie protokołu SOAP z protokołem HTTP jako warstwą transportową. Po pierwsze, zabrania się m.in. użycia mechanizmu rozszerzeń HTTP Extension Framework, jak również nie zaleca się używania mechanizmu HTTP Cookies do zarządzania sesją - jego użycie jest dopuszczalne tylko w drodze wyjątku, do integracji z już istniejącymi aplikacjami wykorzystującymi ten mechanizm.

Profil podstawowy precyzuje sposób posługiwania się mechanizmem statusów HTTP. Grupa kodów statusu 2xx jest używana do informowania o sukcesie, grupa 3xx - do informowania o przekierowaniu, grupa 4xx - do sygnalizowania błędów klienta, zaś grupa 5xx - do sygnalizowania błędu serwera. Ze względu na fakt, że kod statusu HTTP może być zmieniony w trakcie komunikacji, tylko komunikaty zawierające atrybut soap:Fault mogą być traktowane jako komunikaty o błędzie w usłudze Web.

Rady dla niepokornych

W rozdziale poświęconym opisom usług Web profil podstawowy dzieli wymagania na siedem grup.

1) Struktura dokumentu. Profil powołuje się tu na poprawione wersje schematów dla WSDL - w oryginalnej wersji specyfikacji WSDL 1.1 są bowiem nieścisłości pomiędzy podanymi w załącznikach schematami a tekstem specyfikacji. Do importu opisów można posłużyć się wyłącznie atrybutem wsdl:import. Profil wyjaśnia też nieścisłości w WSDL 1.1 odnośnie do umiejscowienia elementu wsdl:documentation. Profil podstawowy zaleca ostrożne podejście do rozszerzeń WSDL, ponieważ mogą one wywoływać konflikty z innymi wymaganiami profilu. Profil podstawowy postuluje ponadto, aby korzystać tylko z tych rozszerzeń, które zostały zdefiniowane w jednym z profilów WS-I. Odradza też nadawanie rozszerzeniom atrybutu obowiązkowości.

2) Typy (element wsdl:types). W tym miejscu profil podstawowy precyzuje głównie sposób deklaracji dla struktur danych typu array.

3) Komunikaty abstrakcyjna definicja komunikatu (wsdl:message) oraz jej przywiązanie (wsdl:binding) do protokołu. Zaleca się, aby wszystkie atrybuty definicji abstrakcyjnej były mapowane na protokół SOAP. Profil wyjaśnia także, z ilu elementów składowych wsdl:part może składać się komunikat oraz w jaki sposób powinny być one definiowane.

4) Typy portów (element wsdl:portType). Ten podrozdział wskazuje m.in. że kolejność elementów w komunikacie musi być taka jak w opisie. Zabrania się użycia typów operacji Solicit-Response oraz Notification ze względu na ich nie do końca pełną definicje oraz ich brak w specyfikacji WSDL 1.1. Zabrania się także przykrywania (overloading) operacji w ramach danego typu portu, co oznacza, że nazwy operacji powinny być unikatowe.