The traditional need for QoS is driven by the desire to use networks more efficiently, and yet still support key delay sensitive applications. For example, IP networks dynamically assign capacity in order to maximize the use of bandwidth. However, to support applications such as VoIP, QoS techniques such as queuing and MPLS are required.

As pointed out in previous newsletters, part of the value proposition for Web services is that they are reusable by multiple applications. And that means that we now need to develop QoS-like functionality for Web services. 

As an example, consider a Web service called "Get Weather Data." Now assume that this Web service is part of five different applications, four of which are not time sensitive. However, one of these five applications is a very time sensitive arbitrage application for trading crop futures. Some QoS mechanisms are necessary to ensure that the arbitrage application's use of the "Get Weather Data" Web service is not impeded by the other four applications.

It is worth pointing out that this QoS problem is really thorny as it involves developing and coordinating QoS functionality across networks, servers, and applications - something the industry has never done before.

This problem is the focus of work that Cisco says it has underway with a few vendors that it refuses to name. Cisco hopes that the solution, which has not yet been developed, will be approved by one or more standards organizations.  In the meantime, supporting delay sensitive Web services will involve implementing ad hoc techniques, such as running virtual machines on each server, and hoping the problem goes away.

Steve Taylor is president of Distributed Networking Associates and publisher/editor-in-chief of Webtorials. Jim Metzler is vice president of Ashton, Metzler & Associates.