Nowa generacja web services, oparta na XML i SOAP (Simple Object Access Protocol), nie jest zasadniczo szybsza czy bardziej niezawodna. Powodem tego stanu rzeczy jest to, iż XML i SOAP są "nowym towarem w starym opakowaniu", którego "wędrówki" odbywają się za pośrednictwem protokołu HTTP. Protokół HTTP cierpi natomiast na brak standaryzowanych mechanizmów zapewniających gwarantowane i punktualne dostarczenie zawartości - HTML, XML, strumieni wideo czy cokolwiek innego - z serwera do klienta. HTTP oferuje dostarczanie, które można eufemistycznie określić jako "dobre chęci", polegające na tym, że każdy ruter pośredniczący będzie próbował wyekspediować pakiety do optymalnie najbliższego węzła, ale cała droga end-to-end, pokonywana przez różne pakiety, jest poza kontrolą jakichkolwiek węzłów.

Web services nie będą gotowe na szersze stosowanie w sieciach przedsiębiorstwa, dopóki przemysł nie zapewni odpowiednich narzędzi, standardów i rozwiązań do zarządzania ruchem, zapewniających przewidywalne osiągi w układzie end-to-end.

Zobacz również:

• Mozilla stworzyła nową usługę, która usuwa nasze wrażliwe dane z internetu

Niestety przemysł nie zaczął jeszcze wykorzystywać możliwości wiązania SOAP z czymkolwiek innym poza HTTP - na przykład protokołami warstwy pośredniczącej, takimi jak Java Message Service czy MQSeries, które obsługują gwarantowane dostarczanie wiadomości.

Pomimo tego Web services pracują wystarczająco dobrze w wielu zastosowaniach. Implementatorzy web services mogą pochwalić się wieloma kreatywnymi rozwiązaniami przyśpieszającymi i skalujacymi dostarczanie ruchu HTML i XML/SOAP poprzez HTTP, bez mieszania w podstawach 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". Jak dotąd jednak przemysł nie wykonał odpowiedniej konwergencji w standardach, niezbędnej do współdziałania pomiędzy różnorodnymi rozwiązaniami zarządzania ruchem, pochodzącymi od różnych dostawców. Dopóki dostawcy nie uzgodnią takich standardów, efektywne podejście do globalnego zarządzania ruchem web services pozostanie 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 używana z bazami danych związanymi z zawartością dynamiczną. Dobrą wiadomością jest to, że istnieją standardy buforowania weba, złą, że istnieje ich zbyt wiele. Dostawcy rozwiązań buforujących implementują wiele zarówno własnych, jak i otwartych specyfikacji.

Sytuacja w zakresie choreografii zawartości nie jest lepsza. W środowiskach web services pojęcie "choreografii" odnosi się do strukturalizowanych, sterowanych przez reguły, przepływów informacji i zadań, przez połączenia sieciowe, pomiędzy dwoma lub więcej komponentami aplikacji. W środowiskach opartych na SOAP, choreografia sprowadza się do funkcji wykonywanych przez brokerskie serwery integracji oraz, w mniejszym zakresie, nowe generacje specjalizowanych urządzeń - ruterów danych aplikacyjnych.

Rutery danych aplikacyjnych, odmiennie niż rutery IP, nie są zazwyczaj ustawiane do współdziałania z globalną siatką rutingu, wyliczającą optymalne trasy. Działają one przede wszystkim jako procesory, które przyspieszają lokalny ruting i transformacje wiadomości XML/SOAP. Nadal jednak nie istnieją dla nich odpowiedniki protokołów OSPF (Open Shortest Path First) czy BGP (Border Gateway Protocol).

W ciągu najbliższych kilku lat, tradycyjne rutery sieci IP mogą ewoluować w stronę możliwości rutowania zawartości SOAP i funkcji buforowania. Niedawno przemysł wykonał wstępny krok we właściwym kierunku opracowując specyfikację WS-Routing, która zapewnia składnię definiowania tras end-to-end dla wiadomości SOAP. Jednak WS-Routing definiuje trasy statyczne, a nie dynamiczne, które są niezbędne dla adaptacyjnego zarządzania ruchem web services w czasie rzeczywistym.

W coraz większym zakresie rozwiązania pośredniczące web services są wdrażane w krytycznych aplikacjach sieciowych przedsiębiorstw. Jednak web services ciągle muszą same sprawdzać, czy wydajność i skalowalność są wystarczające. Jeżeli przemysł nie podejmie wyprzedzająco tematyki otwartych problemów narastających wokół zarządzania ruchem end-to-end, to fakt ten może to stać przyczyną dużego rozgardiaszu w tym obszarze.