The development of composite web services poses very interesting challenges concerning their QoS characteristics. On the one hand, a composite web service depends on the QoS properties of its component web service providers, in order to provide a satisfactory service to the consumer. On the other hand, the concept of self-healing web service has been introduced in order to describe services which exhibit such properties. A self-healing web service can repair itself if any execution problems occur, in order to successfully complete its own execution, while respecting QoS agreements. In the design of a self-healing WS, several aspects have to be considered. For instance, the service should be able to predict the failures as soon as possible and to enact suitable recovery actions. One of the recovery action is reselection of web service in order to replace the failed service. However, selecting a service and replacing it may cause problem on global QoS constraints. Moreover, different QoS service levels might be considered in order to complete the service execution in case of error, possibly with degraded performance.
The main issues for the fulfillment of QoS agreements are concerned with web service performance variability. Indeed, the QoS of a web service may evolve relatively frequently, either because of the internal changes or because of workload fluctuations. The performance of an atomic web service may change frequently and hence the composite web service of which, this is a component is likely to deviate from its QoS agreements. Nevertheless, the composite service should be able to successfully accomplish its task as a whole, to fulfill the QoS requirements. In order to achieve this, the composite web service should be able to repair itself to complete its own execution successfully. The performance of the composite web service may be significantly improved by monitoring the execution of the component web services and by flexibly reacting to failures in a timely fashion. One of the approaches to tackle with this QoS (non-functional) failure is the reselection of the web service which can be substituted for the failed service and the reconfiguration of the composite web service. Thus reselection of web service is an important facet.
Reselection:
The reselection procedure broadly falls in one of the following categories.
Online Approach : In online reselection, when the failure occurs, the current composite service is stopped, till the reselection process is finished and the composite web service is reconfigured. As the reconfiguration process starts, it consumes more time and hence the response time of the composite web service will increase.
Backing up approach : Certain number of composite web services which is in pace with the current composite web service is configured and is backed up. When the current composite web service fails, one of the backup composite web services can be replaced with. The problem with this approach is if the performance requirement changes in future, this may not be fulfilled by the composite web service, since it had been configured long back in the past.
The reselection procedure broadly falls in one of the following categories.
Online Approach : In online reselection, when the failure occurs, the current composite service is stopped, till the reselection process is finished and the composite web service is reconfigured. As the reconfiguration process starts, it consumes more time and hence the response time of the composite web service will increase.
Backing up approach : Certain number of composite web services which is in pace with the current composite web service is configured and is backed up. When the current composite web service fails, one of the backup composite web services can be replaced with. The problem with this approach is if the performance requirement changes in future, this may not be fulfilled by the composite web service, since it had been configured long back in the past.
No comments:
Post a Comment