OPTIMIS SLA Framework and Term Languages for SLAs in Cloud Environment

(1)

Project Acronym:

OPTIMIS

Project Title:

Optimized Infrastructure Services

Project Number:

257115

Instrument:

Integrated Project

Thematic Priority:

ICT-2009.1.2 – Internet of Services, Software and

Virtualisation

OPTIMIS SLA Framework and Term

Languages for SLAs in Cloud

Environment

Activity 2:

Service Construction

WP 2.2:

Cloud QoS Contracting and Service Configuration

Due Date:

M12

Submission Date:

31/05/2011

Start Date of Project:

01/06/2010

Duration of Project:

36 months

Organisation Responsible for the Deliverable:

SCAI and ULEEDS

Version:

1.0 Status

Final

Author(s):

Wolfgang Ziegler

Ming Jiang

SCAI

ULeeds

Reviewer(s)

Johan Tordsson

Kleopatra Konstanteli

UMU

ICCS/NTUA

(2)

Project co-funded by the European Commission within the Seventh Framework Programme

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission)

RE Restricted to a group specified by the consortium (including the Commission)

(3)

Index of Figures

Figure 3.1 - Agreement template ...11

Figure 3.2 - Agreement state model ...12

Figure 3.3 - Service Term States ...13

Figure 3.4 - Guarantee Term States ...14

Figure 4.1 - Conceptual overview of the layered negotiation model ...15

Figure 4.2 - Structure of a Negotiation Offer ...17

Figure 4.3 - Offer/Counter Offer State Transitions ...17

(5)

1 Executive Summary

Deliverable D2.2.2.1 has two major parts, the first one (Section 3 –Section 5) describing the technology used in OPTIMIS to negotiate and create Service Level Agreements (SLAs), the second part describing the term languages to define the TREC parameters (parameters for Trust, Risk, Eco-efficiency and Cost )used in the OPTIMIS SLAs.

After giving a high level overview on Agreement first part discusses rationales why WS-Agreement has been selected as base technology in OPTIMIS for SLAs between Service Providers (SP) and Infrastructure Providers (IP):

We need to negotiate SLAs with different autonomous cloud providers that offer different service levels to their customers. The SP aims to reach an agreement with the IP on the QoS taking into account e.g. the TREC parameters or constraints with respect to data location or elasticity requirements.

For negotiation it is essential that there is a protocol to be followed and that the two negotiating parties have a common understanding of the objects the negotiation is about. WS-Agreement provides this protocol.

The negotiations should result in SLAs with binding character for both parties to deliver a reliable service to the end-user. This is the outcome of a successful negotiation with WS-Agreement.

WS-Agreement is already widely used in distributed computing infrastructures, especially the context of Grids.

WS-Agreement is a standard of the Open Grid Forum.

Because of its domain agnostic approach it is not limited to the use in a specific domain but may be adapted to arbitrary domains just by using the term language for the service description terms that best fits to the domain.

Structure and processes of WS-Agreement are described in detail in the rest of this section. Negotiating capabilities and service levels offered by the different IPs is an essential way to select the most suited IP with respect to the TREC requirements of an SP and additional constraints like geographic location of a datacenter. OPTIMIS uses the current draft of the Open Grid Forum’s specification for SLA negotiation using WS-Agreement, which originally has only limited negotiation capabilities. WS-Agreement Negotiation closes this gap. Model, structure, protocol and flow are described in Section 4.

There already exist a number of implementation of WS-Agreement and WS-Agreement Negotiation, most of them stemming from projects with different use-cases for SLAs. Thus, many of them have implementations of WS-Agreement with a probably limited scope that fits to the requirements of the individual project. The most complete and domain independent implementation of WS-Agreement and WS-Agreement Negotiation currently is the WSAG4J framework [14], a Java-based implementation developed at the Fraunhofer Institute SCAI. It therefore has been selected as code-base for the CloudQoS component in OPTIMIS. Section 5 gives an overview on the framework.

Trust, Risk, Eco-efficiency and Cost are central concepts used by the SP to decide which provider to select. The TREC parameters for year one have been defined and agreed upon in the first 6 months of OPTIMIS.

(6)

Trust is a subjective measure and assessed in OPTIMIS both by the SP and the IP for their respective counterpart by using reputation mechanisms: the rank of IPs will be based on how well they accomplish promised level of service, while SPs will be ranked according to e.g., the fluctuations in their capacity requirements and their willingness to commit to long term relationships.

Risk corresponds to hazardous events that have a negative impact on the provision of functionality. Thus, identifying, assessing, treating, and monitoring risk is imperative for proactive operation of providers in the cloud ecosystem. In OPTIMIS, risk is considered during all phases of the service lifecycle and for the two stakeholders: in SPs during service construction, deployment, and operation, and in IPs during admission control and internal operations.

Environmental concerns reflected in upcoming legislation have increased the awareness of the ecological (Eco) impact of the ICT industry. OPTIMIS will make it possible to specify and enforce power consumption limits in SLAs, to decide where services are to execute based on electricity prices, as well as to monitor and assess ecological factors in running services

In OPTIMIS, cost is an explicit parameter throughout the full service lifecycle. The OPTIMIS tools will incorporate economics-related features and thus will e.g., facilitate comparisons of alternative configurations for a service, giving rise to cost efficient services.

Section 6 describes the terms used for the OPTIMIS Trust, Risk, Eco-efficiency and Cost parameters. Additionally, legal requirements and constraints with respect to data security, e.g. encryption, and geographical location of datacenters storing and processing the data have to be part of the SLA. To that end, OPTIMIS has adapted the OVF specification of the DMTF to be used as term language for expressing data security and data center placement.

(7)

2 Introduction

Deliverable D2.2.2.1 – OPTIMIS SLA Framework and Term Languages for SLAs in Cloud Environment presents the framework used in OPTIMIS for negotiating and creating SLA and the results of year one for the definition of the TREC parameters (Trust, Risk, Eco-efficiency and Cost) and the parameters for requirements and constraints regarding data security and geographical location of the data centre. This is the first of three deliverables to be produced in the course of the OPTIMIS project, each of them summarizing the achievements made in the previous year.

