A Middleware Supporting Context-Aware Services Based on Context ...

A Middleware Supporting Context-Aware Services Based on Context Business Objects Jinhua Xiong1,2, Manfred Wojciechowski3, Bernhard Holtkamp3, Shaohua Yang1,2, Jianping Fan1 1 Institute of Computing Technology, Chinese Academy of Sciences 2 Graduate School of the Chinese Academy of Sciences 3 Fraunhofer Institute for Software- and Systems Engineering, Germany [email protected] Abstract Although the demand for context-aware applications seems very high, not many applications are in real use. Besides the strenuosity, their insufficient adaptability to changing environment is a major reason. To address the issue, we proposed a VINCA-cc approach and a context middleware to support business-level dynamic configuration of context-aware service. In our approach, all kinds of context information are abstracted to standardized context business objects (CBO), registered in the context middleware. The business-level context model, CBO, represents a set of business-level properties and abstract unified operations that are applicable to all context information. Based on the visual business-level service composition language-VINCA and CBO model, context-aware services can be visually (re-)configured at the business-level. The paper focuses on the context middleware, CBO model and its application.

1. Introduction With the development of sensor technology, software engineering, and context-aware applications, the Ubiquitous Computing paradigm, has gained more attention than before, from academy to industry. Some real applications have already embedded context-aware functionalities, e.g. location-based services on mobile phones. Meanwhile, service-oriented computing (SOC) paradigm utilizes services to support loosely-coupled context-aware application development. Until now, although the demand for context-aware applications seems very high, not many context-aware applications are put into real use. The key problems are: the development of context-aware applications is still very

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007

difficult or time-consuming, and the adaptability of context-aware applications can not fulfill the requirement of rapidly changing environments. (1) Different kinds of context and situation information are too complex for many context-aware application developers, and there is lack of a unified and simple access to such complex information. For example, by location information, some context-aware application decision will be based on whether the referred location is within a scope, or identical to a logical location address, and so on. How to isolate context-aware application developers from dealing with different kinds of processing on context or situation information is a challenging issue. (2) For many context-aware applications, changes in user demand, changes (delete or add) in available context or situation sensor, and the evolution of the application itself are inevitable. But for most current context-aware applications, developers design and implement all the functions and context-aware behavior at one time. Such applications can not adapt to changes quickly, and do not support customizing context-aware behavior dynamically. To address these issues, a business-level (or application-level) configuration approach—VINCA-cc is proposed for context-aware service development. Here, VINCA is a user-centric, business-level service composition language [8]; CC stands for Contextaware Configuration. The paper focuses on the context middleware and context model. The paper is organized as follows. Section 2 introduces VINCA-cc approach together with a typical scenario. Section 3 presents the context middleware, context model (CBO), and its implementation. Section 4 is the CBO middleware’s application and evaluation. Section 5 discusses related work. Section 6 is the conclusion and future work.

Two Abstractions, One Configuration：

2. VINCA-cc approach

(2) Abstraction of SOA Application

(3) Context-aware Configuration

restaurant

All restaurant query

All restaurant reservation

ti

Muslim Choice

Preference Nearby restaurant query

Curr. Location Transportation service

Nearby restaurant reservation Legend:

Logical Location

Travel Situation: Walking, Driving

Context information

Figure 1. Context-aware composite services

From the above scenario we can see, the task of retrieving different context or situation information, and operating on them is independent from specific services or application functionalities. Such task may be too complex for a context-aware application developer. Through the separation between this task and basic service functionalities, our VINCA-cc approach simplifies the development of context-aware applications, and targets making the development of context-aware applications a quick configuration process in an open environment. Figure 2 illustrates the VINCA-cc approach and its architecture. The approach can be summarized as: two abstractions, one Configuration. Context Abstraction: (1) The context modeler is responsible for modeling context and situation information based on a common semantic

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007

Inter-Operations on CBOs CBO Instance Management CBO Type Registering Context Entity Mgmt. Context Repository Encapsulating

Context

& Standardizing

Ontology

Ontology inference Ontology Modeling

Query and Reservation of Restaurant Islamic

Islamic restaurant query

VINCA Process Studio

(2) Abstraction of Context

Context Middleware

