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: http://www.w3.org/2004/09/ws-cc-program.html#papers The authors are: Steve Ross-Talbot, Said Tabet, Sharma Chakravarthy , and Gary Brown
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:
- Policy 5: IF a Customer is a Platinum Customer and the Service Usage is less than 30 days THEN the transaction cost is 2 cents
- Policy 5b: IF a Customer is a Platinum Customer and the Service Usage is more than 29 days THEN the transaction cost is 1 cent
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).
- The interchange format enables the use and integration of SLA engines from various platform and in a web-based and distributed fashion
- Support for network-based SLA architectures
- Reusability and ease of maintenance of SLA rules (by not being hardcoded)
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.
- expressive power of the interchange format to match the capabilities required by SLAs
- Support for the both the static and dynamic aspects of SLAs
- Support for the functionality and requirements of Web Services and distributed architectures
5.1. Actors and their Goals
- An organization deploying a new or an updated version of a web service
- A client or a consumer of such web services. Clients provide declarative descriptions of capabilities they expect from available web services
- An organization providing matching services to both web service publishers and consumers
5.2. Main Sequence
- WS Factory (WSF Inc.) Web Services provider wishes to deploy new services to enhance client service
- WSF Inc. defines a new set of SLA rules in its natural language editor
- WSF Inc. generates a new set of automated policies in the interchange format
- WSF Inc. deploys its new web service to gether with the associated SLAs
- WSClient is a gold level client looking for new services that can guarantee response time dynamically (support for dynamic SLAs)
- WSClient prepares to run its discovery process
- 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.
- WSClient starts its discovery process and finds the service WS1 from WSF Inc.
- WSClient and WSF Inc both use RIF to make sure there is a match and agreement
- 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.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:
- Policy 1: A Platinum Customer is a Customer who purchased a Platinum Support
- Policy 2: A Gold Customer is a Customer who purchased a Gold Support
The following two policies define the customer’s maximum transaction response time based on their support level (gold or platinum):
- Policy 3: IF a Customer is a Platinum Customer THEN the Customer’s Max Transaction time is 5 seconds
- Policy 4: IF a Customer is a Gold Customer THEN the Customer’s Max Transaction time is 10 seconds
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:
- Fact1:Messaging is Reliable
- Fact2:Security is Kerberos
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,
- Constraint1:Messaging is Reliable AND Security is Kerberos
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).