IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

Context processing within an open, component-oriented, software framework

Marco Luca Sbodio1, Dr. Wolfgang Thronicke2

1 Hewlett-Packard, Italy Innovation Centermarco.sbodio@hp.com

2 Siemens Business Services GmbH & coOHG, GermanyWolfgang.Thronicke@c-lab.de

Abstract. This paper presents some architectural guidelines for an open, com­ponent-oriented software framework supporting applications running on wear­able devices, and describes an approach for implementing context processing capabilities within such framework. The authors describe an open approach in­tended to both enhance reusability and simplify the development of context-aware applications.

Introduction

The increasing availability of affordable and wearable computing hardware, and of pervasive and ubiquitous computing is changing the scope of usage of such systems from academic to industrial and business domains. The project wearIT@work [15] is investigating the effects and the use that this technology will have from both technolo­gical and social perspective in real-world working environments. Successful systems today have to be modular, and they have to be built and configured from standard core component. One of the goals of wearIT@work project is the definition, design, and implementation of a Open Wearable Computing Framework (OWCF), which aims at being a standardized, cost-effective platform that can attract the interest and consensus of the major players in the field of development of wearable applications (“wearable application” is used in this paper as convenient short form to address an “end-user ap­plication designed to run on a wearable device”). One of the distinguishing character­istics of a wearable application is “context awareness”: it is the key to reactive and situation-dependent applications in mobile, wearable, and ubiquitous computing scen­arios. However, most current implementations of context awareness are uniquely craf­ted and therefore hardly reusable, or they address only parts of the requirements for a solution accepted by the industry to be integrated into an open software framework.

Context awareness capabilities require on one side to cope with the challenging task of processing inputs to determine the current context, and on the other side to expose the detected context as useful information for application developers.

Processing inputs is a task which often involves dealing with low level signals (for example data collected from sensors), and which is encompassed with the need for fast and efficient processing of the obtained input data using specific algorithms. In con­trast to such highly specific task, designing end-user applications requires simple, standard components, which allow an application developer to easily handle whatever

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

input information (also context) and to effectively use it within a wearable application. If we look at the common desktop and server domain we can see that application de­velopers can rely on a rich collection of standard elements and architectures for solv­ing common application tasks. This is supported by established software engineering methodologies, which allow to model data, structural, and control entities in order to reason about the system at conception and design time. One of the ambitions of the OWCF is to bring a similar level of standardization and reusability of components in the area of context processing. This is just one aspect of the more general vision of the OWCF, which aims at evolving the engineering and development of software applica­tions for wearable devices from the current niche’s position to a mature and wide­spread technology, which can rely on tested, standard-based and reusable components and tools, and deliver effective solutions for real-life work environments.

This paper presents the goals for the OWCF, and its design methodology within the scope of the project wearIT@work; it then introduces some details on the implementa­tion of the framework itself. The paper covers then the design and the current Java im­plementation of the context-processing components within the OWCF, and concludes with n outlook on the development and some notes on the accompanying European re­search project wearIT@work.

Related works

This paper describes an evolution and implementation of some ideas presented in [5]. It is also based on the foundations laid in [1,2] and [4]. The design of the work presen­ted in this paper has also been influenced by the guidelines, experiences and lessons learned reported in [3]. Finally, from a software engineering perspective, the main principles adopted in this work refer to [6], [7] and [8].

The design of a software framework

It is somewhat difficult to give a clear and general definition of “software framework”. In the scope of wearIT@work we intend the Open Wearable Computing Framework (OWCF) to be the software infrastructure (i.e. a middleware) that supports the con­struction of domain specific applications for wearable devices. Applications can seam­lessly take advantage of the framework functionalities and capabilities. Such an infrastructure is intended to: (I) simplify the software development process, (II) en­courage reuse of software components across different applications, and (III) promote better software engineering practices.

A major issue when designing a software framework is represented by the difficulty in identifying the related requirements. Several methodologies exist to collect and formalize requirements for end-user applications, however they do not address directly the peculiarities of a software framework. The project wearIT@work has adopted the User Centered Design (UCD) as the leading project methodology.

