Building Context-Aware Services fromNon-context-aware Services

Ichiro Satoh

Abstract. This paper presents a framework for providing context-aware services.It supports the separation of services and context, so that application-specific ser-vices can be defined independently of any contextual information. It also providestwo mechanisms. The first is to enable non-context-aware services to be used ascontext-aware services. The second is to enable context-aware services to be de-fined independently on any contextual information. The framework is useful in thedevelopment of software for non-context-aware services in ubiquitous computingenvironments. Our early experiments proved that it enabled us to reuse JavaBeanscomponents as context-aware services without having to modify the componentsthemselves.

1 Introduction

Context-aware services are still one of the most typical applications of ambient com-puting. They are provided to users with services according to their contexts, e.g.,users, locations, and time. Software for context-aware services is assumed to sup-port contextual information or processing inside it. However, such software cannotbe reused for other contexts. Furthermore, although there have been numerous non-contextual services, including Web services and components for Java 2 EE, theycannot be directly used in context-aware services.

This paper addresses the reusability of software for context-aware services ornon-context-aware services. Our framework consists of two mechanisms. The firstis based on the notion of containers, used in enterprise software components to em-ulate the execution environments that the components want to receive. The second iscalled connectors, which loosely bind software for defining services and contextualinformation in the real world.

Ichiro SatohNational Institute of Informatics2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japane-mail: ichiro@nii.ac.jp

P. Novais et al. (Eds.): Ambient Intelligence - Software and Applications, AISC 153, pp. 59–66.springerlink.com c© Springer-Verlag Berlin Heidelberg 2012

60 I. Satoh

Our framework is constructed as a middleware system for providing servicesimplemented as JavaBeans like Enterprise JavaBeans (EJB), [4]1 It was inspiredby our practical requirements in the sense that we have been required to providecontext-aware services in public and private environments, such as that at publicmuseums, retail stores, and corporate buildings.

2 Example Scenario

This approach was inspired by our experiment in the development of practicalcontext-aware services in real spaces, e.g., museums and schools. It supports twokinds of context-aware services for visitors in museums.

• Context-aware annotation services for exhibits: Most visitors to museums wantannotations on the exhibits in front of them, because they lack sufficient breathof knowledge about them. Their knowledge and experiences are varied so thatthey tend to be become puzzled (or bored) if the annotations provided to themare beyond (or beneath) their knowledge or interest. Our experiments providedvisitors with annotation services that are aware of the users and their currentlocations.

• Post-It services on exhibits: Social network services (SNS), e.g., Facebook andGoogle+, enables users to make comments on other users’ posts or express theirpositive impressions on the posts. Like SNS, some visitors want to leave theirimpressions or recommendations on exhibits. Other visitors want to read the im-pressions and recommendations. Our experiments provided services that enabledvisitors to comment on the exhibits and other visitors to read the comments whilethey were close to the exhibits.

The contexts of the both services are different, but their application logic was similarin that it provided contents to users. Our goal was to enables context-aware serviceswhose application logic was common to be implemented by the same software byexplicitly specifying the context in which the services should be activated.

3 Approach

We introduce two mechanisms, called containers and connectors, into context-aware services.

3.1 Context-Aware Container

Modern enterprise architectures, e.g., Enterprise JavaBeans (EJB), [4], and .Net ar-chitecture [5] have employed the notion of containers to separate business compo-nents from system components. The original notion has enabled key functionality

1 Since the framework is aimed at context-aware services, it does not support several systemissues, e.g., transactions, used in middleware for enterprise systems.

Building Context-Aware Services from Non-context-aware Services 61

such as transactions, persistence, or security to be transparently added to applica-tion at the time of deployment rather than having to implement it as part of the ap-plication. The notion leads to increased reusability and interoperability of businesscomponents. We used the notion to reuse non-context-aware business-software com-ponents in context-aware ones. Non-context-aware components are not designed tobe used in ubiquitous computing environments, where services appear and disap-pear arbitrarily and nodes cannot possibly know in advance with which other nodesthey will interact. Our container mechanism hide such dynamic environments fromthe components.

3.2 Context-Aware Connector

