WS-I Basic Profile daje wskazówki, jak należy stosować specyfikacje - takie jak SOAP, XML czy UDDI - aby zapewnić możliwość projektowania współdziałających ze sobą web services.

BSPWG ma też się zająć zagadnieniami współdziałania, obejmującymi w szczególności bezpieczny transport i bezpieczeństwo messagingu SOAP.

Będzie także odpowiedzialna za opracowanie scenariuszy użytkowania i odpowiadających im wzorców wymiany informacji (MEP - Message Exchange Patterns). MEP jest szablonem przekazywania wiadomości między dwoma stronami używającymi web services.

BSPWG formuje się od listopada ub.r. W tym czasie stworzono (w ramach WS-I) Basic Security Work Plan Working Group z zadaniem zidentyfikowania i uszeregowania kluczowych dla współdziałania usług webowych spraw związanych z bezpieczeństwem. Grupa ta przedstawiła ustalenia i rekomendacje na niedawnej plenarnej sesji organizacji.

WS-I jest jedną z grup branżowych, której celem jest promowanie otwartych standardów współdziałania web services w różnych platformach, aplikacjach i językach programowania. W jej skład wchodzą takie firmy, jak BEA Systems, Hewlett-Packard, IBM, Intel, Microsoft, Oracle, SAP i od niedawna Sun Microsystem.

Inne grupy zajmujące się standaryzacją web services to: OASIS (Organization for the Advancement of Structured Information Standards), W3C (World Wide Web Consortium) i Liberty Alliance.

Web services a zarządzanie ruchem

Wielu internautów denerwuje fakt, że przebieg typowej sesji przeglądarki często polega na długich przerwach.

Generacja web services, oparta na XML i SOAP (Simple Object Access Protocol), nie jest jednak zasadniczo szybsza czy bardziej niezawodna. Powodem tego stanu jest to, iż XML i SOAP są "nowym towarem w starym opakowaniu", bo transport odbywa się za pośrednictwem HTTP. Protokół ten nie zawiera standaryzowanych mechanizmów zapewniających gwarantowane i punktualne dostarczenie zawartości - HTML, XML, strumieni wideo czy cokolwiek innego - z serwera do klienta. HTTP dostarcza dane w ten sposób, że każdy ruter pośredniczący podejmuje próby wyekspediowania pakietu do optymalnie najbliższego węzła, ale droga pokonywana przez różne pakiety jest poza kontrolą jakichkolwiek węzłów. Web services nie będą gotowe do masowego stosowania w sieciach przedsiębiorstwa dopóty, dopóki nie zapewni się odpowiednich narzędzi, standardów i rozwiązań do zarządzania ruchem, zapewniających przewidywalne osiągi w układzie end-to-end.

Na razie powszechnie nie wykorzystuje się możliwości wiązania SOAP z czymkolwiek innym niż HTTP, np. protokołami warstwy pośredniczącej, takimi jak Java Message Service czy MQSeries, obsługującymi gwarantowane dostarczanie wiadomości.

Mimo to pojawiają się interesujące rozwiązania przyśpieszające i skalujące dostarczanie ruchu HTML i XML/SOAP przez HTTP, bez naruszania podstaw protokołów transportowych. Najbardziej obiecujące techniki zarządzania ruchem web services w układzie end-to-end to buforowanie zawartości i tzw. choreografia. Dotąd jednak nie dokonano odpowiedniej konwergencji standardów, niezbędnej do współdziałania między różnorodnymi rozwiązaniami zarządzania ruchem, pochodzącymi od różnych dostawców. Dopóki dostawcy nie wypracują uzgodnień, dopóty efektywne globalne zarządzanie ruchem w web services będzie nieosiągalne.

Infrastruktura buforująca - która staje się elementem krytycznym w dostarczaniu zawartości HTML, FTP czy innej formy statycznej - w coraz większym stopniu będzie stosowana z bazami danych zawartości dynamicznej. Jednak standardów buforowania weba jest zbyt wiele, a dostawcy rozwiązań buforujących implementują zarówno własne, jak i otwarte specyfikacje.