Back to Article List

Originally published December 2005 [ Publisher Link ]

WS-Inspection: Discovering Web services

Web services are generally described under the pillars of three basic terms -- SOAP, WSDL & UDDI -- which are used for the payload protocol, its binding mechanism and the discovery process, respectively. However, many useful and complementary standards have emerged to support these building blocks. One such technology is WS-Inspection, a service discovery mechanism used for Web services.

WS-Inspection takes a pragmatic approach to the Web services discovery process. To many, UDDI provides all the necessary provisions, and then some, for centralizing and publishing Web services characteristics for later discovery by third parties. Yet, if you have gone through this route, you will have realized that the extra overhead for deploying such a solution in small scale projects often proves hard to justify.

At the other end of the spectrum, Web services discovery may take place through a very austere process: In a text document with various URL's containing Web services locations or even verbally with an administrator or developer. While this layman's approach may prove functional, it is far off from the capabilities offered by UDDI.

WS-Inspection provides a middle-ground process for Web services discovery compared to the previous two approaches. Originally designed by Microsoft and IBM, the intent behind WS-Inspection is to provide a standard means for Web services publishers to distribute their Web services locations directly under the context a Web server.

WS-Inspection's, can be compared to that of another common approach in web bound technology, the robots.txt used on most web-sites. robots.txt is a standard approach by which a site publisher specifies instructions to web-crawlers/search-engines to proceed with content. Similarly, WS-Inspection's aim is to provide a standard way of indicating to web services consumers where to locate web services on a site.

Contrary to the UDDI approach, which generally requires making use of a relational database for storing credentials plus the additional configuration burden of another software suite. WS-Inspection simply requires that a document be built with Web Service Inspection Language (WSIL), containing Web services descriptions and locations, and it be deployed under a publicly accessible site.

While this approach is not rocket science and obviously lacks the robustness offered by UDDI, WS-Inspections is by no means a substitute for UDDI. Rather it complements UDDI. WS-Inspection is just used for specifying Web services location points and as such can contain references to the two most prevalent sources of Web services data, UDDI and WSDL. It also has provisions for any non-standard access points that may emerge in a project.

WSIL -- WS-Inspection's language -- is composed of a few XML elements that are used to describe Web services references related to WSDL locations, UDDI access points or even other WSIL files. Listing 1.1 illustrates a simple example using WSIL's syntax.

<?xml version="1.0"?> 
<inspection 
    xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
  <service>

    <description 
    referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
    location="http://ws.com/weatherservice.wsdl" />
  </service>
  <service>
    <description referencedNamespace="urn:uddi-org:api">
       <wsiluddi:serviceDescription   
           location="http://ws.com/uddi/inquiry">
         <wsiluddi:serviceKey>
           52946BB0-BC28-11D5-A432-0004AC49CC1E
        </wsiluddi:serviceKey>

       </wsiluddi:serviceDescription>
    </description>
  </service>
<link 
referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
location="http://ws.com/secondarysiteservices.wsil"/>
</inspection>

Notice that the <description> element is used for enclosing both UDDI and WSDL data while being nested inside the <service> tag. The <link> declaration on the other hand is used for specifying the location of other WSIL files.

In order to ease the localization of a WSIL files on a Web site, the specification also defines a mechanism through metadata tags which is illustrated in Listing 1.2.

<head>
<meta name="serviceInspection" 
         content="http://ws.com/siteservices.wsil"/>
</head>

This last snippet placed by a Web services provider on a well-known location such as a home page or root directory -- index.htm -- can allow consumers to determine with ease the WSIL described services available to them.

Once a WS-Inspection deployment goes live on a site, the next step is for Web services consumers to make use of this information. To this end, there are few toolkits which are capable of parsing WSIL files for extracting this data, one of the most common being: WSIL4J

Although WS-Inspection may seem like a nonsense approach it provides a common footing for publishing Web services locations through a standardized XML grammar that is backed by major vendors. It can offer your Web services consumers an easy way to locate your updated services, while leveraging another discovery technology like UDDI or avoiding it altogether.

Originally published December 2005 [ Publisher Link ]

Back to Article List