Peter FARKAS
Dr. Hassan CHARAF, Ph.D.
e-mail: pfarkas@avalon.aut.bme.hu |
Keywords: Web Services, QoS, Capacity, Transactions
Abstract
With the widespread proliferation of Web services, quality of service will become a significant factor in distinguishing the success of service providers. QoS determines the service usability and utility, both of which influence the popularity of the service. Delivering QoS on the Internet is a critical and significant challenge because of its dynamic and unpredictable nature, thus applications with very different characteristics and requirements compete for scarce network resources. As most of the Web services are built on standards, QoS will become a differentiating point of these services. QoS covers a bunch of techniques that might be requested from the service provider by the service requestor.
If we want to develop a distributed application using web services we confront many problems. First, which components should I choose? The best practice was: choose one and use it. But if our application is a mission-critical one, it is not the way we proceed. How can we determine whether this web service is reliable or not? Provides security options and transaction handling? The answer is: we do not know.
One request to the UDDI database gives us hundreds of URLs that fill the query we had given. But there is no time stepping over those WSDL documents one-by-one to select the QoS-enabled web service that suits. So, we need something that we can use not only at design time, but in runtime as well. This "new application" must handle the UDDI requests and filter the response given from the database to choose only from a couple locators.
The goal of this project was to handling those web service discovery requests, which need special treatments. The basic concept is that we use the functionality of a newly designed abstract layer, which is between the UDDI registry and the new application.
The service requestor requests the establishment of the binding by specifying the reference to a Web service interface. This request also contains the required QoS. After sending our request to the QoS broker, it searches for the service providers in the UDDI. The Web service QoS broker compares the offered QoS with the required QoS and uses its internal information to determine an agreed QoS. If the QoS negotiation has been successful, the service requestor and service provider are informed that a
negotiation has been successful and a binding has been built. From this moment on these objects can interact through the binding.
We want to show the web services capacity planning concepts from the beginning to the end. Also included the schema we developed.