"The WS-Inspection specification provides an XML format for assisting in the inspection of a site for available services and a set of rules for how inspection related information should be made available for consumption. A WS-Inspection document provides a means for aggregating references to pre-existing service description documents which have been authored in any number of formats. These inspection documents are then made available at the point-of-offering for the service as well as through references which may be placed within a content medium such as HTML." [Specification v1 Abstract]

From the Introduction:

Specifications have been proposed to describe Web Services at different levels and from various perspectives. It is the goal of the proposed Web Services Description Language (WSDL)to describe services at a functional level. The Universal Description, Discovery, and Integration (UDDI) schema aims at providing a more business-centric perspective. What has not yet been provided by these proposed standards is the ability to tie together, at the point of offering for a service, these various sources of information in a manner which is both simple to create and use. the WS-Inspection specification addresses this need by defining an XML grammar which facilitates the aggregation of references to different types of service description documents, and then provides a well defined pattern of usage for instances of this grammar. By doing this, the WS-Inspection specification provides a means by which to inspect sites for service offerings.

Repositories already exist where descriptive information about Web services has been gathered together. The WS-Inspection specification provides mechanisms with which these existing repositories can be referenced and utilized, so that the information contained in them need not be duplicated if such a duplication is not desired.

Principal References

• Web Services Inspection Language (WS-Inspection) 1.0. November 2001. From International Business Machines Corporation (IBM).
• "IBM and Microsoft Issue Specification and Software for Web Services Inspection Language."
• Apache AXIS supports WSIL.

Articles, Papers, News

• [October 29, 2002] "An Introduction to WSIL." By Timothy Appnel. From O'Reilly OnJava.com (October 16, 2002). "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. 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 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..."

• [October 14, 2002] "UDDI and WSIL for e-Science." By Rob Allan, Dharmesh Chohan, Xiao Dong Wang, Mark McKeown, John Colgrave, and Matthew Dovey. CLRC e-Science Centre and Distributed Computing Programme. "In this paper we describe how an private UK e-Science UDDI registry or Web Services Inspection document hosted by the Grid Support Centre might be used to register information about e-Science Virtual Organisations and to enable inter-working between them by exposing their contacts and service points. We propose using UDDI and WSIL to provide APIs for information about UK e-Science projects and also show how individual projects might use the same technology. Examples of the latter are the CLRC Integrated e-Science Environment project (IeSE) and EPSRC's MyGrid. These show how UDDI could be used within a single e-Science project for discovery of its own businessEntities and services by high-level components such as applications and portals. We believe that by providing interfaces to e-Science projects using (proposed) Web services standards, such as UDDI and WSIL, it will facilitate commercial uptake. A partly moderated top-level service will build confidence, allow for testing but still provide the capability to register with the worldwide Universal Business Registry via the publisherAssertion capability as projects become more mature and wish to expose their services to international partners. It nevertheless remains to be seen how the proposed services could be used to enable electronic contract negotiation via the so-called 'tModels'. Finally appendices describe UDDI and WSIL implementations and a proposed architecture for accessing Web services through a firewall using a proxy service. Implementations of this architecture will show if the performance is acceptable for a variety of purposes..."

• [September 18, 2002] "Grid Computing: Electrifying Web Services." By Dirk Hamstra. In Web Services Journal Volume 2, Issue 9 (September 2002), pages 60-64. "Grid computing makes it possible to dynamically share and coordinate dispersed, heterogeneous computing resources. Flexibility and ubiquity are essential characteristics of Web services technologies such as WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol), and UDDI (Universal Description, Discovery, and Integration). The Open Grid Services Architecture (OGSA) combines technologies to unlock and exploit grid-attached resources. OGSA defines mechanisms to create, manage, and exchange information between Grid Services, a special type of Web service. The architecture uses WSDL extensively to describe the structure and behavior of a service. Service descriptions are located and discovered using Web Services Inspection Language (WSIL). By combining elements from grid computing and Web services technologies, OGSA establishes an extensible and interoperable design and development framework for Grid Services that includes details for service definition, discovery, and life-cycle management. Information systems are no longer just defined by what they can process, but also where they can connect to. For example, the growing demands for computing power in simulation and engineering design projects, is increasingly satisfied by 'on-demand' sharing of CPU cycles and disk space across distributed networks. The ultimate goal for these interconnected networks, or grids, is to make IT-power as commonplace and omnipresent as electricity... Grid computing can be described as the coordinated, transparent, and secure sharing of IT resources across geographically distributed sites based on accepted computing standards... From a technical perspective, OGSA is critical to streamlining and accelerating the creation and deployment of grid applications. The architecture unifies existing grid development approaches and is extensible from a technical perspective to incorporate future developments. However, to expand the reach of grid applications beyond the level of a single enterprise the OGSA needs to more thoroughly address issues concerning: (1) Use of WSDL extensions; (2) Definition and use of service ports; (3) Heterogeneous, end-to-end, security; (4) Grid Service manageability... The extensibility of WSDL has implications for interoperability with existing WSDL clients and servers. Full interoperability and accommodation of non-OGSA WSDL clients by grid servers will accelerate the adoption of the extensibility elements. This is important since the handling of extensions is spotty at best in most current toolkits..." See also: "Web Services Description Language (WSDL)."

