QoS-Aware Web Services Discovery with Federated Support for UDDI

Introduction

With the industry’s efforts on promoting the used Web services, a huge number of Web services are being developed and made available on the Web. Organizations now wish to offer electronic services worldwide and this creates several technical problems. First, being able to discover what services are available. Second, being able to determine which services match your specification. Third, being able to control which services are advertised to whom, and when. Fourth, being able to assess previous and current service usage for future selection.

There are three major roles in the Web services architecture: the service provider, the service requester and the service registry. The service provider is the business entity that provides software applications as Web services. The service requester is the entity who has a need that can be fulfilled by an available Web Service. The service registry is a searchable repository of Web services descriptions where service providers publish their Web services and service requesters locate Web services and obtain binding information to invoke the services. UDDI (Bellwood et al., 2002) stands for universal description, discovery and integration. It is a public specification that defines a service registry to publish information regarding the Web services and to make this information available to potential clients.

As more and more services appear on the Web, service requesters are presented with a group of service offers providing similar services. Different service offers may have different qualities of service. This will require sophisticated patterns of negotiation. For example, the trade-offs between quality and cost or invocation of another trade service determining the QoS of various service offers. Current UDDI registries are neither accountable nor responsible for the QOS descriptions in service offers.

Some extension can be made for UDDI to register the service’s QoS description. However, even with the QoS descriptions registered on UDDI through extension, the QoS description may still be a bad prediction of the service’s real performance. This is mainly caused by the following reasons. Firstly, the published description could use false information just to attract potential clients. Through the development of trust mechanism and digital signatures, this problem may be solved. Secondly, the false prediction inherits from the architectural aspect of UDDI system. The most distinctive architectures of UDDI registry system contain centralized architecture and semicentralized model (the cloud model). Single public UDDI is a centralized architecture model. To this model, UDDI is a central point which mediates service publishing/discovering in the framework. All services are registered on it and can be accessed by all those potential requesters. Different service requesters have quite different connection conditions and routing paths. This difference leads to the requester’s different experiences of service QoS even when the service’s server side processing condition is not changed at all. The unique service QoS description in the central UDDI is therefore not a good prediction for requester’s reference. To the semi-centralized model (the cloud model), where there’s more than one UDDI registries, replication technology will be used to ensure consistent content in different registries. Service provider is required to publish the service descriptions to any one of the cloud nodes. After the replica, service requesters can discover the service from any one of the cloud nodes. Through replication, the service requester can choose the most suitable cloud node and this improves the inquiry speed. However, when the services continue to emerge and the cloud continues to grow, the total amount of service description in each registry increases quickly and will affect the registry’s scalability. Furthermore, the replication may still suffer from the incorrect QoS description that occurs in the centralized model. Replication of the QoS description will still remain a problem, as the correct prediction is not possible since the requester’s network condition is very likely to be different from the replicated registry.