D2.2.2.1 is composed of two major parts on the technology for SLAs and the term languages defined and used to express the parameters mentioned before. Section 3 is presenting WS-Agreement, the specification of a standard language and protocol to create SLAs. With a brief overview of the current draft of WS-Agreement Negotiation Section 4 adds the negotiation capabilities to WS-Agreement. In Section 5 the WSAG4J framework is described. WSAG4J is a full Java-based implementation of WS-Agreement and WS-Agreement Negotiation, which is used in OPTIMIS. The second part focuses on the term languages for specifying the terms of the SLAs. Section 6 introduces the individual terms defined and agreed on for the TREC parameters, the data security and data centre location constraints along with a formal specification using XML.

The Annex contains the full version of the OPTIMIS schema definitions and Service Manifest example for year one.

2.1 Purpose

The purposes of this deliverable template are as follows: Introduction in WS-Agreements

Introduction in WS-Agreement Negotiation Introduction in the WSAG4J framework

Presentation of the TREC parameters and the terms defined for use in year one

Presentation of the terms for expressing requirements and constraints regarding data security and geographical location of data centres

Presentation of the schema for the year one OPTIMIS Service Manifest

2.2 Glossary of Acronyms

Acronym Definition

ASP Application Service Provider BSD Berkley Software Distribution CPU Central Processing Unit

D Deliverable

DMTF Distributed Management Task Force EPR End Point Reference

(8)

GUI Graphical User Interface IaaS Infrastructure as a Service IP Infrastructure Provider

ISV Independent Software Vendor

IT Information Technology

KPI Key Performance Indicators

OGF Open Grid Forum

OVF Open Virtualization Format PaaS Platform as a Service QoS Quality of Service SaaS Software as a Service SLA Service Level Agreement SLO Service Level Objective SOA Service-Oriented Architecture

SP Service Provider

TREC Trust, Risk, Eco-efficiency, Cost

WP Work Package

WS Web Service

WSAG4J WS-Agreement for Java

WS-Agreement

Web Services Agreement

WSDL Web Services Description Language WSRF Web Services Resource Framework XML Extensible Markup Language

(9)

3 WS-Agreement

WS-Agreement [9] is a full recommendation of the Open Grid Forum defined by the Grid Resource Allocation Agreement Protocol working group (GRAAP-WG, [10]).

The objective of the WS-Agreement specification is to define a language and a protocol for advertising the capabilities of service providers, creating agreements based on templates, and for monitoring agreement compliance at runtime.

An agreement between a service consumer and a service provider specifies one or more Service Level Objectives (SLOs) both as expressions of requirements of the service consumer and assurances by the service provider on the availability of resources and/or on service qualities.

An agreement life cycle includes the creation, monitoring and termination of agreement. For example, an agreement may provide assurances on the bounds of service response time and service availability. Alternatively, it may provide assurances on the availability of minimum resources such as memory, CPU MIPS, storage, or a software license.

The OPTIMIS project decided early on using WS-Agreement as the technology to define and create SLAs. A WS-Agreement implementation (WSAG4J) will be provided by SCAI.

3.1 Rationales for using WS-Agreement

There are a number of reasons the OPTIMIS project selected WS-Agreement for creating SLAs between service providers (SP) and infrastructure providers (IP):

Different autonomous cloud providers offer different service levels to their customers. Once an appropriate IP has been selected based on the service requirements described in a service manifest the SP can start reaching an agreement with the IP on the QoS taking into account e.g. the TREC parameters or constraints with respect to data location or elasticity requirements. This specific agreement can only be reached through negotiation between SP and IP.

For negotiation it is essential that there is a protocol to be followed and that the two negotiating parties have a common understanding of the objects the negotiation is about. As described in the previous section both can be achieved with WS-Agreement. The negotiations should result in SLAs with binding character for both parties to deliver a reliable service to the end-user. Such SLAs are the outcome of a successful negotiation with WS-Agreement.

WS-Agreement is already widely used in distributed computing infrastructures, especially the context of Grids; it is a standard, and it is extensible.

3.1.1 Wide distribution

Since the publication of the specification as proposed recommendation, WS-Agreement has been increasingly used in the context of Grids [1], [2]. The GRAAP-WG maintains and updates a list of implementations [3].

Currently, WS-Agreement is used or has been used in more than 20 different Grid-related projects; there are 100+ using WS-Agreement in different sectors like e.g. autonomic provisioning, multi-media content negotiation or WS-Agreement Based Semantic Partner Selection. While most of them are research projects there are also developments integrating WS-Agreement in commercial software, e.g. in elasticLM, a product development for software

(10)

license management in Grids and Clouds. One of the used licensing solutions in OPTIMIS is SmartLM, which was developed in another EU project and which was developing a prototype for software licensing in distributed computing infrastructures like Grids and Clouds.

3.1.2 Standard

WS-Agreement is the only open standard specifying a language and a protocol for creating SLAs. Besides WS-Agreement only proprietary solutions are available, most of them developed in and for a certain ecosystem and no longer maintained or further developed, like e.g. the NextGRID SLA [11], or available under a commercial license only, like IBM’s Web Service Level Agreement (WSLA, [6]).

WS-Agreement uses the Web Services Resource Framework (WSRF, [7]) a generic and open framework for modeling and accessing stateful resources using Web services, which has been published as a standard by the OASIS consortium. However, also a rendering of WS-Agreement using REST technology instead of WSRF will be available in near future.

Moreover, SCAI is co-chairing the GRAAP working group. Thus, we can easily ensure that requirements arising during the evolvement of OPTIMIS find their way into the standardisation process.

3.1.3 Extensibility

The intrinsic extensibility of WS-Agreement is an important feature when using it as the general technology for creating SLAs in heterogeneous environments, like Clouds, where each SP or IP deals with different requirements and constraints. Since the specification is completely neutral with respect to specific term languages to express Service Description Terms (SDT) and SLO, Cloud- and therefore OPTIMIS-specific term languages (like those for the TREC parameters) can be defined within the project and plugged into WS-Agreement. This mechanism allows providing common mechanisms for creating agreements while supporting specific requirements.