This was introduced as a spatial relationship between services and the targets thatthe services should be provided for, e.g., users, physical entities, and spaces. It de-ploys services at appropriate computers according to the locations of their targets.For example, when a user moves from location to location, it automatically de-ploys his/her services at computers close to his/her destination. It enables softwarecomponents for defining services to specify their placement outside them. The cur-rent implementation provides two types of context-aware connectors, as shown inFigure 1.

• If a service declares a follow connector for at most one moving target, e.g., phys-ical entity or person, the former is deployed at a computer close to the latter’sdestination, even when the latter moves to another location.

• If a service declares a shift connector for at most one moving target, e.g., physicalentity or person, the former is deployed at a computer close to the latter’s source.

4 Design and Implementation

Our user/location-aware system to guide visitors is managed in a non-centralizedmanner. It consists of four subsystems: 1) location-aware directory servers, 2) run-time systems, 3) virtual counterparts, and 4) context-aware containers. The firstis responsible for reflecting changes in the real world and the locations of userswhen services are deployed at appropriate computers. The second runs on station-ary computers located at specified spots close to exhibits in a museum. It can exe-cute application-specific components via context-aware containers, where we haveassumed that the computers are located at specified spots in public spaces and areequipped with user-interface devices, e.g., display screens and loudspeakers. It isalso responsible for managing context-aware connectors. The third is managed bythe first and deployed at a runtime system running on a computer close to its target,e.g., person, physical entity, or space. The fourth is implemented as a mobile agent.Each mobile agent is a self-contained autonomous programming entity. Application-specific services are encapsulated within the fourth.

62 I. Satoh

VC: Virtual-Counterpart CAC: Context-aware Container

CAC VC

Computer 2 Computer 3Computer 1

CAC

User movement

VC

Computer 2 Computer 3Computer 1

CAC VC

Computer 2 Computer 3Computer 1

VC

Deployment

CAC

CAC VC

Computer 1 Computer 2

CAC

User movement

VC

Computer 1 Computer 2

CCACC CAC VC

Computer 1 Computer 2

VC

DeploymentepDe yoy ee

ACCACCCCAC

Deployment

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

LocationSensor

Shfitconnector

Followconnector

DeD lopl ymy ee tCCCCCCCCCC

CCACCC CAAC CCACCCCCCCCCCCDeployment

Shfitconnector

Shfitconnector

Followconnector

Step 1

Step 2

Step 3

Step 1

Step 2

Step 3

Fig. 1 Context-aware-coupling between virtual-counterparts and services

The system has three unique functions:

• Virtual-counterpart is a digital representation of a user, physical entity, or com-puting device. When its target moves to another location, it is automaticallydeployed at a computer close to the current location of the target by usinglocation-sensing systems.

• Context-aware-container is a customizable wrapper for (non-context-aware) soft-ware components, e.g., JavaBeans, for defining application-specific services touse them as context-aware services.

• Context-aware-connector is the relationship between the locations of one virtual-counterpart and context-aware container. It deploys or activates the latter at acomputer according to its deployment policy (Figure 1).

We assume that virtual-counterparts are managed in the underlying location models.In fact, digital representations in most symbolic location models are directly usedas virtual counterparts, where such models maintain the locations of physical en-tities, people, and spaces as the structure of their virtual counterparts according totheir containment relationships in the real world. For example, if a user is in a roomon a floor, the counterpart corresponding to the user is contained in the counterpartcorresponding to the room and the latter is contained in the counterpart correspond-ing to the floor. The current implementation support our location model, althoughthe framework itself is not independent of the model2. Since the model monitorsits underlying location sensing systems, when it detects the movements of physicalentities or people in the real world, it reflects the movement on the containment rela-tionships of the virtual counterpart corresponding to the moving entities or people.

2 Satoh2005

Building Context-Aware Services from Non-context-aware Services 63

OS/Hardware

AgentDeployment

Service

ConnectorManagement

AgentExecutor

Management

Java Virtual Machine

OS/Hardware

AgentDeployment

Service

ConnectorManagement

AgentExecutor

Management

Java Virtual Machine

VC: Virtual-Counterpart CAC: Context-aware Container

CAC CACVC

CACVC VC

CAC

Runtime systemRuntime system

Network

Context-aware connector

ASC ASC ASC ASC

