This is an archive of an inactive wiki and cannot be modified.

1. Abstract

A policy can be defined as a declarative specification of guidelines, rules of conduct, organization, and behavior of entities in a given environment. The area of policy languages is still maturing from both a research and industrial point of view. From an application standpoint, this field has been dominated by very narrow applications in privacy and security. A number of languages have been proposed, most of them based on limited expressive power.

The use cases we have selected include the concepts of constraints based on security and reliable messaging. We generalized these concepts within a more comprehensive use case that encompasses business specific information and SLAs. When an organization wishes to deploy a new or updated version of a web service, they will want to validate that this service conforms to relevant internal compliance guidelines. For example, to ensure that certain levels of security or reliable messaging are used, or to ensure that only certain approved information types can be used within the WSDL interface.

Policies can be viewed as constraints as well as facts that can be used to determine what an IT system is required to do to meet some business objective. We might have a policy for premium customers that describes a particular level of security and this may be different to those customers that are not premium customers. We might have a policy that describes some throughput of a system that is a reflection on a service level agreement, perhaps it relates to the number of trades and prices that can be executed or offered from a customer to an Investment Bank. It might relate to the amount of electricity that a data centre can consume based on the size of their electricity pipe at their building.

A detailed paper on this work and this use case is available at: The authors are: Steve Ross-Talbot, Said Tabet, Sharma Chakravarthy , and Gary Brown

2. Status

This is a proposed use case based on an existing scenario that was implemented in October 2004 for the W3C "Constraints and Capabilities" Workshop. This use case has been implemented using standards-based and open source technologies with support for production rules (RETE based) in a distributed environment (MAC, Linux, Windows).

Here are two examples of SLA rules have been defined to define the cost per transaction based on the customer level and their service usage:

3. Benefits of Interchange

Interchange of policies is very importan and clearly a key component of the interaction between the various actors (the exchange SLAs as part of the business activity).

4. Requirements on the RIF

SLA systems such as the one we implemented for this scenario require not only various types of rules but also rules that can be either static or dynamic.

5. Breakdown

5.1. Actors and their Goals

5.2. Main Sequence

  1. WS Factory (WSF Inc.) Web Services provider wishes to deploy new services to enhance client service
  2. WSF Inc. defines a new set of SLA rules in its natural language editor
  3. WSF Inc. generates a new set of automated policies in the interchange format
  4. WSF Inc. deploys its new web service to gether with the associated SLAs
  5. WSClient is a gold level client looking for new services that can guarantee response time dynamically (support for dynamic SLAs)
  6. WSClient prepares to run its discovery process
  7. WSClient creates a new derivation rule to require the 'cost' of a service to be factored into the selection process. The rule is validated and a RIF format generated.
  8. WSClient starts its discovery process and finds the service WS1 from WSF Inc.
  9. WSClient and WSF Inc both use RIF to make sure there is a match and agreement
  10. Once both parties are satisfied, the agreement is implemented.

5.3. Alternate Sequences

Changes in the WSF Inc. company policies trigger updates to the deployed web services and impact the SLAs in place. The client is notified during a validation process and decides to generate new rules to discover other services.

6. Narratives

6.1. Static and Dynamic Discovery

The following scenario uses static and dynamic SLAs. Details of the web service could be defined as facts. These details may be based on a domain specific ontology. To define the discovery query relevant for these static capabilities would require the discovery request to be accompanied by a derivation rule that would need to evaluate to true for the service to be considered relevant. For example, we may only want to discover services that use reliable messaging and kerberos security – these are fixed (static) capabilities that would not generally vary between different requests for the service.

A more advanced type of discovery request (dynamic SLAs) could associate derivation rules with the service that would be evaluated against 'facts' provided as part of the discovery request. This enables the nature of the request to only be known at runtime, when the client provided information is evaluated against those rules. For example, the client request could contain the following task specific rule: Constraint2: Transaction cost less than 4 cents

Here are some examples of SLAs used in the scenario implementation:

The following two policies are rules on Customer level (gold or platinum), which is based on the customer’s support type purchased:

The following two policies define the customer’s maximum transaction response time based on their support level (gold or platinum):

6.2. Deployment (Registration) Validation

When an organization wishes to deploy a new or updated version of a web service, they will want to validate that this service conforms to relevant guidelines. For example, to ensure that certain levels of security or reliable messaging are used, or to ensure that only certain information types can be used by the WSDL interface (i.e. approved message types from the organization's repository).

This type of validation would be performed by either processing the WSDL service definition or inspecting additional properties (capabilities/facts) that would have been associated with the service definition. For example, the following facts could be associated with the service definition:

Therefore the validation can be performed on the basis of applying a constraint rule over these facts (e.g. does service use reliable messaging?), and/or transformation rules to the service definition to analyse aspects of the description (e.g. does the service only use authorized types). For example,

7. Commentary

As noted previously, this use case has been defined and implemented in October 2004 as part of a proposed SLA policy specification. The implementation is relevant to the interchange format in a number of ways, particularly from the nature of the interaction between service providers and clients where RIF would be extremely useful. The interaction included the interchange of SLA rules as part of the messages exchanged between the parties involved in the transactions. Each agent was running on a separate environment (including Linux, Mac OS, and Windows).