From a high perspective the most important goal of UCD is to “design usable sys­tems”; UCD explicitly addresses the usability and usefulness of the end-user applica­tion. UCD stresses the importance of the end-user, and actually put the end-user at the

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

centre of the design process; this why only users can properly assess design proposals in the context of their work processes, and provide indispensable indications on how to evolve both the technology and the work processes.The general principle of UCD is applicable to design of any software, and therefore also to the design of a software framework. However, a software framework has some peculiarities: (I) it's not an end-user application, but a software infrastructure (the end-user will hopefully never know that the framework sits behind an end-user application); (II) the actual users of a framework are not the end-users but the applica­tion developers. (III) Since a framework is intended to be used in many different do­mains and applications, a pure user-driven approach must be augmented by incorporating programming methodologies and certain design patterns, because those aspects are not rendered by a collection of requirements from the user-level.

In general we can state that the features of a framework (such as the OWCF) and the features of the applications built on top of it are different, but indirectly coupled. This brings UCD to a higher level of difficulty: the usability and usefulness of the end-user application is just an indirect measurement of the usability and usefulness of the software framework supporting such an application, and the end user will have no no­tion of the underlying implementation.The different perspective of UCD applied to software framework has been analysed in [3], where the authors present some interesting highlights on real-world experience. One of the case studies presented in the [3] is the Context toolkit [2], an infrastructure to support context-aware applications. Since context-awareness is also one of the most important capabilities of the Open Wearable Computing Framework, we can leverage on the experience described in [3] when adopting UCD in the design and implementa­tion of OWCF in general, and specifically of its context-processing capabilities.

Basic software framework

The design and implementation of the Open Wearable Computing Framework (OWCF) is based on the capabilities of modern object-oriented languages and their in­ate concepts, which offer several obvious benefits to programmers of end-user applic­ations.The OWCF is intended to be a software infrastructure which offers several features (services) to the developer of a wearable application. In the scope of wearIT@work project the following core services have been identified: context services, communica­tion services, collaboration services, user interface services, and multimedia services.

Besides providing the functionalities of the core services, the OWCF must also provide a basic, common infrastructure that addresses cross-services, non-functional aspects. The distinction between functional and non-functional aspects comes from a general software design principle known as separation of concerns (see [6]), which basically encourages modular programming separating a complex problem into sub-problems, each of which focuses on one core concern. Functional aspects represents service-specific capabilities, and define how a service can be used and the semantics of its operations; non-functional aspects are not service-specific, and address common­place issue such as configuration of services or dependency among services.

A desirable characteristic of a software framework supporting cross-services, non-functional aspects is “non-invasiveness”: the framework should provide enough capab­

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

ilities to support the most important non-functional aspects, without forcing too many constraints on its services. Especially in scenario where the development of compon­ents is highly distributed (such as in wearIT@work where several project partners con­tribute to the development) such a feature guarantees the desired decoupling of components – even from the framework itself. The design requirement here is that a component should remain usable without the framework itself.

The overall design of the OWCF is based on a component-oriented, interface-driv­en approach. Components are designed to be replaceable and composable; the depend­encies among components are declared using interfaces. The framework services can be thought of as components or set of components depending on each other.

The OWCF adopts some modern software engineering techniques to address non-functional aspects, and it specifically addresses configuration of components and de­pendency among components with a design principle known as inversion of control (see [7] and [8]). The OWCF provides an easy way to configure any component and to declaratively specify dependencies among them, thus shifting from the programmers the burden of dealing with these commonplace non-functional aspects.