While the current specification of WS-Agreement only provides a basic, single round mechanism for negotiating an agreement, a proposed recommendation is currently in a public comment period to become an OGF proposed recommendation extending the negotiation capabilities towards multi round negotiations for creating an SLA and re-negotiation of SLAs already in force.

3.2 Structure

An agreement consists of the agreement name, its context and the agreement terms. The context contains information about the involved parties and metadata such as the duration of the agreement.

Agreement terms define the content of an agreement: SDTs define the functionality that is delivered under an agreement. An SDT includes a domain-specific description of the offered or required functionality (the service itself). Guarantee Terms define assurances on service quality of the service described by the SDTs. They define SLOs, which describe the quality of service aspects of the service that have to be fulfilled by the provider.

The Web Services Agreement Specification allows the usage of any domain specific or standard condition expression language to define SLOs. The specification of domain-specific term language is explicitly left open. Figure 3.1 shows the structure of an Agreement template, which is basically the same as that of an Agreement, except that the final Agreement does not contain Agreement Creation Constraint.

(11)

Figure 3.1 - Agreement template

The Agreement Creation Constrains in the template allow the agreement provider to define a number of constraints defining e.g. the ranges within the agreement initiator may modify the individual SDTs. Besides the specification of actual limits of the services provided, the Creation Constraints help to make a negotiation of the SDTs more focused and thus converge faster.

3.3 Monitoring of an Agreement

Following the creation of an SLA with WS-Agreement, both parties of the agreement need access to the state information of the agreement. In the case of WS-Agreement a set of resource properties is defined that allows monitoring different aspects of the agreement. This information may be retrieved through the GetResourceProperty-function provided by WSRF, which is used by the WS-Agreement specification. Monitoring an SLA also empowers both parties to detect potential violations of the agreement and to take appropriate measures. The WS-Agreement specification allows the monitoring of

Agreement state

Service Description Terms Guarantee Terms

By default it is the task of the agreement responder hosting the agreement to provide the services that may gather the necessary data from the system environment to feed the information for allowing retrieving the different status information.

Data gathered from the system environment may include for example state of the scheduled job, its start time, or system monitoring data, e.g. from Ganglia [15]. As said before, it is in the responsibility of the party hosting the agreement to set up the services to be able to extract the required information.

In case of re-negotiating the agreement already in the state Observed it remains in force until the re-negotiation ends successfully. Only if the re-negotiation leads to a new SLA the new one supersedes the currently active SLA: the latter changes its state to Terminated and the new one changes its state from Pending to Observed. Since the new SLA also has a new End Point Reference EPR this has to be used for the SLA-specific monitoring.

(12)

3.4 WS-Agreement states

The proposed recommendation WS-Agreement version 1.0 defines three classes of states, which can be used to monitor the state of the Agreement as a whole, the state of individual service description terms, and the state of the guarantee terms. Services in OPTIMIS, i.e. the provisioning of VMs, are governed by SLAs created with WS-Agreement. To that end, the service states are reflected in the states of the corresponding agreement. Moreover, the OPTIMIS service life cycle is equivalent to the life cycle of the corresponding agreement. The service is started after the agreement has been created and the service is shutdown when the agreement is terminated. Moreover, if a service is aborted prior to the termination of the agreement the service term states and guarantees are evaluated to calculate whether the IP has to pay penalties.

During the lifetime of the agreement the states of service terms and guarantee terms are monitored (using the OPTIMIS monitoring) to determine whether the service terms are in the state completed and whether (and – depending on the type of guarantee -how often)the guarantee terms have been violated.

3.4.1 Agreement States

The overall Agreement has a state derived from the Agreement protocol. The Agreement State observes the following state model:

OfferReveived

Pending Observed Complete

Rejected PendingAnd Terminating ObservedAnd Terminating Terminated

Figure 3.2 - Agreement state model

Pending, PendingAndTerminating, Observed, ObservedAndTerminating, Rejected, Complete

and Terminated are the normative primary states of an Agreement State. Each state can be extended with one or more sub-states in a specific usage domain. “OfferReceived” is an initial transition state (that is not exposed to the initiator — represented by the dashed lines) to clarify that exposed initial states can be Pending, Observed or Rejected.

Pending - The Pending state means that an Agreement offer has been made but it has been neither accepted nor rejected.

Observed - The Observed state means that an Agreement offer has been made and accepted. This state MAY follow Pending.

Rejected - The Rejected state means that an Agreement offer has been made and rejected. This state MAY follow Pending.

(13)

Complete - The Complete state means that an Agreement offer has been received and accepted, and that all activities pertaining to the Agreement are finished. This state MAY follow Observed.

Terminated - The Terminated state means that an Agreement offer has been terminated by the Agreement Initiator and that the obligation no longer exists. This state MAY follow Pending, PendingAndTerminating, Observed or ObservedAndTerminating when the termination decision is made. The fact that the Agreement is in this state MAY imply that a domain specific penalty is imposed.

PendingAndTerminating - This state means that an Agreement offer has been made and it has not been accepted or rejected and furthermore a Terminate operation has been issued by the Agreement Initiator and is being processed. This state MAY follow Pending. This state MAY be followed by the Pending state in a case where a termination request is made but not accepted by the responder.

ObservedAndTerminating - This state means that that an Agreement offer has been made and accepted. Furthermore, a Terminate operation has been issued from the Agreement Initiator and is being processed by the Agreement Responder. This state MAY follow Observed or PendingAndTerminating. This state MAY be followed by the Observed state in a case where a termination request is made but not accepted by the responder.

3.4.2 Service Term States

The service term state observes the following state model:

Not Ready Ready

Processing Idle

Completed

Figure 3.3 - Service Term States

Not Ready, Ready and Completed are the normative primary states of a service description term. Each state can be extended with one or more sub-states in a specific usage domain. Processing and Idle are two normative sub-states of the primary state Ready.

The semantics of the states is as follows:

NotReady – The service cannot be used yet.

Ready – The service can now be used by a client or be executed by the service provider.

Processing – The service is ready and currently processing a request or is otherwise active.

Idle – The service is ready, however currently not being used.

Completed – The service cannot be used anymore and any service provider activity, e.g. performing a job, is finished. This state does not express whether an execution of a job or service was successful.

