Personally, I have mixed feelings about UDDI Inquiry as a SOAP API. It looks good on the surface, until you actually attempt to search a UDDI registry—that's when you discover the weakness of UDDI. In order to execute a search effectively you have to know the names (at least some of the names) of the things you're seeking, or the proper categories to search by. This is more difficult than it sounds because organizations are not using categorizations consistently, as you would expect them to. In addition, some organizations are simply entering the data improperly. Amazon.com, for example, has an entry in IBM's UDDI operation site, in which they have placed their WSDL document URL in the accessPoint element of the business Service, rather than in a tModel where it's supposed to be. Access any UDDI public directory and try to find organizations by a specific category and you'll quickly discover that searching is difficult.
One solution to this problem would be for Web service standards organizations to define strict requirements on how organizations list and categorize their business Entitys, bindingTemplates, and tModels. More predictability would reduce the difficulty of searching a UDDI directory. The WS-I organization defines such requirements in its WS-I Basic Profile 1.0—we can hope other standards organizations follow suit.
Another problem with the UDDI Inquiry API is that you cannot search description elements for key words, such as "book" or "wholesale." When I brought this problem to the attention of a UDDI expert, I was assured that it would be addressed in UDDI version 4.0, which probably won't be available for a while.