Dynamic Context Bindings in Pervasive Middleware

4 downloads 4 Views 217KB Size Report
CACI also provides the creation and maintenance of bindings to context producing entities based on such specifications. This paper discusses the design and.

Dynamic Context Bindings in Pervasive Middleware1 Tom Broens, Marten van Sinderen, Aart van Halteren, Dick Quartel Centre for Telematics and Information Technology, ASNA group, University of Twente, P.O. Box 217, 7500 AE Enschede, the Netherlands, {t.h.f.broens, m.j.vansinderen, a.t.vanhalteren, d.a.c.quartel}@utwente.nl Abstract Context-awareness (CA) enables the development of personalized pervasive services. Current context-aware infrastructures focus on middleware solutions to support acquisition, usage and management of context. However, using context requires the CA application to create a binding between itself and one or more context producing entities. Creating this binding is the responsibility of the CA application developer, which is often an extensive manual task. The ad hoc availability of context-producing entities further complicates this responsibility. This paper proposes an application infrastructure, coined CACI, which offers a binding transparency to support rapid development of CA applications. CACI enables developers to specify context requirements at a high abstraction level using a declarative binding language. CACI also provides the creation and maintenance of bindings to context producing entities based on such specifications. This paper discusses the design and implementation of CACI. Additionally, it discusses the validation of CACI using a pervasive healthcare scenario.

1.

Introduction

In pervasive computing, context-awareness (CA) plays an important role. Context information is used by CA applications, deployed in the pervasive computing environment, to tailor their functioning to the situation of the user. In pervasive computing environments, a loose coupling between CA applications and context producing entities (context producers, for short) is advantageous. A CA application should be able to discover, bind and use context information as it is available during the life-time of the application. As the result of a lack of infrastructural support [1-3], the binding between CA applications and context producers is usually hard coded into the application logic and therefore tightly couples the CA applications to the context producers. This results in inflexibility, since the applications cannot cope with changing circumstances. The availability and quality of context information are subject to constant change. For 1

example, consider the context information available to CA application deployed on a mobile device whose user is moving around. While moving, used context producers can disappear and new ones may appear. Current research efforts on CA middleware [4], focus on developing mechanisms for acquiring, using and managing context to support a loose coupling between a CA application and a context producer. Although these mechanisms facilitate the creation of a binding between a CA application and a context producer (e.g. through discovery), the actual creation of this binding is still the responsibility of the application (developer). Furthermore, with current mechanisms, CA applications are responsible for tackling the dynamicity of context producers (i.e. changing circumstances). Due to the mobile nature of CA applications and possibly context producers, availability of context producers for the CA application is not reliable and guaranteed. Managing the dynamic nature of context producers requires additional complex development effort. This paper proposes an application infrastructure, coined CACI, which offers a binding transparency to simplify the development of CA applications. With this approach, we shift the responsibility of creating and maintaining dynamic context bindings from the application to the infrastructure. Developers specify context requirements using a high-level declarative language. CACI takes this specification to initiate and maintain bindings to context producers that can fulfil these requirements. This paper extends the theoretical background of CACI presented in [5] and discusses the detailed design and implementation of CACI using the OSGi component framework. Additionally, it discusses the validation of CACI using a case of a pervasive healthcare scenario. The remainder of this paper is structured as follows: Section 2 describes the background of context bindings and their dynamic nature. Section 3 presents the design and implementation of the CACI infrastructure. Section 4 discusses the validation of CACI using a pervasive healthcare scenario. Section 5 discusses related work. Finally, section 6 presents conclusions and future work.

