Motivation

One of the promises of Web services is that "equivalent" providers can be swapped without loss of functionality. Provider B may replace provider A if they implement the same interface. Naturally, we expect the semantic interpretation and operation to be constant across such providers.

But providers are not likely to be equivalent, especially in the non-functional sense. And once a provider is selected, a relationship will form, especially for business-critical services and those that require significant resource lock-down (for example, in peer-peer and grid computing). As in the physical world, whether it be physicians, auto mechanics, or telephone companies, one might develop a preference for a particular provider, a mode of interacting, and an approach for choosing a replacement.

Consider the issue of finding a new physician when relocating. A recommendation is sought, or a directory of providers is scanned for one who meets certain criteria (think UDDI). A visit is scheduled and the physician is "tried." In the mechanical world of Web services, a correct result (in this case, doctor provides correct diagnosis) satisfies the interaction. Of course, sometimes you'd like a second opinion, even for Web services -- more about that later.

Naturally, physicians are more than diagnosis engines; they are people with particular interaction skills, in particular environments, with varying availability, and so on. Perhaps it is a complex weighted sum of these other values that decide for you whether you accept this new physician, or continue your search. And should you become ill in the interim, you might even travel back to our prior, established physician.

That equivalent Web services are swappable is true by their (portType) definitions. What is not yet accounted for is how an enterprise will actually operate with that flexibility. An enterprise might begin by consulting a third-party that rates business entries in UDDI registries (a Web services Consumer Reports?). Once a provider is chosen, an enterprise might continue to use provider A while trying provider B, comparing results until satisfied that the providers are in fact (functionally) equivalent. But there are other factors; provider B might compute the result more quickly, or provider B might not always answer during peak periods, or provider B might compute to greater precision. Alternatively, provider B may require client payment for services and when those are not presented in a timely way, provider B might temporarily "black-list" that client or perhaps refuse any resource intensive requests.

At present there is no mechanism for qualifying or penalizing Web services. This article proposes two modes of qualifying Web services: statically for initial selection and then dynamically as part of the on-going provider/consumer relationship. A SOAP header to support qualification between clients and providers is also proposed.

Back to top

Static qualification

As described above, Web service selection is likely to become a significant process in itself. One obvious approach is to establish an independent service qualifier (that is, WS rating service) that exercises Web services pointed to by UDDI registries or WS-Inspection indexes. The publish/find/bind process then becomes publish/qualify/recommend/bind, as shown in Figure 1.

A less formal, more organic approach could use a rating system, based on the eBay model, where consumers feed back to an independent agent that accumulates scores over a set of (defacto) standard qualifying dimensions. In this scenario the accumulated average rating becomes the qualifying factor. The publish/find/bind process is extended to include qualification as shown in Figure 2, where the the qualifying agent recommends a service based on rating; the consumer then binds, uses, and finally offers its own rating for (that is, "qualifies") the service.

You can imagine the service qualifier or rating repository are themselves Web services, and document-style SOAP messages carry the dimensions of qualification in header blocks as agreed in a defacto or formal standard. The dimensions of qualification might include the following enumerated aspects of QoS (see Mani and Nagarajan), as would be specified in a Service Level Agreement (SLA).

• Availability
• Accessibility
• Integrity
• Performance
• Reliability

The SOAP header might look like Listing 1.

   <q:Envelope xmlns:q=...>
       <q:Header>
            <v:S-qualification xmlns:v=...>
                 <v:Availability value="9999" />
                 <v:Accessibility value="AsAdvertised" />
                 <v:Integrity value=... />
                 ...
            </v:S-qualification>
       </q:Header>
        ...
   </q:Envelope>

The qualifier values might be absolute values to be compared against those advertised (for example, in a UDDI business registry entry) or they might simply indicate whether the quality is consistent with that advertised.

To facilitate finding a replacement provider, the list of previously used (and now abandoned) providers could be carried in the SOAP message of the recommend or find interaction (a null list might indicate the first "lookup").

Back to top

Dynamic qualification

Once a Web service is selected, how do you maintain the relationship over the lifetime of its use? For commodity services, this may not be an issue. But for business-critical functions, abrupt abandonment for non-performance is untenable. As in human social interactions, Web service interactions include functional and non-functional aspects that must be integrated over time to maximize business performance.

For example, a financial firm is not likely to abandon an important service provider for an unexpected, short duration server outage. However, if outages were to become frequent the relationship would be strained and eventually a new provider would be selected. Similarly, an important customer is not likely to be abandoned for an occasional late payment. However, should accounts receivable increase, the service provider might shift that customer to a lower Quality of Service (QoS), or even refuse service requests that require significant resource lock-down until financial trust is re-established.

Dynamic qualification deals primarily with non-functional aspects of a Web service from both the provider and consumer points of view, including but not limited to those established in an SLA. As mentioned for static qualification, the dimensions of qualification are likely to be carried in the SOAP header blocks in the service interactions. For example, we might use a simple "thumbs up or down" rating system over the following qualifying dimensions (of course a more granular, enumerated rating system can be used)in Listing 2.

   <q:Envelope xmlns:q=...>
       <q:Header>
            <v:D-qualification xmlns:v=...>
                 <v:QoSasAgreed value="thumbs up"  />
                 <v:PaymentsInGoodStanding value="thumbs up" />
                 <v:LockedResoursesNotIdle value="thumbs down" />
                 ...
            </v:D-qualification>
       </q:Header>
        ...
   </q:Envelope>

Dynamic qualification has broad implications. One can imagine a service provider requiring management oversight to monitor the overall state of satisfaction with its services, and likewise service consumers will have to monitor the non-functional aspect of responses to provide continuous feedback. From an enterprise integration standpoint, this leads to the need for CRM, financial and SLA conformance monitoring systems to be tied into the applications that provide or consume the business-critical Web services. The computations required to evaluate the dimensions of qualification, and especially the mechanisms used to dynamically replace a provider or deny access to a consumer, are significant implementation issues for the interaction end-points (that is, not part of the SOAP message itself).

As in human social interaction, there will be an opportunity to "play games," which has a game theory response. For example, a service consumer may want maximum throughput but is only paying for basic service. His or her "play" is to always complain about QoS, and at first the service provider improves this dimension. Over time, this "play" is recognized and "thumbs down" becomes "no information." Tit-for-tat or the even better "tit-for-tat with forgiveness" are reliable responses to these sort of gambits.

Back to top

Conclusion

Static and dynamic qualification address Web service selection and the on-going relationship between service providers and consumers.

Dynamic qualification provides a non-abrupt interaction mode designed to resolve issues in non-functional performance in a quasi-autonomic fashion. Dynamic qualification augments the work being done in describing contracts and agreements for Web services, by providing a prediction and alerting mechanism.

Acknowledgements

Special thanks to Rawn Shah (rawn@us.ibm.com) and Veronika Megler (vmegler@us.ibm.com) for their insightful reviews and comments.

Resources

• A great primer on Web services is Programming Web Services with SOAP by Snell, Tidwell and Kulchenko (O'Reilly).
  
  
• For an introduction to Game Theory, see Game Theory by Morton Davis (Dover).
  
  
• An excellent, related article on specifying and using QoS in Web services is Understanding quality of service for Web services by Mani and Nagarajan.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Motivation
• Static qualification
• Dynamic qualification
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers