Elimina'ng ¡Implicit ¡Dependencies ¡ in ¡Component ¡Models ¡for ¡ Networked ¡Embedded ¡Systems ¡ ¡ Danny ¡Hughes ¡ Katholieke ¡Universiteit ¡Leuven ¡ ¡ danny.hughes@cs.kuleuven.be ¡
Structure ¡of ¡This ¡Talk ¡ 1. What ¡is ¡a ¡component ¡model? ¡ 2. Cri=que ¡of ¡contemporary ¡component ¡models ¡ ¡ 3. The ¡Loosely-‑coupled ¡Component ¡Infrastructure ¡ 4. Conclusions ¡
Structure ¡of ¡This ¡Talk ¡ 1. What ¡is ¡a ¡component ¡model? ¡ 2. Cri=que ¡of ¡contemporary ¡component ¡models ¡ ¡ 3. The ¡Loosely-‑coupled ¡Component ¡Infrastructure ¡ 4. Conclusions ¡
Defining ¡Components ¡ “A ¡software ¡component ¡is ¡a ¡unit ¡of ¡composition ¡ with ¡contractually ¡specified ¡interfaces ¡and ¡ explicit ¡context ¡dependencies ¡only. ¡A ¡software ¡ component ¡can ¡be ¡deployed ¡independently ¡and ¡is ¡ subject ¡to ¡third-‑party ¡composition.” ¡ ¡ ¡ ¡-‑ ¡Clemens ¡Szyperski ¡ Microso3 ¡ ¡
Contractually ¡Specified ¡Interfaces ¡ • Types ¡of ¡Interface: ¡ – Provided ¡interfaces ¡define ¡the ¡services ¡that ¡a ¡component ¡offers. ¡ – Required ¡ interfaces ¡define ¡the ¡services ¡that ¡a ¡component ¡ requires. ¡ • Interfaces ¡are ¡specified ¡in ¡a ¡standardized ¡form ¡and ¡may ¡be ¡ inspected. ¡ • This ¡enables ¡us ¡to ¡easily ¡compose ¡custom ¡soJware ¡images ¡ op=mized ¡for ¡a ¡specific ¡context. ¡ • This ¡is ¡cri=cal ¡in ¡NES, ¡where ¡we ¡have ¡very ¡constrained ¡ resources. ¡
Contractually ¡Specified ¡Interfaces ¡ “A ¡so3ware ¡component ¡is ¡a ¡unit ¡of ¡composi@on ¡ with ¡contractually ¡specified ¡interfaces ¡and ¡explicit ¡ context ¡dependencies ¡only. ¡A ¡so3ware ¡component ¡ can ¡be ¡deployed ¡independently ¡and ¡is ¡subject ¡to ¡ third-‑party ¡composi@on.” ¡ -‑ Clemens ¡Szyperski ¡
Contractually ¡Specified ¡Interfaces ¡ “A ¡so3ware ¡component ¡is ¡a ¡unit ¡of ¡composi@on ¡ with ¡contractually ¡specified ¡interfaces ¡and ¡explicit ¡ context ¡dependencies ¡only. ¡A ¡so3ware ¡component ¡ can ¡be ¡deployed ¡independently ¡and ¡is ¡subject ¡to ¡ third-‑party ¡composi@on.” ¡ -‑ Clemens ¡Szyperski ¡
Contractually ¡Specified ¡Interfaces ¡ “A ¡so3ware ¡component ¡is ¡a ¡unit ¡of ¡composi@on ¡ with ¡contractually ¡specified ¡interfaces ¡and ¡explicit ¡ context ¡dependencies ¡only. ¡A ¡so3ware ¡component ¡ can ¡be ¡deployed ¡independently ¡and ¡is ¡subject ¡to ¡ third-‑party ¡composi@on.” ¡ -‑ Clemens ¡Szyperski ¡
Applica'on ¡Composi'ons ¡ • Component-‑based ¡development ¡consists ¡of ¡two ¡ phases: ¡ – Development ¡of ¡re-‑usable ¡components. ¡ – Wiring ¡of ¡components ¡into ¡an ¡‘applica=on ¡ composi=on’. ¡ Generic ¡Components ¡ Bindings ¡ ALARM ¡ TEMP ¡ TEMP ¡ GUI ¡ SENSOR ¡ ALARM ¡ Fire ¡Monitoring ¡Composi=on ¡
Independent ¡Deployable ¡ • Components ¡should ¡be ¡deployable ¡as ¡self-‑ contained ¡en==es ¡without ¡support. ¡ • This ¡enables ¡the ¡injec=on ¡of ¡specific ¡func=onality ¡ at ¡run-‑=me ¡without ¡monolithic ¡re-‑flashing. ¡ • This ¡enables: ¡ – SoJware ¡evolu=on ¡through ¡component ¡updates. ¡ – Adapta=on ¡through ¡component ¡replacement. ¡ ¡ • This ¡is ¡an ¡excellent ¡fit ¡with ¡the ¡dynamic ¡ characteris=cs ¡of ¡NES. ¡
Characteris'cs ¡of ¡NES ¡(1/2) ¡ • Heterogeneity ¡in ¡mul=ple ¡dimensions: ¡ – Compu=ng, ¡networking, ¡sensing, ¡soJware. ¡ • Extreme ¡resource ¡constraints: ¡ – CPU, ¡Memory ¡and ¡Networking. ¡ – Limited ¡power ¡supplies ¡(baaery ¡or ¡solar ¡power). ¡ • Dynamic ¡opera=ng ¡environments: ¡ – Changing ¡applica=on ¡requirements. ¡ – Tight ¡coupling ¡with ¡environment. ¡
Characteris'cs ¡of ¡NES ¡(2/2) ¡ • Unreliable: ¡ – Nodes ¡use ¡unreliable ¡radio ¡links. ¡ – Nodes ¡power ¡supplies ¡may ¡be ¡exhausted. ¡ • Highly ¡distributed: ¡ – Typical ¡applica=ons ¡use ¡thousands ¡or ¡nodes. ¡ – Nodes ¡have ¡a ¡range ¡of ¡may ¡be ¡deployed ¡across ¡ 100s ¡of ¡KM ¡of ¡variable ¡terrain. ¡
3 rd ¡Party ¡Composi'on ¡ • Combina=on ¡of: ¡explicit ¡interfaces ¡and ¡explicit ¡context ¡ dependencies ¡allows ¡for ¡3 rd ¡party ¡composi=on. ¡ • As ¡the ¡component ¡describes ¡the ¡services ¡it ¡provides, ¡ we ¡can ¡find ¡compa=ble ¡building ¡blocks. ¡ • As ¡the ¡component ¡is ¡independently ¡deployable, ¡we ¡ can ¡treat ¡it ¡as ¡a ¡black ¡box ¡in ¡our ¡composi=on. ¡ • The ¡vision ¡is ¡that ¡the ¡developer ¡is ¡relieved ¡from ¡low-‑ level ¡details ¡and ¡becomes ¡a ¡‘composer’ ¡of ¡ components.... ¡but ¡there ¡are ¡complica=ons. ¡
3 rd ¡Party ¡Composi'on ¡ • Combina=on ¡of: ¡explicit ¡interfaces ¡and ¡explicit ¡context ¡ dependencies ¡allows ¡for ¡3 rd ¡party ¡composi=on. ¡ • As ¡the ¡component ¡describes ¡the ¡services ¡it ¡provides, ¡ we ¡can ¡find ¡compa=ble ¡building ¡blocks. ¡ • As ¡the ¡component ¡is ¡independently ¡deployable, ¡we ¡ can ¡treat ¡it ¡as ¡a ¡black ¡box ¡in ¡our ¡composi=on. ¡ • The ¡vision ¡is ¡that ¡the ¡developer ¡is ¡relieved ¡from ¡low-‑ level ¡details ¡and ¡becomes ¡a ¡‘composer’ ¡of ¡ components.... ¡ but ¡there ¡are ¡complica/ons. ¡
Explicit ¡Context ¡Dependencies ¡ PDA ¡(node ¡1): ¡ Sensor ¡(node ¡2): ¡ ¡ ¡ ALARM ¡ ¡ ¡ TEMP ¡ TEMP ¡ GUI ¡ ¡ ¡ SENSOR ¡ ALARM ¡ ¡ ¡ ¡ ¡ ¡ ¡ • Required ¡soJware ¡interfaces ¡are ¡ ¡one ¡form ¡of ¡ dependency, ¡others ¡include: ¡ – PlaHorm ¡dependencies ¡ on ¡OS ¡and ¡hardware. ¡ – Distribu@on ¡dependencies ¡ on ¡IP, ¡RMI, ¡etc. ¡
Explicit ¡Context ¡Dependencies ¡ PDA ¡(node ¡1): ¡ Sensor ¡(node ¡2): ¡ ¡ ¡ ALARM ¡ ¡ ¡ TEMP ¡ TEMP ¡ GUI ¡ ¡ ¡ SENSOR ¡ ALARM ¡ ¡ ¡ ¡ ¡ ANDROID ¡ ¡ CONTIKI ¡OS ¡ ¡ OS ¡ • Required ¡soJware ¡interfaces ¡are ¡ ¡one ¡form ¡of ¡ dependency, ¡others ¡include: ¡ – Pla4orm ¡dependencies ¡ on ¡OS ¡and ¡hardware. ¡ – Distribu@on ¡dependencies ¡ on ¡IP, ¡RMI, ¡etc. ¡
Explicit ¡Context ¡Dependencies ¡ PDA ¡(node ¡1): ¡ Sensor ¡(node ¡2): ¡ ¡ ¡ ALARM ¡ ¡ ¡ TEMP ¡ TEMP ¡ GUI ¡ ¡ ¡ SENSOR ¡ ALARM ¡ ¡ ¡ ¡ ¡ ANDROID ¡ Java ¡RMI ¡ ¡ SQUAWK ¡O/S ¡ ¡ OS ¡ • Required ¡soJware ¡interfaces ¡are ¡ ¡one ¡form ¡of ¡ dependency, ¡others ¡include: ¡ – Pla4orm ¡dependencies ¡ on ¡OS ¡and ¡hardware. ¡ – Distribu/on ¡dependencies ¡ on ¡IP, ¡RMI, ¡etc. ¡
Introspec'on ¡ • Dynamism ¡and ¡unreliability ¡means ¡that ¡we ¡ cannot ¡assume ¡a ¡fixed ¡composi=on. ¡ ¡ PDA ¡(node ¡1): ¡ Sensor ¡(node ¡2): ¡ ¡ ¡ ALARM ¡ ¡ TEMP ¡ ¡ TEMP ¡ GUI ¡ ¡ ALARM ¡ ¡ SENSOR ¡ ¡ ¡ ¡ ¡ ANDROID ¡ Java ¡RMI ¡ ¡ SQUAWK ¡O/S ¡ ¡ OS ¡
Introspec'on ¡ • Dynamism ¡and ¡unreliability ¡means ¡that ¡we ¡ cannot ¡assume ¡a ¡fixed ¡composi=on. ¡ ¡ ALL ¡ CLEAR ¡
Introspec'on ¡ • Dynamism ¡and ¡unreliability ¡means ¡that ¡we ¡ cannot ¡assume ¡a ¡fixed ¡composi=on. ¡ ¡ ALL ¡ CLEAR ¡ POWER ¡IS ¡INTERRUPTED ¡AND ¡NODE ¡FAILS ¡
Introspec'on ¡ • Dynamism ¡and ¡unreliability ¡means ¡that ¡we ¡ cannot ¡assume ¡a ¡fixed ¡composi=on. ¡ ¡ ALL ¡ CLEAR ¡ POWER ¡RESUMES ¡AND ¡NODE ¡REACTIVATES ¡
Introspec'on ¡ • Dynamism ¡and ¡unreliability ¡mean ¡that ¡we ¡ cannot ¡assume ¡a ¡fixed ¡composi=on. ¡ ¡ PDA ¡(node ¡1): ¡ Sensor ¡(node ¡2): ¡ ¡ ¡ ALARM ¡ ¡ ¡ GUI ¡ ¡ ¡ ¡ ¡ ¡ ¡ ANDROID ¡ ¡ SQUAWK ¡O/S ¡ ¡ OS ¡ BUT ¡OUR ¡COMPOSITION ¡IS ¡FAULTY ¡DUE ¡TO ¡MISSING ¡COMPONENTS. ¡
Recommend
More recommend
