[ieee 2011 ieee international conference on pervasive computing and communications workshops (percom...
Post on 14-Mar-2017
Embed Size (px)
Decoupling Context-aware ServicesSren Debois
IT University of Copenhagendebois@itu.dk
Arne John GlenstrupIT University of Copenhagen
Francesco ZanittiIT University of Copenhagen
AbstractWe present a novel software architecture for context-aware applications based on a distributed, non-monolithic, simpleand extensible relational model for representing context; aservice-oriented architecture for computing these relations in adecoupled, flexible fashion; and with data driven, event basedcommunication providing the kind of fine grained dynamicservice composition required in mobile and volatile environments.A prototype implementation is running a Bluetoothsensor-basedactive map of users at our home university.
In this paper, we introduce a novel software architecturefor context-aware services. Within the last 18 years, theconstruction of software architectures for context aware ap-plications has been a hot topic , , ; context-awareservices joined the fray within the last five , . Thearchitecture we propose (cf. Figure 2) has the same aims asmany of these works: it seeks to promote code reusabilityby encouraging compositionality of system design. It distin-guishes itself from these other approaches principally by beingdata-driven: Services are composed not by specifying whichservices invoke which other services, but rather by specifyingwhich services need what context information. For example,three different services might provide the same kind of locationdata: one based on Bluetooth (BT), one on WiFi, and one onGPS. Services consuming this location data need not concernthemselves with the origin of that location data, only the dataitself.
This data-driven composition mechanism is of course notin itself novel; other architectures have separated context datafrom its computation. The novelty here is that we make avery fine-grained division of the computation of context intosuch decoupled services. As a consequence we get (a) veryfine-grained re-usability of code: very small computations canbe meaningfully re-used; and (b) a very neat mechanism forsensor-subsystem switch-over, as alluded to above.
Our architecture is intended for the scenario where a largearea, say, a shopping mall, an airport, a train station, ora supermarket is equipped with physical sensors, such astemperature or location sensor, tracking the whereabouts ofcustomers. The tracking could be based on the clients mobiledevices, RFID equipped shopping carts, or other positioningtechnologies provided by the merchants.
This work funded in part by the Danish Research Agency (grant no.: 2106-080046) and the IT University of Copenhagen (the Jingling Genies projects).Authors are listed alphabetically by last name.
A key point is that our architecture is flexible and extensiblein the sense that several different merchants can deploy eachtheir system, perhaps relying on different technologies, yetstill allowing the context sensitive applications to operateseamlessly.
While this scenario is not new , it is recently of renewedinterest: it is finally happening outside the laboratory. Theadvent of the ubiquitous hand-held mobile phone with BT,GPS, WiFi or RFID provides a cheap, non-intrusive means ofzone-based tracking of individuals in public spaces , ,, , just to mention some location tracking technologies.At the same time, institutions such as airports, train stations,supermarkets etc. are beginning to deploy the necessary in-frastructure for context aware systems: tracking equipmentinstalled to find customer movement patterns , , conveniently doubles as a source of location information forcontext aware services.
Such environmentsairports, supermarkets, etc.are asso-ciated with particular activities, and knowledge about theseactivities is a source of context information different fromphysical, sensor-obtained data. This knowledge is stored indatabases, relating, e.g., passengers with flights, flights withdeparture times and gates, etc. Examples of activities providingcontext information are people going to airports to take planesand to supermarkets to buy groceries.
In most cases the expected activity of users is to a degreepredictable from existing databases. In airports, the activitiesare almost fully formalised: a database somewhere knowspassengers names, passports and flight numbers, as well asplane departure times, gate numbers, etc. In supermarkets, adatabase somewhere knows exactly what goods are availablein the supermarket, where they are, and how fast those goodsusually disappear in the course of a normal business day. If asupermarket in question has a frequent-shopper program, somedatabase somewhere might also have a very precise idea aboutwhat particular individual shoppers tend to buy.
Thus, the present architecture targets a scenario wherecontext awareness is based both on physical sensors and somewell-defined activities we may get from existing databasesascenario in fact being realized commercially right now.
The architecture proposed in the present paper is not onlyproposed, it is in fact implemented and available for down-load . A prototype active map tracking people at ouruniversity is also available online .
8th IEEE Workshop on Context Modeling and Reasoning
978-1-61284-937-9/11/$26.00 2011 IEEE 450
II. CONTEXT-AWARE SERVICES
We contend uncontroversially that the central challenge ofcontext-aware computation consists of computing the actualcontext from whatever data is available. Software architecturesfor context-awareness distinguish themselves primarily bywhat way they assist that computation.
Its important to note that for even the simplest of examples,such computation is non-trivial. To be concrete, suppose acontext-aware application needs to know whether some pas-senger in an airport has passed through security. This is asimple boolean piece of information, obtainable by simplyinspecting the current location of the passenger in question.Even so, in even the most naive of implementations, thiscomputation will typically require (at least) two steps. First,the information that the device with MAC-id 0x2198f172 iscurrently in range of sensor 0x31 must be converted to theinformation that passenger Jones is in the Lufthansa First ClassLounge. Second, we must check whether this Lounge is in factsituated before or after security.
The opportunity for code re-use in the development ofcontext-aware applications stems from the observation thatwithin a given application domainsay, a specific airportsome of these computations will be almost universally useful.In the above example, the ability to map particular sensor in-puts to particular passengers high-level location would likelyhave such usefulness. In fact, also the information whether ornot a passenger has passed security is conceivably interestingto variety of applications, even if it is not universally useful.
As usual for Software Oriented Architecture (SOA), weconsider a context-aware service to be something whichimplements a reusable, distinct computation of context. Theapplication in the above example then uses two services: onefor the low-level sensor-to-passenger mapping, and one for thehigh-level location-to-security-state mapping.
However, put this way, there is no discernible difference be-tween a context aware service and a context aware procedure.To maximise the potential reuse of context-aware services, weshall further decouple them in the following section.
III. CONTEXT-AWARE SERVICE INTERFACES
Let us call the mapping of low-level sensor-data to high-level location L, and the mapping of high-level locationto security state H . Suppose that the low-level sensors itinterfaces with is the Ekahau WiFi-positioning system . Inplaces where WiFi is not available, the airport can augment thelocation tracking with a BT-based positioning system. How dowe modify the existing context-aware application to use alsothe new BT-based tracking system?
By use of the service H , the remainder of the applicationis already shielded from this change. But what should happento H and L themselves? In a procedural world, H and Lwould be tightly coupled. For H to also accommodate thenew location system we must implement a service L takingBT-based positions to high-level locations, and we would haveto modify H so that it always queried both L and L.
But there is a better way! We know that the service H isonly interested in high-level locations. It is not interested inother services. There is no need for H to know where its high-level location information comes from; whether it be L, L orsome third entity is absolutely irrelevant to H .
Thus we propose that services be further decoupled sothat the composition is not formed by one service directlyaccessing another service, but rather by one service requiringparticular data, no matter who provides it. In composition, therelevant identifier for a data-stream from a service is no longerits name, but rather the particular kind of data it produces andconsumes.
However, this definition leaves us with a practical problem:how does a service specify the particular kind of data itproduces or consumes?
IV. RELATIONAL CONTEXT MODELS & RELATIONTRANSFORMERS
Describing what context-data is produced is of course a mat-ter of selecting a context meta-model. Fortunately, the problemof describing classes of context models, of constructing acontext meta-model, is by now fairly well studied, and hasproduced suggestions using various techniques, ranging fromtuple-space  and object-orientation  to ontology-based, and even combinations (e.g. OO with ontology ).
The great strength of ontologies is that they come withdescription logics as declarative language