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


AddThis Social Bookmark Button

An Introduction to WSIL

by Timothy Appnel

The Web Service Inspection Language (WSIL) is an XML document format to facilitate the discovery and aggregation of Web service descriptions in a simple and extensible fashion. While similar in scope to the Universal Description Discovery and Integration (UDDI) specification, WSIL is a complementary, rather than a competitive, model to service discovery.

Since its release, UDDI has been widely criticized for its implementation, and its relevance questioned repeatedly at this stage of Web services architecture development. Created by a group of IBM and Microsoft engineers and released in November 2001, WSIL is significant because of its simpler document-based approach, which is more lightweight and straightforward and better leverages existing Web architectures. This approach could lead to this specification's rise to prominence.

In this article, I will cover the core elements of the WSIL specification, including how WSIL inspection documents are located. Additionally, I will take a cursory look at the specification's extensibility with service descriptions such as WSDL, and point out some problematic issues in the specification. First, let's return to the complementary and contrasting approaches UDDI and WSIL employ in service discovery.

WSIL and UDDI: Same Space, Different Models.

WSIL and UDDI assist in the publishing and discovery of services, but their models are distinctly different. In this section, we'll go a bit deeper into these differences.

Related Reading

Java Web Services
By David A. Chappell, Tyler Jewell

UDDI implements service discovery using a centralized model of one or more repositories containing information on multiple business entities and the services they provide. You could compare UDDI to the Yellow Pages in your phone book, where multiple businesses are grouped and listed with a description of the goods or services they offer and how to contact them. The specification provides a high level of functionality through Simple Object Access Protocol (SOAP) by requiring specifically an infrastructure to be deployed with substantial overhead and costs associated to its use.

WSIL approaches service discovery in a decentralized fashion, where service description information can be distributed to any location using a simple extensible XML document format. Unlike UDDI, it does not concern itself with business entity information, nor does it specify a particular service description format. WSIL works under the assumption that you are already familiar with the service provider, and relies on other service description mechanisms such as the Web Services Description Language (WSDL).

WSIL documents are located using a few simple conventions using existing Web infrastructure. In many ways, WSIL is like a business card -- it represents a specific entity, its services, and contact info, and is typically delivered directly by whom it represents. The low functionality and lightweight nature of WSIL leaves the processing for the developer to implement. WSIL begins to break down and become too unwieldy to search or manage if a given document grows too large, or a collection of documents aggregates too deep. Eventually, development effort will diminish as WSIL toolkits are developed, like the one found in the Apache Software Foundation's Axis project [1].The low functionality of a simple XML document format also provides the flexibility for novel and innovative applications of this information to be easily created.

As you can see, while UDDI and WSIL are both mechanisms for Web services discovery, their models are quite different. Deciding which you should use depends on your situation. In many cases, it may be advantageous to use both. As you will see, WSIL can be used to "point" to UDDI repositories and the service descriptions therein.

The WSIL model is more RESTful than UDDI. In many ways, WSIL is like RDF Site Summary (RSS) for Web services. RSS is a file format with pointers to published content that can be syndicated and aggregated. WSIL is a file format with references to published Web services that can be discovered and bound.

WSIL Basics

The WSIL specification was designed to provide a means of service discovery that is simple, lightweight, and extensible. Furthermore, WSIL was designed so information could be easily authored, published, and maintained. The core WSIL specification elements consist of six tags. In this section I will review the basic WSIL document structure syntax before examining how, through the use of XML namespaces, WSIL can be extended to support additional infosets that some service descriptions and aggregations require for the discovery process. For more in-depth information about WSIL, read the WSIL 1.0 specification .

Example 1: A Simple WSIL File Example

<?xml version="1.0" encoding="UTF-8"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
   <abstract>Acme Industries Public Web Services</abstract>
      <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/"
   <link referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/" 
         location="http://example.org/services/ecommerce.wsil" >
      <abstract>Acme Industries Public e-Commerce Services</abstract>

At the root of all WSIL documents is the inspection tag. This tag contains the namespace declarations for the document, in addition to all other service information and references tags. Since this is a relatively simple WSIL document, only the WSIL namespace is defined.

The abstract tag is an optional tag that can be inserted into any tagset that allows for children to provide a text description to document its parent. Here we provide a short text description ("Acme Industries Public Web Service") for the inspection file. Later in our files, we also use the abstract tag to provide some documentation on our service and the link to another inspection document. If the description had been written in a specific language, I could have optionally defined a xml:lang attribute, like in the XML 1.0 specification.

In this simple example, we are defining a reference to just one service description, such as a WSDL file, beginning with the service tagset. name, like the abstract tag, is an optional tag that allows authors to document the enclosing service with a descriptive name, such as "Store Finder Service." This name is for documentation purposes only and does not necessarily have to be unique. Also, like the abstract tag, name allows an optional xml.lang attribute to be defined in specifying the language used.

The description tagset is the workhorse of the service block, as it contains all of the information necessary to discover a specific service description. In our example, we are only referencing a WSDL file that defines a single service description, requiring no additional information for a consumer to retrieve. The description tag uses a required attribute of referencedNamespace to indicate the namespace of the service description. This namespace reference can be used in determining the relevance of the reference and whether to retrieve the service description at the end of the reference. The description also uses an optional location attribute to define a direct reference to the service's description. This mechanism is sufficient for our simple reference; however, WSIL's extensibility can be utilized to insert additional information into the description tagset for the consumer to retrieve the service description. A service block can have multiple description tags to provide consumers different service description options. For instance a service could define references to a WSDL file, a UDDI repository entry, and an HTML document.

Besides references to service descriptions, WSIL supports links to other aggregations of service pointers, such as another WSIL file or a UDDI repository. This is facilitated by the link tagset. Like the service block's description tag, the link tagset implements referencedNamespace and location in the same manner. Similarly, it can contain extended WSIL elements in enabling consumers to connect to this aggregation. In our example, we link to another WSIL document, presumably with service descriptions of Acme Industries e-commerce services.

Pages: 1, 2

Next Pagearrow