(14)

NotReady is the initial state of a service description term while the service is being activated or provisioned. Once a service is ready, it may cycle through the periods of active use and idling, represented by the sub-states of Processing and Idle, respectively. Once a service is completed and cannot be reused further, the service description term reaches the terminal state, marked

Completed. It is important to understand, that the Completed state is reached regardless for which reason the service is completed, e.g. it ended normally fulfilling the request, it failed for some reason, the user aborted it. It is up to the service monitoring to figure out the reason and to eventually initiate corrective measures.

If a service is not ready or idle, the state of a guarantee relating to this service term is not determined. If the service description term is processing or completed, the guarantee term can expose the states fulfilled or violated.

3.4.3 Guarantee States

The guarantee terms follow a simple guarantee states model:

Not Determined

Fulﬁlled

Violated

Figure 3.4 - Guarantee Term States

The semantics of the states are as follows:

Fulfilled – Currently the guarantee is fulfilled.

Violated – Currently the guarantee is violated.

NotDetermined – No activity regarding this guarantee has happened yet or is currently happening that allows evaluating whether the guarantee is met.

NotDetermined is the initial state of a guarantee term, until a service is invoked or fulfilled and assessment is made. Depending on the assessment the terminal state can be either Fulfilled or

Violated. For guarantee terms that require recurring assessment, the term state after every assessment period may be in Fulfilled, Violated or NotDetermined state. If there was no service activity in the preceding window, then the term state will be in NotDetermined state.

(15)

4 WS-Agreement Negotiation

WS-Agreement itself only supports a one-round negotiation process: based on a template an offer is created, which then can be accepted by the consumer or can be rejected; when the consumer accepts the offer, the SLA will be created. In some scenarios a more flexible and dynamic negotiation specification and process is required. Therefore the WS-Agreement Negotiation specification was introduced [8], which adds negotiation and renegotiation capabilities on top of the WS-Agreement specification, and is based on work, which was done in the OGF GRAAP working group in order to standardize an agreement negotiation and renegotiation protocol. The high-level requirements defined for WS-Agreement Negotiation are:

Should be used in conjunction with WS-Agreement

Describes the basic concepts of SLA negotiation and renegotiation Defines the relevant data structures and XML schemas

Defines the Interfaces of the relevant components

In OPTIMIS the negotiation follows the state model described below. The negotiation is based on templates that describe the service quality an IP is willing to deliver. The expected QoS is described in the Service Manifest of the SP and used to select the IP offering the most suitable QoS. Details of the QoS, e.g. the individual TREC parameters, or legal restrictions, may then be negotiated between SP and selected IP.

4.1 Negotiation Model

The WS-Agreement Negotiation model consists of three layers with a clear separation between these layers: the negotiation layer, the agreement layer and the service layer. These layers are depicted in Figure 4.1

(16)

The negotiation layer provides a protocol and a language to negotiate agreement offers and counter offers, and to create agreements based on negotiated offers. The negotiation process comprises the exchange of negotiation offers and counter offers. Negotiation offers, as defined in this specification, are non-binding by nature. They do not comprise any promise of the agreement responder that it will create an agreement based on a negotiated offer. They only indicate the willingness of the two negotiating parties to subsequently create an agreement. However, it is possible to define languages that can be used in conjunction with this specification in order to realize binding negotiation processes.

The agreement layer provides the basic functionality to create and monitor agreements. It comprises the port types defined in the WS-Agreement specification.

At the service layer the actual service defined by an agreement is provided. This service may or may not be a web service, and it may consist of multiple services. A resource provisioning service may for example comprise the provisioning of the specified resources and a monitoring service for the provided resources. The services on the service layer are governed by the agreement layer.

4.2 Negotiation

The negotiation service defines a service instance that is used by the negotiation participators to dynamically exchange information in order to reach a common understanding of a valid agreement offer. During the negotiation process the participators exchange negotiation offers in order to indicate their negotiation goals and requirements.

4.2.1 Negotiation Context

The negotiation context defines the roles of the negotiation participators, their obligations, and the nature of the negotiation process such as negotiation of the new agreements or re-negotiation of the existing agreements.

It optionally can specify additional domain specific negotiation parameters, such number of negotiation rounds or expiration time.

4.2.2 Negotiation Offer

A negotiation offer is a non-binding proposal for a potential agreement that one negotiation party makes to another. One or more negotiation offers made by one or more negotiating parties may precede a binding agreement offer as defined in the WS-Agreement specification. The offer describes the service an SLA to be negotiated is about and the associated quality of service in terms of guarantees. An offer that is created on the base of a previous offer is called counter offer. In general each offer in a negotiation process is a counter offer. In the context of this specification the term counter offer refers to the relationship of the originating offer and the offer that was created on the base of it.

The structure of a negotiation offer shown in Figure 4.2 is basically the same as an Agreement Template. However, a negotiation offer contains the additional elements Negotiation Offer Context and Negotiation Constraints.

(17)

Figure 4.2 - Structure of a Negotiation Offer

The negotiation offer context represents metadata associated with a specific negotiation offer. It contains information such as the id of the offer that was used to create this offer and the expiration time of the offer. It may also contain domain specific extensions in order to define augmented negotiation protocols.

The negotiation constraints are a method to control a negotiation process. A negotiation participator uses negotiation constraints to define the structure or specific values that are applicable for counter offers that are based on a specific offer. Therefore, negotiation constraints are a means to express the requirements of a negotiating party.

4.3 Negotiation Offer States

The negotiation offer state is used to describe a specific state in the life cycle of a negotiation offer. The negotiation offer state can include domain specific data that can be used by the negotiating parties to exchange information related to the offer life cycle, and advance the negotiation process in an efficient way. Figure 4.3 illustrates the states that negotiated offers can have and the valid state transitions.

(18)

Advisory State - The Advisory State identifies negotiation offers with which no further obligations associated. Offers in the Advisory State usually contain elements that are currently not specified. Therefore, these offers require further negotiation.

Solicited State - This state bears no obligations for an offer, but it requires that counter offers are either in the Accepted or the Rejected State. Solicited offers indicate that a negotiation participator wants to converge the negotiation process and requests only counter offers that can be accepted as is, e.g. where no further negotiation of the counter offers is required.