• [August 28, 2002] "Ease service discovery with WSIL4J. Processing Web Services Inspection Language documents is a snap with this Java API." By Alfredo da Silva (Advisory Software Engineer, IBM Software Group). From IBM developerWorks, Web services. August 2002. ['Before you can make use of Web services on the network, you have to discover them and get information about them. Web Services Inspection Language (WSIL) eases this process somewhat. In this article, Alfredo da Silva presents a Java API that makes it even simpler. You'll take a look at code that processes WSIL documents and presents the information they contain in an easy-to-read tabular format. Once you've mastered this API, you'll be able to unleash its power in your own applications.'] "IBM's contribution of the WSIL4J API to the Apache Software Foundation simplifies the process of writing applications that need to perform service discovery. This article will introduce a sample application, the WSIL Loader, that unleashes the power of the WSIL4J API. By examining the WSIL Loader, you'll see how to write JSP/servlet code that takes as input a WSIL inspection document URL and displays a WSDL table based upon the contents of that WSIL document. The generated table has three columns, listing the names, abstracts, and locations of various discovered services. Each column is only displayed if the corresponding element in the loaded WSIL inspection document is present. The location column contains hyperlinks to the WSDL documents that were enclosed by the passed WSIL inspection document reference..."

• [June 25, 2002] "IBM to Sharpen Web Services Toolkit." By Ed Scannell. In InfoWorld (June 25, 2002). "IBM on Wednesday [2002-06-26] is expected to roll out a spruced-up version of its WebSphere Software Developer Toolkit for Web Services that contains a UDDI (Universal Description, Discovery, and Integration) repository, the latest APIs for XML, and a built-in database upon which developers can host applications and Web services. One aim of this latest version, which is a follow-up to IBM's first Web services toolkit just more than a year ago, is to hasten the adoption of Java-based Web services among developers in both the Windows and Linux communities... The new version weaves together both tools and core runtime infrastructure that most developers need to design, build, and test Java-based Web services, said Hebner. The resulting services can be deployed to any open Web services platform, he said... In related news IBM will announce on Wednesday that it is contributing two Web services technologies to the Apache Software Foundation in hopes of advancing the adoption of Web services in the open-source world. The first is called the WSIF (Web Services Invocation Framework), a technology for invoking services that are compliant with the WSDL (Web Services Description Language) across a number of different network protocols including SOAP (Simple Object Access Protocol), JMS, and RMI (Remote Methods and Invocation). The second is called the WSIL4J (Web Service Inspection Language for Java), which will allow Java programmers to both access and process Web Services Inspection Language documents on a Web site. Co-developed by IBM and Microsoft, the WS-Inspection specification defines how an application can examine a Web site for those Web services that are available. It is intended to be a complement to UDDI global directory technology by helping discover services on Web sites that are not listed in the UDDI registries... While he declined to say specifically when, Hebner said future versions of the Web services toolkit will integrate new Web services features and functions that support the WS-I's (Web Services Interoperability Organization's) upcoming reference profiles and scenarios. WSIF and WSIL4J have both been open-sourced through the Apache Software License." Both technologies can be downloaded; see WSIF. See: (1) "Universal Description, Discovery, and Integration (UDDI)"; (2) "IBM alphaWorks Releases Web Services Invocation Framework (WSIF)."

• [April 12, 2002] "IBM Beefs Up Web Services Toolkit." By Ed Scannell. In InfoWorld (April 12, 2002). "Wasting little time after Thrusday's announcement of a Web security specification it is co-developing with Microsoft and VeriSign, IBM on Friday said that it is adding two new security features into the 3.1 version of its Web Services Toolkit. The new additions include an implementation of the SOAP Security Token and the Digital Signature components of the newly announced WS-Security specification. The SOAP Security Token indicates what the name, identity, credentials, and capabilities are of a user sending a message. This sort of technology can be useful to Web services providers in those situations where they must support users with different authentication mechanisms, according to IBM officials. It also makes it possible for Web services providers to incorporate additional security features to Web services applications over time... The WS-Security specification is an effort to offer guidance to users hoping to build secure and more broadly interoperable Web services. Besides SOAP (Simple Object Access Protocol), the functions within Version 3.1 of the toolkit are based on WSDL, WS-Inspection, and UDDI (Universal Description, Discovery, and Integration). These functions can work with Windows XP, Windows 2000, and Linux..." See the news item: "IBM Web Services Toolkit Supports the WS-Security Specification."

• [November 02, 2001] "An Overview of the Web Services Inspection Language. Distributed Web Service Discovery Using WS-Inspection Documents." By Peter Brittenham (Web Services Architect, IBM Corporation). From IBM DeveloperWorks. November 2001. ['Service discovery defines a process for locating service providers and retrieving service description documents, and is a key component of the overall Web services model. Service discovery is a very broad concept, which means that it is unlikely to have one solution that addresses all of its requirements. The Universal Description, Discovery and Integration (UDDI) specification addresses a subset of the overall requirements by using a centralized service discovery model. This article will provide an overview of the Web Services Inspection Language (WS-Inspection), which is another related service discovery mechanism, but addresses a different subset of requirements using a distributed usage model. The WS-Inspection specification is designed around an XML-based model for building an aggregation of references to existing Web service descriptions, which are exposed using standard Web server technology.'] "The Web services architecture is based upon the interactions between three primary roles: service provider, service registry, and service requestor. These roles interact using publish, find, and bind operations. The service provider is the business that provides access to the Web service and publishes the service description in a service registry. The service requestor finds the service description in a service registry and uses the information in the description to bind to a service... The WS-Inspection specification does not define a service description language. WS-Inspection documents provide a method for aggregating different types of service descriptions. Within a WS-Inspection document, a single service can have more than one reference to a service description. For example, a single Web service might be described using both a WSDL file and within a UDDI registry. References to these two service descriptions should be put into a WS-Inspection document. If multiple references are available, it is beneficial to put all of them in the WS-Inspection document so that the document consumer can select the type of service description that they are capable of understanding and want to use..." See also (1) the Web Services Inspection Language (WS-Inspection) 1.0 Specification, and (2) the announcement: "Microsoft and IBM Unveil New XML Web Services Specification. Web Services Inspection Specification Defines an Additional Method for Discovering XML Web Services." Full references: see "IBM and Microsoft Issue Specification and Software for Web Services Inspection Language." [PDF, cache]

• [November 02, 2001] "The WS-Inspection and UDDI Relationship." By William A. Nagy (IBM) and Keith Ballinger (Microsoft). From IBM DeveloperWorks. November 2001. ['The Web Services Inspection Language (WS-Inspection) and the Universal, Description, Discovery, and Integration (UDDI) specification both address issues related to Web service discovery. Even so, they were designed with different goals in mind, and thus exhibit different characteristics which must be evaluated before an application of the technology can be made. This paper describes the Web services discovery space in terms of an analogy to personal information discovery and illustrates how the two specifications may be used jointly to address a variety of requirements.'] "In addition to the patterns which they support, discovery mechanisms may be characterized according to two other attributes: by the choice of the point of dissemination of information, and by the costs associated with the discovery process. During discovery, information may be extracted either directly from the source/originator of the information or from a third-party. Retrieving information directly from the source increases the likelihood of the information being accurate, while fetching it indirectly gives the opportunity to utilize additional services provided by the third-parties and doesn't require that the original source always be available or easily locatable. The costs associated with the discovery techniques also vary. Certain environments have a much higher cost associated with storing and presenting the information than do others. From the attributes listed above, a taxonomy can be constructed through which discovery techniques and their supporting mechanisms can be compared and contrasted. To summarize, discovery mechanisms can be categorized according to the following criteria: (1) Which discovery patterns are supported? Does the mechanism support only focused discovery patterns, only unfocused discovery patterns, or combination of both? If it is a combination, to what extent is each category of patterns supported? (2) Where is the point of dissemination? Is the information generally discovered directly from the source/originator or through a third-party? (3) What is the overhead associated with the discovery mechanism? Is there a basic cost associated with storing and presenting the information for discovery, and if so, how significant is it? Note: This is the cost to the information/infrastructure provider for supporting the discovery mechanism; the differences in the cost of consuming the information can be assumed to be negligible... Here we describe several mechanisms used for personal information discovery, and classify them according to the above taxonomy. We apply the same taxonomy to the Web services space, and describe where the UDDI and WS-Inspection mechanisms fit..." See: "IBM and Microsoft Issue Specification and Software for Web Services Inspection Language."