 | |||
|
Wednesday January 16 2002 WSIL: Do we need another Web Services Specification? Explaining the difference between UDDI The Universal Description, Discovery, and Integration (UDDI) specification started out with and still has very noble intentions. The promise of UDDI is simple: to provide a place where service creators can publish their services and service consumers can search for and ultimately integrate with services for consumption. But let's face it; UDDI is not really fulfilling its promise. In fact, preliminary results from independent research and tests conducted by SalCentral (see Resources) makes it pretty obvious that UDDI has yet a long way to go. The truth is that there still exists a chasm between service providers and service consumers. That's exactly where the Web Services Inspection Language (WSIL) fits in. WSIL promises to help us cross this chasm while UDDI registries get their act together. WSIL was announced by IBM and Microsoft in November of 2001. As I will show you in this article, WSIL is complementary to UDDI. Better yet, this is also another example of how Microsoft and IBM continue to pave the Web Services road ahead. In this article, I will attempt to explain what WSIL is and why it is not just another specification. The Million Dollar Question If the existing UDDI, SOAP, and WSDL specifications (from IBM and Microsoft) already cover all aspects of the basic Web Service architecture, do we really need another Web Services related specification (also from IBM and Microsoft)? A very good question indeed and in the remainder of this article I will attempt to answer it. The Problem with UDDI Although from a distance all seems well in Web Services land, the truth is there are still many glitches that need to be overcome. A few such glitches have to do with the current state of UDDI registries. As mentioned in the leading paragraph of this article, UDDI started out with and still has the noble intention of providing a directory service for service providers and service subscribers. UDDI compliant registries serve as central hubs where service providers and service requestors come together and satisfy their needs. There is no doubt that the concept of service registries is at the center of today's Web Services architecture. There are, however, two critical flaws in the UDDI business model that prevents it from taking off (at least today) the way it was intended:
Most business partners today do not find one another from UDDI registries; rather they are based on existing relationships. The above two shortcomings further justify why businesses choose to do so. That is where the Web Services Inspection Language (WSIL, also WS-Inspection) fits in. WSIL decentralizes the centralized model of service publication within a UDDI registry and distributes the pieces such that each service provider itself can advertise its Web Services offerings. WSIL thus facilitates the behavior that most businesses desiring to use Web Services (today) are most comfortable with (today). What is Web Services Inspection Language? The gist of the WS-Inspection specification can be summarized as follows: "WSIL defines how a service requestor can discover an XML Web Service description on a Web server, enabling such requestors to easily browse Web servers for XML Web Services." Thus, using WSIL, a service provider can make services available for discovery and use by service requestors. This is very similar to UDDI's mission statement and should come as no surprise since WSIL is meant to be the stepping-stone to UDDI (more on this later). The following diagram shows the modified relationship between the service requestor, provider, and centralized UDDI registry when WSIL gets added to the mix. The primary difference from earlier is that the Web Service "find" no longer goes directly to a centralized UDDI registry. Instead, the "find" is sent directly to the service providers from the requestors. Thus the centralized, un-moderated registry is now a decentralized, moderated registry distributed over the web. Also note that there is nothing preventing the service providers from registering their service offerings in a UDDI registry and redirecting a service "find" to that UDDI registry as shown in the figure.
An XML based Language allowing publishers to advertise their services WSIL defines an XML based language by which services can be advertised to interested requestors. Note that this is not a language to describe the capabilities of the Web Services themselves; that part is covered by WSDL. The WSIL language is only used to advertise the Web Services. The elements for this language are defined in the schema namespace http://schemas.xmlsoap.org/ws/2001/10/inspection/, which must be referenced by all WSIL documents. The simplest WSIL document consists of a service element, which contains a description element. All WSIL documents must have a root element called service, which wraps the service advertisements. WSIL documents are not restricted to just advertising or listing Web Services that are described using WSDL. Rather, the WSIL specification is designed to be extensible with other definition types. In fact, even the WSDL support in WSIL is achieved through the use of these extensibility elements. The only difference here is that the WSDL extensions are pre-built. WSIL also comes with pre-built support for UDDI. I'll cover this in more detail in the section on UDDI interoperability. A set of conventions allowing service requestors to locate WSIL documents One could advertise Web Services using WSIL documents all day long and it would be of little value if there were no standard way of finding these documents. That is why the WSIL specification defines a set of conventions allowing requestors to locate WSIL documents on any web site. These conventions are:
The fixed name for WS-Inspection documents is inspection.wsil. A document with this name should be placed at common entry points for a web site. For example, if the common entry point for a web site were http://www.aprovider.com/, then the location of the WSIL document would be http://www.aprovider.com/inspection.wsil. At the very least all service providers using WSIL should provide this top level WSIL document. It is reasonable to think that as WSIL is adopted more widely, established and forthcoming search engines such as Google and Yahoo! will enable searching for WSIL documents. In order to allow service providers to organize their service listings in a hierarchical manner, WSIL documents can be linked. This is achieved through the presence of a link element. All WSIL documents can have any number of such links, thus creating an entire hierarchy of WSIL documents. To put the usefulness of linking WSIL documents in perspective, consider a financial services company that offers a variety of related Web Services. These Web Services could be grouped together in three categories, namely banking services, insurance-related services, and investment services. The insurance service category itself could be comprised of a variety of subcategories such as car insurance, home insurance, health insurance, life insurance, etc. In this scenario, the top level WSIL document (at the web site entry level) would not advertise any services itself. Instead, it would contain links to three other WSIL documents; one WSIL document each for banking, insurance-related, and investment services. The WSIL document at the insurance services level in turn would have multiple WSIL document links corresponding to the various categories of insurance services. Thus, WSIL allows a hierarchical layout of Web Services very similar to the hierarchical web page layout used by web designers or directory structure on your hard drive. UDDI Interoperability While it is true that UDDI still faces a few challenges to becoming a feasible Web Services repository solution, it is very likely that it will overcome these challenges in the future. WSIL recognizes this and does not intend to replace or compete with UDDI. In fact, WSIL is not only complementary to UDDI, but an excellent stepping-stone for businesses to become comfortable with UDDI. This is because as mentioned earlier, WSIL has pre-built support for working with UDDI. In such a case, the WSIL document provides a reference to an entry in a UDDI registry via the serviceDescription element in the http://schemas.xmlsoap.org/ws/2001/10/inspection/uddi namespace. This element has a location attribute, which specifies the location URL of the UDDI registry, and has a child element, serviceKey (also in the same namespace), which specifies the UDDI key for locating the service within the registry. If the service has been properly registered with the UDDI registry, then the same WSDL document should be available from the service entry in the UDDI registry as was available from the service provider in the WSIL document. Note that the UDDI registry referenced by the location attribute could be one of the Public UDDI registries, run by IBM or Microsoft. Linking WSIL and UDDI Initially, service providers can advertise services and their associated descriptions directly from their web site. Gradually, though, they will be able to migrate the service descriptions to UDDI registries as they become more mature. Conclusion Currently, despite UDDI, there exists a chasm between service providers and service requestors. WSIL is a specification proposed by IBM and Microsoft to help cross this chasm today, while UDDI matures and becomes a feasible solution for tomorrow. Although WSIL is still a proprietary specification, both IBM and Microsoft have announced their intentions of submitting the WSIL specification to a standards body. I would speculate that this body will probably be the World Wide Web Consortium (W3C) since that is also where SOAP and WSDL were submitted.
Keep up to date with all the new articles and features on
Web Services Architect: |
