07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 1 Component Framework for Consumer Electronics Middleware Location: TU/e (HG 5.95) SAN Weekly presentation Date:10 September 2004 Johan Muskens
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 2 Outline Introduction – Background – Motivation – Requirements Component Model – Life-Cycle – Component Packaging Run Time Architecture – Executable Component – Run Time Environment – Download Framework – Resource Management Framework Discussion
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 3 Background Research is part of the following projects Robocop ( ) – Define an open, component-based framework for the middle-ware layer in high-volume consumer devices (robustness/reliability, upgrading/extension, and trading) Space4U ( ) – Extend and validate the Architecture Fault Management Power Management Terminal Managment
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 4 Motivation for Component Based Development Aim: Increase productivity (Reduce Time to Market) by making reuse easier. How: Reuse at component level Easy composition (and modification of a composition) – Interaction through well defined interfaces – Dependability on interfaces in stead of components – Composition at run-time (run-time upgrading) Component Trading – Component repositories
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 5 What is a Component Model? A component model specifies the standards and conventions imposed on developers of components. A component model addresses (at least) the following: – the set of component types, including their interfaces, – the allowable patterns of interaction (component- component and component-run-time interaction); in particular the binding mechanism. Component Model = Rules
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 6 What is a Component Framework? A generic software architecture (described in terms of component interfaces, composition mechanisms and composition rules) together with a set of generic software components that may be used to realize specific software architectures. Component Framework = Tools + Generic Architecture + Generic components
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 7 What is an Architecture? The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 8 What is offered by Component Frameworks? blue = mandatory
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 9 Existing Component Frameworks (D)COM EJB.NET CORBA Koala PECOS AutoComp Robocop...
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 10 Focus in CE Domain red = focus CE domain
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 11 Evaluation Existing Component Frameworks yellow = focus CE domain
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 12 Outline Introduction – Background – Motivation – Requirements Component Model – Life-Cycle – Component Packaging Run Time Architecture – Executable Component – Run Time Environment – Download Framework – Resource Management Framework Discussion
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 13 Component Life-cycle
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 14 Component Packaging A Robocop component is a set of possibly related models – RC = P(M) x P(M x M x T) – M=EM ∪ BM ∪ RM ∪... – T=MODELTYPE x MODELTYPE x NAME
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 15 Component Packaging (Motivation) Trading – Different views for different stakeholders Executable for consumer Source code, documentation for developer... – Desirable to trade more than binaries Analysis – During Development Simulations / Analysis for feasibility tests – At Run Time Admission tests during downloading of components
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 16 Component Packaging (Example)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 17 Outline Introduction – Background – Motivation – Requirements Component Model – Life-Cycle – Component Packaging Run Time Architecture – Executable Component – Run Time Environment – Download Framework – Resource Management Framework Discussion
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 18 Runtime Architecture Run-time view of a terminal – Application Layer Applications – Middleware Layer Run Time Environment Executable Components – Platform Layer OS Abstraction Device & HW drivers
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 19 Executable Component Executable Components implement a number of Services Executable Components are instantiated in OS terms – Static in process (LIB) – Dynamic in process (DLL) – Dynamic out process (EXE) Executable Components have a fixed entry point for – Registration to Run Time – Retrieving Service Manager Service Manager is used for instantiating services
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 20 Services Services offer their functionality through a set of ports (named interfaces) Services have explicit dependencies required ports (named interfaces) An Interface is a set of operations Services are instantiated at Run Time – Service ≈ Class in object oriented programming Service Instance is an entity with its own data and a unique identity – Service Instance ≈ Object in object oriented programming
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 21 Executable Component (Example)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 22 Run-time Environment Responsibility – Registration of components and services – Handle requests for services instances (and services managers) – Offer support for QoS (Optional) Implementation – Three tables Association between Component (ID) and Location Association between Component (ID) and Service (ID) Complies relation between Services (IDs)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 23 Run Time Environment ( Example Registry Content )
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 24 Run Time Environment ( Example Registry Content ) This graphically depicts the contents of the registry on previous slide
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 25 Download Framework Responsibility – Transfer Robocop components from repository to a target terminal. Implementation – 5 roles together accomplish the download Initiator Locator Decider Repository Target (needs to be on the terminal)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 26 Download Framework (Key Features) Low Resource Footprint on Target – Only the target role needs to be resident on the target terminal Supports external initiation of download – Initiator can be resident on a external server Supports decision on suitability of a component for a specific target – Decider role
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 27 Download Framework (Procedure)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 28 Download Framework (Example Deployment)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 29 Resource Management Framework Resource Management using the following Quality Aware Entities – Quality Manager Maintain global quality. – Assign & Negotiate budgets – Resource Manager Setting & Accounting & Enforcing budgets – Quality Chief (application of service) Interact with Quality Manager (Negotiation) – Resource Chief Interact with Resource Manager Isolate platform dependent issues
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 30 Platform Layer Resource Management Framework ( Overview ) Quality Manager and Resource Manager are part of the RRE. Quality Aware entities implement the IQualityChief interface – Services – Applications Resource Chiefs are part of the OS – In Robocop the linux kernel has been patched RRE Quality Manager Resource Manager QoS Manager Quality Chief Application QoS-aware Quality Chief Service QoS-aware Resource Chief Application Layer Platform Layer Middleware Layer
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 31 Resource Management Framework (API) Quality Manager – addApplicationQM / removeApplicationQM – reviewSystemQuality – assessFeasibility Resource Manager – checkFeasibility – setConfiguration – setBudgetUser / removeBudgetUser – getMonitoringInfo Quality Chief – getQualityInfo – setQualityLevel – getBudgetID Resource Chief – createBudget / removeBudget – getStatusBudget – getMonitoringInfo –...
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 32 Resource Management Framework (Negotiation)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 33 Resource Management Framework (Setting Configuration)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 34 Resource Management Framework (Change Configuration)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 35 Outline Introduction – Background – Motivation – Requirements Component Model – Life-Cycle – Component Packaging Run Time Architecture – Executable Component – Run Time Environment – Download Framework – Resource Management Framework Discussion
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 36 Discussion Robust and Reliable Operation – Explicit dependencies between services – Resource Management Framework – Fault Management Framework (Space4U) – Integrity Management Framework (Space4U)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 37 Discussion Low Resource Footprint – Minimal Run Time Service registration & instantiation only Download Framework, Resource Management Framework,... are all optional Computation intensive part (e.g. deciding and customizing)of Download Framework can be done outside the terminal – Minimal Communication overhead Interfaces use vtables this requires one additional pointer dereference per method invocation. – No interpreted language
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 38 Discussion Upgrading and Extension – Applications and services are dependent on (binary)interfaces not on services. – New components can be downloaded and registered at run-time (Download Framework)
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 39 Discussion Trading – Download Framework enables transfer of components – Different models address the different concerns of the different stakeholders