The process of locating a provider is composed of three stages, first the requester has to compile a request for a provider and send it to the Registry. Second, the Registry has to match the request with advertisements it stored of Web Services available on the Web, third the requester selects the provider that more closely fits its needs.
The requester at this point knows that problem it expects the provider to solve, but has no idea of what providers are available to solve that problem. In order to find a provider it needs to be able to inquire the registry to locate Web Services with a given capability. The automatic compilation of a request requires an abstraction from the problem the requester faces to the capabilities the requester expects the provider to have in order to solve the problem. Crucially, the solution of the problem also requires an advertisement and query language that supports the representation of capabilities of Web services, so that the Registry receives capability information and processes it.
The task of the registry is to locate an advertisement that matches a request. The matching of the request and the advertisement should guarantee that the selected Web Service produces the effects that the requester expects. It is crucial to stress that the matching process should take into account that different parties with different perspectives may provide radically different descriptions of the same service. The matching process therefore should not be restricted to an exact match between the request and the provided advertisements, rather it should allow for degree of matching in which Web Services that provide a service similar to the one requested are selected, while Web Services that definitely do not provide the service are discarded. The result is a list of potential providers among which the requester has to select a provider.
The selection of the providers requires a type of registry that is outside the registries offered by the growing Web Services infrastructure, namely UDDI. UDDI stores a host of useful information about Web Services such as information about the organization that fielded the Web Service; binding information to allow Web Services to interact, and an unbounded set of properties, called TModels, that allow to attach any additional information to a Web Service. The problem of UDDI is that it does not have an explicit representation of what the Web Service does. Therefore, the search for a Web Service with a given capability becomes very difficult. As an example, to locate a Web Service that reports weather information within the US, a requester may look for all the Web Services that contain a TModel associated with a classification of services such as NAICS [18] which are specified as weather providers, and all the Web Services descriptions that contain a TModel that associate the Web Service with the US, and then look in the intersection of the results of the two searches. The problem of course is that this type of search cannot distinguish between weather services that provide information about the US, from US based weather services that may provide information about the weather in other countries. Overall, because UDDI misses any form of capability representation and capability matching, it is extremely difficult to find Web Services with a desired capability using UDDI.