First-generation architecture

As presented in "Guarantee your Web Service with a SLA" (see Resources), the following shows the Web services architecture covered by a SLA. It is very simple.

This architecture works well with a Web service in which the service client (requestor) finds a service while a service provider publishes another service, and the service is binded to the provider. Only one arrow connects each service role to another.

This architecture is inadequate for today's increasingly complex world of Web services applications. It is becoming obsolete, particularly in Service-Oriented Architecture (SOA) for four reasons:

• Reason 1: The first-generation architecture primarily does not consider the need of a Web services application client to discover another Web service to complete the tasks of the originating Web services application. The time it takes to complete the tasks can be brief or long with no interruptions. The client does not receive an alert to confirm or verify that the discovery of a Web service was successful or not.
• Reason 2: The architecture assumes that the provider sends requests to publish all services with no problems, and that the broker publishes them with 100 percent accuracy and reliability. The provider does not need a notice from the broker on successful or unsuccessful completion of the service publication in a repository.
• Reason 3: It does not address the need for the client to receive a response from the provider on what to do next in integrating a Web service into a Web application. The integration might require that communication be either synchronous (like a client using the ATM machine to make a withdrawal) or asynchronous (like a long-running transaction involving an ordered item temporarily out of stock for several weeks).
• Reason 4: The architecture does not consider the SOA in which a Web services application competes with a non-Web services application for resources it needs to respond to a query or a request for a Web services application. It omits the possibility of interoperability issues and does not address the issues of integrating non-Web services into a Web services application.

Back to top

Second-generation architecture for Web services

To correct the deficiencies of the first-generation architecture, you must incorporate processes between the provider and client in the SOA into the mechanisms that trigger the provider and clients alerts from the broker and the communication. In doing this, you create a second-generation of the architecture that uses double arrows to connect one service role with another.

Let's arbitrarily divide both provider and client alerts into three types: confirmation, verification, and failure. The contents of each type vary from one event to another.

For instance, when the application client successfully discovers a Web services application, the broker sends an alert to confirm or verify the discovery success. If the client cannot find the service, the broker sends it another type of alert informing that the discovery attempt failed.

Upon the receipt of successful discovery, the client binds it with the provider. If the provider determines that the service requires additional Web services to complete the tasks of the originating Web services application, it communicates with the client regarding what to do next.

The application provider sends to the broker a request to publish a service. If the broker successfully publishes the service in its repository, it sends an alert to the provider to confirm the success. Otherwise, it sends an alert that its attempt to publish failed.

Back to top

SOA: The big picture

Web services applications are built upon platform-independent protocols -- SOAP, WSDL, UDDI, and HTTP. These protocols fulfill the requirements of a SOA that has been around longer than Web services. The SOA requires that a service be discoverable and have invokable interfaces to perform business processes.

In pre-Web services days, Web services applications were non-existent in SOA. Today, Web services applications are the major players in SOA. They supplement the enterprise application integration (EAI) applications consisting of non-Web services applications or components. Web services applications are competing with non-Web services applications for the resources they must have to respond to a query to discover, a request to publish and a request to bind.

SOA is primarily using Web services standards to support interoperability across enterprises given that the SOAP, WSDL and other interoperability issues have been resolved before the SLA-covered Web services application is launched into the production environment. This includes SLA Web services that expose SLA as a public service in a UDDI or another public registry. These Web services must address the rights and remedies (technical and monetary) on the performance impacts of resource competition on response times.

Similar to the logic of architecture for a Web services application, a SOA service client queries a directory service for a service. If the client finds the service, the directory service gets the service provider to invoke the service through a proxy. On the other hand, if the client cannot find the service, it might get an alert from the directory service indicating a failed search. Likewise, if the provider cannot publish a service in the directory, it might get an alert indicating a failed attempt.

Back to top

Sending failure alerts

Since all SLAs contain the steps that the provider must take to recover from various failure events, the communication and alert messages must include information on how long it took each service role to respond to various failure events, other than the fatal ones, and how long it look to recover automatically from a warning failure.

The instance of a failure event must be within the provider's control. The provider needs to determine the types of failure to be avoided and the rights and remedies it must enforce when a service guarantee fails at a certain level (for example, below 99.9% uptime availability). If it is beyond the provider's control, the developer along with the provider should spell it out as an exception in the SLA, such as hardware failure, telecommunication failure, software bugs and flaws, and even monitoring and measuring system failure.

Since explaining some failures can be very wordy it is a good idea for you to assist the provider in assigning a code -- either numerical (preferably in hex), alphabetical, or both -- to each message of actual or potential failure incident. When assigning weights to measured response times, you should arbitrarily divide the codes into three distinct categories: warning, severe, and fatal. If the business operations interrupt too often, the client would want the option to exercise the right to implement the SLA exit clause due to unsatisfactory resolutions for recurring problems.

