16
SelfCon Foil no 1 Pre-structured Systems
SelfConFoil no 1
Pre-structured Systems
SelfConFoil no 2
Pre-structured systems (e.g. SDL systems)
• Stable (cannot be added or changed dynamically) :
•System structure
•Block/process sets
•Block/process types
• Variable:
•Number of instances in block/process sets
•Parameter and variable values
•Static and dynamic links (PId values)
• Is some degree of self configuring/adaptation possible?
• Stable (cannot be added or changed dynamically) :
•System structure
•Block/process sets
•Block/process types
• Variable:
•Number of instances in block/process sets
•Parameter and variable values
•Static and dynamic links (PId values)
• Is some degree of self configuring/adaptation possible?
System X
b(,):BT
c(,):CT
d(,):DT
a(,):AT??
??
??
??
??
SelfConFoil no 3
Self configuration and adaptation:
• 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).
• Self adaptation requires continuous supervision and adaptation to changes
• Information must be provided for each variable part (component set)
• 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).
• Self adaptation requires continuous supervision and adaptation to changes
• Information must be provided for each variable part (component set)
SelfConFoil no 4
How to do it?
we need:
• to discover/explore and monitor the environment –detect changes
• to manage addresses and keep a Registry over external entities and their properties
• to interpret properties and configure the system - create the internal instance structure, assign references and data values: AppConfigurer
• suitable identities/references and routing mechanisms
we need:
• to discover/explore and monitor the environment –detect changes
• to manage addresses and keep a Registry over external entities and their properties
• to interpret properties and configure the system - create the internal instance structure, assign references and data values: AppConfigurer
• suitable identities/references and routing mechanismsSystem X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
AppConfigurer
Here the system adapts to changes in the
environment
Registry may be outside or inside system
SelfConFoil no 5
Object plug-and-play
1. Object plug-in
2. Get address, discover Registry, and do registration
3. Notifiy AppConfigurer
4. Create application objects
5. Objects execute with dynamic find-bind if needed
1. Object plug-in
2. Get address, discover Registry, and do registration
3. Notifiy AppConfigurer
4. Create application objects
5. Objects execute with dynamic find-bind if needed
System X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
AppConfigurer
1
2
3
4
5
Think of some
examples
SelfConFoil no 6
Pre-structured systems in general
• Fixed (known) communication infrastructure
• Fixed (known) set of types
• Fixed (known) content structure
• Dynamic linking and data values
• Part descriptions (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
• Part descriptions (reflection)
• Mechanism for part registration, discovery and configuring
Limitations?
SelfConFoil no 7
What if there are alternative component types?
System X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
AppConfigurer
Several alternative component types may serve the new object
1
2
3
4
5
SelfConFoil no 8
Then we need
1. A way to represent alternatives
2. A way to select the best alternative
3. or dynamically compose the best alternative (using compositional adaptation)
1. A way to represent alternatives
2. A way to select the best alternative
3. or dynamically compose the best alternative (using compositional adaptation)
System X
b(,):BT
c(10,125):CT
d(,):DT
a(2,2):AT
ae(2,2):AET
Registry
ce(10,125):CET
AppConfigurer
1
2
3
4
5
SelfConFoil no 9
What if the object type is new?
Instances of unknown object types
System X
*(,):*
c(10,125):CT*
a(2,2):AT*ae(2,2):AET*
RegistryRegistry
ce(10,125):CET*
AppConfigurer
*(,):*
SelfConFoil no 10
... then we need
• an extensible structure
• a way to load and ”install” new types
• i.e. some support for dynamic components
• less is known at design-time, more postponed to run-time
• an extensible structure
• a way to load and ”install” new types
• i.e. some support for dynamic components
• less is known at design-time, more postponed to run-time
System X
*(,):*
c(10,125):CT
a(2,2):ATae(2,2):AET
RegistryRegistry
ce(10,125):CET
AppConfigurer
*(,):*
SelfConFoil no 11
Towards dynamic components• Using a minimal invariant infrastructure: addressing, routing, registry, ...
• Dynamic component lifecycle: install, configure, start, ... uninstall
• Dynamic linking with alternatives
• Extending/changing the structure
• Using a minimal invariant infrastructure: addressing, routing, registry, ...
• Dynamic component lifecycle: install, configure, start, ... uninstall
• Dynamic linking with alternatives
• Extending/changing the structure
System X
*(,):*
c(10,125):CT*
a(2,2):AT*ae(2,2):AET*
RegistryRegistry
ce(10,125):CET*
AppConfigurer
*(,):*
Changing/replacing types
Changing/replacing types
Extending/changing structure
Extending/changing structure
infrastructure infrastructure
Dealing with the unaticipated
Dealing with the unaticipated
SelfConFoil no 12
And now it is getting difficult
• Services are not fixed
• Structure is not fixed,
• Even the types may change.
• Only a minimal infrastructure remains invariant and known
• Services are not fixed
• Structure is not fixed,
• Even the types may change.
• Only a minimal infrastructure remains invariant and known
–How to reason about the unknown?
–How to adapt to the unanticipated?
–How to ensure interoperabilty and consistency?
SelfConFoil no 13
Basic functionalities identified so farGeneric:
• Detection, e.g. plug-in; plug-out
• Explore/discover: get address, find the registry and other support units
• Registry: register, de-register, lookup
• Learn: load new types/code
Generic:
• Detection, e.g. plug-in; plug-out
• Explore/discover: get address, find the registry and other support units
• Registry: register, de-register, lookup
• Learn: load new types/code
System X
*(,):*
c(10,125):CT
a(2,2):ATae(2,2):AET
Registry
ce(10,125):CET
AppConfigurer
*(,):*
Application dependent:
• AppConfigurer: configure, re-configure
• Find-bind-release (session initiation):
•Roles
•Agents
• Context/situation adaptation
Application dependent:
• AppConfigurer: configure, re-configure
• Find-bind-release (session initiation):
•Roles
•Agents
• Context/situation adaptation
Doctors
DoctorAgent[m]
Patients
PatientAgent[n]
SelfConFoil no 14
Is the AppConfigurer such a good idea?
• Needs to know the applications
• Needs to change with the applications
• Build it into the applications in stead?
• Needs to know the applications
• Needs to change with the applications
• Build it into the applications in stead?
System X
*(,):*
c(10,125):CT
a(2,2):ATae(2,2):AET
RegistryRegistry
ce(10,125):CET
AppConfigurer
*(,):*
SelfConFoil no 15
from content constraints to context constraints
Let object themself take care of application dependent configuringLet object themself take care of application dependent configuring
block type XT
b(,):BT
c(,):CT
d(,):DT
a(,):AT ae(,):AET
Registry
ce(,):CET
AppConfigurer
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 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 roles provide context rules.
SelfConFoil no 16
Pre-structured systems vs. dynamic component systems
• Pre-structured – emphasis on content constraints defining the part structure and the part types: compositional adaptation bounded by the structure
• Dynamic component systems – emphasis on context constraints that govern how components may be composed (without prescribing a particular structure): compositional adaptation bounded by the components
• Pre-structured – emphasis on content constraints defining the part structure and the part types: compositional adaptation bounded by the structure
• Dynamic component systems – emphasis on context constraints that govern how components may be composed (without prescribing a particular structure): compositional adaptation bounded by the components
Context constraints are key to dynamic component systems,
i.e. interface definitions
