A Component Framework for Consumer Electronics Middleware J. Muskens, M.R.V Chaudron and J.J. Lukkien Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, P.O. Box 513, 5600 MB Eindhoven, The Netherlands
[email protected],
[email protected],
[email protected]
Abstract. Developers of Consumer Electronics (CE) devices face the problem of the ever increasing amount of software that needs to be developed. At the same time the time to market of their products needs to decrease. In other domains Component Based software development aids in solving the resulting problems. However, existing component frameworks fail to meet some of the requirements specific for the CE domain. In order to improve this situation a component-based framework has been developed. In this chapter we describe this framework and motivate the architectural choices. These choices are influenced by the requirements on the framework. Some of these requirements are specific for the CE domain, others are more general.
1
Introduction
1.1
Background
The component framework presented in this chapter has been developed in the context of the Robocop project 1 . The aim of Robocop is to define an open, component-based framework for the middleware layer in high-volume consumer electronic devices. The framework enables robust and reliable operation, upgrading, extension, and component trading. The appliances targeted by Robocop are consumer devices such as mobile phones, set-top boxes, dvd-players, and network gateways. 1.2
Motivation
With the increasing capacities of Consumer Electronics (CE) devices the amount and complexity of the software in these devices is growing rapidly. The software is determining to a large extent what a device is or feels like. Producers of these devices face the challenge of developing this continually increasing amount of software while the time-to-market should preferably decrease. Component Based Software Engineering (CBSE) promises to aid in solving the resulting problems. Key success factors generally attributed to CBSE are: 1
The project is funded in part by the European ITEA program. This is a joint project of various European companies, together with private and public research institutes.
1. the possibility of re-use at the level of components; 2. the support for component composition such as to build new applications; 3. the promise of improved reliability because of explicit specifications and subsequent convergence of individual components to comply with their specifications. In short, the success should come from being able to use software components in a similar way as we do their hardware counterparts. This includes the way components are paid for or otherwise traded. Presenting a piece of software as a component should therefore really represent a gain in terms of abstraction. In particular this calls for elimination of as many dependencies as possible and, as far as dependencies exist, to specify them explicitly and to bring them to the component interface. Several component frameworks have been developed over the last years, all addressing to some extent these three success factors. However there are also a lot of differences between the existing component frameworks, mainly due to the different requirements in the individual problem domains. Successful adoption will depend on how well the three issues mentioned above are addressed plus some other factors depending on domain specific requirements. These factors are discussed in section 2. Existing component frameworks did not meet some of the requirements particular important for the CE domain: – – – –
Robust and reliable operation Run-time upgrading and extension Low resource footprint Support for component trading
In order to improve this situation a number of European companies and universities have joined forces in an effort to develop a component-based framework for the middleware layer of network-enabled consumer devices, addressing several of the points above. This work was done in the context of the Robocop project [14] which was subsequently used as input for the Space4U project [19]. In this paper we describe the approach defined by these projects. 1.3
Overview
This chapter is structured as follows. Section 2 describes the project context and the target requirements set out for the component framework. It also relates these to existing component frameworks. Section 3 discusses the architecture and how it relates to the targets. Section 4 presents the download framework which enables runtime upgrading and extensibility of a component assembly. Concluding remarks and related work follow in section 5.
2
Background and Requirements
In this section, we discuss the most important requirements for the Robocop component framework and how they influenced the architecture.
Component Framework Extra−functional properties Timeliness Low Resource Footprint Security Robustness & Reliability Trading Upgrading & Extension Development Support Language Independence Platform Independence Analysis Support Infrastructure Instantiation Communication Binding Announcement Capabilities Distribution Discovery
Fig. 1. Component Framework Features (gray=mandatory, white=optional)
There are quite some differences between existing component frameworks. These differences are due to different requirements in the targeted application domains. Figure 1 shows the ’features’ provided by component frameworks. Some of the features are mandatory (marked gray), for example Communication. Some of the features are optional (marked white), for example Language independence. 2.1
Common Features of Component Frameworks
In this section we discuss some features that are common to many component frameworks. We distinguish the categories of features depicted in Figure 1: – Infrastructure: All component frameworks provide an infrastructure. With infrastructure we mean mechanisms for component instantiation, binding, communication, distribution of components over hardware, announcing capabilities of components and discovery of desired components. These mecha-
nisms are needed to create a composition of components that can cooperate in performing a certain task. • Instantiation: A Component Instance is the instantiation of a Component implementation at a specific location in the memory of a device. The relation between a component instance and a component implementation is the same as that between an object and a class. Once in operation, each component instance may create and manage its own data. There is a number of different ways in which the instantiation can be achieved. The distinguishing factor is the element in the architecture that controls the instantiation. In existing component frameworks instantiation is typically controlled either by the component infrastructure, a component container, or a component factory. • Binding: In the context of component-based systems, binding is the creation of a link between multiple component instances. Binding can be done at design-time, compile-time and run-time. At design time and compile time the binding is done by the developer. The link between component instances may be used for communication and navigation between component instances. The distinguishing aspect of the different ways in which binding can be organized in a component framework is the party that initiates the binding. We distinguish 1st party binding and 3rd party binding. In case of 1st party binding a component instance binds itself to another component. In case of 3rd party binding a binding between component instances is created by a party not part of any of the subjects of the binding. • Communication: To facilitate communication between components, a component infrastructure must provide some interaction mechanisms. The interaction styles supported are partially defined by the architectural styles that the component framework supports. The communication styles that a component infrastructure supports determine a number of the quality properties that systems built using these components can obtain. For instance, some communication styles favor efficiency over flexibility. The most common style is request-response as implemented by procedure / method-calling. This style is the basis of all imperative programming languages and does not require any special facilities from the componentmodel. The next most commonly supported interaction style is events. Typically events are used for notification; e.g. of exceptions. Often this style is used in conjunction with request-response interaction. Publish / subscribe can be seen as a generalization of events to distributed systems. Component framworks that are aimed at supportint multi-media processing often provide mechanisms that support streaming as interaction style. • Discovery: Every component framework needs to define a mechanism by which presence of components in the system can be discovered. Such a Discovery mechanism is needed to support late and dynamic binding. Discovery mechanisms are the most prominent in component frameworks
with run-time changes/binding. In systems with design-time or compiletime binding the discovery is typically guided by the designer / developer. In systems with run-time adaptation a registry is commonly used for the discovery of components. • Announcement of capabilities: Usually the capabilities of a component are expressed by a number of interfaces that are implemented by a component. The way in which interfaces are specified differ between component frameworks. Some component frameworks introduce a special language for expressing interfaces, others use programming languages to specify the interfaces. – Component and application development support: Components and applications are developed using a component framework. The component frameworks have different development features. For example COM[1] and .NET support programming language independent development of components, whereas Enterprise Java Beans (EJB) [15] supports platform independence. • Language independence: Component frameworks often support component development in different programming languages. In order to achieve interoperability between the components developed in the different programming languages the interfaces must be specified in a manner that is independent of the programming language. Usually an interface description language (IDL) is used for this purpose. • Platform independence: Some component frameworks offer platform independence; this means that executable components can be executed on different platforms. This is usually achieved using a intermediate language. This intermediate language can be interpreted at run-time or compiled by a Just In Time (JIT) compiler. • Analysis support: During development of individual components and applications it can be desirable to have analysis techniques. These techniques can be used to prove correctness of the software [7], or to predict extra functional properties [5], [11]. – Support for upgrading and extension: Software evolves over time. The value and the economic life-time of a device and the software on it can be increased by supporting upgrading and extension of the software. Component frameworks can support upgrading and extension at different stages of the software life-cycle (design-time, compile-time, run-time, etc.). The current trend is that upgrading and extension is shifting more and more to the runtime phase of the software life-cycle. In this way, devices can be customized to the needs of a consumer in the period that it is owned and used by the consumer. – Support for extra functional properties: In conjunction to functional requirement, software also needs to satisfy extra functional properties like performance, security and reliability. Which extra functional properties are important for a component framework highly depends on the problem domain that it targets. The extra functional properties that are important can introduce all kinds of restrictions on a component framework. For example, when a low
resource footprint is important this can exclude the use of virtual machines for interpretating of programs. – Support for trading: In order to gain the benefits of reuse and trading, a large market of components and hence component-producers is needed. The fact that components should be traded has technical implications for the component framework. 2.2
Focus for the CE Domain
The requirements on a specific component framework highly depend on the problem domain in which the framework will be used. Below we will discuss the features that were specifically important for the consumer electronic domain and, consequently for Robocop: – Upgradability and Extensibility: Improvements in software are developed in rapid succession. To extend the economic lifetime of devices, they should be able to upgrade software components with improved versions. In addition to upgradability, there is a need to be able to add new functionality to a device. The mechanism needed for uploading new functionality can be largely shared with that for upgrading. – Robustness and Reliability: In the area of consumer electronics, it is unacceptable that systems break down. Building stable systems requires special effort during their design [2] as well as special mechanisms at runtime [3] [17] [12]. – Low resource footprint: Consumer electronic systems must be made cost effective. This results in limited available resources on the targeted devices and imposes strict resource constraints on the components and the infrastructure. – Trading: One of the main reasons for component based development is decreasing time to market and increasing productivity by increase the (re-)use of existing components. In order to maximally exploit (re-)using existing components, it should be possible to use third-party components. This requires support for trading. In Robocop this requirement highly influenced the choice for component packaging. In section 3 we present the architecture and motivate how it was constructed driven by the requirements mentioned above. Section 4 presents a download framework that can be used in addition to the architecture to realize support for run-time upgrading and extension. In the remainder of this section we will discuss which features are realized by existing component frameworks and how they are realized. Figure 2 shows which features are supported by the existing component frameworks. This Figure shows that there is a core set of features offered by all existing component frameworks. There are also a number of features at which component frameworks distinguish themselves. The features that where especially important for the CE domain are highlighted. Infrastructure features are
Fig. 2. Features of existing component frameworks (features particular important for the CE domain are highlighted)
Fig. 3. Common solution for component framework features (features particular important for the CE domain are highlighted)
offered by all component frameworks. These features like instantiation, binding and communication are needed to create a system out of components that cooperate to achieve a certain goal of the system. The largest differences between the individual component frameworks can be found at the level of support for extra functional properties, flexible upgrading / extension, development and trading. The need for these features, and therefore the selection of the component framework, depends highly on the target problem domain. In Figure 3 we show some existing solutions for component framework features. Most features cannot be dealt within isolation. Solutions for one feature can exclude, or negatively influence, other features. This means there is no such thing as a free lunch. For example platform independence is usually realized using an interpreted or intermediate language, which negatively influences performance. Each component framework needs to make a trade-off between the different features.
Developed Component
Publish
Published Component
Development Tailoring ROBOCOP
DOMAIN
ARCH.
REQS
Load (OS) & Instantiate Tailored Component
Target Loading Installed Component
Registration
Resident Component
Fig. 4. Component Life-cycle
3
Architecture of Framework and Component Model
In this section we will discuss the architecture and component model that has been developed during the Robocop project. We will discuss the Robocop component life-cycle, Robocop component packaging, executable component structure and the run-time execution model. 3.1
Component Life-cycle
The Robocop life-cycle addresses Robocop components from development time, until run-time instantiation of services. During their life-cycle the Robocop components manifest themselves in different ways. Once developed, Robocop components are published in a repository. Published Robocop components can be generic in the sense that they still need to be tailored to run on a specific platform. This may involve e.g. compilation and linking for that platform. At this time the Robocop component can be loaded on the specific target. When a Robocop component is resident on the target it needs to be registered. After registration the component is ready to be used. The component can be loaded and services implemented by the component can be instantiated. The life-cycle is depicted in Figure 4. 3.2
Component Packaging
Unlike Szyperski [20], we found that the unit of trading is not the same entity as the unit of deployment. We distinguish between Robocop components which are the units of trading and configuration management and executable components which are executable code that is physically present in the memory of a device during execution. During the component life-cycle a number of stakeholders are involved. These stakeholders are interested in different aspects of a component. A user of a device
is interested in executable code for his device. A system developer is interested in documentation as well, maybe even the source code. Some of the stakeholders are not interested in the executable code, an system architect can decide to use a component based on a specification or simulation model. The Robocop component model can support all these different uses by using different models for the individual aspects. Usage of multiple different models is very useful in component trading, since a number of stakeholders can be involved with different concerns. Furthermore we found that it is often desirable to trade more than executable code (documentation, sources, etc). A Robocop component (component package) is a set of related models (see Figure 7). The set of models is not fixed, but may be extended if needed. Any particular Robocop component must consist of one or more of these models. The information in the models can be human-oriented or machine-oriented. An example of human-oriented models is documentation. Typically one of the machineoriented models will be the executable component. In order to achieve technical interoperability of executable components, many issues concerning the run-time execution model need to be defined. More details about this are given in the remainder of this paper. Other examples of (machine-oriented) models are: – A simulation model. This type of model could be of use during design of an application to analyze the interaction between components. Such models should be supplied by the developers of the component. Colored PetriNets [8] are a candidate for this type of model. – A resource model. This type of model describes the resource needs of a component. This can be used both during design and during the dynamic upgrading to assess whether a configuration of components fits within the available resources [4]. – A functional model. This type of model specifies the functionality of the component. A candidate specification language for this type of model is Z [18]. – Interface model (Robocop IDL). This model describes the functions provided and required by the component. Based on this model it is possible to check whether or not all dependencies in a configuration can be resolved. An example of a Robocop IDL description can be found in Figure 5. Each Robocop component contains a globally unique identifier (GUID). This is needed for configuration management. Additionally each model is also identified by a GUID. Figure 8 shows two examples of different Robocop components. Robocop component 1 contains one executable, one IDL, one simulation model and one resource model (see also Figure 6). Robocop component 2 contains two executables, two resource models, one IDL and one simulation model. Multiple executables implementing the same IDL can occur when a Robocop component provides executables for multiple platforms. In that case the resource consumption of the executables can be different, thus different resource models for the executables are included. Relations are used to indicate which resource model is related to a specific executable model.
module Printers { interface IPrinter {6083D1C4-0643-4ce6-B1EA-66467A65840C} { void printLn( in string line ); ... }; service SPrinter {68CCA7C4-C24A-4bee-9A5E-AF79B806483D} { provides { IPrinter printer; }; };
service SPlotter {6782A98F-06D5-436f-AE89-0D6E064AB047} complies SPrinter { provides { IPrinter printer; }; }; component CLaserPrinter {B7621504-7FCD-42ea-BCF0-90F67FE557C7} { provides SPlotter; }; };
Fig. 5. Example Robocop IDL description
3.3
Executable Component Structure
The Robocop component package, as described in section 3.2, is applicable to any type of model. Therefore it can be applied to any kind of binaries: e.g. static or shared libraries, COM components, or even complete executables. However, the executable view of the component determines how applications can be built from these components. This view is different for the various executable models, and determines at which abstraction level systems are composed. We will now discuss the executable component model. In the remainder of this paper we will use the term component for the executable component model. For the Robocop component package we will use the term Robocop component. Within Robocop, a component contains a number of services. These services implement the functionality of the component. Each service offers this functionality through a set of named interfaces (ports). The interfaces used are COM [1] interfaces. The vtable approach used in these interface results in little communication overhead. The overhead is limited to one pointer dereference per operation invocation on an interface. Services have explicit dependencies through a set of named requires interfaces (ports). All interfaces have a standard error return mechanism and there is a facility to pass additional error information from a service to the client using the service. The explicit dependencies, and the error return mechanisms enable the development of a robust and reliable system. Every component implements at least one service manager. This service manager is used to instantiate services and initialize attributes of the created service instances. Each component has a fixed entry point, this entry point is used to get a service manager. Figure 9 illustrates the structure of the executable component.
Fig. 6. Example Robocop component description
The services implemented by components can be specified in a Robocop IDL (RIDL). RIDL is inspired by the CORBA [10] IDL. For each service the provided ports and required ports are specified as well as the public attributes of a service. RIDL allows a developer to specify that a service is compliant with another. Service X is compliant with another service Y at a structural level means: service X provides at least the named interfaces that are provided by service Y and service X requires the same named interfaces that are required by service Y. In this case code written to use service Y will also work using service X. 3.4
Run-time Execution Model
In this section we will present the run-time execution model used in Robocop. The Robocop runtime environment (RRE) has a key role in this execution model. In order to enable a low resource footprint the RRE kept minimal and can be extended with optional frameworks. The RRE supports registration of components / services and instantiation of services. All other features, like for example resource management, are optional. If these features are not used there is no resource overhead. Next we will discuss how the RRE stores the component information in a registry, how components are registered, how services of a component can be instantiated and how the functionality provided by a service can be used. The RRE Registry The core responsibility of the RRE is to handle requests for service instances (and service managers). The desired service instance is identified by its GUID and the RRE needs to find a component that can deliver instances of the specified service. To that end, the RRE maintains sufficient information in a database (referred to as the registry).
Robocop Component Resource Model Simulation Model Documentation Function Model Source Code ... Executable Model
Fig. 7. A Robocop component is a set of models
This registry contains three tables (see Figure 10). The first table contains the association between the component GUID and the physical location of the component. This physical location is formatted in a URL-like fashion. When the component is stored in a file system, the location will be file:// followed by the actual file name. For systems that store the component in a direct addressable memory space the location looks like address:// followed by the physical address containing the component code. The second table contains the relation between the component GUID and the service GUID. As indicated earlier, a component can implement multiple services. It is equally well possible that a particular service is implemented in more than one component. When multiple components are registered in this table for the same service, the implementation of the RRE is free to choose any of these components when there is a request for a service. The third table contains the complies relation for services. When a service is requested, the RRE can use this table to find compliant services that can be used to satisfy the request. In Figure 11 below, there is a graphical representation of a sample registry contents (the same contents as in Figure 10). The solid lines indicate the complies relation between services: e.g. the SPixelScreen service complies to the SCharacterScreen. So, the SPixelScreen can be used when a SCharacterScreen service is needed. The dotted lines indicate which component implements which service. In the example the CScreen component implements both the SPixelScreen and the SCharacterScreen service. When the SCharacterScreen is requested, the RRE will activate the CScreen component and send it a request to instantiate the SCharacterScreen service. When the SOutput service is requested, there is no component registered that can instantiate the service. The RRE might activate the CLasterPrinter, and request it to instantiate the SPlotter service, or it might activate the CScreen
Robocop Component 1 Resource Model 1
IDL
Simulation Model 1
Executable Model 1
Robocop Component 2 Resource Model 1
Resource Model 2
IDL
Simulation Model 1
Executable Model 1
Executable Model 2
Fig. 8. An example Robocop Component
component, and request it to instantiate the SPixelScreen or the SCharacterScreen service. The actual component and service used, is left to the RRE. Registration The behavior of the RRE is driven by the information in the registry. When components are resident on a system, information needs to be added to the registry (registration) in order for the RRE to be able to use the component and the implemented services. The components themselves play a passive role in this registration process: the system configurator controls the registration process. This role can be exercised by a person assembling the system or can be automated to some degree. We do not let components themselves be in control of this registration process, because it is a system-wide aspect, i.e. can only be done well with system-wide knowledge. For example, when two components can offer the same service, neither of the components can decide which one should be used in the system. Instead of using an overwrite strategy (e.g. the component most recently registered takes precedence), this choice needs to be made external to the individual components. The registration information needed is either directly known to the system configurator (e.g. location of the component on the target) or can be obtained from the RIDL description (component GUID, service GUIDs, complies relations) or via one of the other models in the Robocop Component. Note that a system configurator may decide not to use all of the information for the registration. The configurator can decide not to register all of the services, or ignore some of the complies relations. This is useful, because the complies relation on the RIDL level only expresses substitutability at a structural level.
CScreen
Component entry point
ServiceManager
Executable Component
rcIService interface
Named provided interface (port)
SPixelScreen
SCharScreen Service
Named required interface (port)
Fig. 9. Executable component
Component Location component guid
Component−Service Relation service guid
Complies Relation service guid
complies with
component url
component guid
CScreenGUID
file://CScreen.so
CScreenGUID
SCharScreenGUID
SCharScreenGUID
SOutputGUID
CLaserPrinterGUID
file://CLaserPrinter
CScreenGUID
SPixelScreenGUID
SPixelScreenGUID
SCharScreenGUID
CLaserPrinterGUID
SPlotterGUID
SPrinterGUID
SCharScreenGUID
SPlotterGUID
SPrinterGUID
Fig. 10. The RRE registry with example contents
This does not address extra-functional aspects. The resource usage of the service may exceed what the system is willing to spend, and thus it makes sense not to register this service on the device. Instantiating Services Clients can get a Service Instance by calling functions in the RRE. Instantiating a service is a multi step process, with shared responsibility between the RRE and the Component that can instantiate the Service. The process can be broken down in three steps: – Locating and activating the component – Retrieving the Service Manager – Retrieving the Service Instance Locating a component has been described earlier in this section (The RRE Registry). Once the correct component is located, the RRE will activate the
CScreen
SPixelScreen
SCharScreen
SOutput Components are underlined Services are not underlined
SPlotter
SPrinter
CLaserPrinter
C1
S1
C1 implements S1
S1
S2
S1 complies with S2
Fig. 11. Graphical representation of registry contents
component. This entails loading the component in OS terms, which means mapping the component into (executable) memory space; e.g. from the filesystem where the component is stored. Each component supports a fixed entry point. This entry point is used to get a service manager, and to check if a component can be unloaded. The Service Manager is part of the factory pattern for the services [6]. The service instances are created using the Service manager. Additionally, the service manager can be used to pre-set attributes of the service instances.
Interacting with Service Instances As described earlier, the service instances expose their functionality through named interfaces (ports). Each service implements the rcIService interface. It supports methods to retrieve the provided ports of service instances, and the bindTo and the unBind method to bind and unbind interface instances (provided ports of a different service instance) to requires ports of the service. The methods to do this are not strongly typed. In order to have a type safe mechanism, each service definition gives rise to an interface definition that is implemented by the service. This interface is a descendant of the rcIService interface. For each provided port, there is a specific method GetProvides in this interface that returns an interface of the type as mentioned in the service definition. The is the actual port name used in the service definition. Similarly, there are two methods in this interface to bind and unbind requires interfaces: the bindTo and unBind. In general, a service instance can not operate when its requires ports are not bound. In order for a client to signal that it has finished binding its required interfaces and wants to start using the service instance, the client calls the Start method. This method can be called either in the rcIService interface, or in the service specific descendent of that interface.
4
Download Framework
In this section we will present the download framework. The download framework has been developed as part of Robocop to fulfill the requirements concerning upgrading and extension. During the period that a CE device is owned by a user there is a need for improving and extending the software on the device in order to extend the economic lifetime of the device. The download framework is responsible for transferring Robocop components from a repository to a target and their registration with the RRE. In the component lifecycle (see 3.1) this corresponds to the phases tailoring, target loading and registration. Within the Robocop project little work has been done on tailoring of components and automated registration of components. For locating Robocop components and target loading a solution has been developed that consists of the following conceptual roles: – – – – –
Initiator Locator Decider Repository Target
At run-time these roles can run at different devices. The target role runs at the terminal to which a component is transferred. The roles are discussed in detail in sections 4.1, 4.2, 4.3, 4.4, and 4.5 respectively. Within the download process we distinguish the following phases: – – – –
Location of entities that participate in the download process Decision about the feasibility of a given download Target loading, the actual transfer of the Robocop component to the device. Confirmation of the download and registration of the downloaded component at the RRE.
All roles that participate in the download process communicate using gSOAP [21]. The gSOAP technology enables communication between the different roles eventhough they might be deployed on different hardware nodes. The download process is depicted in Figure 12. Next, we will discuss the individual roles in more detail. 4.1
Initiator Role
In this subsection we will discuss the initiator role in the download process. The main responsibility of the initiator is verifying the presence of all the entities in the download process and coordinating the download process. The initiator role can be implemented by a component on the target device. It is also possible that the initiator role is implemented on a different device, this can be useful in case of remote maintenance. An initiator starts the download process in response to some external event. Such an event may be triggered for instance by the component upgrading process
Initiator
Locator
Decider
Repository
Target
ComponentAvailable
Location phase
Resp.(Status + Locations)
Resp.(Status) MakeDownloadDecision GetComponentProfile Resp.(Status + Profile) GetTargetProfile Resp.(Status + Profile)
Decision phase
DownloadDecision Resp.(Status) DownloadDecision
Resp.(Status) PushTransfer HTTP PUT
Transfer phase Resp.(Status)
ConfirmDownload
Confirmation / Registration phase Resp.(Status)
Fig. 12. The download procedure
or as result of a change in user preference settings. An initiator can participate in multiple download processes at the same time. The download processes are identified by the GUID of the Robocop component that needs to be transferred and a unique name for the target. In order to verify the presence of all the entities and to coordinate the download process, the initiator needs the addresses of all the entities. To that end the initiator has a table with the addresses of one or more locators ordered by priority or proximity (see Figure 13). Using one of these locators, the initiator can retrieve the addresses of the other entities involved in the download process. 4.2
Locator Role
In the process of downloading a Robocop component from a repository to a target, the locator is responsible for locating a repository which is to provide the Robocop component to be downloaded, and the target where the Robocop component is to be transferred. In addition, the locator is responsible for locating the entity playing the decider role which is responsible for deciding whether the given download will take place or not. Hence, the locator provides the addresses which can be used to contact the repository, the target and the decider. Although the functionality of the locator does not depend on the interconnection network used for the download, the latter determines the type of the address returned by the locator. For the sake of precision, the term address in the above definitions stands for a comprehensive descriptor of an entity in an interconnection network which allows its holder to contact that entity. For example, in an all-IP network this descriptor is the IP address of the entity.
L : Table of locator addresses N : Name of instance implementing role C : Class identifier (only for decider) T : Table of targets (name and address) D : Table of deciders (name,class and address) R : Table of repositories (name and address) Locator T: target name
address_v
R: rep. name
address_z
D: decider name decider class
address_y
adress_x
Decider Target
C: decider class
Initiator
N: target name L:
L:
address_x address_v
address_x address_w
Repository
N: decider name
N:
rep. name
L:
L:
address_x
address_x address_y
address_z
Fig. 13. Example of deployed download roles
In order to be able to provide the address information the locator maintains three tables. The first table is used to store all the registered targets, the second table is used to store the registered repositories, and the last is used to store the registered deciders. For all these entities the name and address is stored. For the deciders also the decider class is stored which can be used to distinguish different type of deciders. Information about which repository contains which components is not stored at the locator. When the locator receives a request to locate a repository that contains a Robocop component it will query all known repositories for that specific Robocop component using its GUID. A locator provides a registration mechanism for targets, deciders and repositories. Entities implementing these roles use this mechanism to register themselves at a number of locators. 4.3
Decider Role
A decider awaits a request (typically from an initiator) to determine if it is possible that a given Robocop component can be downloaded onto and subsequently registered on a given target. This is done by investigating and matching the acquired profiles of repository resident components and profiles of the target. After this matching process the decider will notify the involved parties of the decision. The decision procedures performed by the decider may be sophisticated. For example, in the case of components that are subject to a real-time scheduling
policy, a schedulability-test may be performed. Within the Robocop project little work has been done on defining advanced decision procedures. 4.4
Repository Role
The main responsibility of a repository is the storage of Robocop components in order to be transferred to a target. It is also possible that the repository tailors Robocop components; for example by compiling a component for a specific platform. During the download process the repository is first queried for the availability of a Robocop component. At a later phase in the download process the decider will request the component profile. After the repository has received a positive decision from the decider, it must prepare the specific Robocop component to be transferred to the target. The actual transfer of the Robocop component is activated by the initiator. The download framework supports two types of transfer strategies: Push and Pull. Figure 12 illustrates the Push strategy. In that case the initiator sends a message to the repository to start transferring the Robocop component. In the latter case the initiator will send a message to the target that it should fetch the Robocop component at the repository. 4.5
Target Role
The target role has two main responsibilities. The first is that a target should be ready to receive the Robocop component that is transferred during the download process and make it resident on the device. The second responsibility is providing the a profile of the target device to the decider. This is necessary for the decider to be able to make sure that the downloaded Robocop component is suitable for the target. In case of a Pull strategy for the transfer of the Robocop component, the target will have an additional responsibility: fetching the Robocop component. The example download process in Figure 12 is based on the Push strategy in which this is not the case.
5 5.1
Concluding Remarks Discussion
In recent years a number of component models have been developed. These component models aim to increase productivity and reduce time to market by enabling re-use of software. These benefits are also desirable in the CE domain. However, existing component models have failed to meet some of the specific requirements in the CE domain: – Robust and reliable operation – Run-time upgrading and extension – Low resource footprint
– Support for component trading In this chapter we presented the Robocop component framework that is specifically developed to satisfy these requirements in order to be suitable for the for the CE domain, or more general for the domain of high volume embedded systems. Robust and reliable operation have been achieved by using explicit dependencies between components and by providing hooks for analysis techniques (models describing the properties of components and services). Run-time upgrading and extension have been realized using dynamically loadable components. In order to achieve runtime upgrading and extension, services needed a binary interface. At runtime, services can be instantiated and connected by a third party. We used the vtable approach that is also used in COM [1]. Low resource footprint was one of the high priority requirements. To achieve this requirement we adhered the following principle: ”Do not pay for what you don’t use!”. We designed a minimal runtime environment that offers the core functionality of a component framework, e.g. discovery, instantiation, binding, and an efficient communication mechanism. Additional features are provided using optional frameworks. If an optional frameworks is not used, then there no overhead is incurred during run-time. Support for component trading should enlarge the market of components in order to increase the benefits of component based development. We distinguish Robocop components that are the unit of trading and configuration and executable components which are executable code that can be executed on the target device. To increase the tradeability of the components, it is desirable to have more information about a component than its executable only. For example, documentation, source code, specification, may be very useful. Therefore, Robocop components are defined to be a set of models. One of these models typically is the executable component; other models may provide complementary information about the component. 5.2
Related Work
Over the last couple of years a number of component models have been developed. A taxonomy of the most well known component models has been presented in section 2. Koala [13], PECOS [22], and AutoComp [16] are component models developed especially for embedded systems. These component models have some of the features required in the CE domain; they enable robust & reliable operation and a low resource footprint. Although run-time upgrading was already supported by existing component models like COM [1], EJB [15] and .NET [9], this was not the case for component models for embedded systems. To remedy this, the Robocop component model enables run-time upgrading and increase the support for run-time trading of components. In the Robocop framework we combine ideas for run-time upgrading from COM with ideas for robust and reliable operation from Koala.
5.3
Contributions
With the development of the Robocop framework we combined a number of solutions from existing component models to create a component model suitable for the CE domain. In addition we introduced the notition of a Robocop component as a set of models. Different model-types can be used to describe different aspects of a component, similar to the way multiple views are used in describing software architectures. The different models of a component increase the tradability since customers are usually not interested in just the executable code, but need additional information to assess suitability. 5.4
Acknowledgments
We are grateful to all the partners of the Robocop project for their contributions. Philips Electronics, Nokia, CSEM, Saia Burgess, ESI, Fagor, Ikerlan, University Polytechnic de Madrid, and Eindhoven University of Technology.
References 1. D. Box. Essential COM. Object Technology Series. Addison-Wesley, 1997. 2. I. Crnkovic and M. Larsson. Building Reliable Component-Based Software Systems. Artech House Publishers, 2002. 3. E. Dashofy, A. van der Hoek, and R. Taylor. Towards architecture-based selfhealing systems. In Proceedings of the first workshop on Self-healing systems. ACM, Nov. 2002. 4. M. de Jonge, J. Muskens, and M. Chaudron. Scenario-based prediction of run-time resource consumption in component-based software systems. In Proceedings: 6th ICSE Workshop on Component Based Software Engineering: Automated Reasoning and Prediction. ACM, June 2003. 5. E. Eskenazi, A. Fioukov, D. Hammer, and M. Chaudron. Estimation of static memory consumption for systems built from source code components. In 9th IEEE Conference and Workshops on Engineering of Computer-Based Systems. IEEE Computer Society Press, Apr. 2002. 6. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patters: Elements of Reusable Object oriented Software. Addison Wesley, 1995. 7. G. Holzmann. Spin Model Checker. Addison Wesley, 2003. 8. K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Springer-Verlag, 1997. 9. J. Lowy. .NET Components. O’Reilly and Associates, 2003. 10. T. Mowbray and R. Zahavi. Essential Corba. John Wiley and Sons, 1995. 11. J. Muskens and M. Chaudron. Prediction of run-time resource consumption in multi-task component-based software systems. Technical Report TR-117, Technische Universiteit Eindhoven, 2003. 12. J. Muskens and M. Chaudron. Integrity management in component based systems. In Proceedings of the 30th EUROMICRO conference, Rennes France, Aug. 2004. 13. R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The Koala component model for consumer electronics software. IEEE Computer, 33(3):78–85, Mar. 2000.
14. Robocop Consortium. Robocop: Robust open component based software architecture for configurable devices project (http://www.extra.research.philips.com/euprojects/robocop/), 2001. 15. E. Roman, S. Ambler, and T. Jewell. Mastering Enterprise JavaBeans. John Wiley and Sons, 2001. 16. K. Sandstrom, J. Fredriksson, and M. Akerholm. Introducing a component technology for safety critical embedded real-time systems. In 7th ICSE Workshop on Component-Based Software Engineering, May 2004. 17. B. Schmerl and D. Garlan. Exploiting architectural design knowledge to support self-repairing systems. In Fourteenth International Conference on Software Engineering and Kno wledge Engineering, 2002. 18. G. Smith. The Object-Z Specification Language. Kluwer Academic Publishers, Boston, 1999. 19. Space4U Consortium. Space4u: Software platform and component environment 4 you (http://www.extra.research.philips.com/euprojects/space4u/), 2003. 20. C. Szyperski. Component-based Software Engineering beyond object orientation. Addison-Wesley, 1998. 21. R. van Engelen and K. Gallivan. The gsoap toolkit for web services and peer-to-peer computing networks. In 2nd IEEE Internation Symposium on Cluster Computing and the Grid. IEEE Computer Society Press, May 2002. 22. M. Winter, T. Genssler, A. Christoph, O. Nierstrasz, S. Ducasse, R. Wuyts, G. Arevalo, P. Muller, C. Stich, and B. Schonhage. Components for embedded software - the PECOS approach. In 2nd ECOOP Workshop on Composition Languages, 2002.