To illustrate the VINCA-cc approach, Figure 1 gives a composite service for restaurant query and reservation related services, which can be accessed through digital companions by different users. To provide context-aware service, the composite service will be based on all available context or situation (refer to high-level context) information to filter appropriate services, recommend different branches for different users, and fill in the input of requested services automatically. For example: as a condition factor for process branch selection, user’s confession “Muslim”, or user’s ‘Food Preference’ with “MuslimFood” will be used to recommend the “Islamic restaurant” service branch for the user (in another scenario, recommendation of services may be based on the scope calculation of a user’s current location); as a service input, here, the user’s logical location and travel situation may be used to find a nearby restaurant for the user.

VINCA Interpreter

Execution Engine

Business Service Community Registering

(1) Common Semantic Physical sensors

Infrastructure

Logical sensors (Profile)

Figure 2.

WEB Services Resources

VINCA-cc approach and its architecture

infrastructure, establishing CBO Specification, including Context ontology and CBO Type in Figure 2. (2) In accordance with CBO specification, the context/situation information stored in “Context Repository” or scattered on different sites is encapsulated to CBOs. (3) In the Context Middleware a CBO layer is presented to context-aware application developers as a view of business-level context objects, which are graphical objects with properties and supported operations. Application Abstraction: In SOC paradigm, application building blocks are different WEB Services. VINCA approach is a kind of business-level WEB service composition approach. In VINCA, through semantic annotation and service abstraction, technical and supplementary details of Web Services are hidden and only the business-level aspects, called “business service”, are presented to application developers, then with the support of VINCA Process Studio, application developers can construct their SOA applications based on “business services” [8]. Context-aware Behavior Configuration: With the above two abstraction processes, context/situation information is abstracted to standardized business objects with a set of business operations; and an application is abstracted to a kind of business-level composite service. Then developers or end users can drag required graphical context objects to the right place in the composite service, and can also choose business operations (which he wants context objects to execute). Through such a drag-choose-configuration process, context-aware applications can be constructed.

3. Context middleware In this section, the layered architecture of the context middleware, business-level context model together with its abstraction mechanism, and CBO implementation analysis are introduced.

3.1. A layered context model architecture To support different context application patterns, (e.g. centralized context server vs. distributed context management, semantic-rich case, etc.), our context model adopts a layered logical architecture, illustrated in Figure 3. The first layer--core context model defines basic concepts related to context information modeling, which serves as concept basis between different layers. The second layer–unified context model targets unified usage of context information with enough expressive abilities, like the SQL language providing a unified language to support definition and operation on database. Different context infrastructures have different requirements e.g. datacentric, semantic-rich or others; then different technologies can be chose to implement such layer. In our context middleware, OWL is used to model and store semantic-rich context information. Context-aware Context-aware Application Context-aware Application

Graphical Representation Internal Representation

Context Middleware

Business-level Model

Unified Context Model

Core Context Concept

CBO Model

OWL Model

ER-like Core Concepts

Figure 3. A layered context model architecture

applications can access context information based on a unified query language-SPARQL. The third layer – business-level model is CBO model layer which models different context/situation information as standardized context business objects, designed to support business-level configuration. By adopting such layer architecture, the context model is flexible to tailor different application patterns. As context information is a special kind of information, we borrowed ideas from well-established conceptual model technology, i.e. ER Model, to define the basic concepts in our core context model. In the

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007

model, only three concepts are explicitly identified: Context Entity, Context Dimension, and Context Entity Relation. As Dey [5] mentioned, “any information that can be used to characterize the situation of an entity”, entity and the “information” to characterize an entity are at different levels. By “Context Entity” we mean a “thing” which can be identified. Context entities are categorized into different context entity types. Examples of such context entity types are Person (e.g. tourist John) or Place (e.g. City, Restaurant, and Meeting Room). “Context Dimension” standardizes different kinds of information, including static information and dynamic information, which will be used to characterize different aspects of context entities. A context dimension consists of different aspects: value set, semantic identifier, and other attributes to specify the dimension. A “Context Entity Relation” is modeled at entity level separately. A context entity is linked to other context entities by uni-directional relations. The relation originates at a single entity which we call owner of the relation. A relation consists of related context entities, a relation name, a semantic identifier, and other attributes to specify the relation [14].

