QoS negotiation & binding establishment
The following steps should be performed during binding establishment using a QoS-enabled Web
services platform:
- 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.
- The QoS broker searches for the service providers in the UDDI.
- The QoS broker performs QoS negotiation as described below.
- The Web service QoS broker compares the offered QoS with the required QoS and uses its
internal information to determine an agreed QoS. This process is called QoS negotiation.
- 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.
Bottlenecks in performance of Web services
Web services can encounter performance bottlenecks due to the limitations of the underlying
messaging and transport protocols. The reliance on common widely accepted protocols such as
HTTP and SOAP, however, make them a permanent burden that must be shouldered. Thus it is
important to understand the workings of these limitations.
HTTP
HTTP is a best-effort delivery service. It is a stateless data-forwarding mechanism which tends to
create two major problems:
- There is no guarantee of packets being delivered to the destination.
- There is no guarantee of the order of the arriving packets.
If there is no bandwidth available, the packets are simply discarded. Bandwidth is clearly a bottleneck,
as users and amounts of data running over the network increase. Traditionally, many applications
assume zero latency and infinite bandwidth. Also traditionally, applications use synchronous
messaging. Synchronous messaging is fine when you run an application on your own computers;
components communicate with latencies measured in microseconds. However, with Web services,
they communicate across the Internet, which means latencies are measured in tens, hundreds, or
even thousands of milliseconds.
Although newly designed protocols like Reliable HTTP (HTTPR), Blocks Extensible Exchange Protocol
(BEEP), and Direct Internet Message Encapsulation (DIME) can be used, widespread adoption of
these new protocols for Web service transport like HTTPR and BEEP will take some time. Hence,
application designers making use of Web services should understand performance issues of Web
service such as latency, and availability while designing their systems. Some of the ways to improve
Web service performance are given below.
Use of asynchronous message queues
Applications which rely on remote Web services can use message queuing to improve reliability, but
at the cost of response time. Applications and Web services within an enterprise can use message
queuing like Java Messaging Service (JMS) or IBM MQSeries for Web Service invocations. Enterprise
messaging provides a reliable, flexible service for the asynchronous exchange of critical data |
