Transcript SelfCon
Dynamic component systems 2 SelfCon Foil no 1 Now let us look at the HNS system again • • • • • • • • • • 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. SelfCon Foil no 2 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 SelfCon Foil no 3 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 SelfCon Foil no 4 Basic component model • Application specific services • Generic support services s2 Reg C3 app s1 C3 support s4 Lcs SelfCon Foil no 5 Rtr Using OSGi • The component is a bundle with a manifest • Provided as a Service object OSGi Registry API OSG reg OSGi LCS OSGi LSC API SelfCon Foil no 6 s2 C3 app s1 C3 support s4 rtr Provided and required Java interfaces Direct method calls on Service objects Distributed support • Asynchronous messaging for real-time, distribution and flexibility • Global Rtr for distribution transparency • Global Reg for remote find-bind Message interface over Rtr S2’ Global Reg Global Rtr C3’ app’ S1’ C3 global S4’ C3 local Java interface OSGi reg SelfCon Foil no 7 OSGi LCS Message interfaces over Rtr Java interfaces A distributed system using OSGi App CPT 1 Global COM App CPT 2 App CPT n Global Reg Global RTR OSGi LCS SelfCon Foil no 8 OSGi Reg Network OSGi Bundle 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 SelfCon Foil no 9 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 SelfCon Foil no 10 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 Logical structure SelfCon Foil no 11 “Physical” structure 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 SelfCon Foil no 12 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 SelfCon Foil no 13 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 SelfCon Foil no 14 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 SelfCon Foil no 15 Generic Seeker and Responder as blocks • Manages collaboration session establishment • Provides session messaging SelfCon Foil no 16 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 SelfCon Foil no 17 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 Message SignalID: String Sender: PortSessionId Receiver: PortSesssionId Payload: Object SelfCon Foil no 18 Distributed routing • A router in each node • NodeID part of address • Routing tables dynamically updated as cpt come and go (self adapting) SelfCon Foil no 19 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 SelfCon Foil no 20 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 ... SelfCon Foil no 21 ... how to • Input a room plan if desired? • Associate components with rooms? 1.By network segment 2.By manual identification SelfCon Foil no 22 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 SelfCon Foil no 23 How to deal with variability in types? • Type selection in seeking • Direction of seeking • Ensuring compatibility across interfaces – interoperability SelfCon Foil no 24 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 SelfCon Foil no 25