Quick Review:Ajax
Understanding quality of service for Web services Improving the performance of your Web services

QoS negotiation & binding establishment

The following steps should be performed during binding establishment using a QoS-enabled Web
services platform:

  1. 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.
  2. The QoS broker searches for the service providers in the UDDI.
  3. The QoS broker performs QoS negotiation as described below.
  4. 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.
  5. 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 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

 June 2008 | Java Jazz Up | 41
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,

, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51,   Download PDF