(IJEM-V1-N3-9)

I.J. Engineering and Manufacturing 2011, 3, 55-61

Published Online June 2011 in MECS (https://www.wendangku.net/doc/048861342.html,)

DOI: 10.5815/ijem.2011.03.09

Available online at https://www.wendangku.net/doc/048861342.html,/ijem

Research of the QoC-Aware Service Selection for Middleware Based

Pervasive Applications

Di Zheng a, Hang Yan b, Jun Wang c

a Department of Computer Science, Naval University of Engineering, Wuhan, HuBei, China 430033

b Department of Electronics and Information Engineering, Huazhong University of Science and Technology,

Wuhan, HuBei, China 430074

c Key Research Lab, Wuhan Radar Institute, Wuhan, HuBei, China 430019

Abstract

With the rapid development of information technology, it is inevitable that the distributed mobile computing will evolve to the pervasive computing gradually whose final goal is fusing the information space composed of computers with the physical space in which the people are working and living in. Furthermore, with the development of SOA, more and more pervasive applications have been composed of different kinds of services. So how to choose a suitable service from all the useable services is the most important step for pervasive computing. Compare to the traditional service selection we must take more care of the context as well as the quality of them in pervasive environment. However, most of existing researches pay no attention to QoC (Quality of Service) which may lead to unreliable selections. Therefore we proposed a middleware based service selection scheme to support QoC-aware service selection efficiently.

Index Terms: QoC; middleware; Context-aware; Pervasvie

? 2011 Published by MECS Publisher. Selection and/or peer review under responsibility of the Research Association of Modern Education and Computer Science.

1.Introduction

Nowadays, the vision of pervasive computing is becoming a reality. The paradigm for pervasive computing aims at enabling people to contact anyone at anytime and anywhere in a convenient way. So, context-awareness has become one of the core technologies in pervasive computing environment gradually and been considered as the indispensable function for pervasive applications [1].A context-aware system generally consists of two parts: sensing a context scenario, and adapting the system to the changing context scenario by providing desired services for a user.

Furthermore, with the development of SOA, more and more pervasive applications begin to provide users with cost-effective services that have the potential to run anywhere, anytime and on any device without (or with little) user attention. Such services are usually called pervasive services and they are part of pervasive (or ubiquitous) computing [2].

* Corresponding author.

E-mail address: dizheng@https://www.wendangku.net/doc/048861342.html,, Hangyan04@https://www.wendangku.net/doc/048861342.html,, junwang@https://www.wendangku.net/doc/048861342.html,

56Research of the QoC-Aware Service Selection for Middleware Based Pervasive Applications

Existing Service Selection methods such as Mobile Agent, Bluetooth, Diane, Jini, Universal Plug and Play (UPnP) have proposed a number of solutions of how to deal with the problems including the semantic description, service discovery, system architecture, service binding in the service selection problem, and these programs focus on the different considerations. Based on these researches, many works have been carried out for service selection [3-7] in pervasive environment. However, these systems rarely pay little attention to the Quality of Services for pervasive applications. In [17], Kun give a QoS based service selection method for pervasive applications by thinking about the contexts of Network quality, Node availability, Network delay, Network reliability, User-perceived quality and so on. By using these criteria they can complete the selection of services. However，how we get the values of the criteria? All the values are so-called service contexts coming from different sensors too. We should pay attention to the service contexts themselves. For example, two services have the same values for all the criteria. Then we should choose which one? In fact, the accuracy of service A’s contexts is 70% while the other one is 85%.It’s obviously the latter service is a better choise. So we should pay attention to the Quality of Context information (QoC) of the services when we complete the service selection.

Buchholz et al. [8] has been the first ones to define QoC “as any information describing the quality of information that is used as context”. Furthermore, context information can be characterized by certain well-defined QoC aspects, such as accuracy, precision, completeness, access security, and up-to-date [12]. Despite its importance few works [9~13] have proposed different QoC measuring methods. Moreover, these studies evaluate quality only on some aspects, i.e. they do not consider complex and comprehensive applications. Comparatively, pervasive environments have a wider range of applications such as performing collaborative work. Hence, complex data structures are used to gather data from sources ranging from the simple sensors to user interfaces and applications in mobile devices.

Therefore, based on our previous works [14-16], we propose a context-aware framework that support QoC management including threshold control, duplicate context discarding and inconsistent context discarding in various layers. Moreover we extend our autonomic management approach for the service selection so as to make these applications can be selected more accuracy and efficient than traditional methods.

2.Middleware based QoC-aware Service selection

A.Architecture of the Context-aware Middleware

As our previous architecture depicted in figure 1[9,10,11], the core provides the fundamental platform-independent services for the management of the component/service based applications.

Context Manager is responsible for sensing and capturing context information and changes, providing access to context information (pull) and notifying context changes (push) to the Adaptation Manager.

Fig. 1 Architecture of Context-aware Middleware Fig.2 Architecture of the Context Manager

Adaptation Manager is responsible for reasoning on the impact of context changes on the application(s), and for planning and selecting the application variant or the device configuration that best fits the current context.

Configurator is responsible for coordinating the initial instantiation of an application and the reconfiguration of an application or a device according to the configuration template for the variant selected by the Adaptation Manager.

Autonomic Manager provides the basis for realizing the dynamic, automatic binding of components/services into concrete functionality as well as the dynamic replacement of a component/service with another.

Service management module aims to provide context-aware services to cognize the user situations and their surroundings. It is key components for pervasive computing that purposes adaptive service to user in various devices on everywhere.

B.Architecture of the Context Management

As depicted in figure 2, the context repository is the main entry point for clients to the context manager. The primary tasks of the context repository are to maintain a context model, register and notify listeners, give access to context elements, and keep registry of available components.

The context sensors are components which provide context information to the context repository (a type of context source). Sensors can be wrappers around specialized hardware drivers, or legacy code used for monitoring context, such as battery, memory, and network information.

The context interpreter abstracts raw or low level context information into richer or higher level information according to interpretation rules described by using the context meta-model provided by the middleware. Furthermore, this component can fuse kinds of basic information into more comprehensive elements.

The context reasoners can produce one or more context elements using other context elements as input. This component is used to filter context information to determine relevant ones, and notify the subscribed component of these context changes.

The reasoners are “plug and play” in order to make it possible to target reasoners according to different needs and domains.

The context storage keeps the track of historical context information which is often required in order to determine trends in context data (for example trends in user behavior, network stability, etc).

C.Ontology based Context-aware Service Model

Fig.3 Ontology based Context Model Fig.4 QoC-aware Context Model based on Ontology

As depicted in figure 3 is the ontology based context model, the contexts are composed of computation contexts, location contexts, user contexts and activity contexts. The service contexts belong to the computation contexts. Service ontology is not connect directly to upp er ontology’s context information but waits exit process of executing service. Domain ontology is inherited context information from upper ontology and creates core ontology in domain-specific area. If service deduction arises in domain ontology, service ontology is created after service matching between domain-extend ontology and new service ontology, and executes it.

As depicted in figure4, we use the parameters as follows based on ontology:

(1).Security

We use security as the probability with which the context is delivered in security to the consumers. This parameter is useful to know the probability with which the context has been maintained in security, from its capture by sensors to its use.

(2).Precision

We use precision as the level of details in which the context characterizes the real world. For numeric context information, the value described with three significant figures (e.g. 32.2) is more precise than with two significant figures (i.e. 32).

(3).Resolution

We use resolution as the spatial granularity with which the context is being described/sensed from the environment. For instance, the lightness of a building can be described in the following spatial granularity levels: building, floor, and room.

(4).Freshness

We use freshness as the temple granularity with which the context is being described/sensed from the environment. This parameter reflects the time exhausted for passing the context to consumers.

(5).Certainty

We use certainty as the probability of the accuracy of the context. As we all know, the context comes from different kinds of sources and some of them more sensitive and useful than the others. So when we have similar contexts from different sensors, we should choose the right context with the help of certainty.

(6).Completeness

We use completeness as the ratio of the number of context information available to the total number of context gatherings. The completeness of a context object is computed as the ratio between the sum of the weights of available attributes of a context object, and the sum of the weights of all the attributes of that context object.

D.QoC-aware based Service Selection

Firstly, based on the QoC-aware context model in figure5, we propose a QoC-aware context manager as depicted in figure 4.

Fig.5 QoC-aware Context Manager Fig.6 Quality-aware Context Processing Procedure

As depicted in figure4, we provide different levels of QoC. When the context retriever gets the context from different providers, it can use different thresholds to discard some of the context for its lower certainty, precision, freshness. Then we can get less and more useful context. Furthermore, the main question when completing context interpretation and context aggregation is the detection and discarding of the duplicate or inconsistent context. The detailed quality-aware context processing procedure is shown in Figure6.

The first step is the raw context gathering, in which raw contexts from various sensor sources are collected during a fixed short period. In this step we will use one or multiple thresholds to refinery the raw context.

The second step is the duplicate and inconsistency resolution during context interpretation and aggregation. We resolve inconsistency among different raw contexts in this step because duplicate and inconsistent raw contexts may lead to high-level contexts more difficult to handle. We process raw contexts in a batch by batch manner instead of a piece by piece manner. Inconsistency in a batch of raw contexts should be cleaned prior to context reasoning so that the inconsistency of high-level contexts can be mitigated in certain degree. We will update the context repository with raw contexts and check the dependency. Outdated or incorrect high-level contexts will be deleted in this step. If they are not removed, they will result in serious inconsistency among contexts after reasoning.

E.QoC-aware Context based Autonomic Service Selection

Based on the Context-aware technology, the Service Selection architecture obtains and using the context information. We can define context-aware criteria that link the two sides of context and service nonfunctional constraints. Context-aware criteria consist of a number of criteria that are initialized from the meta data of the correct service category. For example, we can use one of the QoC criteria such as precision, freshness, certainty, completeness and so on. We can also use two or more criteria to complete the selection. All the selection is managed by the autonomic manager according to the configuration of users.

All the procession is controlled by the Autonomic Management Module. When deployed, every service will have several context configuration constraints which imply the services pay more attention to which contexts. We can also set the thresholds for the constraints. If a service’s contexts are und er thresholds, then the service cannot be selected.

Initially, the Autonomic manager of an our context-aware middleware discovers the service providers that match the user’s requirements by given service discover methods. Then the Autonomic manager compares QoC of different services by using the methods choose by users and selects one of the suitable providers and creates a binding to it. During service execution, when the Autonomic manager detects broken service bindings (e.g. the bound service provider becomes unavailable), it will repair them by discovering and binding to an alternative provider.

Besides the initial binding configuration and repair facilities, the Autonomic manager can be configured to continually optimize service selection during runtime. Furthermore, a service provider that was optimal in a certain context may be automatically replaced by a different service provider, which becomes the optimal choice in a new execution context. The context filter can be specified to trigger the dependency optimization each time a new service provider with the required specification becomes available. And we will take more complex replacement methods into account in the future researches.

3.Performance Measurements

We are deploying the proposed framework in a university building in order to provide context-aware services to the users, such as context-based access control and context-aware control of heating and lighting, among others. Afterwards, the gathered information was transmitted to a server running a CIS (Intel Core Duo 2.8GHz, 4 GB, Windows vista 32bits, SQL Server 2008). The sensing was carried out during 24 hours, with intervals of 5 seconds. The evaluation consisted of (i) a study of performance verifying the time overhead added by the quality support in the framework and (ii) the compare of the different discarding algorithms.

Fig.7 The Overhead of the QoC-aware Context Dealing Fig.8 Analysis of the true probability

As depicted in figure 7, we compare the overhead of the common context processing procedure as well as the procedure with QoC-aware dealing. We can see the QoC-aware dealing may exhaust more time. However, by using the QoC-aware dealing schemes,we can select better service. As depicted in figure 8, we compare the true probability of the contexts by using different contexts dealing algorithms such as selecting the newest service, selecting the service with the highest certainty and the service with the highest relativity as follows.

We can see all the dealing algorithms can get better true probability. If using the composition of more than one QoC criteria, we can make better selections. However, more time will be exhausted too. So, we should balance the accuracy and efficiency as well as making assure the difference of kinds of applications. In future works, we will complete more experiments continuously to find better service selection algorithms based on our framework.

4.Conclusion

In this paper, we have proposed a middleware based context-aware framework supporting QoC management for the service selection. By this framework we can evaluate raw context, discard duplicate and inconsistent context so as to protect and provide QoS-enriched context information for better service selection. In future work, we will verify how these QoC indicators depend on each other in further and take into account one or more QoC indicators in order to improve the context-aware decisions for service selection.

References

[1] A. K. Dey, “Understanding and using context,” Personal and Ubiquitous Computing, vol. 5, no. 1, pp. 4–

7, 2001.

[2]Kun Yang ,Alex Galis ,Hsiao-Hwa Chen, “QoS-Aware Service Selection Algorithms for Pervasive

Service Composition in Mobile Wireless Environments, ”Mobile Netw Appl (2010) 15:488–501. [3]Ardagna D, Pernici B (2007) Adaptive service composition in flexible processes. IEEE Trans Softw Eng

33(6):369–384

[4]Zhao Tang, Wenan Zhou, Jie Chang,Research on the Context-aware Service Selection

Architecture,2010.

[5]Liu shulei, Liu yunxiang, Zhang fan. A Dynamic Web Services Selection Algorithm with QoS Global

Optimal in Web Services Composition[J].Journal of Software, 2007, 18 (3): 646-656.

[6]Reiff-Marganiec, S., Truong, H.-L., Casella, G., Dorn, C., Dustdar, S., Moretzki, S.: The incontext

pervasive collaboration services rchitecture. In: Mahonen, P., Pohl, K., Priol, T. (eds.) Proceedings of Service Wave 2008. LNCS, vol. 5377, pp. 134–146. Springer, Heidelberg (2008)

[7]Riva, O., Toivonen, S.: A hybrid model of context-aware service provisioning implemented on smart

phones. In: Proceedings of ACS/IEEE International Conference on Pervasive Services (2006)

[8]T. Buchholz, A. K¨upper, and M. Schiffers, “Quality of context: What it is and why we need it,” in

(HPOVUA 2003), Geneva, 2003.

[9]Y. Kim and K. Lee, “A quality measurement method of context information i n ubiquitous

environments,” in ICHIT’06. Washington, DC, USA: IEEE Computer Society, 2006, pp. 576–581. [10]P. N. MA Razzaque, S Dobson, “Categorization and modelling of quality in context information,” in

Proceedings of the IJCAI 2005, 2005.

[11] D. Preuveneers an d Y. Berbers, “Quality Extensions and Uncertainty Handling for Context Ontologies,”

in Proceedings of (C&O 2006), P. Shvaiko, J. Euzenat, A. L′eger, D. L. McGuinness, and H. Wache, Eds., Riva del Garda, Italy, August 2006, pp. 62–64. [Online]. Available: http://www.cs.kuleuven.be/ davy/publications/cando06.pdf.

[12]K. Sheikh, M. Wegdam, and M. van Sinderen, “Quality-of-context and its use for protecting privacy in

context aware systems,” JSW, vol. 3, no. 3, pp. 83–93, 2008.

[13] A. Manzoor, H. L. Truong, and S. Dust dar, “On the evaluation of quality of context,” in Smart Sensing

and Context, Third European Conference, EuroSSC 2008, Zurich, Switzerland, October 29-31, 2008.

Proceedings, 2008, pp. 140–153.

[14]Di Zheng，Jun Wang，Yan Jia，Wei-hong Han，Peng Zou. Deployment of Context-aware

Component-based Applications based on Middleware. In UIC 2007，July，2007，Hongkong.

[15]Di Zheng，Jun Wang，Yan Jia，Wei-hong Han，Peng Zou. Middleware based Autonomic

Management of the Context-aware Component-based Applications. In ATC 2007，July，2007，Hongkong，

[16]Di Zheng, Yan Jia, Peng Zhou, Wei-Hong Han. Context-Aware Middleware Support for Component

based Applications in Pervasive Computing. In： Proceedings of The 7th International Conference on Advanced Parallel Processing Technologies，November， 2007.

[17]Kun Yang , Alex Galis , Hsiao-Hwa Chen. QoS-Aware Service Selection Algorithms for Pervasive

Service Composition in Mobile Wireless Environments,2009.