Accepted State - The accepted state indicates that a negotiation participator accepts a negotiation offer as is. All details of a negotiation offer are specified and no further negotiation is required. However, since the negotiated offers are non-binding, there is no guarantee that a subsequent agreement is created. Augmented negotiation protocols may be created based on this specification to address binding negotiations. Rejected State - If a negotiation offer is rejected, it is sent back to the inquiring party with the rejected state. The negotiation offer MAY contain a domain specific reason why it was rejected. Negotiation offers that are marked as rejected MUST NOT be used to create an agreement. However, they MAY be used to continue the negotiation process by taking into account the reason for rejecting the offer.

(19)

5 WSAG4J Framework

The SLA management layer of OPTIMIS will base on, extent, and port existing implementations of WS-Agreement to benefit from experience already made, e.g. described in [4]. One of the most complete and advanced implementation of the Agreement specification is WS-Agreement for Java (WSAG4J, [5]). The SLA management layer based on WS-WS-Agreement comprises a number of reoccurring tasks, which are implemented and automated by the WSAG4J system to a different degree. Domain independent tasks such as template publishing, offer validation, agreement creation and monitoring, and guarantee evaluation are completely automated by the framework. For domain dependent tasks such as service instantiation and monitoring a programming model is provided in order to add this functionality to the WSGA4J system. The framework can be used to realize SLA-aware service provisioning systems for specific application domains and it provides a full implementation of the WS-Agreement protocol and language. The framework comprises features such as the WS-Agreement AgreementFactory port type and the WS-Agreement AgreementState port type. It makes use of digital signatures to enforce message integrity (WS-Security) and also provides the listing of existing agreements via WS-Service Groups. Figure 5.1 shows the basic modules of the WSAG4J framework and their deployment.

Figure 5.1 - WSAG4J Architecture

As described in the WS-Agreement specification, an agreement factory exposes an operation for creating an agreement out of an initial set of terms and returns an Endpoint Reference (EPR) to an Agreement service. The agreement factory also exposes resource properties like templates – representations of acceptable offers for the creation of an agreement. To create an agreement, a client makes an agreement offer which has exactly the same structure as the final agreement. For this purpose the client receives beforehand a list of templates the factory exposes. Like an agreement document, the template is composed of a template name, a context element, and agreement terms, but additionally also includes information on agreement creation constraints to describe a range of agreements it might accept. The agreement factory provides also the capability of negotiating templates, which is an improvement of the initial WS-Agreement protocol.

(20)

6 Term Languages for SLAs in Cloud Environment

This section will focus on the identifications of the term languages for expressing the non-functional properties such as trust, risk, eco-efficiency, cost and legal requirements in a SLA in the context of the OPTIMIS project. These identifications of the languages are based on either the adaptations of existing languages for the use in Cloud environments or definitions of new ones where necessary. These term languages should also be injected into the work of Cloud computing standards bodies to contribute to the improvement of interoperability between different environments.

6.1 Overview of the TREC factors of OPTIMIS

OPTIMIS pursues to optimize the management of relationships in a secure cloud ecosystem based on the TREC factors. This optimization is the foundation of Innovation 2 of the OPTIMIS project: Dependable Sociability = Trust + Risk + Eco + Cost and Innovation 3: Adaptive and Eco-Aware Self-Preservation. OPTIMIS envisages the infrastructure and its services to be able to self-evaluate their own status, controlling and maximizing reliability, cost and energy expenditures. The OPTIMIS Toolkit will provide an innovative holistic approach to perform all management actions (SLA enforcement, elasticity enactment, services consolidation, data placement, replication, etc.) harmonized by overarching policies that will consider trust management and risk assessment to comply with economical and ecological objectives without compromising operational efficiencies. Assessing risk of economical and ecological parameters is a unique, albeit challenging, goal for OPTIMIS. An important aspect of the Toolkit is the capability of IPs to perform admission control policies to verify that an ecological or economical parameter is not lost or exposed to unacceptable risk due to the acceptance of an additional service. This is in part led by internal policies for over- or under-provisioning of resources according to the business goals of the provider. Furthermore, OPTIMIS will allow for negotiation of SLA terms when accepting services.

6.2 Term Language for Trust

Trust is a subjective measure, and to cope with this subjectivity OPTIMIS will assess trust by using reputation mechanisms: the rank of IPs will be based on how well they accomplish promised level of service, while SPs will be ranked according to e.g., the fluctuations in their capacity requirements and their willingness to commit to long term relationships.

Trust Level Robustness Reliability Performance Latency/Response time Network Throughput Security Level

6.3 Term Language for Risk

Risk corresponds to hazardous events that have a negative impact on the provision of functionality. Thus, identifying, assessing, treating, and monitoring risk is imperative for proactive operation of providers in the cloud ecosystem. The treatment of risk must be performed at the service, data, and infrastructure layers, and must consider ecological,

(21)

economical, and security parameters for evaluation. In OPTIMIS, risk is considered during all phases of the service lifecycle and for the two stakeholders: in SPs during service construction, deployment, and operation, and in IPs during admission control and internal operations.

Probability of Failure (PoF) of SLA/Service/VM/Host/etc Risk Impact Level e.g. [very low, low, medium, high, very high] Risk Level, e.g. [very low, low, medium, high, very high]

6.4 Term Language for Eco-efficiency

Environmental concerns reflected in upcoming legislation have increased the awareness of the ecological (Eco) impact of the ICT industry. The level of ecological awareness can now be a deciding factor between competing providers. Furthermore, rising electricity prices may guide the execution of services to locations in which the requested services are provided in a more efficient way. OPTIMIS will make it possible to specify and enforce power consumption limits in SLAs, to decide where services are to execute based on electricity prices, as well as to monitor and assess ecological factors in running services.

Energy used for task or resource, KWh CO2 per task or resource, KG CO2e

What is your annualized average PUE? <Range 1 – 2.5>

Are you European Code of Conduct for data centre compliant? Yes/No (Endorser or full participant)

Do you have an Energy Star for datacenter rating, <Points range or star rating> Are you LEED for data centre rated? <Platinum, gold, silver etc>

