Article Preview
TopIntroduction
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