In previous issues of .NET UPDATE, we've looked at the XML Global Services address routing and security concerns that aren't covered in the core XML Web Services of Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). The global services we've examined to date are extensions of SOAP, the protocol that .NET nodes use to communicate with one another. Web Services Inspection Language, the WS-Inspection protocol, extends WSDL—a protocol that specifies how to describe published services and data to be transmitted—and UDDI, which helps humans and applications find the XML services they need.
Just as the other Global XML Web Services don't supplant SOAP, WS-Inspection doesn't supplant WSDL or UDDI; rather, it uses their capabilities to create more comprehensive service listings. WS-Inspection documents can provide, independently of format, pointers to other resource documents. Just as Web Services Routing Protocol (WS-Routing) makes SOAP message transfers independent of HTML or SMTP by providing some of the routing information that SOAP messages typically rely on those application-layer protocols to provide, WS-Inspection makes service searches less dependent on UDDI by providing a list of services that are available through the use of any number of formats. WS-Inspection isn't a replacement for UDDI. Not only can WS-Inspection documents list UDDI-published services, but in some situations (I'll explain more about this later in the article) UDDI is the better search tool. Rather, WS-Inspection is an alternative and possible way of widening the field of available services.
After WS-Inspection makes the lists, service providers and servers that don't provide particular services but know about them can make WS-Inspection lists available to applications looking for those services. A WS-Inspection list includes a link to the WS-Inspection document and can contain the discovered services' abstract description, as well as links to the description reference, service description, and the service key. In short, a WS-Inspection list is a collection of links to available services. Because the information a list contains might be presented in a variety of formats, not all the information will be useful to every application that reads the document looking for service information. However, storing service information in this way means a service provider need maintain only a single service-list document. The catch, of course, is that this document is not a complete list of every available service—only of the services that the server is hosting or knows about.
Basically, WS-Inspection and UDDI offer alternative methods of searching for services. If an application knows the kind of service it needs but doesn't know of a server that might offer that service, the specification suggests that UDDI's Yellow Pages approach, which allows applications to search for services based on description, would be useful. Of course, such a search will turn up only services published with UDDI. Using WS-Inspection documents, in contrast, seems to be a more efficient search method for applications that need to be format-agnostic about the way the services they use are presented (e.g., the applications can use both HTTP-published WSDL documents and UDDI-published services) but that also know where to start looking. If an application doesn't know which server might have the services it needs, then finding the WS-Inspection document listing the services it needs could be difficult.
To learn more about WS-Inspection, read the following Microsoft specification articles.
"WS-Inspection Specification Index" "Web Services Inspection Language (WS-Inspection) 1.0"