Specyfikację IBM, Microsoftu, BEA i Tibco, związaną z gwarantowanym dostarczaniem wiadomości, opublikowano w dwa tygodnie po tym, jak OASIS sformowała komitet techniczny Web Services - Reliable Messaging (WS-RM), który ma pracować nad niemal identyczną specyfikacją.

IBM, Microsoft i ich partnerzy zignorowali fakt, że do 11 marca miały złożyć deklarację co do wspólnych prac prowadzonych przez Fujitsu, Hitachi, Oracle, NEC, Sonic Software i Sun, publikując specyfikacje

WS-Reliable Messaging (tej samej nazwy używa OASIS) i WS-Addressing. Oba protokoły mają zapewniać dostarczanie wiadomości między aplikacjami, oddzielonych pewną liczbą pośredników lub dystrybutorów, działających na różnorodnych platformach. Każda z tych specyfikacji jest pewnym rozszerzeniem SOAP i może być używana w dowolnej technice transportowej, takiej jak HTTP. Brak standardowych protokołów w zakresie niezawodności, bezpieczeństwa, zarządzania i przepływu procesów biznesowych to główne powody powolnego upowszechniania się web services przy integrowaniu systemów zewnętrznych.

W kwietniu ub.r. Microsoft, IBM i VeriSign opracowały specyfikację WS-Security, która jest teraz na ścieżce standaryzacyjnej w OASIS. Drugim przykładem jest wspomniana BPEL4WS.

Prace nad gwarantowanym messagingiem powtarzają ten sam schemat: wprowadzenie niezależnej specyfikacji i zabieganie o poparcie dla niej przed przekazaniem do organizacji standaryzacyjnej.

WS-Reliable Messaging zaproponowana przez IBM/Microsoft wykorzystuje podstawowe założenia przyjęte w OASIS, określające trzy typy niezawodnego dostarczania:

• gwarantowane dostarczenie, oznaczające dostarczenie wiadomości co najmniej raz;

• dostarczanie eliminujące duplikowanie, które zapewnia wyłącznie jednokrotne dostarczenie wiadomości;

• sekwencjonowanie wiadomości, określające porządek dostarczania wiadomości.

IBM/Microsoft dołączył jednak kolejny poziom funkcjonalności, wprowadzając specyfikację WS-Addressing, która zawiera także wyniki prac prowadzonych przez BEA Systems.

WS-Addressing ma zapewniać ciągłą wiedzę o nadawcy i odbiorcy wiadomości, gdy przechodzi ona przez zapory ogniowe, bramy i różne technologie transportowe w drodze od nadawcy do odbiorcy. Specyfikacja może być też używana do określania, jak, kiedy i czy system musi potwierdzać pomyślne przekazanie wiadomości w kolejnym węźle drogi, którą przebywa.

W ubiegłym roku tandem IBM/Microsoft stał się główną siłą w projektowaniu standardów protokołowych, które wypełniają podstawowe luki w web services, obejmujące niezawodność, bezpieczeństwo i przepływ procesów biznesowych. Firmy te stworzyły także Web Services Interoperability Organization (WS-I), która oferuje porady, jak projektować współdziałające usługi webowe.

IBM i Microsoft zapewniają jednocześnie, że proponują protokoły, które mają pomagać ich klientom w integrowaniu produktów, ale celem głównym jest standaryzacja. Przedstawiciele Microsoftu twierdzą, że prace nad niezawodnym messagingiem są prowadzone od ponad roku i były tak blisko ukończenia, że zdecydowano się na ich kontynuowanie zamiast przyłączenia się do WS-RM.

Jednak członkowie zignorowanego przez IBM/Microsoft komitetu OASIS widzą sprawę inaczej. W ich opinii prowadzenie takiej polityki przez głównych dostawców jest niefortunne. Firmy Sonic Software, Fujitsu, Hitachi, Oracle, NEC i Sun stworzyły podstawy wspólnej specyfikacji dla komitetu technicznego OASIS (WS-RM). Użytkownicy oczekują ścisłej kooperacji dostawców, a nie rywalizacji przy tworzeniu standardów, prowadzącej do braku współdziałania produktów, i w związku z tym ograniczenia - upowszechniania nowej technologii. Uważają, że prace standaryzacyjne powinny być prowadzone w ramach organizacji standaryzacyjnych.