And two basic parameters as the subsets or contributors to the above “C02 per task or resource” parameter:

Kg of CO2 offset, KG CO2

Kg of CO2 covered by renewable energy certificates, KG CO2

6.5 Term Language for Cost

Cost aspects are necessary to balance the previous three goals. Optimizing for high trust levels between stakeholders, reduced risk, and incorporating eco-efficiency aspects is trivial if cost is not an issue. In OPTIMIS, cost is an explicit parameter throughout the full service lifecycle. The OPTIMIS tools will incorporate economics-related features and thus will e.g., facilitate comparisons of alternative configurations for a service, giving rise to cost efficient services. These terms and examples are adopted from the Unified Service Description Language (USDL) Pricing Module [13].

PricePlan

A PricePlan is a set of charges associated with a network-provisioned entity. Alternative sets of fees (i.e. alternative PricePlans) of the same service provision may be made available for the consumer to choose from, for example to offer the consumer the choice between a flat price scheme and a usage-based scheme (a common practice in the telecommunication industry). Several PricePlans may exist for the same service in order to suit different user profiles and charge them appropriately (e.g. heavy- and light-usage users), or as a key price customization

(22)

instrument to individually match diverse service valuations. There are three attributes associated with the PricePlan term:

1. currency, as a name string, EString: the currency for all price amounts within this PricePlan, e.g. , EUO.

2. planCap, as a float num., EFloat: providing this maximum PricePlan value prevents from charging the user a higher total price, regardless of the cumulative total price the components and adjustments within this PricePlan may eventually amount to. Example: A cap may be used to set an upper limit in a strictly usage-based plan.

3. planFloor, as a float num., EFloat: providing this minimum PricePlan value prevents from charging the user a lower total price, regardless of the cumulative total price the components and adjustments within this PricePlan may eventually amount to. Example: A floor may be used to set a lower limit to discounts that may result in an excessively low price.

PriceComponent

PriceComponents are fees included in a PricePlan, which subject to conditions (expressed as PriceFences) may contribute to the total amount charged. Components within the same plan are summed together in order to get the total amount (price of the service). Common examples of PriceComponents that may coexist in the same PricePlan are: startup or membership charges (to access the service), periodic subscription fees (with a certain recurrence - e.g. monthly - as long as committed to by the contract), pay-per-unit charges (whose total will be proportional to the metered usage), options or feature dependent charges. The final value of the component will depend on the active PriceLevel (determined by the evaluation of the relative PriceFences) and the PriceAdjustments that may apply (e.g. discounts). There are two attributes associated with the PriceComponent term:

1. componentCap, as a float num., EFloat: providing this maximum PriceComponent value prevents the component final price from exceeding a certain amount, regardless of its levels and the parameters they are indexed to. Example: A cap may be used to set an upper limit for a component whose levels vary with usage.

2. componentFloor, as a float num., EFloat: providing this minimum PriceComponent value prevents the component final price from falling below a certain amount, regardless of its levels and the parameters they are indexed to. Example: A floor may be used to set a lower limit for a component whose levels vary with usage.

PriceLevel

PriceLevel captures amounts charged by a PriceComponent. Since each PriceComponent may assume several values depending on the provider's price segmentation strategies, it is allowed to contain multiple PriceLevels. This allows shaping charged amounts according to customers’ behavior and aligning usage with capacity or incurred costs (just like utilities do by offering different electricity rates for different times of day).

PriceMetric

PriceMetric represents the unit of measurement by which the customer is charged for the consumption of the service or bundle. Metrics can be abstract/un-typed (e.g. per invocation)

(23)

or typed (e.g. per MByte). The latter are covered by the sub-class TypedPriceMetric. The attributes that defines the PriceMetric is the

factor, as a float num., EFloat: the minimum block of units that is priced, i.e. the step increase the price metric may take. It may also be a fraction. Examples: - A Gigabyte metric could be expressed equivalently as a Megabyte metric with a factor 1024 - A professional service priced with hourly rates but charged in 15 minutes increments (factor would be 0.25).

TypedPriceMetric

TypedPriceMetric represents a concretely typed price metric, i.e. a metric associated with a defined unit of measurement. It is defined by one attribute:

typeReference: a pointer to an entity in a type schema that formally specifies the structure of the metric .

Reference: An example of the PricePlan: <pricePlan>

<value> PhotoService</value> <type> name </type>

</names>

(24)

© OPTIMIS Consortium Page 24 of 48 <absoluteAmount>10.00</absoluteAmount> <priceMetrics> <priceMetric>VM_Cost</priceMetric> </priceMetrics> </priceLevel> </componentLevels> <multiplier>totalHours</multiplier> </priceComponent> </planComponents> <planComponents> ………… ………… ………… </planComponents> </pricePlan>

6.6 Term Language for SLA Capturing Legal Requirements

Under EU law framework there are several impacts on the provision or consumption of Cloud services, which may be considered in the OPTIMIS project.

According to the Model Contracts for the transfer of personal data to third countries [12], there are specific rules of how the customer and cloud provider have to come up with a mutual agreement on how to treat the data: The contract will be governed by the law of the Member State in which the data exporter is established, i.e. Greece. While the (Greek) data exporter (i.e. Service Provider) has to ensure that the transfer to the third country is in compliance with Greek data protection law, the exporter additionally has to ensure that the data importer (i.e. Infrastructure Provider in India) is likewise compliant with his instructions and the Clauses. Thus, the data importer must process the data in compliance with Greek data protection law. Within the (Greek) legal framework, the parties are free to agree on any processing of the data.

According to Clause 4 (d) and (e) EU Standard Contractual Clauses, the data exporter (the organization transferring the data to a third country) has to implement appropriate security measures and ensure compliance with these measures. In principle, the requirements are similar to those mentioned in the Data Protection Directive: data must be protected against

Accidental or unlawful destruction Accidental loss

Alteration

Unauthorized disclosure

Unauthorized or access, in particular where the processing involves Transmission of data over a network

(25)

All other unlawful forms of processing