This work is part of the Freeband AWARENESS Project. Freeband is sponsored by the Dutch government under contract BSIK 03025. (http://awareness.freeband.nl)

2.

Dynamic context bindings

Generally, there are two roles in a CA system: (i) context consumers, which retrieve and use context information, and (ii) context producers, which create and offer context information. Typically, a context consumer is a CA application and a context producer is a context sensor (wrapper). There can be also software entities performing both roles, like context reasoning entities which consume context information to produce other context information. A complete CA system can therefore be seen as a composition of associated context consumers and context producers. We use the term context binding to denote the association between a context consumer and a context producer which is needed for context exchange However, creating and maintaining context bindings for CA applications is difficult, due to some inherent characteristics of context producers: (i) context producers are distributed, which makes them challenging to discover and access, (ii) context producers have dynamic availability which makes the binding unreliable, (iii) context producers provide context information with different and changing qualities which enables to distinguish 'better' and 'worse' context producers, and (iv) context producers have heterogeneous context models which make them difficult to interoperate with. Current CA middleware approaches tackle mainly the first aspect. They develop, so called, context management frameworks that facilitate discovery of context producers and exchange of context [4]. Additionally, substantial research is being done on the fourth aspect to get a generic and interoperable context model [6]. We target our approach as an extension of these approaches where we leverage on their facilities. Specifically, we position our work as a solution to minimize the impact of the second and third property of a context producer, to simplify the development of CA applications.

3.

Detailed design and implementation

CACI takes a component-oriented approach in which context producers and consumers are represented as components (see Figure 1). These components are deployed in a container which contains the CACI binding mechanism. A component is described in terms of ports (i.e. based on CCM [7]). We distinguish between two types of ports: application ports and context ports. Application ports describe application functionalities a component requires and can offer. Context ports describe the context information a component requires and can offer. In this paper we focus on facilitating the fulfilment of context requirements. We see facilitating context offerings as a promising future extension of CACI.

Component ports are described in the component descriptor. CACI offers a XML-based declarative language, called CACI Component Description Language (CCDL), to describe context requirements. Elements of this language are: (i) description of the required context and (ii) binding meta-properties. The context description consists of the required element (e.g. Location), entity (e.g. Tom), format (e.g. Lat/Long) and quality (e.g. accuracy > 70%). Our current implementation does not yet incorporate Quality of Context (QoC), we consider this for future work. The meta-properties express required properties of the binding CACI has to establish (e.g. priority). For a detailed discussion on CCDL, see [5]. Component descriptor Context ports

CA Component Application ports

Container

CACI binding mechanisms

Figure 1: CACI generic architecture Figure 2 presents the high-level implementation architecture of CACI. The underlying technology for CACI is the OSGi component framework [8]. This framework offers a container for deployment and lifecycle management of components. We extend the OSGi container by creating a virtual CACI container. This CACI container interacts with deployed components via the IContextProducerManager interface which offers operations to retrieve references of context producers to which CACI establish bindings. This is done based on the CCDL descriptions of the components. Standard components on which CACI depends are deployed as separate components. These are the kXML framework to facilitate the parsing of CCDL descriptions, the Shell component for user interaction with CACI, Log4J for logging purposes and the SimuContext repository (based on [9]) for testing. SimuContext is discussed in more detail later on in this section. Component Component Component IContextProducerManager CACI

kXML

Shell

Log4J

SimuContext repository

OSGi container

Figure 2: High-level implementation architecture

Figure 3, presents the detailed functional decomposition of the CACI binding mechanism. On deployment, the deployer intercepts the component that is being deployed. A component that wants to use the CACI binding mechanism has a CCDL description. By adding a CCDL pointer to a standard OSGi description (component manifest), the parser is able to extract and parse the CCDL description when the component is deployed. Binding requests are extracted for every required context producer and they are stored in the CACI database. The binder, which is the central entity in CACI, dispatches each binding request to the monitor to monitor a corresponding binding. The monitor deploys a probe in the underlying discovery network to be notified of changes. Because the binding does not yet exist, the monitor forwards the request to the discovery manager which does a context producer discovery on the underlying discovery network. Possible results are sent to the decider which selects the most suitable producer. The binder creates a context producer proxy and binds it to the selected ‘real’ producer. The proxy is sent to the proxy manager which makes it available to the component via the IContextProducerManager interface. The monitor detects when a producer becomes unavailable or new producers appear. When a producer becomes unavailable, a new discovery process is initiated; when a new producer appears, the decider is invoked to check if re-binding is appropriate. The GUI presents an overview of the state of the CACI database (e.g. installed CACI components, binding requests) and is used for debugging (see Figure 4). Component getContextProvider

CCDL Description

Deploy

IContextProducerManager

Deploy

GUI

parse Parser

Deployer

CACI database

The bundling part contains code to bundle CACI as a light-weight (+-60kB) standard OSGi component. It is therefore also able to be deployed on different OSGi implementations. Currently, CACI is tested on the Oscar and Knopflerfish OSGi implementations both on PC and on a mobile device running windows mobile and the J9 virtual machine. As can be seen from Figure 3, CACI uses an underlying context producer discovery mechanism. For testing purposes we currently use the SimuContext framework (based on [9]) as a substitute. However, CACI is generic enough to support different discovery mechanisms.

Figure 4: GUI with some installed components SimuContext offers a library to simulate context producers. It lets developers specify the required characteristics of a producer (e.g. concerning context types, context values and context update frequency) and then instantiates this specified context producer. We extended the SimuContext framework described in [9] with a repository function. As a result of this, developers can instantiate context producers and register them to the repository. Applications can then discover these registered simulated context producers.

Proxy manager

bindReq

Bundling

rebind

proxy

discoveryResult Decider

Producer selection

Binder

producerChange Discovery manager

Discover

Monitor

monitorReq

CACI producerDiscovery

producerChange Context producer discovery mechanisms (SimuContext)

Figure 3: Detailed implementation architecture Figure 5: CACI component generator

Furthermore, for testing purposes, we created a CACI component generator. This generator offers an easy graphical interface (see Figure 5) to add arbitrary CCDL descriptions to a generic component. On generation, the generic component is compiled and bundled together in a CACI component using an ANT build file. This component is automatically deployed in the local CACI container or can be deployed in an arbitrary CACI container.

4.

Case: Epilepsy Safety System

In [10] we discuss a challenging future pervasive healthcare scenario. The scenario describes the epilepsy safety system (ESS) which is a system that supports epilepsy patients in their daily life. Epilepsy is a neurological disorder in which nerve cells of the brain occasionally release abnormal electric pulses (so called seizures). Due to the unexpected nature of these seizures, epileptic patients have a strong feeling of insecurity and are therefore seriously limited in their daily life (e.g. mobility, social contacts). The ESS offers seizure detection and notifies care givers which can offer first-aid. This enables an epilepsy patient to have a more active participation in society and have a higher quality of life. The ESS deploys a sensor system on the patient’s body (called a Body Area Network (BAN)) which collects and transfers vital signs when a seizure is detected. This data is stored and analyzed in healthcare centres for diagnosis, first-aid and treatment. Context can play a major role in improving the healthcare process of the ESS by (i) tailoring of ESS functionality and (ii) tailoring of the ESS information. Amongst others, possible beneficial context types in the ESS are: patient and care-giver location, care-giver availability and patient BAN bandwidth usage. Location information helps to decrease travelling time to the patient in case of emergencies. First, because the precise location of the patient (destination) is known and second because a nearby care-giver can be dispatched to the patient. Availability information of care-givers helps to decrease false dispatches of unavailable care-givers. Bandwidth usage information assists to tailor the transferred vital sign data to decrease costs in case a of non-emergency situation, while this information also assists to prevent congestion and failing transfer of vital sign data in case of emergency situations. Consider we create the CA ESS first-aid system that helps patients in emergency situations (see Figure 6). This requires application parts located at the patients, care givers and health-care centre. The parts need bindings to several context producers. The patient application needs bandwidth information to decide which vital signs to send. The care-giver

application needs the location of the patient having an emergency and the healthcare-centre needs the location of the patient and care-giver and availability of care-givers to dispatch the right care-giver to the patient. This context information can be provided by multiple and changing context producers (e.g. location by RFID sensors or GPS) Care-giver Location

RFID sensors Bandwidth

... GPS sensors

Callender Bandwidth sensor

Location/ Availability

... Phone On/Off

Patient

Health-care center

Context producer discovery network

Figure 6: ESS emergency scenario Developers create bindings by adding CCDL descriptions to their standard application components. In these descriptions, they describe the context producer requirements. Figure 7 presents a simplified CCDL description which is added to the ESS component at the health-care center to create the binding to location and availability producers. For the other components at the patient and care-giver the descriptions are similar.

Figure 7: Health-care center CCDL description This description is handled by the CACI infrastructure where the binding is resolved. The application developer only needs to retrieve the bound producer (see Figure 8) by subscribing a callback to the IContextProducerManager service (i.e. the local services mechanism is provided by OSGi) offered by CACI. CACI notifies the component when a producer is bound. ServiceReference ref = bc_.getServiceReference(IContextProducerManager.class.getName()); IContextProducerManager manager = (IContextProducerManager)bc_.getService(ref); IContextProducerCallback cb = new Callback(this); try{ manager.subscribe("patient_Location", cb); manager.subscribe("care_giver_Location ", cb); manager.subscribe("care_giver_Availability", cb); }catch(ConsumerSubscribeException e){ System.out.println("Wrong binding ID."); }

Figure 8: Health-care center bound producer retrieval Developers can then retrieve context information from the context producer as they would have done without

CACI. The CACI infrastructure presents a proxy of the physical context producer, effectively shielding the application component from dynamic behavior of the physical context producer like appearing and disappearing [5]. Since creating and maintaining dynamic context bindings is simplified by using CACI, application developers can focus on the creation of specific application logic needed for their application. CACI offers a simple descriptive language expressed in XML. The patient and care-giver side application each need approximately 7 lines of simple CCDL XML description while for the healthcare centre-side application 18 lines of XML code is needed (i.e. two more context producers bindings). Additionally, all three sides need approximately 10 lines of java code to embed CACI and retrieve the requested context producer. In total this results in 62 lines of code to create and maintain context bindings of the three application parts which make up the ESS system. As no metrics are available on the efforts required to develop CA system in general, we calculated (using an Eclipse Metrics plug-in) the code of CACI’s Discover Manager, Monitor and Decider functional blocks. This approximates the code a developer has to produce for similar context binding functionality without CACI. Together these blocks consist of approximately 350 lines of code which have to be replicated and specialized for the three different parts. In total this would result in approximately 1050 lines of code. Although CACI simplifies the development of CA applications, it does require the developer to learn how-to use the infrastructure. We don’t think this presents a serious drawback, for two reasons. First, CACI provides simple interfaces and XML schemas to ease this process. Planned future extensions include a GUI that can enable developers to graphically generate CCDL descriptions and CACI integration code. Second, CA application development without CACI also requires similar learning efforts to cope with the underlying discovery mechanism. Another possible drawback of adding a layer of indirection by CACI is its performance penalty. We performed some initial measurements on the time spent deploying a component, parsing the CCDL, discovery of context producers (making sure a discovery match can be made), selection of a context producer and returning the selected producer to the deployed component. This resulted both on the PC and the windows mobile device in insignificant overhead (less than 1ms time spent when logging is disabled). Although more performance measurements are needed, our preliminary conclusion is that the delay introduced by CACI is considerably less or can be neglected compared to the delay for the (remote)

discovery of context producers (i.e. communication and processing delay).

5.

Related work

In general, current middleware binding mechanisms have two related goals: (i) shift parts of the binding process to the infrastructure to make the binding more implicit for the developer (explicit vs. implicit bindings [11]) and (ii) only create the binding when needed (at runtime), incorporating the situation at hand (early vs. late binding). Examples of middleware binding mechanisms are the CORBA Naming Service [12], the CORBA Trader [12], CORBA Dynamic Invocation Interface (DII) [12], Web service UDDI and the Web Service Invocation Framework (WSIF) [13]. However, dynamic behaviour of the binding, like appearing and disappearing binding ends are not incorporated in these mechanisms. Coping with this issue is still the responsibility of the application developer. Several mechanisms, such as Context-sensitive bindings [14], Service-oriented network sockets [15] and OSGi (Extended) Service Binder [16, 17], recognize the need for extending binding mechanisms in which the dynamicity of the binding is incorporated. Compared to CACI, they have a similar goal but are not tailored to the novel type of context-aware applications. Although, context producers and consumers could be considered as generic distributed entities, they have distinct characteristics that have to be incorporated in the binding mechanism to be able to fully support the application developer. For example, context binding mechanisms should be based on a context model and the notion of quality of context (QoC) should be incorporated in the mechanisms. When zooming into binding mechanisms specific for context-aware systems, several context-aware middleware infrastructures [4, 18-20] shift parts of the context specific binding mechanism (often called context management) to the infrastructure. Generally, this functionality enables context consumers to discover and bind to context producers using programming statements. However, often dynamic monitoring capabilities (e.g. notification when new and possibly better, context producers arise) are not available and when context producers become (un)available the decision to re-bind and the choice to which context source to bind has to be taken by the application rather than the infrastructure. CACI tries to leverage from the capabilities of current context-aware middleware infrastructures and extend them with binding maintenance that copes with the dynamic availability and quality of context producers. Additionally, we take a different approach, compared to most context management systems, by offering developers ways to

specify their context requirements in high level descriptions. These descriptions are interpreted and dealt with by CACI in stead of that developers have to program technology specific binding statements. In this way, we further facilitating the developers in rapidly creating context-aware applications.

6.

Conclusions

This paper presents an application infrastructure, coined CACI, which aims to simplify the development of context-aware applications. Context-aware applications acquire context from distributed and heterogeneous context producers which have dynamic availability and offer context information with dynamic quality. Coping with this dynamism currently requires substantial programming efforts in addition to developing the core application logic. CACI offers a novel approach to relieve application developers from creating and maintaining dynamic context bindings between the application and context producers. Using CACI, the developer specifies high-level context requirements which are bundled together with the application component. CACI retrieves and processes this specification and resolves the context bindings on behalf of the component. Additionally, CACI shields the application logic from dynamic availability and quality of context producers. It monitors the binding and performs, when needed, re-binding, without the developer needs to cope with this aspect or the end-user being aware of these changes. In this way, CACI facilitates application developers to rapidly create robust context-aware applications. Additionally, this paper describes a proof-of-concept prototype based on the OSGi framework running on a PC or mobile device. Case validation showed valuable code decrease. Additionally, initial performance tests did not indicate significant additional performance overhead. Some of the planned future extensions are: (i) supporting the deployment of context producers, (ii) incorporating QoC in CCDL, (iii) validation of CACI on other component frameworks and using different discovery mechanisms, and (iv) conducting more extensive performance evaluations of the CACI mechanism.

References [1]

[2]

A. Dey, "Providing Architectural Support for ContextAware applications", vol. PhD: Georgia Institute of Technology, 2000. M. Ebling, D. Guerney, H. Hunt, and H. Lei, "Issues for Context Services for Pervasive Computing", in Workshop on Middleware for Mobile Computing. Heidelberg, Germany, 2001.

[3]

[4]

[5]

[6] [7] [8] [9]

[10]

[11] [12]

[13] [14]

[15]

[16]

[17]

[18]

[19]

[20]

T. Gu, H. Keng, and D. Zhang, "A service-oriented middleware for building context-aware services", Journal of Network and Computer Applications, vol. 28, 2005. K. Henricksen, J. Indulska, T. McFadden, and S. Balasubramaniam, "Middleware for Distributed ContextAware Systems", in DOA 2005. Agia Napa, Cyprus: Springer Verlag, 2005. T. Broens, A. v. Halteren, and M. v. Sinderen, "Infrastructural support for dynamic context bindings", in 1ste European conference on Smart Sensing and Context (EuroSSC'06). Enschede, the Netherlands: Springer Verlag, 2006. T. Strang and C. Linnhoff-Popien, "A Context Modelling Survey", in UbiComp'04. Tokyo, Japan, 2004. OMG, "Corba Component Model version 3.0", 2002. OSGi Alliance, "About the OSGi Service Platform, whitepaper", 2004. T. Broens and A. Halteren, "SimuContext: Simply Simulate Context", in International Conference on Autonomic and Autonomous Systems (ICAS'06). Silicon Valley, USA, 2006. T. Broens, A. v. Halteren, and M. v. Sinderen, "Towards an application framework for context-aware m-health applications", International Journal of Internet Protocol Technology (IJIPT), forthcoming, 2007. G. Blair and J. Stefani, Open Distributed Processing and Multimedia: Addison-Wesley, 1998. OMG, "Common Object Request Broker Architecture: Core Specification", in http://www.omg.org/docs/formal /04-03-01.pdf, 2004. Apache WSIF project, "Web Service Invocation Framework", in http://ws.apache.org/wsif/, 2006. R. Sen and G. Roman, "Context-Sensitive Binding, Flexible Programming Using Transparent Context Maintenance", Technical Report WUCSE-2003-72, Washington University 2003. U. Saif and M. Palusak, "Service-oriented Network Sockets", presented at International conference on mobile systems, applications and services (MobiSys'03), San Francisco, USA, 2003. H. Cervantas and R. Hall, "Autonomous Adaptation to Dynamic Availability Using a Service-Oriented Component Model", in 26st International Conference on Software Engineering. Edinburgh, Scotland, 2004. A. Bottaro and A. Gerodolle, "Extended Service Binder: Dynamic Service Availability Management in Ambient Intelligence", in FRCSS'06. Vienna, Austria, 2006. H. Kranenburg and H. Eertink, "Processing Heterogeneous Context Information", in Next Generation IP-based Service Platforms for Future Mobile Systems workshop. Trento, Italy, 2005. B. Kummerfeld, C. Quigley, C. Johnson, and R. Hexel, "Merino:Towards an intelligent environment architecture for multi-granularity context description", in workshop on User Modelling for Ubiquitous Computing, 2003. J. Bardram, "The Java Context Awareness Framework (JCAF) - A Service Infrastructure and Programming Framework for Context-Aware Applications", in Pervasive Computing. Munchen, Germany, 2005.

Suggest Documents