12.4 Services Discovery


The Universal Description Discovery and Integration (UDDI) specification described in Chapter 10 provides the way to advertise and discover web services; however, it doesn't support all possible patterns of discovery. It's often compared with Yellow Pages, but people don't always use the Yellow Pages to find services they need: they may already know about the service existence, but don't know the details; they may get the new service from the service provider they already use; or they get referral from people they know. While it's possible to implement these patterns using UDDI, it isn't the best tool for the job. The Web Services Inspection Language was proposed to fill the niche.

12.4.1 Web Services Inspection Language (WS-Inspection or WSIL)

The Web Services Inspection Language specification can be found at:

http://www.ibm.com/developerworks/ webservices /library/ws-wsilspec.html

Released by IBM and Microsoft, it consolidates concepts that can be found in ADS and DISCO specifications. It also provides an XML format for specifying rules for aggregating references to existing services and assisting in the inspection for available services.

The structure of WS-Inspection document is succinctly simple. The inspection element is the root element of the document and contains only three types of elements: zero or more abstract , zero or more service , and zero or more link elements. The abstract element can be used for documentary purposes to provide a location for small textual description of the service. The service element can provide links to service descriptions and may have zero or more abstract elements (try to guess what those are for) and zero or more name elements. It must have at least one description element. The link element can provide a link to other inspection documents and related aggregation information sources. The name element can associate a name with the service and is intended only for human consumption. The structure of a simple WS-Inspection document is shown in the Example 12-2.

Example 12-2. A simple WS-Inspection document
 <?xml version="1.0"?> <inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">   <abstract>O'Reilly book service </abstract>   <service>     <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/"                  location="http://oreilly.com/books.wsdl"/>   </service>   <service>     <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/"                  location="http://oreilly.com/authors.wsdl "/>   </service>   <link referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/"         location="http://oreilly.com/partners.wsil"/> </inspection> 

The description element provides the most useful information in the inspection document. It provides pointers to service description documents of various formats (all of which may describe the same service), allowing consumers to pick one they find most useful. The referencedNamespace attribute identifies the namespace to which the referenced document belongs, thus unambiguously describing the type of the service description. The optional location attribute may point to the actual reference of the description. The location attribute is optional because the description element may contain the extensibility element that provides all necessary location information, in which case the location attribute isn't needed.

The WS-Inspection specification defines WSDL and UDDI bindings that provide additional information about a described service. For example, a WSDL binding may provide hints about the presence of endpoint information in a WSDL document ( <reference endpointPresent="false"/> ), and the UDDI binding may provide references to UDDI businessEntity or businessService entries. Developing additional bindings is also covered by the specification.

Inspection documents will be of low value if there is no easy way to locate and access these documents. The WS-Inspection specification describes several ways to discover a WS-Inspection document. First, the inspection document may be discovered by traversing other inspection documents and following links provided in link elements. Second, an inspection document may be stored in an inspection.wsil file and placed where the most common entry points to web sites or applications are located. Third, the inspection document can be linked from within HTML documents using a META tag:

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML>   <HEAD>     <META name="serviceInspection" content="localservices.wsil">     <META name="serviceInspection" content="http://www.oreilly.com/services.wsil">   </HEAD>   <BODY>...</BODY> </HTML> 

Be warned that wide open exposing of the services and service descriptions may pose a security risk. Also, because the specification permits inspection documents in different locations, it may be wise to separate descriptions for public and private services and protect not only the service itself, but also a service description, for example, using basic authentication for HTTP protocol.

UDDI and WS-Inspection specifications should be viewed as complimentary technologies that support each other and can be used separately or together depending on the situation. For example, search engines may access links to WS-Inspection descriptions linked via META elements in HTML documents, and store retrieved information in a UDDI repository. Alternatively, the UDDI repository can be discovered through the links in WS-Inspection documents.



Programming Web Services with Perl
Programming Web Services with Perl
ISBN: 0596002068
EAN: 2147483647
Year: 2000
Pages: 123

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net