University of Dublin Trinity College - School of Computer ... · This is where Autonomic Behaviour is defined . University of Dublin Trinity College ... • Intra-organisational integration

University of Dublin Trinity College

Autonomic Management and Ontologies

Example Application Domain


Autonomics 101

With thanks to IBM

Autonomic Management and Ontologies © Declan O’Sullivan 3

Growing Complexity… Future network environment and system

Core Network

Satellite

Broadcast Networks

(DAB, DVB-T)

The Internet

ISP

CDMA, GSM, GPRS

IP-based micro-mobility

Wireless LANs

Signalling Gateway

WAP Accounting

Context-aware information Centre

Billing VHE SIP Proxy Server

WiBro, HSDPA

4G Bluetooth Zigbee

access operator

ISP

ASP

corporation

DMB

MP3

Camera

M-banking

Cam Navigation


Growing Complexity… Service Oriented Environments


Growing Complexity… Very large scales

•  million of entities

Ad hoc (amorphous) structures/behaviors •  p2p/hierarchical architecture

Dynamic •  entities join, leave, move, change behavior

Heterogeneous •  capability, connectivity, reliability, guarantees, QoS

Unreliable •  components, communication

Lack of common/complete knowledge •  number, type, location, availability, connectivity, protocols, semantics, etc.


Coping with complexity… Our system programming paradigms, methods and management tools seem to be inadequate for handling the scale, complexity, dynamism and heterogeneity of emerging future network and systems Biological systems have evolved strategies to cope with dynamic, complex, highly uncertain constraints Recently, research applying biological system concepts to solve its unsolved problems


Autonomic Computing Autonomic

•  Pertaining to an on demand operating environment that responds automatically to problems, security threats, and system failures

•  Cf) self-adaptive, self-governing, self-managing, … The term “autonomic” is derived from human biology – autonomic nervous system

•  ANS monitors heartbeat, body temperature, … –  Without any conscious effort on one’s part!

Nature has evolved to cope with scale, complexity, heterogeneity, dynamism and unpredictability, lack of guarantees

•  self configuring, self optimizing, self healing, self protecting, highly decentralized, heterogeneous architectures that work !!!

The goal of autonomic computing is to use appropriate solutions based on current state/context/content based on specified policies


Autonomic Computing Attributes

Self-managing systems that deliver Increased Responsiveness Adapt to dynamically changing environments

Business Resiliency Discover, diagnose,

and act to prevent disruptions

Operational Efficiency Tune resources and balance workloads to maximize use of IT resources

Secure Information and Resources

Anticipate, detect, identify, and

protect against attacks


Autonomic model (MAPE)


How to get there…


Key Aspects of an Autonomic System Model

Various

SOUPA

Policy models Ponder, XACML,

PCIM

Rei, Kaos,

DARPA XG SWRL

Resource models

MIBs, CIM, SID

OWL…

CORBA, RMI, WSDL

OWL-S, WSMO

Ontologies becoming lingua franca

This is where Autonomic Behaviour is defined


Engineering Autonomics

The role of ontologies


Questions What is the potential role of Ontologies in the Engineering of Autonomic Systems? What are the benefits and costs of engineering with ontologies? Where do we go from here?

© David Lewis


Key Aspects of an Autonomic System Model

Various

SOUPA

Policy models Ponder, XACML,

PCIM

Rei, Kaos,

DARPA XG SWRL

Resource models

MIBs, CIM, SID

OWL…

CORBA, RMI, WSDL

OWL-S, WSMO

Ontologies becoming lingua franca

This is where Autonomic Behaviour is defined

© David Lewis


Adaptive Service Element A Reference Model to show how ontology based semantics can help integrate:

•  service-oriented modelling •  resource-modelling •  policy-based management •  context-modelling

Resource is logically managed / wrapped by a service Service Elements have well defined inputs and output and can be composed Service Element’s operation and adaptation is dependent on its preconditions and effects Adaptive behaviour can be:

•  Context Driven •  Constrained by Policy

Not an ‘Autonomic Service Element’

Adaptive behaviour

model Input Output

Preconditions Effects

Policy Management Interface

Resources Context

© David Lewis


Wireless Access

ISP Service

Sensor Network

Adaptive behaviour

model Input Output

Preconditions Effects

Policy Mgmt i/f

Resources Context

User User or Value

Governened Adaptive Service Element

Application Service

Network Service

Client Application

E2E service policies

Policy Refinement

Composite Autonomic System – combines:

