SelfCon Foil no 1 Pre-structured Systems

SelfCon Foil 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 ??

SelfCon Foil 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)

SelfCon Foil 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 mechanisms System 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

SelfCon Foil 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 Think of some examples

SelfCon Foil 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 ?

SelfCon Foil 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

SelfCon Foil 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

SelfCon Foil 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* Registry ce(10,125):CET* AppConfigurer *(,):*

SelfCon Foil no 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):AT ae(2,2):AET Registry ce(10,125):CET AppConfigurer *(,):*

SelfCon Foil 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* Registry ce(10,125):CET* AppConfigurer *(,):* Changing/r eplacing types Extending/c hanging structure infrastructure Dealing with the unaticipated

SelfCon Foil 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?

SelfCon Foil no 13 Basic functionalities identified so far 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 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):AT ae(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 Doctor Agent[m] Patients Patient Agent[n]

SelfCon Foil 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):AT ae(2,2):AET Registry ce(10,125):CET AppConfigurer *(,):*

SelfCon Foil no 15 from content constraints to context constraints Let 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 content context 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.

SelfCon Foil 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