SelfCon Foil no 1 Dynamic component systems 2

SelfCon Foil no 2 Fire and burglar alarms Climate control: heating and cooling Power control: minimize power costs Smart metering (AMS) Access control Assisted living (well-fare technology) Entertainment Cooking Lighting Etc. Fire and burglar alarms Climate control: heating and cooling Power control: minimize power costs Smart metering (AMS) Access control Assisted living (well-fare technology) Entertainment Cooking Lighting Etc. Now let us look at the HNS system again

SelfCon Foil no 3 We want as much self adaptation as possible – how? Every device is networked! We want to plug in and out devices: heaters, alarm sensors, panels, power meters, appliances, weather stations,... We want to connect devices with service providing applications We want to (buy and) install applications We want to access external resources and to have remote access Every device is networked! We want to plug in and out devices: heaters, alarm sensors, panels, power meters, appliances, weather stations,... We want to connect devices with service providing applications We want to (buy and) install applications We want to access external resources and to have remote access

SelfCon Foil no 4 How simple can it get? The bare necessities: A component model for device and application components: Cpt A network with dynamic registration, routing and registry discovery: Rtr Registry functionality to register, lookup, subscribe-notify: Reg Life cycle support to install, update, remove components The bare necessities: A component model for device and application components: Cpt A network with dynamic registration, routing and registry discovery: Rtr Registry functionality to register, lookup, subscribe-notify: Reg Life cycle support to install, update, remove components

SelfCon Foil no 5 Basic component model Application specific services Generic support services Application specific services Generic support services C3 support s1 s2 s4 Reg Rtr Lcs C3 app

SelfCon Foil no 6 Using OSGi The component is a bundle with a manifest Provided as a Service object The component is a bundle with a manifest Provided as a Service object C3 support s1 s2 s4 OSG reg rtr OSGi LCS C3 app Provided and required Java interfaces Direct method calls on Service objects OSGi Registry API OSGi LSC API

SelfCon Foil no 7 Distributed support Asynchronous messaging for real-time, distribution and flexibility Global Rtr for distribution transparency Global Reg for remote find-bind Asynchronous messaging for real-time, distribution and flexibility Global Rtr for distribution transparency Global Reg for remote find-bind C3 global S1’ S2’ S4’ Global Reg OSGi LCS C3’ app’ C3 local Global Rtr OSGi reg Message interfaces over Rtr Message interface over Rtr Java interfaces Java interface

SelfCon Foil no 8 A distributed system using OSGi OSGi Reg Global RTR OSGi LCS Global COM App CPT 1 App CPT 2 App CPT n Global Reg Network OSGi Bundle

SelfCon Foil no 9 Important issues to consider The nature of components: Just Java classes? State machines? Other? Dealing with concurrency: Just Java Threads? Concurrency and real-time support? How to communicate: Just Java method calls? Web services, JSON, HTTP,....? Asynchronous messaging? Devices and network issues: Device drivers; I/O Timing constraints The nature of components: Just Java classes? State machines? Other? Dealing with concurrency: Just Java Threads? Concurrency and real-time support? How to communicate: Just Java method calls? Web services, JSON, HTTP,....? Asynchronous messaging? Devices and network issues: Device drivers; I/O Timing constraints

SelfCon Foil no 10 Global Component Model Identity: unique ID generated for each Cpt and session Rtr interface: Registering in Rtr Discover Reg: getting the Reg address (or use well-known ID) Reg interface: Register Cpt services (i.e. collaborations) in Reg Look up other Cpt services according to application Application services (i.e. collaborations): Dynamically link service roles according to application and ctx Identity: unique ID generated for each Cpt and session Rtr interface: Registering in Rtr Discover Reg: getting the Reg address (or use well-known ID) Reg interface: Register Cpt services (i.e. collaborations) in Reg Look up other Cpt services according to application Application services (i.e. collaborations): Dynamically link service roles according to application and ctx

SelfCon Foil no 11 Case 1: Access Control System The structure of components is to be “magically” created by the components themselves when plugged in... with a little help from the router and the registry using the Acs Point name as association key The structure of components is to be “magically” created by the components themselves when plugged in... with a little help from the router and the registry using the Acs Point name as association key Logical structure “Physical” structure

SelfCon Foil no 12 Creating links The seeker uses Lookup while the responder uses Register The seeking direction can be determined for each collaboration/interface Here we have chosen the many-to-one direction An Association Key is needed to select instances – here the ACS Point Name A component may be both seeker and responder, but in different collaborations Lookup and Register must deal with collaborations and roles, not just CPT The seeker uses Lookup while the responder uses Register The seeking direction can be determined for each collaboration/interface Here we have chosen the many-to-one direction An Association Key is needed to select instances – here the ACS Point Name A component may be both seeker and responder, but in different collaborations Lookup and Register must deal with collaborations and roles, not just CPT

