My blog has moved and can now be found at

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, February 18, 2007
« Comparison of Web Services Stacks | Main | Reactivity and Cisco - Another consolida... »

I was reading through the research article "Adaptive QoS for Mobile Web Services through Cross-Layer Communication" in the current issue of IEEE Computer Magazine in which the authors are proposing something called WS-QoS framework, which is an approach to unify Quality of Service (QoS) for web services across transport, computing and app layers.  It is an interesting read.

Per the article, the discovery, selection and invocation process consists, at a high level, of :

  1. Service Provider registers with a UDDI based registry. Each service has a unique interface key.
  2. Potential Service Consumer queries an "offer broker" (This is a new entity in the mix) for services that match a specific interface key AND QoS requirements
  3. The offer broker acts as the middle man in identifying the "best match" between the QoS requirements of the Service Consumer and potential Service Providers who are registered in the UDDI based registry.
  4. The Service Consumer directly invokes the identified best match Service Provider.

The manner in which QoS is codified is based on a specific XML Schema .

For example, for the Transport Segment you could have something like:

<operationQoSInfo name="myOperation">

 For Servers it could be:


And at the App Layer you could have something that codifies facets like compression and decompression and other items.

As a thought exercise, given that the point of using web services is all about interoperability, I went through what would need to happen from the standards and vendor support to make all this real.

  1. Given the amount of work going on around WS-Policy, wrap up the QoS information as a domain policy language for QoS under the WS-Policy umbrella
  2. The direct integration of the "offer broker" functionality into the Registry/Repository
  3. Built in support from the networking vendors that can map the codified policies into the appropriate technology specific network mechanism such as priorities for expedited forwarding, assured forwarding, best-effort etc.
  4. Built in support from the server OS vendors that can map the codified policies into server performance levels. And given that a lot of folks are using virtualization in their computing tier, support from those folks as well.
  5. Last but not least, agreement and profiling of the specification(s) between all of the web service stack vendors.

I am sure that I have grossly over-simplified a lot of things in the above and probably gotten some of it completely wrong. But the essence remains. Beyond this being a technically challenging problem, there needs to be significant amount of agreement between a lot of vendors as well as the incorporation of a variety of these technologies into the various product sets (Vendor Politics, Oh My!).

It is going to be a while! <sigh>

2/18/2007 1:13 PM Eastern Standard Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.