Managing QoS Degradation of Component Web Services in a Dynamic Environment

Managing QoS Degradation of Component Web Services in a Dynamic Environment

Navinderjit Kaur Kahlon (Department of Computer Science, Guru Nanak Dev University, Amritsar, India), Kuljit Kaur Chahal (Department of Computer Science, Guru Nanak Dev University, Amritsar, India) and Sukhleen Bindra Narang (Department of Electronics Technology, Guru Nanak Dev University, Amritsar, India)
Copyright: © 2018 |Pages: 29
DOI: 10.4018/IJSWIS.2018040108

Abstract

In Services Oriented Computing, a composite web service is a value-added service composed of loosely coupled, independent, and distributed component web services. Component or partner web services jointly contribute to fulfil functional as well as non-functional requirements of users of a composite web service. One of the fundamental challenges in Services Oriented Computing is to ensure that a composite web service is flexible enough to react to changes (QoS degradation) in its partner web services at the time of execution. In this context, it is important that the time to adapt to changes should not be significant. Several solutions exist for run-time monitoring of partner web services so that clients can replace them with better alternatives when their QoS values degrade. But these solutions follow either a reactive approach (which is time consuming), or a prediction-based proactive approach (again time consuming, and moreover predicted events may never happen). This article proposes a solution using a publish/subscribe mechanism which is distributed between web service clients and the service providers, and follows a proactive preventive approach. It uses mobile agents to communicate partner web service's QoS status to its clients just in time, in order to decide to choose an alternative in case the QoS values are not satisfactory. The prototype is implemented using JAVA and Java Agent DEvelopment framework (JADE) programming languages. The experimental results show effectiveness of the proposed approach when compared with a static approach (the benchmark), as well as with a reactive solution. Moreover, the framework performs well even in the wake of the increasing levels of QoS degradation of partner web services.
Article Preview

Introduction

Service Oriented Computing(SOC) utilizes web services as basic building blocks for developing software solutions. Such solutions are flexible, and can reconfigure dynamically at run-time. While this ability seems to be an attractive proposition, it also exposes them to undesired changes of their partner web services. Due to the inherent nature of web services, their Quality of Service (QoS) properties, besides functionality and environment, may change on the fly. Any degradation in their QoS values adversely affects the QoS of the software solution that they are a part of. Run-time adaptation of a web service based solution (also known as Composite Web Service or CWS) requires monitoring of its partner web services as they execute, and to notify the client as soon as possible for timely web service replacement decisions. Dustdar and Schreiner (2005) identified runtime monitoring of web services as one of the major issues that impact web service composition. This paper focuses on continuous monitoring of dynamically changing QoS properties of partner web services of a CWS. Many researchers have proposed models and mechanisms for monitoring partner web services to enable dynamic reconfiguration of a CWS (Angarita et al., 2016), but there is need to reduce the time gap between the moment QoS degradation of a web service happens and the moment it is substituted with an alternative. There is need to reconfigure a web service composition in time when undesirable events happen during its execution (He et al., 2017; Medeiros Campos et al., 2017).

This research addresses the issue by making service provider monitor a partner web service, and share the data with its clients using publish-subscribe mechanism. Ghezzi and Guinea (2007) define two approaches for QoS monitoring of partner web services as client side monitoring and server side monitoring. Both the approaches have their own pros and cons. In this paper, we propose to use a hybrid of both the approaches. A provider employs a Service Monitor Agent (SMA) to monitor a web service. This software agent creates a log as it monitors the service. It analyses the log in real time, and generates alerts (or notifies) when it detects anomalous events. A service client sends mobile agents to providers of the partner services. The Client Mobile Agent (CMA) subscribes to the SMA and waits for notifications. As it gets notified of an anomalous event, it informs the client. Then the client takes a decision to replace the service with an alternative. Therefore, the proposed solution is distributed between client and provider sides, and reaps benefits of both the approaches. To further ease the pressure on the infrastructure during execution, the idea here is to pick a bag of top candidate services (and not only the best service) for future replacement options, and avoid searching the external service registries for future service discovery iterations as much as possible. Searching services from external registries becomes time consuming as number of services increase and therefore is not an attractive proposition during run time.

The proposed solution integrates web service technology with the mobile agent technology. Security related issues may be a point of concern at this juncture. For this study, the mobile agents are being dispatched by trusted clients. So service providers can allow for their execution. Mobile agents don’t put any extra overhead on the providers infrastructure as verified in the study through experimental analysis (see results and analysis section).

This solution may be called proactive from the point of view that adaptation does not happen after the CWS has actually encountered the failure (except in the worst case). On average, a CWS gets prior notification (before it invokes the service) of QoS degradation of its component service and decides to adapt the composition configuration in advance before that service is invoked during the execution of the CWS (see Figure 1). In the worst case, QoS degradation notification and service invocation happen at the same time. In this case, CWS execution halts and waits for the adaptation logic to run before resuming the execution.

Figure 1.

Space-time diagram of the CWS execution process

Complete Article List

Search this Journal:
Reset
Open Access Articles
Volume 15: 4 Issues (2019): 1 Released, 3 Forthcoming
Volume 14: 4 Issues (2018)
Volume 13: 4 Issues (2017)
Volume 12: 4 Issues (2016)
Volume 11: 4 Issues (2015)
Volume 10: 4 Issues (2014)
Volume 9: 4 Issues (2013)
Volume 8: 4 Issues (2012)
Volume 7: 4 Issues (2011)
Volume 6: 4 Issues (2010)
Volume 5: 4 Issues (2009)
Volume 4: 4 Issues (2008)
Volume 3: 4 Issues (2007)
Volume 2: 4 Issues (2006)
Volume 1: 4 Issues (2005)
View Complete Journal Contents Listing