ASC: Application-specific Component

Context-aware connector Context-aware connector

Fig. 2 Service runtime systems

4.1 Context-Aware Container

Each context-aware container is an autonomous programmable entity implementedas a mobile agent. We developed a mobile agent-based emulator to emulate thephysical mobility of its target terminal by using the logical mobility of the emulator[9, 10]. It could provide application-level software with the runtime environmentcompatible to its target device and carry it between computers through networks.Context-aware containers can provide application-specific components with theirfavorite runtime environments and carry them between computers. They are de-fined according to types of application-specific components. Each context-awarecontainer in the current implementation is a collection of Java objects and supportJava-based components, e.g., JavaBeans and Java Applets.3

4.2 Context-Aware Connector

The framework enables each container to have a connector for at most one virtualcounterpart. Each connector is activated when its target virtual counterpart movesin the location model according to the movement of the counterpart’s target in thephysical world. Next, it deploys the container, including a service, at a computeraccording to its deployment policy, if the computer does not have the service. Itactivates the service wrapped in the container at the computer. The current imple-mentation supports the two built-in policies explained in Figure 1. Nevertheless,connectors can be extended by overwriting classes for the built-in connectors.

4.3 Runtime System

Each service runtime system is responsible for executing and migrating application-specific components wrapped in context-aware containers to other service runtimesystems running on different computers through a TCP channel using mobile-agenttechnology. It is built on the Java virtual machine (Java VM version 1.5 or later),

3 The framework itself is not independent of Java and has the potential to support existingservices written in other languages.

64 I. Satoh

which conceals differences between the platform architectures of the source anddestination computers (Fig. 2). It governs all the containers inside it and maintainsthe life-cycle state of each application-specific component via its container. Whenthe life-cycle state of an application-specific component changes, e.g., when it iscreated, terminates, or migrates to another runtime system, its current runtime sys-tem issues specific events to the component via its container, where the containermay mask some events or issue other events. The deployment of each context-awarecontainer is specified in its connector and is managed by runtime systems withoutany centralized management system. Each runtime system periodically advertisesits address to the others through UDP multicasting, and these runtime systems thenreturn their addresses and capabilities to the runtime system through a TCP channel.

4.4 Current Status

A prototype implementation of this framework was constructed with Sun’s Java De-veloper Kit, version 1.5 or later version. Although the current implementation wasnot constructed for performance, we evaluated the migration of a context-aware con-tainer based on connectors. When a container declares a follow or shift connectorfor a virtual-counterpart, the cost of migrating the former to the destination or thesource of the latter after the latter has begun to migrate is 88 ms or 85 ms, wherethree computers over a TCP connection is 32 ms.4 This experiment was done withthree computers (Intel Core 2 Duo 2 GHz with MacOS X 10.6 and Java Develop-ment Kit ver.6) connected through a Fast Ethernet network. Migrating containersincluded the cost of opening a TCP-transmission, marshalling the agents, migrat-ing them from their source computers to their destination computers, unmarshallingthem, and verifying security.

5 Application

We constructed and conducted an experiment at the Museum of Nature and Hu-man Activities in Hyogo, Japan, using the proposed framework. The experimentconsisted of four spots in front of exhibits, where each spot had an active RFID tagreader. We provided each visitor with an RFID tag. Location-aware directory serversmonitored one or more RFID tag readers. When a location-aware directory serverdetected the presence of an RFID tag in a spot, it instructed the underlying locationmodel to migrated the virtual counterpart corresponding to the visitor attached tothe tag to the counterpart corresponding to the spot.

We provided visitors with the two kinds of services discussed in Section 2,i.e., context-aware annotation services for exhibits and post-it services for exhibits.These services were implemented as Javabeans software and their containers werealso the same. The software was a multimedia player to display rich text on thecurrent computer. The container for the former service had a follow policy for the

4 The size of each virtual-counterpart was about 8 KB in size.

Building Context-Aware Services from Non-context-aware Services 65

counterpart corresponding to a user and the container for the second had a shiftpolicy for the counterpart corresponding to a user.