SelfCon Foil no 13 Access Control System with link creation Rtr and Reg omitted for simplicity below Each component have: one or more static collaboration sessions with other components, maintained locally by roles Responder or Seeker roles(to perform Register or Lookup) for each link application behaviour using the roles. basic component management behaviour, e.g. OSGi Rtr and Reg omitted for simplicity below Each component have: one or more static collaboration sessions with other components, maintained locally by roles Responder or Seeker roles(to perform Register or Lookup) for each link application behaviour using the roles. basic component management behaviour, e.g. OSGi

SelfCon Foil no 14 Component model illustrated A Cpt can have any number of collaborations with different seeking directions Each is established by a seeker-responder pair interacting with the Registry Collaboration behaviour is application dependent There is a port at each end of a link The ports register in the Rtr and the portID is used as message addresses A Cpt can have any number of collaborations with different seeking directions Each is established by a seeker-responder pair interacting with the Registry Collaboration behaviour is application dependent There is a port at each end of a link The ports register in the Rtr and the portID is used as message addresses

SelfCon Foil no 15 A possible Plug-In sequence Assumptions: The ports generates their own PortID The PortID is registered in the Rtr tables The Reg has a well-known identity provided as parameter Assumptions: The ports generates their own PortID The PortID is registered in the Rtr tables The Reg has a well-known identity provided as parameter

SelfCon Foil no 16 Generic Seeker and Responder as blocks Manages collaboration session establishment Provides session messaging Manages collaboration session establishment Provides session messaging

SelfCon Foil no 17 Global Registry A Responder registers: Register(Cpt ID, Ass Key, Collaboration Name, Responder Port ID) A Seeker Looks up: Lookup(Ass Key, Collaboration Name) The registry is stateless A Responder registers: Register(Cpt ID, Ass Key, Collaboration Name, Responder Port ID) A Seeker Looks up: Lookup(Ass Key, Collaboration Name) The registry is stateless

SelfCon Foil no 18 Addressing and Routing Routing is based on Ports and Port ID Each (stateful) session has a Port at each end with its own Port ID and a reference to the remote Port Session ID Each port registers in the Rtr table with its own Port ID The Rtr table maps from Port ID to Java message listeners Routing is based on Ports and Port ID Each (stateful) session has a Port at each end with its own Port ID and a reference to the remote Port Session ID Each port registers in the Rtr table with its own Port ID The Rtr table maps from Port ID to Java message listeners Message SignalID: String Sender: PortSessionId Receiver: PortSesssionId Payload: Object

SelfCon Foil no 19 Distributed routing A router in each node NodeID part of address Routing tables dynamically updated as cpt come and go (self adapting) A router in each node NodeID part of address Routing tables dynamically updated as cpt come and go (self adapting)

SelfCon Foil no 20 Developing the Access Control Application 1.Develop the component types 2.Create the objects needed, provide Ass Key information to each object 3.Start the objects and let the system self configure: 1.responding roles dynamically Register 2.seeking roles dynamically Lookup and link to responding roles 4.The validation database has to be entered by other means 1.Develop the component types 2.Create the objects needed, provide Ass Key information to each object 3.Start the objects and let the system self configure: 1.responding roles dynamically Register 2.seeking roles dynamically Lookup and link to responding roles 4.The validation database has to be entered by other means

SelfCon Foil no 21 Simple Home Heating App Any number of rooms, any number of heaters in each Temperatures and programs set for each room, either locally or centrally Everything plugged in and linked dynamically... but there is a problem... Any number of rooms, any number of heaters in each Temperatures and programs set for each room, either locally or centrally Everything plugged in and linked dynamically... but there is a problem...

SelfCon Foil no how to Input a room plan if desired? Associate components with rooms? 1.By network segment 2.By manual identification Input a room plan if desired? Associate components with rooms? 1.By network segment 2.By manual identification

SelfCon Foil no 23 Smart Home Heating Takes power price and weather into account and uses shades/curtains to collect and conserve energy when possible Now there is a choice between Simple- and Smart-H-Heat Takes power price and weather into account and uses shades/curtains to collect and conserve energy when possible Now there is a choice between Simple- and Smart-H-Heat

SelfCon Foil no 24 How to deal with variability in types? Type selection in seeking Direction of seeking Ensuring compatibility across interfaces – interoperability Type selection in seeking Direction of seeking Ensuring compatibility across interfaces – interoperability

SelfCon Foil no 25 Discussion items Physical networking Network protocols How to really plug-in and plug out devices How to select among alternatives How to discover the configuration at startup and restart? Associate devices with rooms? Input the overall room plan? Load new services and device types? Using existing protocols like UPnP Physical networking Network protocols How to really plug-in and plug out devices How to select among alternatives How to discover the configuration at startup and restart? Associate devices with rooms? Input the overall room plan? Load new services and device types? Using existing protocols like UPnP