Web services are gaining acceptance as the prime technology used to interconnect disparate applications and ease interoperability between heterogeneous and autonomous systems both for internal and external integration. The variation of contexts in which shared Web services could be used and the resulting variation in functional and Quality of Service (QoS) requirements motivate extending Web services management platforms with more sophisticated control mechanisms to cater to differentiated service offerings.

However, most Web services platforms are based on a best-effort model, which treats all requests uniformly, without any type of service differentiation or prioritization. This article explores the typical generic requirements for differential QoS support in Web services management. We then evaluate various emerging management frameworks to assess the degree to which they meet the identified requirements. Finally we present the typical architecture for priority-based differentiated QoS for Web services.

Web Services Management
Web services management (WSM) provides the necessary infrastructure to help enterprises monitor, optimize, and control the Web services infrastructure by using a policy-oriented approach to ensure that QoS objectives are met. A WSM system provides visibility into the Web services runtime environment to enable:

• Monitoring of availability, accessibility, and performance of Web services
• Service level agreement (SLA)-compliance tracking
• Error detection, resolution, and auditing

OASIS Web Services Distributed Management (WSDM) is a key standard for Web services management. It allows exposing management functionality in a reusable way through two specifications: one for Management Using Web Services (MUWS) and the other for Management of Web Services (MOWS). The MUWS specification provides a framework that defines how to represent and access the manageability interfaces of resources as Web services. MOWS builds on MUWS to define how to manage a Web service as a resource. It defines WSDL interfaces, which allows management events and metrics to be exposed, queried, and controlled by a broad range of management tools. However, WSDM does not provide any support for differential QoS.

Differential QoS Requirements in Web Services: One Service Implementation - Many Levels of Service
In the business world differentiated services are very common, just as gold card holders get preferential services compared to silver or bronze card holders. Leveraging the notion of differentiation to vary the level of service offerings in Web services environments is a challenging task. For example, a Stock Quote Web service could report prices with different levels of timeliness, ranging from real time to fifteen-minute delay to a 24-hour time lag. Service request metadata such as the grade of the service customer (gold, silver, etc.), or the security level (employee, customer, partner, etc.) could then be used to determine the service level to offer to the user at the time of request.

However, current Web services management platforms do not address differentiated services requirements comprehensively, and requests are often processed according to their order of arrival. Figure 1 summarizes the typical architectural requirements for differential QoS.

Generic service-level offerings - The first requirement to achieve differentiated QoS is the ability to encode QoS assurances in machine-readable format. An expressive language is required to specify the various service levels offered by the service provider. For example, services can be offered using an Olympic classification such as gold, silver and bronze.

Individualized service-level offerings - Besides the support for defining generic service levels, sometimes it is useful to be able to define custom service levels (SLAs) per service consumer.

Matching and negotiation of service levels - Particularly for custom SLAs, sometimes it is useful to be able to dynamically negotiate service levels depending on the requester's requirements, the service provider's capabilities, and the dynamic runtime conditions such as service load.

Admission control - Admission control regulates the "intake" and manages the acceptance of new requests while taking into account current service policies and system load. In case of overload, a request may be either rejected or have its QoS level downgraded (through negotiation), so that it can be accepted at a lower service class.

Request classification - Request classification is responsible for receiving incoming requests and assigning a service class to requests to enable prioritization according to a predefined classification schema. The request is then placed on the appropriate priority queue according to its assigned service class.

Requests policing - Requests policing is required to make sure that the number of requests per customer is within a predefined limit. Requests exceeding the maximum throughput limit are assigned a low priority class.

Differential QoS dispatcher - Dispatcher uses scheduling algorithms such as weighted round-robin scheme to dispatch requests for processing, while ensuring that the number of dispatched requests to each service does not exceed its capacity.

QoS measurement and monitoring - A QoS metrics engine is required to gather QoS metrics, monitor the workload, and readjust the class-of-service weights for request queues. This allows the Service provider to ensure that the promised performance is being delivered, and to take appropriate actions to rectify noncompliance with an SLA such as reprioritization and reallocation of resources.

Policy manager - For implementing differentiated services, there is typically a set of rules or policies that control the QoS variations. From an architectural point of view, this requires a separate policy management layer to allow separating out the policy aspects from service implementation.

Automated resource management - The most important and challenging requirement for differential QoS management is still QoS delivery through automated resource management, particularly arbitration in allocating resources to client requests (e.g., providing more resources to process higher priority requests) and mapping QoS requirements onto the configuration of underlying QoS provision technologies across all abstraction layers.