ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

An Introduction to WSIL
Pages: 1, 2

Locating WSIL Files

Once an inspection document has been created, a consumer needs to be able to find it. WSIL's decentralized document-based model would make locating these files difficult if it were not for a couple of simple conventions defined in the specification.



The first convention employs the use of a fixed filename of inspection.wsil located in common entry points. Consumers would only need to ping a URL such as http://example.org/inspection.wsil or http://examples.org/services/inspection.wsil to discover the file's existence for retrieval.

The second convention employs embedded references in other documents, such as HTML or other WSIL documents. WSIL advocates use of a meta tag in an HTML document that establishes a link to the inspection documentation location. This is similar in nature to the way stylesheets, RSS syndication files, and weblog channel rolls can be autodiscovered. (However, they make use of the HTML's link, which is the appropriate tag to use for this function.)

A Hypothetical Use of WSIL by Google

Let's suppose for a moment that Google launched its Web services API without the fanfare with which it was greeted. How would Google "advertise" the availability of their services, particularly to other Web-services-aware applications? How would a service consumer discover and bind to Google's services?

First, Google would start by creating a WSIL document. Example 2 is what their inspection document might look like. In keeping it simple, I'm assuming once again the WSDL file contains only one service description.

Example 2: A Hypothetical WSIL for Google

<?xml version="1.0" encoding="UTF-8"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
   <abstract>The Google Search API</abstract>
   <service>
      <abstract>Google Search</abstract>
      <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/" 
	           location="http://api.google.com/GoogleSearch.wsdl"/>
      <description referencedNamespace="http://www.w3.org/1999/xhtml" 
	           location="http://api.google.com/documentation/search.html"/>
  </service>
</inspection>

Note the two description tags in the service block. One points to a WSDL file, and the other to an a XHTML document, presumably with a description of the service. (This HTML document doesn't actually exist on Google's site, but it illustrates WSIL's ability to reference multiple, different service descriptions for different purposes.)

Once the inspection document has been created, Google could place it at http://www.google.com/inspection.wsil or perhaps http://api.google.com/inspection.wsil. Google could also embed the following HTML in its Web pages:

<meta name="serviceInspection" content="http://www.google.com/inspection.wsil" />

There is no cost to doing both. In fact, it's advantageous to do so, because it gives potential service consumers the option of locating the inspection document as they prefer.

WSIL Extensibility

The WSIL specification provides for a certain amount of extensibility through the use of XML namespaces. This extensible mechanism is important because it allows for the evolution of service descriptions and repositories without having to revise the base specification.

Currently, the WSIL specification defines extensions for WSDL and UDDI. Example 3 illustrates what an inspection file referencing a complex WSDL file or a UDDI repository might look like. In sticking to the basics, we won't go into the details of how these extensions are utilized.

Example 3: A Sample WSIL document With WSDL and UDDI Extensions

<?xml version="1.0" encoding="UTF-8"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
 xmlns:wsilwsdl="http://schemas.xmlsoap.org/ws/2001/10/inspection/wsdl/"
 xmlns:wsiluddi="http://schemas.xmlsoap.org/ws/2001/10/inspection/uddi/" >
  <abstract>Acme Industries Public Web Services</abstract>
  <service>
    <name>Store Finder Service</name>
      <abstract>A service to perform a geographical search of Acme 
	        store locations.</abstract>
      <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/" 
	        location="http://example.org/services/storefinder.wsdl">
       <wsilwsdl:reference>
         <wsilwsdl:referencedService 
		   xmlns:ns1="http://example.org/services/storefinder.wsdl">
		   ns1:StoreFinder<wsilwsdl:referencedService>  
       </wsilwsdl:reference>
      </description>
   </service>
   <link referencedNamespace="urn:uddi-org:api">
      <abstract>Acme Industries Public e-Commerce Services</abstract>
      <wsiluddi:businessDescription 
	        location="http://example.org/uddi/inquiryapi">
         <wsiluddi:businessKey>3C9CADD0-5C39-11D5-9FCF-BB3200333F79
		      </wsiluddi:businessKey>
         <wsiluddi:discoveryURL useType="businessEntity">
                   http://example.org/uddi?3C9CADD0-5C39-11D5-9FCF-BB3200333F79
         </wsiluddi:discoveryURL>
      </wsiluddi:businessDescription>
   </link>
</inspection>

In this example, unlike the previous examples, we make reference to a WSDL file that is presumed to have multiple service descriptions, of which we identify StoreFinder as the reference description. We also provide a link to a UDDI repository that contains the service descriptions for Acme Industries.

Simplicity begins to give way to extensibility, but the utility and adaptability provided makes it a reasonable tradeoff.

Other bindings for service description mechanisms are easily authored by following a few simple rules, which are documented in section 5.0 of the WSIL 1.0 specification.

XMethods, a directory of publicly-available Web services, is an earlier adopter of WSIL and has developed a binding extension for its service. A section of their WSIL file is listed in example 5.

Example 4: A subset of XMethods.net's WSIL File

<service>
    <abstract>Develop Your Own Applications Using Google</abstract>
    <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/"  
	    location="http://api.google.com/GoogleSearch.wsdl"/>
    <description referencedNamespace="http://www.xmethods.net/">
      <wsilxmethods:serviceDetailPage 
	    location="http://www.xmethods.net/ve2/ViewListing.po?serviceid=73855">
        <wsilxmethods:serviceID>73855</wsilxmethods:serviceID>
      </wsilxmethods:serviceDetailPage>
    </description>
 </service>

The extension defined by the wsilxmethods provides a URI of a dynamically-generated HTML page detailing the service. The extension also provides the service's XMethod ID separately, which could be helpful in utilizing other functionality of the XMethods directory.

A Good Start That Is Far From Perfect

Hopefully, at this point you now understand the advantages and utility of WSIL in Web service discovery, and are interested in putting it to use. IBM and Microsoft have done an admirable job in developing WSIL, but it does suffer from issues that are commonplace in the initial release of a specification that was developed by a closed select committee.

Here I will note some of these issues that I found in my review of the specification. It is by no means a complete and thorough list, but simply my personal observations from working with markup languages over the years.

  • The specification misuses the meta tag for embedding a link in a service provider's HTML. As I mentioned previously, CSS stylesheets, RSS syndication files, and weblog channel rolls facilitate autodiscovery through the link tag, which, unlike meta, was designed for such a use.

  • The specification could use more meta data tags, such as the name of the service owner or a support email address, to better document the service description. The versatile abstract and the service block's name tags are helpful, but may not be sufficient enough. Take XMethod's use of WSIL into consideration. The WSIL specification assumes the service provider is delivering an inspection document, which in not true in the XMethods case. In this case, additional meta information would be helpful and warranted. Ideally, the meta data could also be extensible to allow the embedding of more granular forms of meta information for specific problem domains.

  • The tag semantics of the specification could use some refinement to keep the document smaller and more readable. For example, the referencedNamespace used by the description and link tags could have been represented as nsref. While referencedNamespace is syntactically more description, nsref is smaller and more consistent with the XML Namespace declaration (xmlns) and HTML hyperlink references (href). Another such instance is the location attribute, which defines a URI and could instead be represented as uri.

  • Another naming nit: index.* is the common convention for naming a document that is served by default when a specific document is not specified in an HTTP request. WSIL should follow this same convention and use index.wsil for fixed name discovery convention.

Conclusion

WSIL is a simple, lightweight mechanism for Web service discovery that complements, rather then competes with, UDDI. WSIL's model is a decentralized one that is document-based, and leverages the existing Web infrastructure already in place. While UDDI can be seen as a phone book, WSIL is more like a business card. Looking at it in another way, WSIL is like the RSS of Web services.

I find WSIL intriguing because of its simplicity and lightweight implementation. It's what the Web services space needs now. I would go so far as to argue that WSIL should have preceded UDDI as the solution we all need for services discovery, and is a logical stepping stone towards extensive Web services repository services for those who eventually require them.

As a low-function, lightweight specification that leaves the processing logic to the developer, I am equally as intrigued and enthusiastic about the potential for innovative and novel applications that will undoubtedly arise from the accessibility of this information. Who knows what our understanding of "service discovery" could be in a year or two?

Timothy Appnel has 13 years of corporate IT and Internet systems development experience and is the Principal of Appnel Internet Solutions, a technology consultancy specializing in Movable Type and TypePad systems.

[1] Axis contains the WSIL toolkit that IBM donated to the Apache Project. http://www.oreillynet.com/pub/wlg/2113



Return to ONJava.com.