FIFR@SLA@SOI

From FutureInternetWiki

Jump to: navigation, search

This page describes how SLA@SOI, as an Affiliated Project, relates to the Future Internet Functional Requirements (FIFR).

Contents

[edit] Project Information

Project Name: SLA@SOI (Empowering the Service Economny with SLA-aware infrastructures)

Project Homepage: http://www.sla-at-soi.eu

Contact Person: John Kennedy, Joe Butler

Architecture/Interaction Diagram

Image:Slaatsoi interaction l.jpg

[edit] Statement

SLA@SOI is a three year project, launched in June 2008, that is committed to research, engineer and demonstrate technologies that can embed Service-Level-Agreement -aware infrastructures into the service economy of the future.

In particular, the project is looking to bring three major benefits to the provisioning of services:

  • Predictability & Dependability: The quality characteristics of services can be predicted and enforced at run-time.
  • Transparent SLA management: SLAs defining the exact conditions under which services are provided/consumed can be transparently managed across the whole business and IT stack.
  • SLAs and provisioning, delivery and monitoring of services will be automated allowing for highly dynamic and scalable service consumption.

The initiative includes tracks dedicated to Business Management, Service Management, Infrastructure Management, SLA Foundations and Predictable Systems Engineering. The project is anchored to the real world by five diverse but complementary Use Cases.

SLA@SOI is addressing key challenges facing the internet of the future, particularly in the areas of Large-scale computing, Notification Services, Trust and Service Infrastructure. Specific functionality is referenced below. Please contact any member of the consortium for further information.

[edit] Related Future Internet Functional Requirements

[edit] Visionary

6. Large-scale computing
c. Trustworthy sharing of computing systems including data
  Comment: 'SLA@SOI is researching how and to what extent the definition, negotation, monitoring and disposition of 
  SLAs can be formalised and automated between a customer and service (in the broad sense) provider. The trustworthy 
  provisioning of cloud-computing infrastructure is an important component of this relationship. An SLA-aware framework
  that includes rich monitoring at all levels of the SLA stack, the prediction of SLA violations, dynamic reprovisioning
  and appropriate alerting all the way to the customer will help deliver the trustworthy sharing of computer systems.'
g. Virtualization cross-business boundaries
  Comment: 'Core to SLA@SOI is the negotiation and management of machine-readable SLAs between customers and service
  providers. Software services typically need to be provisioned on dynamically allocated infrastructure, again provided in
  accordance with an SLA. Virtualisation is a key enabler for this Infrastructure as a Service / Cloud-computing paradigm.'
7. Service Orchestration
b. Service-On-Demand (coordination & registration of physical services) available on a large scale
  Comment: 'The dynamic delivery of services based on the on-demand orchestration of lower level services (business, 
  software & infrastructure) is a fundamental aspect SLA@SOI.'
f. Service Trading
  Comment: 'SLA@SOI inherently supports the trading of services by realising computable service level agreements 
  (including models and negotiation protocols) together with a dedicated eContracting component that addresses the automation of
  trading procedures.'
j. Service composition modelling
  Comment: 'SLA@SOI is investigating models for reflecting service and SLA hierarchies which can be used for dynamic composition.'

[edit] Incremental

3. Notification Services
d. Early warnings
  Comment: 'SLA@SOI is implementing comprehensive monitoring and alerting functionality to support SLA-awareness. Prediction services are
  used to warn of the potential violation of SLAs, automatically triggering dynamic reprovisioning where possible to prevent the violation.'
  
8. Trust
a. Protect personal information
  Comment: 'Although not a focus of the project, SLA@SOI allows privacy requirements to be explicitly declared via SLA Non-Functional Parameters.'
b. Trust into service providers
  Comment: 'Trust is a  prerequisite to IaaS / Cloud Computing.'
e. SLAs
  Comment: 'SLA-awareness is core to SLA@SOI. '
10. Service Infrastructure
a. Virtualization
  Comment: 'Virtualization is a core enabler for the Infrastructure as a Service / cloud computing model that SLA@SOI is delivering.
  As well as allowing more efficient utilisation of infrastructure, virtualisation allows infrastructure to be dynamically reprovisioned. 
  With live-migration, the reprovisioning can be invisible to the customer.'
b. Operating environments for virtual clouds
  Comment: 'SLA@SOI is creating an infrastructure management framework that can be used to manipulate arbitrary internal and external 
  providers. Services can thus be deployed in virtual clouds - be they wholly internal or external, or spanning the two.'
c. Energy management in service provisioning
  Comment: 'Energy management can be defined by customer via NFPs, and can also be optimised internally based on provider policies.' 
  providers. Services can thus be deployed in virtual clouds - be they wholly internal or external, or spanning the two.'
d. Lifecycle management of services.
  Comment: 'SLA management in SLA@SOI covers the entire lifecycle of services: from creation, description and offering to negotiation,
  scheduling, provisioning and ultimately monitoring, adjustment and tear down.'
e. Formal definition of non-functional requirements.
  Comment: 'Non-functional requirements are typically a very important part of SLAs - the model for SLAs developed by SLA@SOI supports
  both functional and non-functional requirements, and the framework being developed by the project understands, monitors and manages them.'
f. Optimization of geographical deployment of services on physical infrastructure
  Comment: 'SLA@SOI appreciates that some customers of infrastructure providers will have geographical requirements for their services.
  e.g. data remains within the bounds of a particular country for legal reasons. The models and framework being developed by SLA@SOI support
  this aspect of geographical deployment.'

[edit] Additional Related URLs

Personal tools