Back to top

Measuring response times

One of the best ways to measure response times is to ask questions and answer them. After compiling the questions, you can prioritize them based on latency, throughput, and failover.

Latency is the amount of time that a packet of data takes to get from one point to another and then back in a round trip. Examples include:

• SQL latency at the database server
• Latency from Network A router to Network B application server
• Latency of dynamic alerts and binding
• Latency of dynamic application integration

Throughput is the volume of requests that the broker can serve in a given time. A failover test measures how well a failover solution for a Web services application is properly working. Developers must consider the tradeoffs between latency and throughput. Another measurement element to consider is how well the application is providing corrective actions for deadlock, hung process and time-out periods.

Asking questions

Here are some examples of questions you should ask when you attempt to improve the performance of Web services applications by modifying these applications or developing new ones:

• Is the Web services application taking too long to respond (for example, more than 10 seconds) to a client's query? Is it possible to send an alert to the end user when the Web service is not publishable or invokable?
• Is the Web services client taking too long to respond to communication initiated by the provider? Is the broker taking too long to initiate an alert that it failed to discover a service?
• Is the Web services broker taking too long to respond to a request for publishing a service? What about verifying or confirming the request after it has published or discovered the service?
• Is the Web services application competing with a non-Web services application in a SOA for resources it needs to process voluminous client or provider query requests?
• Is an increase in network traffic for Web services applications due to insufficient caching mechanisms?

To answer these questions, the criteria for measuring response time must be precise. Otherwise, the parties will not agree on what service or performance in various network scenarios the SLA is measuring and at what service level in a SOA.

Considering client's views

In one instance, a client might believe that an agreed service level measures three networks, each with different distributions of Web service applications and non-Web service applications at a given time, as follows:

Table 1. Scenario 1

In another instance, a client might believe that an agreed service level measures the same networks with the same distributions, but excludes non-Web service applications running in all three networks from response time measurements, as follows:

Table 2. Scenario 2

Added to the complexity of the problem are some Web services applications' calls for non-Web services applications to complete a series of tasks, but the client might believe these non-Web applications are excluded from the measurements. As shown in Figure 3, not all Web services applications depend on non-Web services applications

Table 3. Scenario 3

Testing and monitoring SLAs

Web services testing tools such as those provided by PushtoTest (see the Resources section below for a link) are not the only mechanism to act as a SLA monitor. You can set up exception conditions to monitor and check for the latency of Web services, throughputs, and caching mechanisms. These conditions must be listed as part of the agreed SLA.

Back to top

Conclusion

So far, I have explained the more advanced technical parameters of a SLA-covered second-generation Web services application. If you plan to offer a Web services application that interacts with non-Web services to your paying customers, they would want a SLA to make sure that they get the return on their investment that they expect.

I've also given question examples, some of which you could use to lay the groundwork to meet the customer's expectations on measuring latency and throughput. Answering them adequately will partly help to increase the chances that the customer will be satisfied with the agreed service levels in the SOA.

Otherwise, the client and provider must renegotiate the terms of the agreement, including the rights, remedies, and exceptions, to establish a level that satisfies the customers as a supplement to the EAI applications. For the developer, it is important to keep this mind during the process of integrating Web services applications with non-Web services and implementing them. You must consider the customer's business and technical expectations of how the resulting integration behaves in the SOA.

Resources

• Get information on how to use SLAs in a Web services context from the other papers in this series:
  • "Guarantee your Web service with a SLA" (developerWorks, April 2002)
  • "Integrate Web services into EAI with a SLA guarantee" (developerWorks, October 2004)
  • "Secure multiple Web services with a SLA guarantee" (developerWorks, November 2004)
  • "Firewall Web services with a SLA guarantee" (developerWorks, December 2004)
  • "Localize Web services with a SLA guarantee" (developerWorks, January 2005)
  • "Mitigate risk for vulnerability with a SLA guarantee" (developerWorks, January 2005)
  
  
  
• Learn more about PushtoTest to test and monitor Web services.
  
  
• Read Judith Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
  
  
• Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition.
  
  
• Publish your Web service or application in IBM's UDDI version 2 registry, which features a graphical user interface and conformant APIs for public use. IBM's UDDI version 3 beta registry is also available for testing.
  
  
• Explore and learn more about "Complex datatypes in SOAP-based Web services" when you build them from existing Java code (developerWorks, May 2001).
  
  
• Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• First-generation architecture
• Second-generation architecture for Web services
• SOA: The big picture
• Sending failure alerts
• Measuring response times
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers