1. SelfCon Foil no 1 Self configurating systems - a starter Rolv Bræk, Item

2. SelfCon Foil no 2 Self configuration By self configuration we mean dynamic configuration with minimal human participation. Self configuration means dynamic adaptation to changing environments. Applied in plug-and-play, ad-hoc systems/networks, autonomic computing,... By self configuration we mean dynamic configuration with minimal human participation. Self configuration means dynamic adaptation to changing environments. Applied in plug-and-play, ad-hoc systems/networks, autonomic computing,...

3. SelfCon Foil no 3 What can I do here? ???

4. SelfCon Foil no 4 Self configuration Basis 1.Communication infrastructure 2.Registry functionality: to register objects, types, services/roles to find objects, types, services/roles to manage dynamic associations 1.Communication infrastructure 2.Registry functionality: to register objects, types, services/roles to find objects, types, services/roles to manage dynamic associations Registry object-a:Type-1object-x:Type-z Type-1Type-n role c

5. SelfCon Foil no 5 Object plug-in 1.plug-in 2.Find Registry (Discovery) 3.Register with Registry 4.Explore the Registry 5.Request actors of services/roles 6.Establish dynamic association (lease) May be mutually performed 1.plug-in 2.Find Registry (Discovery) 3.Register with Registry 4.Explore the Registry 5.Request actors of services/roles 6.Establish dynamic association (lease) May be mutually performed Registry object-a:Type-1object-x:Type-n Type-1Type-n object-b:Type-2 1 2 3, 4, 5 6

6. SelfCon Foil no 6 Object plug-out 1.Release dynamic associations 2.De-register with Registry 3.Plug-out 1.Release dynamic associations 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

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

8. SelfCon Foil no 8 Using stubs/proxies 1.Hiding the protocols actually used 2.Making remote interfaces local May be only one-way interfaces in some cases 1.Hiding the protocols actually used 2.Making remote interfaces local May be only one-way interfaces in some cases Registry object-a:Type-1object-x:Type-n Type-1Type-n x-proxy:a-proxy: x-stub: a-stub: x- skeleton: a- skeleton: Synchronoues method calls:

9. SelfCon Foil no 9 Composite plug-in, plug-out Registry object-a:Type-1object-x:Type-z Type- 1 Type- n role c Registry object-a:Type-1object-x:Type-z Type- 1 Type- n role c Eg: –Bluetooth networks –Sub-systems –Network nodes –Computers –… Possibly a Manager for each composite Manager

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

11. SelfCon Foil no 11 Self configuration viewpoints HW OS Middleware i/o application Services/roles Type-1 Type-2 modeling implementation –plug-in –plug-out –move –change type –load type

12. SelfCon Foil no 12 Object environments: roles In self configurating systems the object structure is not fixed, even the types may change. 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 In self configurating systems the object structure is not fixed, even the types may change. 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

13. SelfCon Foil no 13 Common use of roles Roles in organizations: role in a play role in a project role in a service or function Roles in organizations: role in a play role in a project role in a service or function Roles in associations: family business session Are played by: actors persons objects AaseSolveigPeer mother lover son HepburnEastwoodRoberts

14. SelfCon Foil no 14 A service role is: Conference Call … Enquiry Call ab c com Basic Call ab call(a,b) callind(a) MSC Basic Call Busy answer(b) calling(b) end banswer(b) end a:subcomsysb:sub com call(a,b) callind(a) MSC Basic Call Succesful answer(b) calling(b) end banswer(b) end a com b S-role behaviour ServicesService roles the part some object plays in a service used to model services separately the part some object plays in a service used to model services separately

15. SelfCon Foil no 15 An association role is: abcom Service roles the part of a behaviour (e.g. service role) visible at an association end or interface it defines a dynamic interface behaviour used to align interfaces, to check consistency and synthesize designs the part of a behaviour (e.g. service role) visible at an association end or interface it defines a dynamic interface behaviour used to align interfaces, to check consistency and synthesize designs association roles call(a,b) callind(a) answer(b) calling(b) A-role behaviour abcom

16. SelfCon Foil no 16 Role relationships service–role association role interface–role 1..*

17. SelfCon Foil no 17 Services and actors Typical services involve more than one service role Actors may play more than one service roles Different actors may play the same service role Service roles may interact and contend for actors Typical services involve more than one service role Actors may play more than one service roles Different actors may play the same service role Service roles may interact and contend for actors A service change typically has impact on several types service Actor service role 1..* plays 1..*

18. SelfCon Foil no 18 Roles are like projections And useful for: Architecture definitions: roles help to define interfaces precisely Reuse: roles are reusable in many types Design synthesis: roles serve as specifications Design verification: inverse of design - checking that the provided roles “contain” the specified roles Validation of associations and links: roles can be used like “plugs” and “sockets” - provided roles must “contain” required roles And useful for: Architecture definitions: roles help to define interfaces precisely Reuse: roles are reusable in many types Design synthesis: roles serve as specifications Design verification: inverse of design - checking that the provided roles “contain” the specified roles Validation of associations and links: roles can be used like “plugs” and “sockets” - provided roles must “contain” required roles

19. SelfCon Foil no 19 An actor has provided and required roles

20. SelfCon Foil no 20 Aligning provided and required roles Provided role behaviours shall “contain” the required role behaviours

21. SelfCon Foil no 21 How to achieve well-formed systems? Content rules: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules. Too restrictive for open systems. Context rules: 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 rules: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules. Too restrictive for open systems. Context rules: 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. self configuration is based on context rules

22. SelfCon Foil no 22 Context rules only Context rules only: Generally: Any object structure is well-formed as long as all context rules are satisfied. Lego: the “rules of the bricks” Here: required roles to be contained by provided roles. Context rules only: Generally: Any object structure is well-formed as long as all context rules are satisfied. Lego: the “rules of the bricks” Here: required roles to be contained by provided roles. O1 O2O3O4

23. SelfCon Foil no 23 Levels of role alignment  Validation. Checking that the required roles are contained in the provided roles, and raising exceptions if not.  Adaptation. Negotiating and adapting the roles (within predefined bounds).  Learning. Learning to play new roles by receiving role definitions (e.g. using Java class loading)  Validation. Checking that the required roles are contained in the provided roles, and raising exceptions if not.  Adaptation. Negotiating and adapting the roles (within predefined bounds).  Learning. Learning to play new roles by receiving role definitions (e.g. using Java class loading)

24. SelfCon Foil no 24 Role composition Defining roles as design units that can be composed and managed by actors Challenge 1: modular design units Challenge 2: composition rules Defining roles as design units that can be composed and managed by actors Challenge 1: modular design units Challenge 2: composition rules Actor Design units Roles Actor Composition

25. SelfCon Foil no 25 Role learning Provider roles are those that provide the service Client roles are those that use the service Client roles are propagated on demand Provider roles are those that provide the service Client roles are those that use the service Client roles are propagated on demand Roles Design units Actor CPC learn C C CPC compose

26. SelfCon Foil no 26 An actor design is required that: simplifies adding or changing provider service roles; can hold descriptions, or references to descriptions, of required client roles in a form that enable client objects to fetch role implementations as part of role alignment; can itself learn client roles required from other objects as part of role alignment. simplifies adding or changing provider service roles; can hold descriptions, or references to descriptions, of required client roles in a form that enable client objects to fetch role implementations as part of role alignment; can itself learn client roles required from other objects as part of role alignment.

27. SelfCon Foil no 27 Vision: plug-and-play for services Define the service in terms of service roles Design the provider roles and client roles (as manus or design pattern) Install the roles in provider agents Dynamic role learning by client agents when linked to providers Challenges: role design role composition dynamic role learning (not the same as Jini Proxies!!) Define the service in terms of service roles Design the provider roles and client roles (as manus or design pattern) Install the roles in provider agents Dynamic role learning by client agents when linked to providers Challenges: role design role composition dynamic role learning (not the same as Jini Proxies!!)

28. SelfCon Foil no 28 Note Few (no) languages support self configuration, support outside the languages is required Inherent part of many architectures: CORBA, DCOM, RMI OSA/PARLAY JINI Service Discovery Protocols in general ­HAVi ­SLP (Service Location Protocol) ­Salutation, NINJA MAC-OS Windows Ad-hoc networking Bluetooth Semantic web Few (no) languages support self configuration, support outside the languages is required Inherent part of many architectures: CORBA, DCOM, RMI OSA/PARLAY JINI Service Discovery Protocols in general ­HAVi ­SLP (Service Location Protocol) ­Salutation, NINJA MAC-OS Windows Ad-hoc networking Bluetooth Semantic web

29. SelfCon Foil no 29 To discuss About object and type description/search criteria and substitution criteria About dependence on physical location and devices And about individual objects vs groups vs any instance of a type Use telecom examples About a typical PC configuration About the need for composites and composite managers About object and type description/search criteria and substitution criteria About dependence on physical location and devices And about individual objects vs groups vs any instance of a type Use telecom examples About a typical PC configuration About the need for composites and composite managers