Building QoS into Web Services and Applications

Now that we have seen why QoS is important for Web services and some of the factors that affect its QoS measure, we next turn to building QoS into Web services. Web services that provide good and predictable QoS will differentiate themselves from competing services and will be more popular for Web services-based applications. As such, when we talk about building QoS into Web services, we must talk about both the provider side and the consumer side.

On the provider side are individual Web services. The questions the architect or developer of a service must answer are:

• How do we build QoS into the services?

• How do we architect the service to achieve acceptable QoS measures?

• How do we support different QoS requirements from multiple applications?

• How do we propagate changes (e.g., access endpoint information) for this service to consuming applications so that they continue to function?

On the consumer side are applications that invoke (or consume) Web services. Applications will select Web services that provide superior QoS. Supporting QoS within applications that consume Web services brings a different mix of issues. Architects and developers charged with implementing Web services-based applications must ask themselves these questions:

• What are my application's QoS requirements?

• Which QoS metrics are "must have" and which are "nice to have"?

• Will these requirements evolve or change over the lifecycle of the application?

• Which Web services address my needs?

• What if this Web service fails to meet my QoS needs in the future (either because my QoS requirements changed or the service's QoS is reduced)?

It is interesting to note that some applications may themselves be made available as Web services, and will have to address issues on both the consumer and the provider side.