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

This is one of the possible Use Cases.

1. Abstract

This is a detailed use case about representing, managing and automatically enforcing/performance monitoring of Service Level Agreements (SLAs). It focuses on advanced rule-based knowledge representation (KR) concepts for service level management (SLM) of loosely coupled and distributed IT services (e.g. Web Services / Service Oriented Computing) with dynamic service provider and service consumer relationships and new e-business models such as On-Demand Computing or Utility Computing.

At the core are rule-based languages to describe SLAs in a generic way. Selected logical formalisms are investigated and combined into an expressive KR called "ContractLog" -- such as temporal event/action logics, deontic normative logics, description logics, typed logic and defeasible logic -- in order to represent event based reactive SLA rules (ECA rules), SLA business rules and SLA policy rules (derivation rules), SLA normative rules defining rights and obligations with violations and exceptions (defeasible normative deontic rules) and default/exception rules with priorities between SLA rules and contract modules (defeasible rules/rule sets). The use case draws on Logic Programming techniques as well as on new standards in the area of web services computing and the Semantic Web. The implemented KR facilitates integration of arbitrary external data sources such as databases, XML/RDFS files etc. into rule execution, and enables procedural attachments on arbitrary external systems in order to reuse existing business object implementations such as EJBs, Web Services or functionalities of system and network management tools.

Typically, the complete IT service contract structure -- consisting of terms and conditions, master SLAs, subordinated standard SLAs, Operational Level Agreements (OLAs) and underpinning contracts as well as other rules from regulations and laws such as Saban Oxley, Basel II etc. -- is scattered between different parties (provider, customer, third parties), departments and organizations. Therefore, in this use case there is a particular need for a RIF, i.e. a high-level declarative rule interchange language, which facilitates the decentralized management of SLA rules, rule interchange even permitting different semantics for interpretation and different business/contract vocabularies e.g. defined as Semantic Web ontologies (RDFS/OWL) as well as serialization, persistence and tools support. The language should support the different rule types such as reactive / ECA rules, derivation rules, normative rules, defeasible rules etc. as well as logical extensions such as typed logic (using type systems, e.g. Java or RDFS taxonomies, to type rule terms), procedural attachments (using external implementations), external data sources as fact bases, etc.

2. Status

Original version proposed by: Adrian Paschke (TU Munich). Current version joint effort by: NRC (HaroldBoley), Adrian Paschke (TU Munich) and Jens Dietrich (Massey University).

The use case is elaborated in the RBSLA project and based on the implemented scenarios/examples derived from several real-world SLAs. More details can be found in the RBSLA project site The rule based SLA approach consists of three layers:

The ContractLog KR has been implemented based on the open source, Java-based Mandarax / Prova rule engine for derivation rules. The RBSLA language is developed based on RuleML and extends it. It is translated to the core ContracLog syntax and executed within the ContractLog KR and the underlying Prova rule engine. The use case has been implemented based on this logical SLA framework. The framework is under active development in the RBSLA project.

3. Links to Related Use Cases

4. Relationship to OWL/RDF Compatibility

A particular need in SLA representation and management in a distributed service oriented scenario is rule interchange. Our RBSLA language is based on RuleML which can be serialized in RDF. Furthermore, RDFS/OWL ontologies defining domain specific concepts and contract vocabularies in order to keep SLA rules domain independent and facilitate interchange of contracts between business partners and organization boundaries (with different vocabularies).

5. Examples of Rule Platforms Supporting this Use Case

6. Benefits of Interchange

7. Requirements on the RIF

8. Breakdown

8.1. Actors and their Goals

8.2. Main Sequence

  1. Design phase
  2. Experts define rule templates, functions and test cases
  3. Practitioners reuse the template to design and write SLA offerings. The test cases safeguard these authoring processes
  4. Negotiation phase
  5. Service consumer and service provider negotiate (a) service contract(s) either using predefined SLA templates or negotiate an individual contract. The contract is exchanged between the parties (consumer, provider, third parties).
  6. Enforcement phase
  7. The SLAs are maintained and executed by the service provider. The RIF SLA is translated into the respective execution syntax and automatically monitored and executed within the rule engine and the underlying systems. Monitoring can be done by the service provider or outsourced to external third parties.
  8. Analysis phase
  9. Collected performance measurement data are used by the service provider for reporting, accounting and operational, tactical and strategically planning.

The main focus of this use case is the enforcement phase, i.e. an existing distributed SLA written in a RIF is exchanged between partners and internal departments / responsible roles and executed within a decentralized rule based Service Level Management system with an internal rule engine.

8.3. Alternate Sequences

9. Narratives

‘’The service availability will be measured every t seconds according to the actual schedule by a ping on the service. If the service is unavailable and it is not maintenance then escalation level 1 is triggered and the process manager is informed. The process manager in escalation level 1 is obliged to restart the service within time-to-repair. If the process manager fails to restore the service in time-to-repair (violation of obligation), escalation level 2 is triggered and the chief quality manager is informed. The chief quality manager is permitted to extend the time-to-repair in order to enable the process manager to restart the service within this new time-to-repair. If the process manager fails to restart the service within a maximum time-to-repair escalation level 3 is triggered and the control committee is informed. In escalation level 3 the service consumer is permitted to cancel the contract.’’

Monitoring schedules and service level

Bonus/Malus/Penalty price policy

Escalation Levels with role models and associated rights and obligations

10. Commentary

The use case has been implemented within the RBSLA project. Results and a complete description are given in the article “A logic-based SLA Management Framework” for the Journal IEEE Transactions on Knowledge and Data Engineering, which is currently under review. More information can be found on the project site