•  Service-oriented provision of value

•  Policy-based governance

•  Context-Awareness •  Resource

management

E2E Service

Policy Refinement

S S C C C R R R

© David Lewis

namespace { _"http://www.dmtf.org/CIM_Device29/Printers#" } concept PrinterJob JobId ofType (1 1) _string JobSize ofType (1 1) _integer MimeTypes ofType MimeType RequiredPaperType ofType (1 1) PaperType Copies ofType (1 1) _integer DefaultNumberUp ofType (0 1) NumberUp HorizontalResolution ofType (0 1)_integer NumberUp ofType (0 1) NumberUp PrintJobstatus ofType (1 1) _string TimeComplete ofType (0 1) time RequiredJobSheets ofType (1 1) _integer OwningPrinterQueue ofType (1 1) PrintQueue PrinterServiceJob ofType (1 1) Printer

concept PrintQueue NumberOnQueue ofType (1 1) _integer MaxJobSize ofType (1 1) _integer OwnPrintJobs ofType PrinterJob PrinterServiceQueue ofType Printer

concept Printer subConceptOf LogicalDevice PrinterStatus ofType (1 1) _string DetectedErrorState ofType (0 1) _string ErrorInformation ofType (0 1) _string PaperSizesSupported ofType PaperSize PaperSizesAvailable ofType PaperSize DefaultPaperType ofType (0 1) PaperType CurrentPaperType ofType (0 1) PaperTpye MimeTypesSupported ofType MimeType CurrentMimeType ofType (0 1) MimeType DefaultMimeType ofType (0 1) MimeType JobCountSinceLastReset ofType (1 1) _integer TimeOfLastReset ofType (0 1) time MaxCopies ofType (0 1) _integer DefaultCopies ofType (0 1) _integer MaxNumberUp ofType (0 1) NumberUp DefaultNumberUp ofType (0 1) NumberUp HorizontalResolution ofType (0 1) _integer VerticalResolution ofType (0 1) _integer MaxSizeSupported ofType (0 1) _integer AvailableJobSheets ofType (0 1) _integer Capabilities ofType Capability DefaultCapabilities ofType (0 1) Capability CurrentCapability ofType (1 1) Capability