3.2. Business-level context model – CBO 3.2.1. CBO model. Business objects are representations of the nature and behavior of realworld things or concepts in terms that are meaningful to business people, provide a way of managing complexity, and operate at a high level of abstraction [2]. We borrowed the idea of “business view” and “high-level” to manage the complexity of context and situation, to develop a context business object model as an abstraction of context information. From an application point of view, all kinds of context information (“context dimensions” and “relations”) are modeled as context business objects (CBOs), which represent a set of business-level or application-level properties, abstract operations (here, business-level and application-level both mean the level which can be easily understood by the people who are not software professionals, even by end-user). The distinctive feature of CBO model is to isolate the heterogeneity of different context and situation information from its “unified” business-level properties and abstract operations, which are applicable to all context and situation information. On the one hand, context providers can encapsulate their context or situation information as standardized abstract operations, and register them in a context middleware; or CBOs can be derived from the underlying unified

context model and context repository within the CBO = (Community, ContextType, Biz-Attribute, context middleware. All implementation details on Biz-Operation). how to retrieve context information, how to implement （1） Community is an identifier of the community decision-making in operations is encapsulated within a where the context business object is registered CBO. On the other hand, for application developers, and managed. Multiple communities can be the CBO model provides a standard way to use all created in our context middleware. kinds of context/situation information. They can （2） ContextType = (Name, Keyword) represents embed such kinds of abstract operations in their the context business object type, and context-aware application; let a CBO itself to retrieve “Keyword” is an exclusive identifier within the the related information, to interpret the logical above-specified community. decision-making. （3） Biz-Attribute = (Description, Value, Format, Our context business object model is defined as a 4Unit, Status, BindingTo, Timestamp, Semantic) tuple: Table 1. A CBO type and its CBO instance example CBO Model

A CBO type example

Its corresponding CBO instance example

Community*

“FLAME” (the community name registered)

(Read only)

Context- Name Type

“Food Preference”

(Inherit the type name or has an instance name)

Keyword* “Preference”

(Read only)

BizDescription “This CBO type standardizes usage of user’s food Attribute preference. All food styles are organized as a hierarchy, e.g., WesternFood\ItalianFood, AsiaFood\ThaiFood or \ChineseFood\ChuanFood, etc. Usage example: Pseudo-code demonstrating how to use the CBO…”

(Can provide more introduction and usage information about the CBO instance.)

Value

“-” (No default value for this CBO type)

“ChuanFood”

Format

“Default” (Default format is straightforward string.)

Unit*

“-” (No unit for this CBO type)

Status

Enumerate variant : (CBO Type Registered), (CBO (CBO Instance Available), Type Unavailable), (CBO Instance Registered) (CBO Instance Unavailable)

(Read only)

BindingTo “-” (It will be filled in with a concrete context entity “UserID” which bounds to this CBO ID for each CBO instance.) instance in Context Entity Management Timestamp “-”Comply with YYYY-MM-DDThh:mm:ss.sTZD “ 2006-05-16T19:20:30.45+08:00” Semantic* “http://www.sigsit.org/2006/owl/food.owl#Food.” (refer to a URI of context ontology)

Can refer to a more concrete ontology, which specifies CBO instance value, http://www.sigsit.org/2006/owl/food.o wl#Chuan_food

Note: The columns marked with “*” are CBO Type level attributes. The dynamic attributes are maintained by the CBO instance itself.

“Description” gives information on how to use the CBO, usage examples, and other information for understanding the CBO. “Value” is used to store a concrete value of a context dimension within a CBO instance. “Format” is used to specify the format of return “Value”. “Unit” is used to describe the unit of the value attribute (e.g. “Fahrenheit” for a temperature CBO). “Status” shows whether the current CBO is

available. “BindingTo” stores information on which context entity the CBO is bound to. As mentioned above, “Context Dimension” is used to characterize a “Context Entity”, and CBO is used for abstracting “Context Dimension” and “Context Entity Relation”, so CBOs are organized according to Context Entities they are bound to. “Timestamp” stores the sample time of a CBO value. “Semantic” refers to a semantic identifier. It can be used by VINCA-cc for semantic

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007