We offered a GUI system that enabled curators in the museum to customizecontext-aware connectors. They were required to change the contexts that servicesshould be activated at the experiment because they relocated some exhibits in theroom. They could assign either a follow or shift connector to such services wrappedin containers for Javabeans components and they services simultaneously providetwo kinds of services. In fact, they could easily customize the contexts throughcontext-aware connectors, because they did not need to know the services them-selves.

We did the experiment over two weeks. Each day, more than 80 individuals orgroups took part in the experiment. Most visitors answered questionnaires abouttheir impressions on the system. Almost all the participants (more than 95 percent)provided positive feedback on it. As application-specific services could be definedas JavaBeans, we were able to easily test and change the services provided by mod-ifying the corresponding agents while the entire system was running.

6 Related Work

Many researchers have studied software engineering for context-aware services. TheContext toolkit was a pioneering work on software engineering issues in context-aware services [1, 8]. It aimed at allowing programmers to leverage off existingbuilding blocks to build interactive systems more easily. It was constructed as li-braries of widgets for GUI. However, since it was only designed for context-awareservices, it did not support the reuse of software for non-context-aware services.

Ubiquitous computing defines a new domain in which large collections of het-erogeneous devices are available to support the execution of applications. Theseapplications become dynamic entities with multiple input and output alternatives.As a result, it is difficult to predict in advance the most appropriate configuration forapplication as has been discussed by several researchers [7, 11]. There have beenmany attempts to construct software component technology for ubiquitous comput-ing [2, 6]. Several researchers have done studies modeling context-awareness in theliterature of software engineering [3]. However, there have been no silver bullet asother systems thus far.

7 Conclusion

We constructed a framework for providing context-aware services. It supported theseparation of services and context, so that application-specific services could bedefined independently of any contextual information. It also provided two mech-anisms, called context-aware containers and context-aware connectors. The firstenabled non-context-aware services to be used as context-aware services to be usedas context-aware services. The second enabled context-aware services to be definedindependently of any contextual information.

66 I. Satoh

References

1. Abowd, G.D.: Software Engineering Issues for Ubiquitous Compuitng. In: Proceedingsof International Conference on Software Engineering (ICSE 1999), pp. 75–84. ACMPress (1999)

2. Areski, F., Christophe, G., Philippe, M.: A Component-based Software Infrastructure forUbiquitous Computing. In: Proceedings of the 4th International Symposium on Paralleland Distributed Computing, vol. 8, pp. 183–190. IEEE Computer Society (2005)

3. Henricksen, K., Indulska, J.: Developing Context-Aware Pervasive Computing Applica-tions: Models and Approach. Pervasive and Mobile Computing 2 (2005)

4. Kassem, N.: Designing Enterprise Applications with the Java 2 Plaform, Sun J2EEBlueprints, Sun Microsystems (2000),http://java.sun.com/j2ee/download.html

5. Micorsoft Corp.: The .NET Architecture, Microsoft Corporation (2000),http://www.microsoft.com/net/

6. Martin, M., Umakishore, R.: UbiqStack: a taxonomy for a ubiquitous computing soft-ware stack. Personal Ubiquitous Computing 10(1), 21–27 (2005)

7. Roman, M., Al-muhtadi, J., Ziebart, B., Campbell, R., Mickunas, M.D.: System Supportfor Rapid Ubiquitous Computing Application Development and Evaluation. In: Proceed-ings of Workshop on System Support for Ubiquitous Computing (UbiSys 2003) (2003)

8. Salber, D., Dey, A.K., Abowd, G.D.: The Context Toolkit: Aiding the Develop-ment of Context-Enabled Applications. In: Proceedings of International Conference onComputer-Human Interaction (CHI 1999), pp. 15–20. ACM Press (1999)

9. Satoh, I.: A Testing Framework forMobile Computing Software. IEEE Trasaction ofSoftware Engineering 29(12), 1112–1121 (2003)

10. Satoh, I.: Software Testing for Wireless Mobile Computing. IEEE Wireless Communi-cations 11(5), 58–64 (2004)

11. Scholtz, J., Consolvo, S., Scholtz, J., Consolvo, S.: Towards a discipline for evaluat-ing ubiquitous computing applications, National Institute of Standards and Technology(2004), http://www.itl.nist.gov/iad/vvrg/newweb/ubiq/docs/1scholtzmodified.pdf