The data exporter then has to agree with the data importer (the organization receiving the data in the third country) on the technical and organizational security measures of the data importer. These must be in compliance with clause 4 (d) EU Standard Contractual Clauses. As a result in practice, both data exporter and data importer should have implemented similar security measures that guarantee appropriate protection of personal data according to the aims mentioned above.

In M24 a report will be published to explicitly address legal factors involved in the OPTIMIS project.

6.7 Term Languages Implemented and Supported for the Year One Demo

While from Section 6.1 to 6.6, a full set of term languages are indentified and proposed for the OPTIMIS project, for year one only a subset of them are implemented in terms of the formal schema definition and supported in terms of the use in the Service Manifest schema. The rest of them will be implemented and integrated into the year two version of the OPTIMIS schema definition and Service Manifest document.

The followings are the TREC factor’s formal schema definitions and corresponding xml template usage examples in the Service Manifest document for year one respectively.

TREC factor’s formal schema definitions for year one:

<!--

Definition of OPTIMIS TREC parameters. --> <xs:complexType name="TRECSectionType"> <xs:sequence> <xs:element name="TrustSection" type="opt:TrustSectionType" minOccurs="0"/> <xs:element name="RiskSection" type="opt:RiskSectionType" minOccurs="0"/> <xs:element name="EcoEfficiencySection" type="opt:EcoEfficiencySectionType" minOccurs="0"/> <xs:element name="CostSection" type="opt:CostSectionType" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="TrustSectionType"> <xs:annotation> <xs:documentation>

Specifies the OPTIMIS trust parameters in a TREC section. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="TrustLevel" type="opt:TrustLevelType"/> <xs:any namespace="##other"

processContents="strict" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>

</xs:complexType>

<xs:simpleType name="TrustLevelType"> <xs:annotation>

(26)

Specifies the OPTIMIS Trust Level that is used for delegation

in a federated cloud scenario.

TODO: is there a specification of the different Trust Levels in OPTIMIS?

</xs:documentation> </xs:annotation> <xs:restriction base="xs:int"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> <!--

Definition of OPTIMIS Risk Constraints. --> <xs:complexType name="RiskSectionType"> <xs:sequence> <xs:element name="RiskLevel" type="opt:RiskLevelType" minOccurs="0"/> <xs:element name="AvailabilityArray" type="opt:AvailabilityArrayType" minOccurs="0"/> <xs:any namespace="##other"

processContents="strict" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>

</xs:complexType>

<xs:complexType name="AvailabilityArrayType"> <xs:sequence>

<xs:element name="Availability"

type="opt:AvailabilityType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="AvailabilityType"> <xs:simpleContent> <xs:extension base="xs:double"> <xs:attribute name="AssessmentInterval" type="xs:duration"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:simpleType name="RiskLevelType"> <xs:annotation> <xs:documentation>

Specifies the OPTIMIS Risk Level that is used for delegation

in a federated cloud scenario.

TODO: see comment TrustLevelType. </xs:documentation> </xs:annotation> <xs:restriction base="xs:int"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> <!--

Definition of OPTIMIS EcoEfficiency Constraints. -->

<xs:complexType name="EcoEfficiencySectionType"> <xs:sequence>

(27)

© OPTIMIS Consortium Page 27 of 48 type="opt:LEEDCertificationConstraintType" default="NotRequired"/> <xs:element name="BREEAMCertification" type="opt:BREEAMCertificationConstraintType" default="NotRequired"/> <xs:element name="EuCoCCompliant" type="xs:boolean" default="false"/> <xs:element name="EnergyStarRating" type="opt:EnergyStarRatingType" default="No"/> <xs:any namespace="##other"

processContents="strict" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:simpleType name="LEEDCertificationConstraintType"> <xs:restriction base="xs:string"> <xs:enumeration value="NotRequired"/> <xs:enumeration value="Certified"/> <xs:enumeration value="Silver"/> <xs:enumeration value="Gold"/> <xs:enumeration value="Platinum"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="BREEAMCertificationConstraintType"> <xs:restriction base="xs:string"> <xs:enumeration value="NotRequired"/> <xs:enumeration value="Pass"/> <xs:enumeration value="Good"/> <xs:enumeration value="VeryGood"/> <xs:enumeration value="Excellent"/> <xs:enumeration value="Outstanding"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="EnergyStarRatingType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="No"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:int"> <xs:minInclusive value="1"/> <xs:maxInclusive value="100"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <!--

Definition of OPTIMIS Cost constraints.

TODO: Additional input required. --> <xs:complexType name="CostSectionType"> <xs:choice> <xs:element name="Price"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:decimal"> <xs:attribute name="currency" type="xs:string"/>

(28)

XML template usage examples in Service Manifest of year one:

<ws:ServiceDescriptionTerm ws:Name="TREC" ws:ServiceName="MultipleImages"> <opt:TRECSection> <opt:TrustSection> <opt:TrustLevel>5</opt:TrustLevel> </opt:TrustSection> <opt:RiskSection> <opt:AvailabilityArray>

<opt:Availability

opt:AssessmentInterval="P1D">98</opt:Availability>

<opt:Availability opt:AssessmentInterval="P1M">99</opt:Availability> </opt:AvailabilityArray> </opt:RiskSection> <opt:EcoEfficiencySection> <opt:LEEDCertification>NotRequired</opt:LEEDCertification> <opt:BREEAMCertification>NotRequired</opt:BREEAMCertification> <opt:EuCoCCompliant>false</opt:EuCoCCompliant> <opt:EnergyStarRating>No</opt:EnergyStarRating> </opt:EcoEfficiencySection> <opt:CostSection> <opt:Price opt:currency="EUR">100.00</opt:Price> </opt:CostSection> </opt:TRECSection> </ws:ServiceDescriptionTerm>

Finally, we present an example of the possible further implementations of the full term language for Risk factors. The term language is proposed for the considerations of integration into the OPTIMIS Schema and corresponding application in the Service Manifest document of the year two version.

And the full set of term languages of other TREC factor and legal factor will also be fully implemented and integrated into the year two OPTIMIS schema.

Proposed formal schema definition of full term language for Risk factor for year two: <!--

Definition of OPTIMIS Risk Constraints. -->

(29)

<xs:complexType name="RiskSectionType"> <xs:sequence>

