• Rule Based Service Level Management and SLAs for Service Oriented Computing

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 http://ibis.in.tum.de/staff/paschke/rbsla/index.htm. The rule based SLA approach consists of three layers:

• ContractLog: The logical core - an expressive KR combining several logical formalisms. More information in the RuleML-2005 paper http://ibis.in.tum.de/staff/paschke/docs/37910209.pdf

• RBSLA: A declarative, high-level Rule Based SLA language (RBSLA) extending RuleML in order to address interoperability with other rule languages and tool support. We extend RuleML with SLA specific concepts and expressive logical constructs abstracted from the ContractLog framework as a means of deriving formal declarative and machine-readable SLA specifications. More information in the IAWTIC paper http://ibis.in.tum.de/staff/paschke/docs/IAWTIC.pdf

• RBSLM: The Rule Based Service Level Management tool is divided into two partitions: the Contract Manager (CM) and the Service Dashboard (SD). The CM is used to manage, write, maintain and update SLA rules and supports different roles such as the (rule) expert or the business practitioner. The SD visualizes the monitoring and enforcement process in the contract life cycle and supports further SLM processes. More details on the project site http://ibis.in.tum.de/staff/paschke/rbsla/index.htm.

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

• E-Contracts with Exceptions, with OWL Process Ontologies: We relate to this use case in that we also address the representation of contracts, however with a particular focus on SLAs for IT services.

• Rule-based Service Level Agreements (SLA) and Web Services: We strongly relate to this use case in the sense that the eventual requirements are the same. But our focus is more general on the level of business rules typically found in SLAs such as service level guarantees, escalation levels, normative rules defining rights and obligations, incident notification, reporting, performance monitoring, measurement directives, metering and accounting, pricing policies with discounts, bonuses and penalties, etc.

• Interchange of Business Rules between Business People in Different Organizations (Units) When Making Agreements: We relate to this use case in the sense that it also proposes a distributed environment in which business rules are interchanged. With our RBSLA language we address this point.

• Information Integration with Rules and Taxonomies: We relate to this use case in that it also addresses the integration of external information into rules. We also allow integrating arbitrary external sources such as web sources, databases etc., external taxonomies e.g. RDFS/OWL or Java class hierarchies as type systems and external implementations such as Web Services, Java/EJBs, Java based APIs etc. into logical rules, e.g. ECA rules to trigger external actions or detect events in monitored systems.

• Ontology Mapping with OWL and Rules: We relate to this use case in that we also combine taxonomies/ontologies defined in RDFS or OWL (lite and dl) and LP rules.

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

• We use Prova as the open-source backward-reasoning rule engine for our reference implementation. Prova is derived from Mandarax, a Java-based backward-reasoning inference system for derivation rules. Prova extends Mandarax by providing a proper language syntax related to Prolog.

6. Benefits of Interchange

• Online exchange of rules.
• Supports loosely coupled and distributed IT service contract structures and decentralized management, execution and maintenance of SLAs
• Permits coexistence of differentiated contract variants
• Integration of external facts and domain specific vocabularies from arbitrary distributed sources
• Reuse of once defined rules in several SLAs, even permitting rule templates which are stored in a repository. We have implemented such a repository approach in the contract manager of the RBSLM tool.
• Integration and combination of rules sets into SLA specifications, e.g. integration of compliance rules from new regulations such as Saban Oxley, integration of operational rule sets from supplying parties, buying/integration of rule sets (policies, e.g. price models) from specialized "rule" vendors.

7. Requirements on the RIF

• Various rule types such as ECA rules, derivation rules, normative rules etc.
• Expressive power of the interchange format to represent complex SLA rules, e.g. rule priorities, defeasible rules, temporal reasoning, event algebras for complex event processing, etc.
• Typed Logic and Mode declarations e.g. Java type system, Semantic Web taxonomies, Input/Output modes.
• Integration of external fact bases, e.g. databases, Web sources, data warehouses etc.
• (Re)use of (existing) external functions or methods, e.g. SQL aggregations, mathematical functions implemented in Java, EJBs, event driven architectures, system/network mgt. tools, messaging capabilities, etc.
• Semantic annotations to support transformation of the normalized interchange format into different execution syntaxes and enable execution in different rule engines with different (logic programming) semantics.
• Rule sets/modules, e.g. defining different contract modules in a hierarchical contract structure (terms and condition module, master SLA, standard SLAs, OLAs).
• Meta rules for meta reasoning.
• Verification and validation support.
• Support for different roles, i.e. different abstraction layers, e.g. model layer (e.g. UML, MDA PIM), if-then related layer, XML-based layer, logical layer (e.g. Prolog)

8. Breakdown

8.1. Actors and their Goals

• Service providers’ domain experts specify SLA rule templates, measurement directives, monitoring and computing functions, interface definitions to external systems and databases, test cases for validation, etc. in an interchangeable rule format and populate the repository with these templates.
• Third party suppliers and specialised rule set vendors offer further rule templates or complete rule sets in the RIF, e.g. derived from general laws, compliance rules from regulations, specialized policies, e.g. price discrimination strategies or rules supporting IT service process models such as ITIL or BS15000.
• Service providers’ business practitioners reuse the predefined templates and functions in their daily business to define differentiated SLA variants for their service offerings, e.g. with different monitoring schedules, graduated service levels, escalation levels, reporting, pricing policies with bonuses, discount and penalties, individual role based rights and obligations, etc.
• A service consumer and a service provider (business practitioner) make an agreement based on a SLA variant or negotiate an individual SLA. The SLA is formalized in the RIF and exchanged between service consumer, service provider (possibly scattered over different organizations and in-house supplier), and third parties. A “need-to-know” principle is applied, i.e. each party only sees the needed parts of the contract.

• In the enforcement phase the RIF SLA rules (e.g. RBSLA) are translated into its logical execution syntax (e.g. ContractLog) and executed within an rule engine. The service provider correlates business practitioners and defined roles, e.g. a process manager executes, maintains and updates the SLA rules and the triggered actions/obligations.

• In the analysis phase the collected performance measurement data are used by the service provider (experts and practitioners) to adapt the SLA (service levels) in an iterative process in order to optimize the high, low and medium values, and to reach ideal values. This process closely relates to the capability maturity model (CMM) defined for software development processes.

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

• Third parties / external rule vendors offer complete SLA templates in a RIF which are bought by the service provider.
• Monitoring and performance measurement are outsourced to third parties. The needed SLA rules are exchanged based on the RIF.

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

• Prime: 8 a.m. – 18 p.m. availability [high:100%,median:99%,low:98%] pinged every 10s
• Standard: 18 p.m. – 8 a.m. availability [high:99%,median:97%,low:95%] pinged every minute
• Maintenance: 0 a.m. – 4 a.m. (optional exception) availability 0%, no measurement

Bonus/Malus/Penalty price policy

• Prime: base: p(prime) / bonus: p(prime)+p(bonus) / malus: p(prime)-p(malus)
• Standard: base: p(standard) / bonus: p(standard)+p(bonus) / malus: p(standard)-p(malus)
• Maintenance: base: p(prime) / no bonus or malus
• Incident Penalty: -p(incident)

Escalation Levels with role models and associated rights and obligations

• Level 1: trigger: service unavailable / role: process manager / time-to-repair (ttr)=10 min. / obligation: restart service
• Level 2: trigger: failed restart in ttr / role: chief quality manager / obligation: adapt ttr till max ttr.
• Level 3: trigger: failed restart in max ttr / role: control committee / obligation: renegotiate with service consumer

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 http://ibis.in.tum.de/staff/paschke/rbsla/index.htm.