A semi autonomic infrastructure to manage non functional properties of a service Pierre de Leusse Panos Periorellis Paul Watson Theo Dimitrakos UK e-Science AHM September 10 th Edinburgh

© British Telecommunications plc Content Introduction Our vision Objectives Results Adaptive security Future research

© British Telecommunications plc Introduction 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 - 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 Profile Uric acid Glucose Iron Phosphorus Potassium Sodium Total protein … Authentication Authorisation Audit Logging Billing Encryption Transport …

© British Telecommunications plc Results – 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 Architecture Managed Profile Architecture Infrastructure services

© British Telecommunications plc Sources 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 Security Managed Security Profile

© British Telecommunications plc Results Profile Manager –The enactment engine retrieves the relevant CCM from the Client Registry at run time and implements the appropriate SP.

© British Telecommunications plc Results

Evaluation 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 research Experimentation / Evaluation Trust / Security brokering Performance

© British Telecommunications plc Summary 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 you Pierre de Leusse Room 2.19, Devonshire Building School of Computing Sciences Newcastle University United Kingdom (0044)