<xs:element name="PoF" type="opt:RiskPoFType" minOccurs="0"/> <xs:element name="RiskLevel" type="opt:RiskLevelType" minOccurs="0"/> <xs:element name="RiskImpactLevel" type="opt:RiskImpactLevelType" minOccurs="0"/>

<xs:any namespace="##other" processContents="strict" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:simpleType name="RiskPoFType"> <xs:annotation> <xs:documentation>

Specifies the acceptable Probability of Failure (PoF) of the service manifest </xs:documentation> </xs:annotation> <xs:restriction base="xs:double"> <xs:minInclusive value="0.0"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="RiskLevelType"> <xs:annotation> <xs:documentation>

Specifies the OPTIMIS Risk Level </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="VeryLow"/> <xs:enumeration value="Low"/> <xs:enumeration value="Medium"/> <xs:enumeration value="High"/> <xs:enumeration value="VeryHigh"/> </xs:restriction>

(30)

</xs:simpleType>

<xs:simpleType name="RiskImpactLevelType"> <xs:annotation>

<xs:documentation>

Specifies the OPTIMIS Risk Impact Level </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="VeryLow"/> <xs:enumeration value="Low"/> <xs:enumeration value="Medium"/> <xs:enumeration value="High"/> <xs:enumeration value="VeryHigh"/> </xs:restriction> </xs:simpleType>

And the proposed Risk factor’s XML template usage examples for the Service Manifest of year two: <opt:RiskSection> <opt:PoF>0.05</opt:PoF> <opt:RiskLevel>Medium</opt:RiskLevel> <opt:RiskImpactLevel>Medium</opt:RiskLevel> </opt:RiskSection>

(31)

7 Summary

In its first part the deliverable presented the foundations of the OPTIMIS SLAs: WS-Agreement and Agreement Negotiation. WSAG4J - the implementation of Agreement and WS-Agreement Negotiation – used in OPTIMIS to negotiate and create SLAs was introduced. The second part of the deliverable focused on the term languages to express TREC parameters and legal requirements in OPTIMIS SLAs. Based on the specific requirements for term languages in Clouds in general and for the OPTIMIS framework in particular, term languages of definitions on non-functional aspects of a cloud service are identified and proposed in this section, which adapts existing languages and define new ones where necessary.

(32)

8 References

[1] Jan Seidel; Oliver Wäldrich; Philipp Wieder; Ramin Yahyapour; Wolfgang Ziegler: Using SLA for Resource Management and Scheduling - A Survey. Grid 2007, Workshop on Using Service Level Agreements in Grids, Austin, USA, September 2007, Springer 2008, CoreGRID Series 8, P. 335 - 347.

[2] Parkin, M., Badia, R, Martrat, J.: A Comparison of SLA Use in Six of the European Commissions FP6 Projects, CoreGRID Technical Report TR-0129, Institute on Resource Management and Scheduling, CoreGRID - Network of Excellence, http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0129.pdf

[3] GRAAP-WG, Open Grid Forum: List of WS-Agreement Implementations

https://forge.gridforum.org/sf/wiki/do/viewPage/projects.graap-wg/wiki/Implementations.

[4] Battré, D., Havestadt, M., Wäldrich, O., Lessons learned from implementing WS-AGREEMENT, Grid 2009, IEEE Workshop on Service Level Agreements in Grids, Springer, CoreGRID Series, to appear.

[5] Oliver Wäldrich: WS-Agreement for JAVA (WSAG4J), http://packcs-e0.scai.fraunhofer.de/wsag4j/

[6] IBM Web Service Level Agreement: http://www.research.ibm.com/wsla/

[7] Web Services Resource Framework:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf

[8] Oliver Waeldrich et al., WS-Agreement Negotiation Version 1.0:

https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.graap-wg/docman.root.current_drafts.ws_agreement_negotiation_specifi/doc16194/2

[9] Web Services Agreement Specification, OGF (GFD.107):

http://www.ogf.org/documents/GFD.107.pdf

[10] Grid Resource Allocation Agreement Protocol working group (GRAAP-WG) http://www.ogf.org/gf/group_info/view.php?group=graap-wg

[11] NextGRID SLA Schema Generalized Specification. Available at: http://www.nextgrid.org/GS/management_systems/SLA_management/NextGRID_SLA_sc hema.pdf.

[12]Model Contracts for the transfer of personal data to third countries: http://ec.europa.eu/justice/policies/privacy/modelcontracts/index_en.htm

[13]Unified Service Description Language (USDL) Pricing Module: http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0-M5-pricing.pdf

[14]WSAG4J framework. Available at: http://packcs-e0.scai.fraunhofer.de/wsag4j/

OPTIMIS SLA Framework and Term Languages for SLAs in Cloud Environment

Project Acronym:

OPTIMIS

Project Title:

Optimized Infrastructure Services

Project Number:

257115

Instrument:

Integrated Project

Thematic Priority:

ICT-2009.1.2 – Internet of Services, Software and

Virtualisation

OPTIMIS SLA Framework and Term

Languages for SLAs in Cloud

Environment

Activity 2:

Service Construction

WP 2.2:

Cloud QoS Contracting and Service Configuration

Due Date:

M12

Submission Date:

31/05/2011

Start Date of Project:

01/06/2010

Duration of Project:

36 months

Organisation Responsible for the Deliverable:

SCAI and ULEEDS

Version:

1.0

Status

Final

Author(s):

Wolfgang Ziegler

Ming Jiang

SCAI

ULeeds

Reviewer(s)

Johan Tordsson

Kleopatra Konstanteli

UMU

ICCS/NTUA

Table of Contents

Index of Figures

1

Executive Summary

2

Introduction

2.1

Purpose

2.2

Glossary of Acronyms

3

WS-Agreement

3.1

Rationales for using WS-Agreement

3.2

Structure

3.3

Monitoring of an Agreement

3.4

WS-Agreement states

4

WS-Agreement Negotiation

4.1

Negotiation Model

4.2

Negotiation

4.3

Negotiation Offer States

5

WSAG4J Framework

6

Term Languages for SLAs in Cloud Environment

6.1

Overview of the TREC factors of OPTIMIS

6.2

Term Language for Trust

6.3