Context processing within an open, componentoriented, software framework Marco Luca Sbodio1, Dr. Wolfgang Thronicke2 1
Hewlett-Packard, Italy Innovation Center
[email protected] 2 Siemens Business Services GmbH & coOHG, Germany
[email protected]
Abstract. This paper presents some architectural guidelines for an open, component-oriented software framework supporting applications running on wearable devices, and describes an approach for implementing context processing capabilities within such framework. The authors describe an open approach intended to both enhance reusability and simplify the development of contextaware 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 technological 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 application designed to run on a wearable device”). One of the distinguishing characteristics of a wearable application is “context awareness”: it is the key to reactive and situation-dependent applications in mobile, wearable, and ubiquitous computing scenarios. However, most current implementations of context awareness are uniquely crafted 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 contrast 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 developers can rely on a rich collection of standard elements and architectures for solving 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 applications for wearable devices from the current niche’s position to a mature and widespread 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 implementation of the framework itself. The paper covers then the design and the current Java implementation of the context-processing components within the OWCF, and concludes with n outlook on the development and some notes on the accompanying European research 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 presented 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 construction of domain specific applications for wearable devices. Applications can seamlessly take advantage of the framework functionalities and capabilities. Such an infrastructure is intended to: (I) simplify the software development process, (II) encourage 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 systems”; UCD explicitly addresses the usability and usefulness of the end-user application. 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 enduser 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 application developers. (III) Since a framework is intended to be used in many different domains 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 enduser 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 notion 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 implementation 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 inate concepts, which offer several obvious benefits to programmers of end-user applications. 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, communication 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 subproblems, 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 commonplace issue such as configuration of services or dependency among services. A desirable characteristic of a software framework supporting cross-services, nonfunctional 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 components is highly distributed (such as in wearIT@work where several project partners contribute 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-driven approach. Components are designed to be replaceable and composable; the dependencies 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 nonfunctional aspects, and it specifically addresses configuration of components and dependency 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 dependencies (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 application development. However, The Spring framework has some interesting characteristics: • 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 customization The current Java implementation of the OWCF exploits the functionalities offered by the core part of the Spring framework to handle components configuration and dependencies. This part of spring is non-invasive and supports the required design principles 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 implementations. 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 eventually be customized with a very fine granularity. The context service of the OWCF is made of several context-processing components, 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 details 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 ambient-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 application 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, system or ambient information. These applications are not optimal in dynamically changing 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 Computing Framework is to provide application developers with easy access to context information, 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 application 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 information 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 example 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 applications from the details related to the processing of low-level inputs from sensor attached 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 IGloveActivity 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 semantics) among different implementation of the OWCF – this can facilitate interoperability (at least at the specification and semantic level).
Figure1: context types as hierarchy of interfaces 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 information, 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 interoperable representation format.
Implementation of context-processing components Based on some ideas described in [5], the Open Wearable Computing Framework envisions 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 application 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
IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany
• •
ContextEventDispatcher ContextEventListener The dependencies among these components are shown in Figure 2.
Figure 2: dependencies among context components 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 identifier of the processor, and a list of strings representing the context events that the processor 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 useful 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 ContextEventPublisher 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 components 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 notified of, and must register these ContextEventListener within the ContextEventDispatcher (the application has therefore a reference to the ContextEventDispatcher). Finally, the ContextEventQueue acts as the shared buffer of the classical producerconsumer problem, and it decouples ContextEventPublisher and ContextEventDispatcher. The typical flow of operations is shown in Figure 3
IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany
Figure3: typical flow of operations for context event publishing 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 ContextProcessor), or for specific context event matching a specific condition, or even a combination 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 specialized context toolkit: for example the framework has an implementation of a ContextProcessor that generates IGloveActivity (see Figure 1) context events fetching data from the UMIT context toolbox. Future versions of the Java context-processing components 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 framework).
Outlook Besides the context processing components, other required modules are currently being designed within the Open Wearable Computing Framework (OWCF). Some ex-
IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany
amples are: a component supporting workflow functionalities and resource-management 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] [2]
[3]
[4]
[5] [6] [7] [8] [9] [10] [11]
Anind K. Dey; Understanding and Using Context, Personal and Ubiquitous Computing Journal, Volume 5 (1), 2001, pp. 4-7. Anind K. Dey, Daniel Salber and Gregory D. Abowd; A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications Special issue on context-aware computing in the Human-Computer Interaction (HCI) Journal, Volume 16 (2-4), 2001, pp. 97-166. Anind K. Dey, Keith Edwards, Victoria Bellotti, and Mark Newman: Stuck in the Middle: The Challenges of User-Centered Design and Evaluation for Middleware in the Proceedings of the 2003 Conference on Human Factors in Computing Systems, Fort Lauderdale, FL, April 5-10, 2003. Jakob E.Bardram; The Java Context Awareness Framework (JCAF) – A Service Infrastructure and Programming Framework for Context-Aware Applications; Center of Pervasive Computing, Technical Report CfPC Technical Report 2004—PB—61. Marco Luca Sbodio, Dr. Wolfgang Thronicke; A systematic approach for the design of context-aware components, IFAWC2005 Edsger W. Dijkstra in 1974; On the role of scientific thought, Edsger W. Dijkstra , EWD 477,30th August 1974, Neuen, The Netherlands Brian Foote; Designing Reusable Classes, Journal of Object-Oriented Programming June/July 1988, Volume 1, Number 2, pages 22-35 Michael Mattson; Object Oriented Frameworks: a survey on methodological issues, Michael Mattson, Department of Computer Science, Lund University, 1996 The Spring framework, http://www.springframework.org/ Apache License version 2.0, January 2004, http://www.apache.org/licenses/ H. Chen, T. Finin, and A. Joshi; An ontology for context-aware pervasive computing 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] [13] [14]
[15] [16] [17] [18]
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. Gregory Biegel, Vinny Cahill. A Framework for Developing Mobile, Contextaware Applications. In Proceedings of 2 nd IEEE conference on Pervasive computing and Communications, Percom 2004 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. wearIT@work – Empowering the mobile worker by wearable computing. Integrated European research project, http://www.wearitatwork.com/ David Bannach, Kai Kunze, Paul Lukowicz, and Oliver Amft; Distributed Modular Toolbox for Multi-Modal Context Recognition in ARCS06, Architecture of Computing Systems, Frankfurt/Main (Germany). Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC2396, http://www.ietf.org/rfc/rfc2396.txt JSR 256: Mobile Sensor API, http://www.jcp.org/en/jsr/detail?id=256
IFAWC2006 March 15-16, Mobile Research Center, TZI Universität Bremen, Germany