checking or inference. Some attributes in Biz-Attribute have context type-level values, (e.g., the Unit attribute can have “db” for a noise CBO, and the semantic attribute refers to a noise ontology defined in OWL.), other attributes are (re-)filled in when a CBO instance is registered. An example of CBO type and instance’s attribute from the sample scenario is listed in Table 1. （4） Biz-Operation = (Basic_OP, Logic_OP, Customized_OP) Biz-Operation provides standardized business-level interfaces to access context information and enable logical decision-making by a CBO itself. z Basic_OP = (GetAttribute, SetAttribute), is used to retrieve or set the value of a CBO instance attribute. The CBO value could also be gotten by dot notation, e.g. FLAME.Preference.Value. z Logical decision-making operations: Logic_OP = (IsA, In, Contain, (>, =, , =, , =, , < ， >=, 15Km, Driving…). The above two implementation ways have different characteristic, therefore could be used in different cases. “OWL-based” way is suitable for semantic-rich, centralized storage of context/situation cases. The semantic basis here could provide reasoning ability, situation calculating ability, etc. The centralized processing could provide efficiency in some cases. “Direct encapsulation” is suitable for distributed context processing, privacy controlled by each CBO participant, and complexity logic inside CBO instances cases.

4. Application and evaluation We have developed a simple prototype of context middleware, which demonstrates context ontology model, context entity management, CBO Type and Instance Management. And we have implemented some CBO instances with web services interface, illustrated in Figure 4. The abstraction mechanism of our CBO model provides the ability to get businesslevel developers or end users participating in the development of context-aware applications. They need neither to know software technical details of encapsulated context sensors, nor the professional knowledge of that kind of context. The application of CBO is straightforward. What context-aware application developers need to do is to check CBOs’ properties and their supported operations, which are interesting for the target application. Back to the above-mentioned scenario, 5 kinds of context/situation information are encapsulated to 5 CBO Types, and registered in the Context Middleware: Nationality CBO, Preference CBO, Logical_Location CBO, Travel_Situation CBO, and Location CBO. Each CBO type may have multiple CBO instances. And then with the support of VINCA workshop tool, a context-

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007

aware composite service can be easily constructed by embedding CBOs and/or operations on CBOs into the composite service. For example, a condition that “if a user’s ‘Food Preference’ contains MuslimFood” could be embedded in the composite service for branch recommendation. Our experiment demonstrates that the configuration of VINCA-cc is in a very straightforward and easy way; the adaptability of VINCA-cc to environment and demand change is high.

Figure 4. Context middleware and a CBO test example

5. Discussion VINCA-cc together with the CBO model does not try to address all kinds of context-aware applications development. According to the 80/20 principle, 20% refined basic functionalities can serve the requirement of 80% context-aware applications. And the SOC paradigm provides better support for loosely-coupled applications, so it is possible to separate the task of retrieving different context /situation information and operating on them, from the task of context-aware application development. The CBO model provides a common specification of such basic functionalities. For a context dimension, the business-level logical operations are common, and powerful enough to express requirements for single context decisionmaking. On top of the above logical operations, interoperations on CBOs will be supported by another context middleware component independent of CBOs. The separation, between CBO-supported logical operation and inter-operation supported by a context middleware, enables two roles, i.e. context provider and context middleware developer to share the task in the development of context-aware application. VINCA-cc has been built on many other approaches, e.g. Context Toolkit [6], Context Infrastructure [10], CARISMA[1], and [15], sharing the idea of context infrastructure and configuration development. In Aura [12], an architectural framework

for user mobility is presented, which includes 4 component types: Task Manager, Context Observer, Environment Manager and Supplier. Activity-based or Task-level computing [4] is a new paradigm, which tries to provide computational support for humans at a familiar level of abstraction: tasks or activities level. Capturing and management user intent is a core issue in Aura and Activity-based computing paradigm. VINCA-cc shares the idea of abstraction of activity or task level to some extent, but VINCA-cc does not step into the level of capturing user intent. VINCA-cc provides a business-level encapsulation specification and (re-)configuration functionality based on semantic and SOC paradigm, aiming at providing an open infrastructure to enable different roles to participate in the development of context-aware application; its configuration is based on business-level process and context business objects; and the CBO model just provides a unified abstraction for different context/situation information. Compared with Business Objects [2], the CBO model borrowed the idea of “business view” and “highlevel” operation to manage the complexity of context/situation. One distinctive feature for CBO is how we abstracted a set of unified business-level logical operations, which are applicable to all context information based on set theory. Other features: (1) an extensible semantic reference mechanism is used to enable cross organization integration; (2) with serviceoriented architecture support, it is possible to build context-aware application based on a set of CBOs in an open environment; (3) the logic embedded in CBOs and the interaction between CBOs are much simpler than that of Business Objects in business information systems, so it is easier to build infrastructure-level context business objects. Haseloff [9] proposed an object model for context, which consists of 4 separate models for location, state, reachability, and surroundings. A context model based on first order predicate logic is proposed in [11]. There are also many other works on ontology-based context models and architectures [7, 3, 13]. Our CBO model separates the functions of complex logic and rule-based inference from context providers and leaves those functions to the context middleware. Because different context information is abstracted into application-level business objects with a set of unified operations instead of predicates, it can be used in a very simple way similar to script mechanisms. The first priority of VINCA-cc approach is simplicity.

6. Conclusion and future work

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007

We presented a business-level configuration approach—VINCA-cc and its supporting context middleware for context-aware services development in SOC environment. The key issue for dynamic configuration is a unified abstract specification. We proposed a context business object model (CBO) to address it. In CBO, different context information is dealt with in the same manner, with a set of businesslevel attributes and a set of unified business-level operations. With VINCA-cc and its middleware support, an application developer, even an end user, can construct context-aware services easily through business-level configuration. We have implemented a prototype. Our configuration approach has shown the adaptability to rapidly changing environment. The prototype is still an ongoing work. End-user friendly inter-operation patterns and interaction between enduser and context-aware application will be paid more effort in our future work, in order to improve user experience.

Acknowledgments The research work is partially supported by National Natural Science Fund of China (Grant: 90412010, 90412005, and 70673098), and Open Funding of SKLSE of China (Grant: SKLSE05-08). We appreciate anonymous reviewers for their valuable comments and colleagues who help to improve the work.

References [1] Capra, L. Emmerich, W. Mascolo, C. CARISMA: Context-Aware Reflective middleware system for Mobile Applications. IEEE Transactions on Software Engineering, 2003, 29(10): 929-945

[2] Casanave, C. Business-object architectures and standards. In: OOPSLA Workshop on Business Object Design and Implementation. Springer, 1995. [3] Chen, H., Finin, T., Joshi, A. Using OWL in a Pervasive Computing Broker. In Proceedings of Workshop on Ontologies in Open Agent Systems (AAMAS 2003), 2003. [4] Christensen, H. B., Bardram, J. “Supporting Human Activities — Exploring Activity-Centered Computing”, In: Proc. of the 4th International

Conference on Ubiquitous Computing UBICOMP, Goteborg, Sweden, 2002. Springer [5] Dey, A.K. Abowd, G.D. Towards a better understanding of context and context-awareness. Georgia Institute of Technology. Tech Rep: GIT-GVU99-22, 1999 [6] Dey, A.K. et al. A conceptual framework and a toolkit for supporting the rapid prototyping of Contextaware applications. HCI Journal. 2001, 16(2-4), 97-166 [7] Gu, T. Pung, H.K. Zhang, D.Q. A Service-Oriented Middleware for Building Context-Aware Services. Journal of Network and Computer Applications, 2005, 28(1): 1-18 [8] Han, Y. Geng, H. Li, H. Xiong, J. et al. VINCA - A Visual and Personalized Business-level Composition Language for Chaining Web-based Services. In: the First International Conference on Service-Oriented Computing. Berlin: Springer. 2003, 165-177 [9] Haseloff, S. Context Awareness in Information Logistics: [PhD dissertation]. Berlin: TU Berlin, 2005 [10] Hong, J. Landay, J.A. An infrastructure approach to context-aware computing. Human- Computer Interaction. 2001, 16(2-4), 287-303 [11] Ranganathan, A. Campbell, R. An infrastructure for context-awareness based on first order logic. Personal and Ubiquitous Computing, 2003, 7:353–364 [12] Sousa, J.P., Garlan, D. “Aura: an Architectural Framework for User Mobility in Ubiquitous Computing Environments” In: Proc. of the 3rdWorking IEEE/IFIP Conference on Software Architecture 2002, Montreal, August 25-31, 2002. [13] Strang, T., Linnhoff-Popien, C., Frank, K. CoOL: A Context Ontology Language to enable Contextual Interoperability. Proceedings of International Conference on Distributed Applications and Interoperable Systems. Paris, 2003, pp. 236–247. [14] Wojciechowski, M., Xiong, J.: Towards an Open Context Infrastructure; Second Workshop on Context Awareness for Proactive Systems (CAPS 2006), Kassel, Germany, 2006 [15] Yau, S.S. Karim, F. Wang, Y. Wang, B. Gupta, S. Reconfigurable Context-Sensitive Middleware for Pervasive Computing. IEEE Pervasive Computing, 2002, 1(3): 33-4

The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007