reprint/republish this material for advertising or promotional purposes or for creating new collective works for ... Email: {tarlano, kellerer}@docomolab-euro.com. Abstract .... systems [9], context spaces use a template field to match context entry ...
A. Tarlano, W. Kellerer: Context Spaces Architectural Framework, in Proc. of 2004 International Symposium on Applications and the Internet (SAINT 2004) Workshops: Workshop on Ubiquitous Services, Tokyo, Japan, January 26-30, 2004. © 2004 IEEE
© 2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
Context Spaces Architectural Framework Anthony Tarlano, Wolfgang Kellerer DoCoMo Communication Laboratories Europe GmbH Landsbergerstr. 312, 80687 Munich, Germany Email: {tarlano, kellerer}@docomolab-euro.com Abstract Context-Aware Computing is a paradigm where context-aware applications, use acquired knowledge, related to a set of environmental states and attributes, to determine and adapt the applications behavior at runtime. Presented in this paper is a context-aware architectural framework, named “Context Spaces”. The context spaces framework enables the development and research of context-aware applications by mitigating common issues associated with dynamic environments. The framework components include a conceptual model, a protocol Application Message Interface for space based-distributed information sharing, and a method for context sharing between spaces called context acquisition.
1. Introduction In recent years computing devices with physical characteristics allowing easy mobility of the device by their users, such as Personal Digital Assistants (PDA’s) and mobile phones, have substantially increased the possibilities of distributed computing systems to exist in virtually any environment. The increased [1] ease of device mobility, coupled with substantial networking resources, allows processing power to be introduced into any physical space the user might roam. Traditional nonmobile distributed computing systems, such as the Unix operating system [2], have created distributed computing environments that spread computation processing and resources among fixed computing nodes. The addition of mobility to these computing devices has the effect of integrating new mobile computing nodes to existing distributed computing system. This integration has introduced new opportunities to be addressed by future context-aware computing applications. Ubiquitous Computing, also referred to as Pervasive Computing with the attribute of mobility [3], is a field of computing research focused on addressing both the challenges and opportunities, presented by the introduction of new mobile computing nodes to the landscape of distributed computing systems.
The focus of this paper is Context-Aware Computing, a sub research field of ubiquitous computing research [4]. “Context-Aware Computing” is a paradigm where context-aware applications, use acquired knowledge, related to the set of environmental states and attributes, to determine and adapt the applications behavior at runtime. Specifically context-aware computing is concerned with: 1. Perception and collection of the environment, i.e. collection of context state and attributes of the environment via sensors 2. Distribution and selection of collected environmental information via data communication 3. Service adaptation mechanisms facilitating dynamic behavior driven by the collected environmental information As used in this paper, context-awareness is the perception and knowledge of the conditions of content in an environment. The content information related to the context of the environment includes: attribute information, such as, time of day, lighting, location, computing resources, the proximity of people or devices, and preferences, where as, state information includes attributes which have a relationship in the environment. In the remaining sections of this paper, we present an architecture named “Context Spaces” (Section 3). Using the context spaces framework, there exists the possibility for the creation of scoped and well defined interest boundaries, where distributed computing nodes can participate to share and retrieve context information during runtime. The architectural framework is comprised of: 1. A conceptual model, 2. A protocol application message interface for spacebased distribution of context information, 3. A method for dynamic context-sharing between space objects at runtime called context acquisition. In Section 4, we provide details of a context spaces testbed implemented at our labs.
2. Motivation Recently, several innovative context-aware applications to enhance and personalize dynamic advertisements using collected context information have
been reported [5]. The purposes of these new contextaware applications are to convey a more personal message or to reach a larger customer base. One reported example is the “Digital Billboards” Service from Smart Sign Media Inc., based in Sacramento, California. The Digital Billboard service is a context-aware application, which adjusts the billboard information displayed based on the context information. Radio sensors near the billboard collect the radio station currently being listened to inside a passing passenger car. Based thereon, the application logic personalizes the billboard display using profile survey data to calculate the average income of the cars occupants. Consider now extending the digital billboard from using just one radio sensor to include a seatbelt sensor, a speed sensor and a car model sensor. How does adding three more sensors possibility allow the application logic to adapt? For example, if businesses would like to adjust their advertisement according the different groups of interrelated passengers that pass by would a business rather divide the billboard display to passengers from different cars listening to different stations or play them both in sequence? What should happen if the automobile models are the same, but the radio stations are different? What should the application logic do if there is more then one sign close together and the cars speed is fast enough enabling two displays to present parts of the same message? What possibilities are enabled when we add a hundreds of new sensor objects? Clearly, when developing context-aware applications driven by collected context information, we are not going to be able to presuppose the number, types, or even existence of sensors objects before runtime, nor the dynamic behavior of the applications logic. Thus, to realize scaleable dynamic adaptation logic, an architectural framework for context-aware applications, also requires a method for the acquisition of behavior from the environment at runtime.
Peer-to-peer systems refer to a class of systems, commonly using an overlay networking addressing scheme, to create a decentralized environment for connected peers to share resources. Peers participating in the system normally offer and consume messages and resources, from other connected peers, using interaction messages. Recent peer-to-peer systems [6] have enabled peers to cooperate and collaborate in a peer-group to advertise and discover resources. Context information in our opinion is good fit as peer-to-peer content. However, we do not address the underlying peer-to-peer communication system in this paper, but concentrate on the context space framework built on it. The context space Application Message Interface (AMI) provides space peers with an interface to allow context information to be shared and stored which is independent of any specific messaging protocol. The conceptual decision of messaging independence allows the use of existing network protocols or transports. Each context space may contain space group objects, which space peers can join based on interest. Space group objects are referred to simply as a “Space”. Spaces can be considered as virtual meeting points of space peers that join a peer group. A space group object is joined by a space peer based on interest. We describe this mechanism in detail in [7]. A Space acts as a container objects for all sub-objects located in the space, such as space peers or other spaces. We describe the different kinds of objects in Section 3.4. During operation, every space peer in all spaces of the context space must have a unique name string to be used for messages delivery and operation within the context space. We have not yet specified a name generation algorithm for space peers; however it is recommended for large systems unique names should be acquired from either a unique lower layer protocol identifier/address or use a W3C Universal Resource Name [8].
3.2. Context Space Structure
3. Context Spaces Architectural Framework 3.1. Conceptual Model Conceptually, “Context Spaces” is a distributed spacebased information system model that can be used by context-aware applications and by sensors to share and store context information. We refer to all participants of a context space as Space Peers. Each space peer implements a common Application Messaging Interface (AMI) protocol to share context information and to maintain the context space in a decentralized peer-to-peer style.
The Context Spaces structure is hierarchical as shown in Figure 1). There is a top level root space object, often referred to as the “outer space”, which may contain objects. Those contained objects may themselves be space objects which contain one or more space objects. Space objects should be thought of as a "places" of interest in which it is possible to store and share context information. We use the term Context Entry Objects to describe context information or any other objects that are maintained in a context space. As with other distributed space-based information systems [9], context spaces use a template field to match context entry objects within the context space. Matching is supported by the application messaging protocol interface. Context spaces differ from other space-based
information systems, due to the fact that context spaces match context entry objects based on a path expression that follows the containment hierarchy, not the content value. Context entry objects are found in spaces using path matching, and in particular, using the XPath language [10] path expressions to match context entries.
space according to a specific topic that they specify by the respective path expression to find a relevant space. AMI Message
Lease-based Method
Notify Method
Context-aware Applications
Timeout Method
Write Method
Take Method
Read Method
Application Messaging Interface
TakeIfExists Method
Context Spaces Framework
S1.0
L1.0.0 C1.0.0
Sxx
S1.1
Space 1
Space 1.0
L1.1.1
L1.1.0
L1.0.1 sub space 1.0 containing a content object entry and two Interpreted logic object entries
Sxx
Context Sensors
C1.2.0
Context Sensors, e.g., location
L1.1.2
Space 1.1 sub space 1.1 containing a content object entry and three Interpreted logic object entries
Sxx
Sxx
Sxx
Top-level space 1 containing a content object entry and two space object entries
C1.0
Sxx
Context acquisition allows the path statement /s1/s1.0/c1.0/ to to match /s1/c1.0/ /s1/c1.0/
Sxx
Figure 1. Context spaces hierarchy Context entry objects stored in a space may either be centrally managed, thus under the control of a single primary peer, or de-centrally managed, thus broadcasted and cached by any or all space peers, depending on the runtime operation of the space. Support for the operation of two models of data distribution, requires space peer roles to be defined. • A space peer, that manages a centralized persistence service for context entry objects within a space, is referred to as a persistence space peer. It is expected that the decision to use a persistence space peers is to increase reliability and the robustness of the distributed space-based information system. • All other peers are referred to as simple space peers, or just space peers. The use of a nonpersistence space increases flexibility and decreases management at the expense of reliability and management.
3.3. Protocol Application Messaging Interface Space peers in our system use the spaces as an abstraction mechanism to collaborate for sharing and storing context entry objects. The respective AMI methods (Figure 2) and their generated XML Message envelopes are defined in the following sub-sections and tables. These methods could be used by space peers such as sensors to update their context information in a space. They will also be used by context aware applications that retrieve related context information from the context
ReadIfExists Method
Figure 2. AMI hierarchy 3.3.1. Write. The write method is used to write context entry objects into a space with a specified lease value. The use of a transaction requires a centralized persistence space peer to be the destination handler of the information. If the need for a transaction is not supplied, the context entry is de-centrally advertised to all space peers in the current space. Possible reactions are based on best availability if any. Table 1. Write method write(expr, entry, lease=None, txn=None) -> result Return value is True if successful or None 'entry' argument is a context entry to be held in the space ‘expr’ is a XPath expression to use to match an entry 'lease' argument is a lease length in milliseconds 'txn=None' a transaction if used requires a persistence data store. XML Message Template:: XPath Expression Entry Element Number of Milliseconds Transaction Number
3.3.2. Read. The read method is used to read a matching content entry object from a space, or execute a logic entry object, based on a path expression. If a match is not found the read method, blocks until one exists, or the timeout expires. Table 2. Read method read(self, expr, txn=None, timeout=None) -> result Return value is a copy of a matching entry or None if a timeout occurs 'expr' argument is a XPath expr to use to match an entry 'timeout=None' a timeout length in milliseconds 'txn=None' a transaction requiring a commit phase preexposure. Use of a transaction parameter, enforces that other transactions can not take that entry until this transaction completes. XML Message Template::
Table 5. Takemethod
XPath Expression Transaction Number Number of Milliseconds
take(expr, txn, timeout=None) -> result
3.3.3. Readall. The readall method is used to read all matching content entry objects, or execute all logic entry objects, based on a path expression from the context space. If a match is not found the read method, blocks until one exists, or the timeout expires. Table 3. Readall method readall(self, expr, timeout=None, txn=None) -> result Return value is list of matching entries or None 'expr' is a XPath expression to use to match an entry 'timeout=None' a timeout length in milliseconds 'txn=None' a transaction requiring a commit phase preexposure. Use of a transaction parameter, enforces that other transactions can not take that entry until this transaction completes. XML Message Template:: XPath Expression Transaction Number Number of Milliseconds
Return value is the matching entry or None 'expr' argument is a XPath expr to use to match an entry 'txn' argument is a transaction requiring a commit phase preexposure. 'timeout=None' a timeout length in milliseconds XML Message Template:: XPath Expression Transaction Number Number of Milliseconds
3.3.6. TakeIfExists. The takeifexists method is used to remove a matching context object entry based on a path expression from the context space, without blocking until one exists. The use of a centralized persistence service is mandatory for reliable service since removal cannot be guaranteed when using broadcasting and caching. Table 6. TakeIfExists method takeifExists(expr, txn, timeout=None) -> result
3.3.4. ReadIfExists. The readIfExists method is used to read a matching content entry object, or execute a logic entry object, based on a path expression from the context space. The readifexists method, is non-blocking, so a specified timeout is only relevant within a transaction. Table 4. ReadIfExists method readifExists (expr, timeout=None, txn=None) -> result Return value is a copy of a matching entry or None 'expr' arguement is a XPath expr to use to match an entry 'txn' argument is a transaction requiring a commit phase preexposure. 'timeout=None' a timeout length in milliseconds XML Message Template:: XPath Expression Transaction Number Number of Milliseconds
3.4.5. Take. The take method is used remove any matching context entry objects based on a path expression from the context space. If a match is not found, the take method, blocks until one exists, or the timeout expires. The use of a centralized persistence service is mandatory for reliable service since removal cannot be guaranteed when using broadcasting and caching.
Return value is the matching entry or None 'expr' argument is a XPath expr to use to match an entry 'txn' argument is a transaction requiring a commit phase preexposure. 'timeout=None' a timeout length in milliseconds XML Message Template:: XPath Expression Transaction Number Number of Milliseconds
3.3.7. Notify. The notify method provides a interface for an event model where the caller can register for remote events based on a path expression. When context entry objects are written that match the path expression into the space the given list of listeners are notified by evaluation of the event object. Table 7. Notify method notify(self, expr, eventobject, txn=None, listeners=None, lease=None) -> result Return value is True if the notify command was accepted in the space None for non-acceptance 'expr' argument is a XPath expr to use to register for remote events 'eventobject=None' a return argument used for listener cookies 'txn=None' a transaction allow notification in the scope of a write 'listeners=None' = a list of registered file objects (pipes, files, etc) 'lease=None' argument is a lease length in milliseconds XML Message Template:: XPath Expression
Listener Cookie Transaction Number Listener Element Number of Milliseconds
3.4. Context Entry Objects Building a dynamic context-aware application, using the context spaces application messaging interface protocol relies heavily on shared and stored Context Entry Objects. As was stated earlier, context entry objects are found in spaces by using path matching, and in particular, using the XPath language path expressions identify a space and to match context entries. By design, all context entry objects within the context spaces framework have one of three types: 1. Content Objects – A content object is any relevant contextual environment state or environment attribute information that can be observed or perceived by a space peer, for the purpose of sharing and storage via a context spaces space object. Thus, the role of content objects are to act as objects for recording the state of content in an environment, leading to context awareness in the context spaces architectural framework. 2. Logic Objects – A logic object is a text file, possibly a script, which involves some form of processing that performs tasks similar to testing conditions, changing environment state or environment attribute information, starting, performing or stopping some action at runtime. As was stated earlier in this paper, to realize a scalable dynamic adaptation logic context-aware application requires an architectural framework to acquire different behavior from the environment at runtime. Thus, the role of logic objects is to perform a behavior on context object at runtime leading to dynamic execution. 3. Space Objects – A space object acts as a container objects for all context entry objects located in any space. The context spaces structure is hierarchical, which means that the top level root space object may contain context entry objects Those contained objects themselves may be space objects, which contain one or more space objects. Space peers can search and join space objects based on interest to form a community bound to an interest [7]. Space Objects can be thought of as simple peer groups, but should be thought of more as Network Communities [11]. Network Communities are interest groups having a unifying relationship, which are modeled after human societies. Import concepts of communities are that they have interest, may overlap and that they are dynamic with respect to size.
3.5. Context Acquisition Acquisition is an Object Oriented Programming (OOP) paradigm that allows dynamic behavior to be shared between objects via containment of the environment at runtime. The acquisition paradigm originally conceived and presented under the name “Environmental Acquisition” [12], sought to propose an alternative abstraction mechanism in response to the object-oriented paradigm of behavior at creation time via inheritance instantiation. The essential OOP principles of Acquisition are: - Objects have hierarchical structure, where hierarchical objects act as “Containers”. Containers are intended to produce a “in-a” composition hierarchy in an OOP sense [Figure 3]. - Objects that don’t have a specific behavior or a “Particular feature” can use acquisition as a means of abstraction to acquire the behavior from their container.
Continent U.S.A. is "in-a" Continent U.S.A
Figure 3. OOP “in-a” compositions hierarchy As is the case with other frameworks that make use of acquisition [13], the use of acquisition in the context spaces architectural framework is intended as a mechanism for sharing a specific behavior, via a logic object, or a feature, via a content object, using containment. However, context spaces “Context Acquisition” is different to other frameworks, because context spaces match context entry objects based on a path expression supporting a peer-to-peer model using two data distribution models, decentralized or centralized, to share and stored context information via context entry objects, across a distributed space-based information system. Context Acquisition within the context spaces architectural framework is used to dynamically either acquire content objects or to call logic objects not existing in the current space object from a containing space object via a path statement passed to AMI methods. To further explain context acquisition by containment, let’s follow a XPath path traversal example using the digital billboard service mentioned in section 2, The space structure can be seen in (Figure 4) and the example will following the path /BillboardSpace/ModelSpace/ YugoSpace/timeContext. As you see in the figure, the root top-level outer space object is BillboardSpace which
contains a content object named timeContent and a space object named ModelSpace. Examining ModelSpace we find two space objects YugoSpace and BMWSpace. Examining YugoSpace we find two content objects passengerContext and radioContext. Examining BMWSpace we find three content objects timeContext, radioContext, and passengerContext. As you see in the path expression we are interested in receiving time context information concerning the YugoSpace, but the space doesn’t hold a timeContext entry item, so you would expect to receive a “Context Miss” which is a request to read from context information which cannot be satisfied. Using context acquisition, however a time would be returned from an AMI Read method. This is due to that fact that the YugoSpace space object contains an ancestor space object that does contain a timeContext context object.
• •
To receive environmental state changes in the form of AMI messages To enable acquisition of behavior from the environment at runtime. JXTA Peer AMI Interface
Context Space
JXTA Peer Groups
SPP
Take
Write
Se
ZODB
SP Space Peers S*o
S*o
SPP Persistence Space Peers
Outer Space Se
Inner Space
Write
Se Se
SP JXTA Peers
Se SP
Inner Space Se Space Entry Content Objects
Notify
Se
SL Space Entry Logic Objects
S0 Space Objects
timeContext BillboadSpace
Figure 5. Testbed components
S S radioContext
S
timeContext
S
YugoSpace
passengerContext
BMWSpace
radioContext
S
S
passengerContext
ModelSpace
Se Space Entry Content Objects
Figure 4. Context acquisition example
4. Testbed To further examine the concepts of the context spaces architectural framework and to gather implementation results a context spaces testbed has been designed and implemented at our labs. The testbed components can be seen in Figure 5. From the system point of view, we regard the context space system as an extended message-oriented paradigm that could be implemented using a variety of implementation platforms, such as peer-to-peer or more traditionally message-oriented middleware like Jabber [14]. Moreover, a space peer should be able to join a group of peers, collaborate by processing the messages it receives, and to achieve the goal of the system as a whole. Thus main functions of the initial phase of the testbed are: • To enable the creation of space objects • The realization of the context space conceptual containment model • To enable the creation of content object entries
To address each of the main functions within the initial phase of the context spaces testbed we identified three existing third-party software components which both allow custom software extensions to be developed and provide existing desired functionality to be used during custom development.
4.1. JXTA The first third-party component to be used during custom development included in the context spaces testbed was a set of peer-to-peer protocols developed by the project JXTA [15]. JXTA is a set of protocol specifications and a reference implementation of the protocols. The JXTA protocols are implemented as services, which are designed to be configurable and extensible, within the JXTA platform. Since, the goal of the JXTA platform is to facilitate the creation of loosely coupled P2P services and applications using a service module framework it was decided to be a good candidate for implementing the context space structure and conceptual model. The JXTA platform allows us to implement specific space peer functionality, which could be initialized, started and stopped, within the concept of a peer group. Space peers can search and join and discover space objects based on interest to form a community bound to an interest. Space Objects were implemented as JXTA peer-groups and space peers were implemented as JXTA peers.
4.2. Zope The second third-party component to be to be used during custom development included in the context spaces testbed was the Zope application server [13]. Zope which stands for “Z Object Publishing Environment” is an application server implemented in python interpreted language, which includes the Zope Object Database (ZODB). The Zope application server allows development of software using three main logic objects Dynamic Template Markup Language (DTML), Zope Page Templates (ZPT) and python scripts. Additionally, the Zope object database has built-in support for environmental acquisition of objects. This allows Zope to be a good candidate for implementing the transactional nature of our persistence space peers using the ZODB for implementation of a centralized persistence service for context entry objects within a space allowing acquisition.
4.3. ElementTree The third third-party component to be used during development in the context spaces testbed was the ElementTree Module for python [16]. ElementTree is a container object, designed to store hierarchical data structures. The ElementTree object is XML centric, lightweight and is integrated with several base XML technologies. Since the 1.2 release of the ElementTree module, the ElementTree object container has had limited support for XPath path expressions. Space peers with in the context space require support for XPath, and since the development of a full XPath engine is outside the scope of the context space testbed, we regard the use of ElementTree to be a good candidate. Additional to the use of XPath provided by ElementTree, a custom implementation of context acquisition in association with ElementTree was a main enabler for searching and implementation of the context space AMI.
5. Conclusion In this paper we provide details of a context-aware computing architectural framework named “Context Spaces”. Using the context spaces architectural framework, we believe there exists the possibility for creation of scoped and well defined contextual interest boundaries, where distributed computing nodes can participate to share and acquire context information during runtime. The main points presented as the architectural framework is comprised of: A conceptual
model, a protocol application message interface for space based-distribution of context information, and a method for run-time context sharing between spaces called context acquisition. Our investigation was not only limited to the identification of an context-ware architectural framework, but included customer development of a context spaces testbed implementing our ideas. We believe that by using our architectural framework context-aware applications driven by collected context information, can realize scaleable dynamic adaptation logic to acquire different behavior from the environment at runtime.
10. References [1] I. Chlamtac and J. Redi, “Mobile Computing: Challenges and Potential”, Encyclopedia of Computer Science, 4th Edition, International Thomson Publishing, 1998. [2] UNIX, URL http://www.bell-labs.com/history/unix/ [3] K. Lyytinen, and Y. Yoo, “Issues and Challenges in Ubiquitous Computing”, Communications of the ACM, December 2002, pp. 63-65. [4] M. Weiser, “The Computer for the Twenty-First Century”, Scientific American, September 1991, pp. 94-104. [5] K. Palmer, “High-Tech tools drive growth in U.S. roadside advertising”, The Wall Street Journal Europe, September 15, 2003, pp A7. [6] D.S. Milojicic, et al., “Peer-To-Peer Computing”, HewlettPackard Company, 2002. [7] A. Tarlano, and W. Kellerer, “Agent Context Interest Communities for Wireless Computing”, WOC 2003 July 2003. [8] URN Syntax, URL http://www.ietf.org/rfc/rfc2141.txt [9] E. Freeman, S. Hupfer, K. Arnold, “JavaSpaces: Principles, Patterns and Practices”, Addison-Wesley, 1999. [10] XML Path Language http://www.w3.org/TR/xpath20/
(XPath)
2.0,
URL
[11] E.D. Mynatt, A. Adler, M. Ito, V.L. O’Day, “Design For Network Communities”, Proc. of ACM SIGCHI, 1997. [12] J. Gil, D. Lorenz, ”Environmental Acquisition – A New Inheritance-Like Abstraction Mechanism”, OOPSLA ’96 CA USA 1996. [13] Zope, URL http://www.zope.org [14] Jabber, URL http://www.jabber.org [15] Project JXTA, URL http://www.jxta.org [16] ElementTree, URL http://www.effbot.org/zone/elementindex.htm