The current Java implementation of the OWCF adopts the open source Spring framework [9] as a basic infrastructure to handle components configuration and de­pendencies (notice that there is also an open source C# implementation of the Spring framework).

The Spring framework is very broad, and its typical usage scenario is in web applic­ation development. However, The Spring framework has some interesting characterist­ics:• it is modular: the standard distributions comes with both a single all-inclusive jar

file, or with a set of specific jar files which can be used separately;• it is widely adopted, and therefore has reached a good level of maturity and it is

has also a very active supporting community of users and developers;• it is open source, released under the Apache license version 2.0 [10], and therefore

its source code is available for modification and customizationThe current Java implementation of the OWCF exploits the functionalities offered

by the core part of the Spring framework to handle components configuration and de­pendencies. This part of spring is non-invasive and supports the required design prin­ciples laid out before.

Furthermore Spring has the additional benefit of improving the modularization of code. OWCF services are made of components. It defines the functional aspects of each component through a Java interface, and provides the corresponding implementa­tions. However, it is very easy to develop other components implementing the same interface defined by the framework, and to specify in the Spring XML configuration file which one to load at run-time. This design approach ensures a very high degree of modularity and flexibility: the actual behaviour of the framework services can eventu­ally be customized with a very fine granularity.

The context service of the OWCF is made of several context-processing compon­ents, and it is an example of this design approach.

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

Design of context-processing components

Although context awareness is a key aspect of wearable applications, the definition of context is always somewhat controversial (see also [1]). Without delving into the de­tails of a formal definition, we can address with the term “context”, a representation of the state of the world, which may encompass both user-related, device-related and am­bient-related information.

A context aware application is interested in the changes of context, which represent changes in the state of the world. The “awareness” comes from the ability of the ap­plication to (autonomously) react to such changes in the context. The operation of a context aware application can be modelled as a state machine, as suggested in [5].

A framework that supports context-awareness should allow programmers to easily provide end-users with applications that effectively adapt themselves (or react) to the different real-world situations of the end-users. Traditional applications have usually little or no access to context information and cannot adapt their behaviour to user, sys­tem or ambient information. These applications are not optimal in dynamically chan­ging situations. Furthermore, the use of context is important in the selection of information and services that may be relevant for the end-user in a specific situation, and this is increasingly crucial in an pervasive (or ubiquitous) computing environment. However, context can be difficult to acquire, and so has been used infrequently.

The major goal of the context-processing components of the Open Wearable Com­puting Framework is to provide application developers with easy access to context in­formation, and with straightforward mechanism to design and implement programmatic reaction to context changes. This means that application programmers need not worry about the details of acquiring context, but can simply work on the ap­plication logic that define if and how the application reacts to context changes.

A major design issue is represented by the representation of context information. The representation should be object oriented, in order to seamlessly coexist within the overall object oriented framework and applications. Furthermore, the representation should be as standardized as possible in order to facilitate the exchange of context in­formation among different platform.

The OWCF has adopted an interface driven design approach to define the context information. The framework define context types through (an hierarchy of) interfaces (as commonly defined in object oriented languages); Figure 1 shows a portion of the context interfaces hierarchy . Each interface exposes the relevant characteristic of the context, but completely shields the developers of end-user applications from the low level details of how data is processed to generate such context information. For ex­ample the interface IGloveActivity shown in Figure1 exposes is designed to exposes as context information the activity of a worker wearing a “sentient glove”, which is able to detect some basic movement of the user (such as “hammering”, “screwing”, etc.) Notice that the interface completely shields the programmers of the end-user applica­tions from the details related to the processing of low-level inputs from sensor at­tached to the glove: the low-level processing could even take place outside of the framework (and this is the case when using for example the UMIT context toolbox [16] attached through a socket). An instance of a class implementing the interface IG­loveActivity is simply a representation of the worker activity in a specific instant (timestamp), and the activity type is exposed as a String through the specific method getActivityType.

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

There is also an effort to keep interfaces aligned (both in respect to naming and se­mantics) among different implementation of the OWCF – this can facilitate interoper­ability (at least at the specification and semantic level).

The ontology approach for context representation has been proposed in several works, among which [5], [11] and [12]. However this approach may raise some issues related to the computing power required to process large amount of RDF/XML in­formation, which is obviously relevant when dealing with wearable devices offering limited processing capabilities. The representation of context information in RDF/XML is therefore still a research topic, which may lead to a standardized and in­teroperable representation format.

Implementation of context-processing components

Based on some ideas described in [5], the Open Wearable Computing Framework en­visions a context-aware application as a state machine, whose transitions are triggered by changes in the context. The purpose of the context-processing components of the OWCF is to provide the mechanisms to trigger state transitions in the application, without enforcing any specific handling of context information within the application itself.

From a software engineering perspective, the context processing components are source of events within the OWCF, and they provide the mechanisms to notify the ap­plication of the context events. Modelling context awareness through an event-based communication mechanism is a technique described also by other works (see [13], [14]). The approach adopted in the OWCF aims at being simple, flexible and easy to evolve. The main idea is that the framework specifies a set of interfaces that support the event mechanism, but keep the implementation of these interfaces as loosely coupled as possible; this is achieved exploiting the Spring framework capabilities of handling components dependencies in a declarative way through an easy-to-manage configuration file.

The current Java implementation of the context-processing components of the OWCF is based on a set of basic interfaces:• ContextProcessor• ContextEventPublisher• ContextEventQueue

Figure1: context types as hierarchy of interfaces

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

• ContextEventDispatcher• ContextEventListener

The dependencies among these components are shown in Figure 2.

ContextProcessor is the basic interface which must be implement by a component that is a source of context events. The interface does not define details related to the functional behaviour of a context processor, but allows for retrieving a unique identifi­er of the processor, and a list of strings representing the context events that the pro­cessor can generate. The current implementation suggests the use of URIs [17] as unique identifiers of context processors: although this is not mandatory, it may be use­ful in future extension when adopting ontologies to define vocabularies of context types (as described in [5]). The event produced by a context processor is represented by a class implementing one of the interfaces defining context types in the context hierarchy (see Figure1).

A ContextProcessor has a reference to a ContextEventPublisher: this interface define a core component of the framework, which is used by all ContextProcessors to publish their events. In the classical producer-consumer problem, the ContextEvent­Publisher acts as producer and the ContextEventDispatcher act as a consumer. The ContextEventDispatcher interface define a core component of the framework, which is used to dispatch event to the components of the end-user application (or to other com­ponents of the framework). The mechanism used by the ContextEventDispatcher to dispatch event is the classical listener-pattern. The ContextEventListener interface define a listener for context events: The developer of the end-user application must implement a ContextEventListener for each context event the application must be no­tified of, and must register these ContextEventListener within the ContextEventDis­patcher (the application has therefore a reference to the ContextEventDispatcher). Finally, the ContextEventQueue acts as the shared buffer of the classical producer-consumer problem, and it decouples ContextEventPublisher and ContextEventDis­patcher.

The typical flow of operations is shown in Figure 3

Figure 2: dependencies among context components

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

Notice that the implementations of ContextEventQueue must handle the potential synchronizations issues due to the concurrent publishing and consuming of context events.

Notice also that the ContextEventDispatcher allows for fine-grained registrations: the application developer can register a listener not only for a specific context event, but also for specific context events generated by a specific source (URI of a Context­Processor), or for specific context event matching a specific condition, or even a com­bination of condition and source.

The component-based, interface-driven approach adopted ensure high flexibility and modularity of the framework. The internals of every component can be replaced with a new implementation, and this would be transparent for any other component having a dependence on its interface. For example the current dispatching algorithm of the ContextEventDispatcher can be replaced with another one without affecting neither the ContextEventQueue or the ContextEventListener interfaces, and this would also be completely transparent for the developer of the end-user application.

The current Java implementation of the context-processing components of the OWCF do not explicitly define details on how data are fetched from their input source (such as sensors), on how such low-level data is represented or processed or fused. Any such detail can be implemented in a custom a ContextProcessor, and kept hidden from the overall framework: in fact the developer of an end-user application does not need such details. This approach allows also for simple integration with external spe­cialized context toolkit: for example the framework has an implementation of a Con­textProcessor that generates IGloveActivity (see Figure 1) context events fetching data from the UMIT context toolbox. Future versions of the Java context-processing com­ponents of the OWCF may leverage on-going standardization efforts and integrate an implementation of Java specific APIs to directly manage sensors (see for example JSR256 [18]); such extension will be evaluated in the context of the User Centered Design (UCD) methodology, and will be implemented if it is useful for or provide some benefit to the developers of end-user applications (i.e. the users of the frame­work).

Outlook

Besides the context processing components, other required modules are currently be­ing designed within the Open Wearable Computing Framework (OWCF). Some ex­

Figure3: typical flow of operations for context event publishing

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

amples are: a component supporting workflow functionalities and resource-manage­ment for wearable applications; components supplying specialized user-interfaces or input sources (gestures, speech) for (mostly) hands-free operations.

These design and implementation activities will benefit from the parallel on-going standardization activities pursued by the wearIT@work project, and will eventually deliver a set of flexible, tested, standard-based and reusable building blocks for the implementation of wearable applications.

Acknowledgements

This work was partly funded under grant 004216 by the European integrated project “wearIT@work - Empowering the mobile worker by wearable computing”

References

[1] Anind K. Dey; Understanding and Using Context, Personal and Ubiquitous Computing Journal, Volume 5 (1), 2001, pp. 4-7.

[2] Anind K. Dey, Daniel Salber and Gregory D. Abowd; A Conceptual Frame­work and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications Special issue on context-aware computing in the Human-Com­puter Interaction (HCI) Journal, Volume 16 (2-4), 2001, pp. 97-166.

[3] Anind K. Dey, Keith Edwards, Victoria Bellotti, and Mark Newman: Stuck in the Middle: The Challenges of User-Centered Design and Evaluation for Mid­dleware in the Proceedings of the 2003 Conference on Human Factors in Com­puting Systems, Fort Lauderdale, FL, April 5-10, 2003.

[4] Jakob E.Bardram; The Java Context Awareness Framework (JCAF) – A Ser­vice Infrastructure and Programming Framework for Context-Aware Applica­tions; Center of Pervasive Computing, Technical Report CfPC Technical Report 2004—PB—61.

[5] Marco Luca Sbodio, Dr. Wolfgang Thronicke; A systematic approach for the design of context-aware components, IFAWC2005

[6] Edsger W. Dijkstra in 1974; On the role of scientific thought, Edsger W. Dijk­stra , EWD 477,30th August 1974, Neuen, The Netherlands

[7] Brian Foote; Designing Reusable Classes, Journal of Object-Oriented Pro­gramming June/July 1988, Volume 1, Number 2, pages 22-35

[8] Michael Mattson; Object Oriented Frameworks: a survey on methodological issues, Michael Mattson, Department of Computer Science, Lund University, 1996

[9] The Spring framework, http://www.springframework.org/ [10] Apache License version 2.0, January 2004, http://www.apache.org/licenses/[11] H. Chen, T. Finin, and A. Joshi; An ontology for context-aware pervasive com­

puting environments, Special Issue on Ontologies for Distributed Systems, Knowledge Engineering Review, 2003

IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany

[12] Ranganathan, A., Campbell, R. A Middleware for Context-Aware Agents in Ubiquitous Computing Environments, in ACM/IFIP/USENIX International Middleware Conference, Rio de Janeiro, Brazil, 2003.

[13] Gregory Biegel, Vinny Cahill. A Framework for Developing Mobile, Context-aware Applications. In Proceedings of 2 nd IEEE conference on Pervasive computing and Communications, Percom 2004

[14] R. Meier and V. Cahill; Exploiting Proximity in Event-Based Middleware for Collaborative Mobile Applications in Proceedings of the 4th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS'03). Paris, France: Springer-Verlag Heidelberg, Germany, 2003.

[15] wearIT@work – Empowering the mobile worker by wearable computing. In­tegrated European research project, http://www.wearitatwork.com/

[16] David Bannach, Kai Kunze, Paul Lukowicz, and Oliver Amft; Distributed Modular Toolbox for Multi-Modal Context Recognition in ARCS06, Architec­ture of Computing Systems, Frankfurt/Main (Germany).

[17] Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC2396, http://www.ietf.org/rfc/rfc2396.txt

[18] JSR 256: Mobile Sensor API, http://www.jcp.org/en/jsr/detail?id=256