1. SelfCon Foil no 1 Self configuring systems - introduction I

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

3. SelfCon Foil 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/

4. SelfCon Foil 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.1S2.1 S3.1S2.2 Program generation Services Designs Deployment, Realization, Execution Self* mechanisms – what and how?

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

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

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

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

9. SelfCon Foil 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 Doctor Agent[m] Patients Patient Agent[n] Registry Patology: ref Hart: ref.... Object pnp here

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

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

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

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

14. SelfCon Foil no 14 Context and content constraints provide 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 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 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.

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

16. SelfCon Foil 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-1 Registry type-x 1 registry role role-a 0..1 type-y role-b 0..* type-z role-c 1..4

17. SelfCon Foil 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-1object-x:Type-z Type-1Type-n role c Essentially SOA

18. SelfCon Foil 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-1object-x:Type-n Type-1Type-n object-b:Type-2 1 2 3, 4, 5 6

19. SelfCon Foil 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-1object-x:Type-n Type-1Type-n object-b:Type-2 1 2 3

20. SelfCon Foil 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-1object-x:Type-n Type-1Type-n object-b:Type-2 1 2 3

21. SelfCon Foil 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-1object-x:Type-n Type-1Type-n x-proxy:a-proxy: x-stub: a-stub: x- skeleton: a- skeleton: Synchronous method calls: This is essentially JINI

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

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

24. SelfCon Foil no 24 The “real” world of implementations HW OS Middleware i/o application Services/roles Type-1 Type-2 modeling implementation –plug-in –plug-out –move –change type –load type

25. SelfCon Foil no 25 Adaptation aspects to communicating objects - horizontal to implementation capabilities - vertical to communicating objects - horizontal to implementation capabilities - vertical Server App Term App 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

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

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