• Some Web Services must be discoverable to be useful
– "business partner" services must be pre-arranged
• only the "current" endpoint is discoverable
– some services are localized (find a restaurant)
• discover them relative to your location
– analogous services may provide different quality of service
• discovery of replaceable multiple implementations
Discovering Web Services
• Web Service discovery mechanisms may include
– personal knowledge (arrange with a business partner)
– service brokers (XMethods)
– find services when you know the server
– replicated central directories of information (UDDI)
What are you discovering?
• Discoverables center around WSDL files that contain
– references to schemas used
– message exchange specifics
– references to definitions of "interfaces" and methods
– protocol details
– web service endpoints
Patterns of Discovery
• Three general patterns emerge
– Web Services offered by a given company
– who implements a given well-defined service?
– find services by category or taxonomy
Standardization of Discovery Mechanisms
• De facto standards are evolving for discovery
– UDDI - centralized searchable directory of services
– WS-Inspection - server-specific dynamic service list
– WS-Inspection is one of the GXA family of specs
• Disco was a Microsoft-specific precursor
• ADS was IBM-specific precursor
What is WS-Inspection?
• WS-Inspection exposes a list of information at a well-known
location on a per-server basis
– by convention, the endpoint is http://server/inspection.wsil
– list of info can be considered a web service business card
– similar to going to http://www.company.com and looking at the
table of contents
What's in a WSIL document?
• WSIL documents can contain pointers
– pointers can reference other WSIL docs
– pointers can reference UDDI company info
– vendor-specific pointers are permitted
WS-Inspection document (1)
<?xml version="1.0" encoding="utf-8"?>
<!-- link to another WS document -->
<abstract>A link to the Authors Service document</abstract>
<!-- link to UDDI -->
<!-- either one of the next two are OK -->
WS-Inspection document (2)
<?xml version="1.0" encoding="utf-8"?>
<!-- vanilla service element pointing at a WSDL location -->
<abstract>This is a test of the ASP.NET declarative attributes</abstract>
<abstract>This is a test of Xml Object serialization</abstract>
<abstract>This is a test of XmlSerializer with SOAP attributes</abstract>
WS-Inspection and DISCO
• DISCO and WS-Inspection overlap in functionality
– both document types may be dynamically generated
– both provide information and pointers
– WS-Inspection may contain DISCO pointers
– parts of WSIL files can be derived from corresponding DISCO
How does DISCO work in .NET?
– DiscoveryClientProtocol is the central class
• Download, Read and Write
– ResolveAll uses ADSI to scan the IIS metabase
public class DiscoveryClientProtocol
// these are for dynamic discovery
public DiscoveryDocument Discover(string url);
public DiscoveryDocument DiscoverAny(string url);
public void ResolveAll();
public void ResolveOneLevel();
// these are used in DISCO.exe
public Stream Download(ref string url);
public Stream Download(ref string url,
ref string contentType);
public DiscoveryClientResultCollection ReadAll(
public DiscoveryClientResultCollection WriteAll(
What else is in a WSIL document?
• WSIL documents can contain descriptions
– Information consists of web service description and WSDL
– Protocol specific information extensions exist for
– Vendor-specific information can be added
Comparing DISCO and WSIL
Pointers to other WSIL
Pointers to other Pointers to other
Disco files discovery files
Web Service documentation Pointers to UDDI business
WSDL endpoint information WSDL endpoint information
Referenced XSD endpoints WSDL extended information
UDDI Web Service
Implementation of Discovery in .NET
• DISCO can get Web Service information
– using ASP.NET HttpHandler mapped to .vsdisco files
– using DISCO.exe command line utility
DISCO implementation utilities
<!-- Note: this is commented out in V1.0 machine.config -->
<add verb="*" path="*.vsdisco"
System.Web.Services, Version=1.0.3300.0, Culture=neutral,
<!-- .... -->
-- start with Default.vsdisco
-- put files in c:\temp
>disco http://localhost/Default.vsdisco /out:c:\temp
An implementation of WSIL
• You can produce a WSIL document from DISCO info
– invoke dynamic DISCO using DiscoveryClientProtocol class
– transpose WSDL information retrieved to WSIL elements
– this can be exposed through an ASP.NET HttpHandler class
• You can use WSIL information in a variety of ways
– most commonly obtain WSDL documents (Add Reference)
– get business info through UDDI reference extensions
– get WSDL documents through UDDI
• get service info
• get tModels from service info
• tModels can contain refs to WSDL documents
WSIL document generation
<add verb="*" path="inspection.wsil"
<!-- .... -->
• UDDI defines how to interact with a rich Web service
– UDDI jointly developed by Microsoft, IBM, and Ariba
– UDDI itself is SOAP-based Web service
– UDDI specification consists of programmer's API (SOAP
requests/responses) and operator's site APIs
• An "operator site" implements the UDDI specification
– can be a public or private site
– public operator sites replicate information (like DNS)
– replication specifications are part of UDDI 2.0
– Microsoft, IBM, and others all have operating sites available
UDDI Information Items
• UDDI registry consists of four main types of information
– business information consists of name, contact info, services
– service information provides business/technical descriptions of
– binding template defines how to connect to and communicate
– tModel provides a technical fingerprint for interfaces/behavior
(or anything else)
– v2.0 adds publisher assertions
• used for companies that are related, but separate
Name Retail URL
Address Health WSDL
Contact Finance tModel
.... ... ...
Relationships among UDDI items
• Most UDDI data items are hierarchically related
– businessEntity is parent of businessService (1-many)
– businessService is parent of bindingTemplate
– tModels are references not hierarchical
– publisherAssertions relate two businessEntities
UDDI Information Items
UDDI Programmer's API
• The UDDI Programmer's API is divided into two groups of
operations: inquiry and publishing
– inquiry API retrieves information from registry
– inquiry API doesn't require authentication
– publishing API inserts/updates information in[to] registry
– publishing API does require authentication and encryption
UDDI Inquiry API
find_business Locates information about one or more businesses.
find_service Locates services within a registered businessEntity.
find_binding Locates bindings within a registered businessService.
find_tModel Locates one or more tModel information structures.
get_businessDetail Gets businessEntity information for one or more businesses.
get_businessDetailExt Gets extended businessEntity information.
get_serviceDetail Gets full details for a set of registered businessServices.
get_bindingDetail Gets bindingTemplate information for making service requests.
get_tModelDetail Gets details for a set of registered tModels.
UDDI Publishing API
get_authToken Requests an authentication token from an operator site.
get_registeredInfo Requests information currently managed by user.
save_business Registers/updates a businessEntity.
save_service Registers/updates a businessService.
save_binding Registers/updates a bindingTemplate.
save_tModel Registers/updates a tModel.
delete_business Deletes a businessEntity from registry.
delete_service Deletes a businessService from registry.
delete_binding Deletes a bindingTemplate from registry.
delete_tModel Deletes a tModel from registry.
discard_authToken Discards an existing authentication token.
Taxonomies, Identifiers and CategoryBags
• UDDI information includes classification information
– businessEntity contains:
• identifierBag - e.g. DUNS (these are tModels)
• categoryBag - e.g. SIC, Geo3166 (these are tModels)
– businessService contains categoryBag (can be tModels)
– bindingTemplate requires tModelKey
– tModels contain
• Identifiers and categories enable searching
– by known taxonomies (DUNS, Geo3166)
– by arbitrary user-defined classifications
• UDDI 2.0 contains specifications for known taxonomies
– defines validated and non-validated taxonomies
– taxonomy specs and placement details
– checked namespaces
• extension specs for categorization and identification
• instructions for site operators
– info on how to add a taxonomy
UDDI Support in .NET
• UDDI support in .NET includes clients and servers
– UDDI 1.0 server in .NET server
– UDDI 1.0 clients downloadable
• .NET client v1.75 for RTM
• UDDI 1.0 COM client
– UDDI 2.0 beta client available for .NET
• WS-Inspection and UDDI emerging as discovery methods
– WSIL is local machine, business card approach
• you know where the implementing server is
– UDDI is centralized service approach
• you know nothing but where the UDDI server is
– WSIL can be implemented in .NET over DISCO
– UDDI 1.0 and 2.0 .NET client libraries available
– UDDI 1.0 server available in .NET server