namespace { _"http://example.org/ont#", dc _"http://purl.org/dc/elements/1.1#", cimPr "http://www.dmtf.org/CIM_Device29/Printers", uPnPPr_"http://www.upnp.org/services/wsmo/

PrintBasicv1_01" } ontology uPnPPr#CreatePrintJob concept uPnPPr#CreatPrintJobReq uPnPPr#JobName ofType (0 1) _string uPnPPr#JobOriginatingUserName ofType (1 1) _

string uPnPPr#DocumentFormat ofType (1 1)

cimPr#MimeType uPnPPr#Copies ofType (0 1) _integer uPnPPr#Sides ofType (0 1) cimPr#SideTypes uPnPPr#NumberUp ofType (0 1)

cimPr#NumberUp uPnPPr#OrientationRequested ofType (0 1) uPnPPr#PaperOrientation uPnPPr#MediaSize ofType (0 1) cimPr#PaperSize uPnPPr#MediaType ofType (0 1) cimPr#PaperType uPnPPr#PrintQuality ofType (0 1) cimPr#Capability

interface CreatePrinterJobIntf choreography CreatePrinterJobChor stateSignature CreatePrinterJobSig importsOntology { "http://www.upnp.org/services/wsmo/PrintBasicv1_01”,

"http://www.dmtf.org/ont/CIM_Device29/Printers"}

in uPnPPr#CreatPrintJobReq out cimPr#PrinterJob

transitionRules PrinterPolicies forall (?request) with (?request memberOf uPnPPr#CreatePrintJobReq and ?request[uPnPPr#DocumentFormat hasValue ?format] and ?request[uPnPPr#Copies hasValue ?copies] and ?request[uPnPPr#NumberUp hasValue ?numup] and ?request[uPnPPr#MediaSize hasValue ?size] and ?request[uPnPPr#MediaType hasValue ?type]

and ?request[uPnPPr#PrintQualit hasValue ?qual] and ?queue[cimPr#PrinterServiceQueue hasValue ?printer] and ?printer[cimPr#MaxCopies hasValue ?maxcopies]

) do add(?job [ cimPr#MimeType hasValue ?

format, cimPr#RequiredPaperType hasValue ?type, cimPr#Copies hasValue ?copies, cimPr#NumberUp hasValue ?numup, cimPr#PRinterServiceJob hasValue ?printer, cimPr#OwningPrinterQueue hasValue ?queue

] memberOf cimPr#PrinterJob) | if ?copies > ?maxcopies then

update(?job[cimPr#Copies hasValue ?maxcopies]) | if ?copies > 100 then update(?job[cimPr#NumberUp hasValue 2]).


Benefits of Engineering with Ontologies

Integration of key modelling aspects Progressive modelling of elements

•  Progressive conceptual understanding

Easier integration of separately sourced models •  Good for multi-vendor systems and value chains •  Integrating with models from completely different domains, e.g. GIS, genetics etc.

Logical consistency checks Exploit general purpose reasoners and tools (Jena, Protégé etc) Non Benefit:

•  Does not help model adaptive behaviour – FSM is minimum, but can expect many non-deterministic models, e.g. bio-inspired

© David Lewis


ASE-Specific Benefits Services

•  More accurate service discovery (provided service offerings are accurate) •  Runtime interoperability

Resources •  More complete model through axiom and rules? •  Progressive, incremental models?

Policy •  Determining applicable policies •  Extensibility – primarily in semantics of condition and targets •  Impact on refinement and conflict handling?

Context •  Gathering context from unknown, heterogeneous sources

–  Widespread in ubicomp research •  Middleware emerging – KBN, Construct etc

© David Lewis


Costs

Classic Semantic Bootstrap problem •  SemWeb: Someone has to bear the costs of providing semantic markup of

content For ASE, the equivalent is Grounding

•  OWL-S/WSMO to WSDL •  Resource models to MIBS/CIM/SID •  Context and policies to native forms

Ontological form may not be best for •  Transmission or storage •  Runtime-matching or interoperability •  Non-DL or rule-based reasoning, e.g. temporal reasoning, sub-reasoning

Must maintain groundings to versions of ‘normative’ models Must frequently invoke grounding mapping function

•  May not be fully automated

© David Lewis


Cost-Benefit Analysis

Benefits win out where: •  Grounding costs are minimised – especially where ontology used for

normative/canonical form •  Service (re)composition and/or changes to policies and context are

frequent and preferably dynamic •  Open market with lots of ASE offerings

Costs win out where: •  Grounding cost are high: non-ontological languages used for core

engineering modelling •  Frequency of change is low and resource/behaviour complexity is high •  Intra-organisational integration more common than inter-organisation

© David Lewis


Likely Application Domains Favours communications domains where:

•  Level of innovation in services and networks is high •  Services and networks can be freely integrated •  Complexity is compositional

Less appealing where: •  Large body of legacy models •  Resource control and commoditisation are priorities •  Complexity is monolithic

Favours •  Internet/mobile application services - Software as a Service •  Lightly regulated wireless – MANETS, Mesh, Cognitive Radio •  Pervasive Computing

Less suited: •  Wired-backbones, expensive/static network elements, ISPs, 3G

© David Lewis


Next Steps

Mixed initiative engineering and governance tools providing help with: •  Inconsistencies when integrating ontologies •  Incompleteness when building models •  Explaining reasons for policy conflicts •  Suggesting policy refinement paths •  Browsing/searching large populations of models •  Developing grounding mappings – including natural language processing •  Developing semantic interoperability mappings •  Version control

Leave Protégé to the SemWeb researchers – need stronger, modular engineering platform, i.e. Eclipse

© David Lewis


Next Steps Tool design need a better understanding of tensions between optimal semantic forms (including non-ontological) for:

•  Sharing and integration •  Human comprehension •  Automated reasoning

Need to understand when to move from general purpose ontological tools and reasoners and to optimised-but-constrained versions

•  From innovation phase to production/provision phase

Semantics for Benchmarking (and benchmarking for semantics)

•  Abstract user/traffic patterns, failure models, threat models

© David Lewis


Ontology-based Engineering - Summary

May be necessary but certainly isn’t sufficient for modelling an autonomic system or its elements

•  Good for monitoring, analysis and execution – not so much for planning

May not be necessary in all cases to providing cost-saving benefits of an autonomic system Definitely necessary to reap the value-adding benefits of autonomic systems

•  Maintaining operational savings of self-management through business change

•  Supporting innovation in creating business value

© David Lewis

Documents

University of Dublin Trinity College - School of Computer ... · This is where Autonomic Behaviour is defined . University of Dublin Trinity College ... • Intra-organisational integration