Embed Size (px)
Citation preview
SelfConFoil no 1
Self configuring systems
- introduction I
SelfConFoil no 2
Self configuring
By self configuring we mean systems and components that configure themselves and dynamically adapt to changing environments with minimal human participation.
Many systems have some degree of self-configuration, but the abilities vary:
• static systems: parameter adaptation
• dynamic systems: compositional adaptation
• autonomic systems: self*
By self configuring we mean systems and components that configure themselves and dynamically adapt to changing environments with minimal human participation.
Many systems have some degree of self-configuration, but the abilities vary:
• static systems: parameter adaptation
• dynamic systems: compositional adaptation
• autonomic systems: self*
System Environment
SelfConFoil no 3
Autonomic systems
The Autnonomic Computation Initiative (IBM):
believes the growing complexity of modern networked computer systems is the biggest limiting factor in their expansion and therefore we need:
• Self-Configuration: Automatic configuration of components;
• Self-Healing: Automatic discovery, and correction of faults;
• Self-Optimization: Automatic monitoring and control of resources to ensure the optimal functioning with respect to the defined requirements;
• Self-Protection: Proactive identification and protection from arbitrary attacks.
• http://www-03.ibm.com/autonomic/• http://en.wikipedia.org/wiki/Self-Management
• http://en.wikipedia.org/wiki/Autonomic_Computing
The Autonomic Communication Forum:
believes that a radical paradigm shift towards a self-organising, self-managing and context-aware autonomous network, considered in a technological, social and economic context, is the only adequate response to the increasingly high complexity and demands now being placed on the Internet
• http://www.autonomic-communication-forum.org/
The Autnonomic Computation Initiative (IBM):
believes the growing complexity of modern networked computer systems is the biggest limiting factor in their expansion and therefore we need:
• Self-Configuration: Automatic configuration of components;
• Self-Healing: Automatic discovery, and correction of faults;
• Self-Optimization: Automatic monitoring and control of resources to ensure the optimal functioning with respect to the defined requirements;
• Self-Protection: Proactive identification and protection from arbitrary attacks.
• http://www-03.ibm.com/autonomic/• http://en.wikipedia.org/wiki/Self-Management
• http://en.wikipedia.org/wiki/Autonomic_Computing
The Autonomic Communication Forum:
believes that a radical paradigm shift towards a self-organising, self-managing and context-aware autonomous network, considered in a technological, social and economic context, is the only adequate response to the increasingly high complexity and demands now being placed on the Internet
• http://www.autonomic-communication-forum.org/
SelfConFoil no 4
Self* builds on variability at runtime
• Areas of variability (Artifacts):
•Services
•Designs
•Deployment
•HW/SW components and platforms
• Kinds of variability:
•Parameter values
•Object and role structure
•Object and role types/classes
•Role binding
•Behavior composition
•Policies
•Mapping/transformation relationships
• Areas of variability (Artifacts):
•Services
•Designs
•Deployment
•HW/SW components and platforms
• Kinds of variability:
•Parameter values
•Object and role structure
•Object and role types/classes
•Role binding
•Behavior composition
•Policies
•Mapping/transformation relationships
S1
S3
S2
Design synthezis
S1.1 S2.1
S3.1 S2.2
Program generation
Services
Designs
Deployment,Realization,Execution
Self* mechanisms – what and how?
SelfConFoil no 5
Static systems (SDL systems)
• Stable parts (cannot be added or changed dynamically) :
•System content(design) structure
•Block/process sets
•Set of types
• Variability:
•Number of instances in block/process sets
•Parameter and variable values
•Static and dynamic links (PId values)
• Is some degree of self configuring possible?
• Stable parts (cannot be added or changed dynamically) :
•System content(design) structure
•Block/process sets
•Set of types
• Variability:
•Number of instances in block/process sets
•Parameter and variable values
•Static and dynamic links (PId values)
• Is some degree of self configuring possible?
System X
b(,):BT
c(,):CT
d(,):DT
a(,):AT??
??
??
??
??
SelfConFoil no 6
Self configuring in static (SDL) systems
• Interrogating the environment and obtaining information
• Using the information to:
•create instances within the block/process sets
•create references linking instances
• initialise and change data
• Note that the information must be dynamically provided by the environment! A configuration file prepared by a human operator does not count!
• Self configuration therefore requires descriptive information - metadata - about the environment to be provided by the environment (reflection).
• Such information must be provided for each variable part (components)
• Interrogating the environment and obtaining information
• Using the information to:
•create instances within the block/process sets
•create references linking instances
• initialise and change data
• Note that the information must be dynamically provided by the environment! A configuration file prepared by a human operator does not count!
• Self configuration therefore requires descriptive information - metadata - about the environment to be provided by the environment (reflection).
• Such information must be provided for each variable part (components)
SelfConFoil no 7
How to do it?
we need:
• to use dynamic references and routing (indirection)
• functionality to discover/explore and monitor the environment: Registry
• functionality to interpret the information and configure the system - create the internal instance structure, assign references and data values: Configurer
we need:
• to use dynamic references and routing (indirection)
• functionality to discover/explore and monitor the environment: Registry
• functionality to interpret the information and configure the system - create the internal instance structure, assign references and data values: Configurer
System X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
Configurer
Here the system adapts to changes in the
environment
Registry may be distributed
What if adaptation is mutual?
SelfConFoil no 8
Object plug-and-play
1. object plug-in
2. registration
3. notification
4. creation
5. binding and use
1. object plug-in
2. registration
3. notification
4. creation
5. binding and use
System X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
Configurer
1
2
3
4
5
Think of some
examples
SelfConFoil no 9
Static and dynamic linking:
find, bind-release
• Find instances (of predefined types) :
• Identified instances or instance sets; e.g. Doctors, subscribers
• Identified functionalities/services; e.g. Printers; Map servers
• Bind by requesting to an allocator or manager
• Release by notifying the allocator or manager.
• Requires:
•Registry to find (map from names to instance sets)
•Managers/allocators to bind-release
• Find instances (of predefined types) :
• Identified instances or instance sets; e.g. Doctors, subscribers
• Identified functionalities/services; e.g. Printers; Map servers
• Bind by requesting to an allocator or manager
• Release by notifying the allocator or manager.
• Requires:
•Registry to find (map from names to instance sets)
•Managers/allocators to bind-release
Doctors
DoctorAgent[m]
Patients
PatientAgent[n]
Registry
Patology: refHart: ref....
Object pnp here
SelfConFoil no 10
Static systems in general (parameter adaptation)
• Fixed (known) communication infrastructure
• Fixed (known) set of types
• Fixed (known) content structure
• Dynamic linking and data values
• Metadata for part description (reflection)
• Mechanism for part registration, discovery and configuring
• Fixed (known) communication infrastructure
• Fixed (known) set of types
• Fixed (known) content structure
• Dynamic linking and data values
• Metadata for part description (reflection)
• Mechanism for part registration, discovery and configuring
Limitations?
SelfConFoil no 11
What if the object type is new?
1. object plug-in
2. registration
3. notification
4. creation
5. binding and use
1. object plug-in
2. registration
3. notification
4. creation
5. binding and use
System X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
Configurer
What if the object type is new?
1
2
3
4
5
SelfConFoil no 12
... then we need
• a more flexible structure
• a way to load and ”install” new types
• i.e. dynamic systems, compositional adaptation
• a more flexible structure
• a way to load and ”install” new types
• i.e. dynamic systems, compositional adaptation
System X
*(,):*
c(10,125):CT
a(2,2):ATae(2,2):AET
Registry
ce(10,125):CET
Configurer
*(,):*
SelfConFoil no 13
Towards dynamic systems – relaxing content constraints
• The content structure is not fixed, even the types may change.
• Minimal fixed (known) communication infrastructure
• Variable (unknown) set of types (new types may be introduced dynamically)
• The content structure is not fixed, even the types may change.
• Minimal fixed (known) communication infrastructure
• Variable (unknown) set of types (new types may be introduced dynamically)
Challenges:
–Ensuring consistency
–Working with the unknown
SelfConFoil no 14
Context and content constraints
provide framework/constraints for self configuringprovide framework/constraints for self configuring
block type XT
b(,):BT
c(,):CT
d(,):DT
a(,):AT ae(,):AET
Registry
ce(,):CET
Configurer
be(,):BET
de(,):DET
contentcontext
• Content constraints: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules.
• Context constraints: govern the external use of (instances of) a type. Gate constraints in SDL and interface definitions CORBA style, can be seen as context rules. Well defined association roles provide context rules.
• Content constraints: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules.
• Context constraints: govern the external use of (instances of) a type. Gate constraints in SDL and interface definitions CORBA style, can be seen as context rules. Well defined association roles provide context rules.
SelfConFoil no 15
Static and dynamic systems
• Static systems – emphasis on content constraints defining the part structure and the part types – parameter adaptation.
• Dynamic systems – emphasis on context constraints that govern how parts may be composed (without prescribing a particular structure) – compositional adaptation:
•object dynamics
•type dynamics
• Static systems – emphasis on content constraints defining the part structure and the part types – parameter adaptation.
• Dynamic systems – emphasis on context constraints that govern how parts may be composed (without prescribing a particular structure) – compositional adaptation:
•object dynamics
•type dynamics
context constraints are less restrictive
SelfConFoil no 16
Context constraints and roles
• All objects assume an environment with roles that are bound statically or dynamically to actual objects (actors)
• When active; objects will seek to find and bind to the actors they need.
• For this they need some basic facilities for discovery and lookup that we assume is handled by a registry
• interfaces may be fixed or adaptable
• All objects assume an environment with roles that are bound statically or dynamically to actual objects (actors)
• When active; objects will seek to find and bind to the actors they need.
• For this they need some basic facilities for discovery and lookup that we assume is handled by a registry
• interfaces may be fixed or adaptable
Type-1Registry
type-x1 registry rolerole-a 0..1
type-yrole-b 0..*
type-zrole-c 1..4
SelfConFoil no 17
Simple Object dynamics
1. Communication infrastructure
2. Registry functionality:
• to register objects, types, services/roles
3. Type definitions with context rules and behaviour to self configure (bind to roles)
1. Communication infrastructure
2. Registry functionality:
• to register objects, types, services/roles
3. Type definitions with context rules and behaviour to self configure (bind to roles)
Registry
object-a:Type-1 object-x:Type-z
Type-1 Type-n
role c
Essentially SOA
SelfConFoil no 18
Object plug-in
1. plug-in
2. Find Registry (Discovery)
3. Register with Registry
4. Explore the Registry, find objects (Lookup), notify
5. Perform dynamic (role) binding (lease) (May be mutually performed)
6. Perform service
1. plug-in
2. Find Registry (Discovery)
3. Register with Registry
4. Explore the Registry, find objects (Lookup), notify
5. Perform dynamic (role) binding (lease) (May be mutually performed)
6. Perform service
Registry
object-a:Type-1 object-x:Type-n
Type-1 Type-n
object-b:Type-2
1
2
3, 4, 5
6
SelfConFoil no 19
Object plug-out
1. Release dynamic bindings
2. De-register with Registry
3. Plug-out
1. Release dynamic bindings
2. De-register with Registry
3. Plug-out
Registry
object-a:Type-1 object-x:Type-n
Type-1 Type-n
object-b:Type-2 1
2
3
SelfConFoil no 20
Rebind on error
1. Detect error on dynamic associations
2. Request another actor for the role
3. Establish new dynamic association
Fault tolerance is a kind of self configuration, but not the same as rebind on error
1. Detect error on dynamic associations
2. Request another actor for the role
3. Establish new dynamic association
Fault tolerance is a kind of self configuration, but not the same as rebind on error
Registry
object-a:Type-1 object-x:Type-n
Type-1 Type-n
object-b:Type-2 1
2
3
SelfConFoil no 21
Using stubs/proxies
1. Hiding the protocols actually used
2. Making remote interfaces local
3. Restricted to client-server
1. Hiding the protocols actually used
2. Making remote interfaces local
3. Restricted to client-server
Registry
object-a:Type-1 object-x:Type-n
Type-1 Type-n
x-proxy: a-proxy:
x-stub:
a-stub:
x-skeleton:
a-skeleton:
Synchronous method calls:
This is essentially JINI
SelfConFoil no 22
A few points
• Each object will discover/find its actual context
• Objects bind dynamically to each other in application dependent ways
• Objects supervise each other, detect errors and may rebind
• Objects may receive configuration information from each other and adapt to each other
• Objects may be composite (subsystems)
• Objects may represent or be associated with external devices
• Discovery may be mutual
• Find, bind-release is universally needed, but in many shades.
• Each object will discover/find its actual context
• Objects bind dynamically to each other in application dependent ways
• Objects supervise each other, detect errors and may rebind
• Objects may receive configuration information from each other and adapt to each other
• Objects may be composite (subsystems)
• Objects may represent or be associated with external devices
• Discovery may be mutual
• Find, bind-release is universally needed, but in many shades.
SelfConFoil no 23
Generalising
• Open structure with context constraints
• Composite parts (types) – with content and context constraints
• Atomic parts
• Allowing new types
• Metadata for parts and types
• Mechanisms for type introduction (e.g. class loading),
• Mechanisms for type registration and discovery.
• Mechanisms for part registration, discovery and configuring.
• Open structure with context constraints
• Composite parts (types) – with content and context constraints
• Atomic parts
• Allowing new types
• Metadata for parts and types
• Mechanisms for type introduction (e.g. class loading),
• Mechanisms for type registration and discovery.
• Mechanisms for part registration, discovery and configuring.
Reg/Conf
Reg/Conf
Reg/Conf
Reg/Conf
SelfConFoil no 24
The “real” world of implementations
HWHW
OSOS
MiddlewareMiddleware i/oi/o
application applicationapplication application
Services/roles Services/roles
Type-1 Type-2
modeling
implementation
–plug-in
–plug-out
–move
–change type
–load type
SelfConFoil no 25
Adaptation aspects
• to communicating objects - horizontal
• to implementation capabilities - vertical
• to communicating objects - horizontal
• to implementation capabilities - vertical
Server App Term AppProtocol Protocol
Server App
RTS
Middleware
Protocol
RTS
Middleware
Protocol
RTS
Middleware
Term App
RTS
Middleware
Principles:
component based design; loose coupling; separation of concerns;layering;metadata
SelfConFoil no 26
McKinley et.al.:Composing adaptive software:
Recommended reading, but focused on programming and not modelling!
Enabling technologies:
• Separation of concerns
• Computational reflection
• Component based design
• Middleware
Key challenges:
• Assurance
• Security
• Interoperability
• Decision making
Enabling technologies:
• Separation of concerns
• Computational reflection
• Component based design
• Middleware
Key challenges:
• Assurance
• Security
• Interoperability
• Decision making
SelfConFoil no 27
Next time ...
• Understanding the nature of services and applications
• Service oriented architectures
• Dynamic role binding and adaptation
• Service discovery and selection
• Interface compatibility, semantic interfaces and service desriptions
• Actorframe seen as a dynamic system example
• Service engineering
• Understanding the nature of services and applications
• Service oriented architectures
• Dynamic role binding and adaptation
• Service discovery and selection
• Interface compatibility, semantic interfaces and service desriptions
• Actorframe seen as a dynamic system example
• Service engineering
