Blank 01

MassWare components and component-level reflection
A MassWare component is a function independent reflective element that provides an interface metaobject by which a component can read its own metadata, extract the metadata from the component (called reification), and use that metadata either to inform the component user or to modify the component’s behavior (called absorption). Metadata is information about the data—that is, information about the types, functions, code, and etc., which are stored along with a component. By using the interface metamodel and component-level reflection, MassWare can examine the types in a component, create new types at runtime, interact with or instantiate the types, and dynamically invoke properties and methods on the instantiated objects (called the late binding). To incorporate a new reflective component in MassWare, users need to describe the types, interfaces, and other attributes of the component in a system script file by using our defined IDL (Interface Description Language), as shown in the Figure, so that the component can be identified and configured by MassWare at runtime through the late binding. We have realized three methods to identify a MassWare component for vehicle applications: the exclusive component name for a registered system component, the complete address for a local component, and the desired attributes for a registered component in the component manager. The component type is declared in the ctype part and the alias is the name of the component used in the adaptation-rule part of the script. The component can be specified by setting its parameters, which can also be reconfigured at runtime according to the adaptation rules. It also provides some interfaces (e.g. input and output interfaces). The connected input and output interfaces must support compatible event messages and their connections can also be reconfigured at runtime. There are two types of MassWare components: reconfigurable functional components (masslets) and extensible context-awareness components (masstools). The context-awareness components can be further classified into measurement tool components (named as awaretools) and user defined function components (named as awarefuncs) built above awaretools. Masslets are the basic functional units to construct vehicle applications. MassWare supports the publish/subscribe model for communication and each masslet provides some output and input interfaces for component assembly. The output interface of a masslet can be subscribed by the message-compatible input interfaces of other masslets and publish messages to them. Measurement tools, which measure and predict real-time context awareness e.g. network conditions for vehicle communication and road situations for action replan in MassWare, are realized as reflective components (called awaretools) to facilitate the reuse and extension of existing measurement tools. The context awareness research has been addressed in our previous work. Awaretools act as the lowest event sources in the event tree that can be subscribed by higher level event nodes and organized in a hierarchical way to build event sensors. MassWare also supports another type of reflective component—awarefunc to assist the extension of awaretools. An awarefunc provides not only output interfaces to accept the subscription from, and notify higher level sensor nodes, but also some input interfaces to subscribe to awaretools and process their raw data as input parameters. Thus it supports user defined functions for pre-processing the measurement results of awaretools, e.g. getting the average value of the bandwidth in the last 5 minutes. To better maintain and update MassWare components, we have proposed a distributed service module, called the Component Manager (CM) that accepts component registration and provides such services to vehicle applications as component identification, evaluation, migration, and virtual connection. So far we have focused our concern on the component employment and realized component identification function according to a user-provided component name and version properties; thus we leave the component evaluation, migration, and virtual connection functions for further work.

MassWare components and component-level reflection

A MassWare component is a function independent reflective element that provides an interface metaobject by which a component can read its own metadata, extract the metadata from the component (called reification), and use that metadata either to inform the component user or to modify the component’s behavior (called absorption). Metadata is information about the data—that is, information about the types, functions, code, and etc., which are stored along with a component. By using the interface metamodel and component-level reflection, MassWare can examine the types in a component, create new types at runtime, interact with or instantiate the types, and dynamically invoke properties and methods on the instantiated objects (called the late binding).

To incorporate a new reflective component in MassWare, users need to describe the types, interfaces, and other attributes of the component in a system script file by using our defined IDL (Interface Description Language), as shown in the Figure, so that the component can be identified and configured by MassWare at runtime through the late binding. We have realized three methods to identify a MassWare component for vehicle applications: the exclusive component name for a registered system component, the complete address for a local component, and the desired attributes for a registered component in the component manager. The component type is declared in the ctype part and the alias is the name of the component used in the adaptation-rule part of the script. The component can be specified by setting its parameters, which can also be reconfigured at runtime according to the adaptation rules. It also provides some interfaces (e.g. input and output interfaces). The connected input and output interfaces must support compatible event messages and their connections can also be reconfigured at runtime.

There are two types of MassWare components: reconfigurable functional components (masslets) and extensible context-awareness components (masstools). The context-awareness components can be further classified into measurement tool components (named as awaretools) and user defined function components (named as awarefuncs) built above awaretools.

Masslets are the basic functional units to construct vehicle applications. MassWare supports the publish/subscribe model for communication and each masslet provides some output and input interfaces for component assembly. The output interface of a masslet can be subscribed by the message-compatible input interfaces of other masslets and publish messages to them.

Measurement tools, which measure and predict real-time context awareness e.g. network conditions for vehicle communication and road situations for action replan in MassWare, are realized as reflective components (called awaretools) to facilitate the reuse and extension of existing measurement tools. The context awareness research has been addressed in our previous work. Awaretools act as the lowest event sources in the event tree that can be subscribed by higher level event nodes and organized in a hierarchical way to build event sensors.

MassWare also supports another type of reflective component—awarefunc to assist the extension of awaretools. An awarefunc provides not only output interfaces to accept the subscription from, and notify higher level sensor nodes, but also some input interfaces to subscribe to awaretools and process their raw data as input parameters. Thus it supports user defined functions for pre-processing the measurement results of awaretools, e.g. getting the average value of the bandwidth in the last 5 minutes.

To better maintain and update MassWare components, we have proposed a distributed service module, called the Component Manager (CM) that accepts component registration and provides such services to vehicle applications as component identification, evaluation, migration, and virtual connection. So far we have focused our concern on the component employment and realized component identification function according to a user-provided component name and version properties; thus we leave the component evaluation, migration, and virtual connection functions for further work.