A semi autonomic infrastructure to manage A semi autonomic infrastructure to manage non functional properties of a servicenon functional properties of a service

Pierre de LeussePanos PeriorellisPaul WatsonTheo Dimitrakos

UK e-Science AHM 2008 - September 10th Edinburgh

© British Telecommunications plc

ContentContent

• Introduction• Our vision• Objectives• Results• Adaptive security• Future research

© British Telecommunications plc

IntroductionIntroduction

R*S*C = enormous amount of work in development and maintenance

(Resource, Settings, Clients)

© British Telecommunications plc

What is Cloud?

• Resources comes from "the cloud", a public network (e.g. the Internet), rather than from a specific identifiable system

• “Computing systems that can manage themselves given high-level objectives from administrators”

– Automation of management tasks (e.g. Amazon Simple Storage Service S3)

• Paradox: add a level of complexity to allow easier tasks for the end user

– Computing resource is a wider concept (e.g. O.S.)• Take advantage of the Non Functional Property (NFP)

providers in the Cloud

© British Telecommunications plc

Prospect - ObjectivesProspect - Objectives

• Manage a resource’s non-functional properties effectively– Allow for rapid change and possibly adaptation

• Allow for an easy integration of potential non-functional properties “handlers”

• Control the quality and security of the non-functional properties management

• Propose an architecture which will enable seamless integration

• Guarantee an able management of the messages

© British Telecommunications plc

Results – Resource ProfileResults – Resource Profile

• Uric acid• Glucose• Iron• Phosphorus• Potassium• Sodium• Total protein• …

• • • • • • • •

AuthenticationAuthorisation

AuditLogging

BillingEncryptionTransport

…

© British Telecommunications plc

Results – Resource ProfileResults – Resource Profile

• Set of non functional properties required• Adaptation level

• Adapt: the broker should find a possible profile as close as possible from the user’s requirements.

• Strictly enforce: the broker should not try to modify the element required and provide it or nothing.

• Request user’s validation: any attempt to change this element should go through the user’s validation before being put in place.

These properties can concern the profile as a whole or an single element

• Resource owner's policies

© British Telecommunications plc

Results – Broker ArchitectureResults – Broker Architecture

Managed Profile Architecture

Infrastructure services

© British Telecommunications plc

Sources of adaptationSources of adaptation

• External factors:– Static/negotiable contract or resource profile (e.g.

RosettaNet Partner Interface Processes (PIPS))– Modification of existing requirements (e.g. security threat

is discovered, user modifications)

• Internal factors:– Unavailability of components

© British Telecommunications plc

Potential output - Adaptive SecurityPotential output - Adaptive Security

Managed Security Profile

© British Telecommunications plc

Evaluation strategyEvaluation strategy

• Qualitative evaluation:– Relevance of the adaptation towards:

• user's request • targeted resource• safety of the resource

– Relevance of the profile• relevance of the safe profile usage• adequacy of selected services• suitability of profile implemented• correctness of profile called

• Quantitative evaluation:– rapidity– scalability limit

© British Telecommunications plc

Future researchFuture research

• Experimentation / Evaluation

• Trust / Security brokering

• Performance

© British Telecommunications plc

SummarySummary

• Context: ever increasing level of complexity– standards and protocols– distributed systems themselves

• Goal: improve the adaptability of resources

• Solution: a broker based architecture that allows for a more dynamic management of the non functional properties

© British Telecommunications plc

Thank youThank you

Pierre de LeusseRoom 2.19, Devonshire Building

School of Computing Sciences

Newcastle University

United Kingdom

(0044)-191 222 8268

pierre.de-leusse@ncl.ac.uk