UDDI was proposed as a solution to publish and search services. UDDI defines data structures relevant to service discovery and a set of APIs to access them. The standard was supported by major software vendors such as IBM, Microsoft and SAP. Although UDDI was claimed to become successful in restricted and controlled environments (there are several implementations of UDDI servers available for the internal use these days), it has not prevailed in the domain of publicly available Web Services (you can read more about shutdown of IBM, Microsoft and SAP public UDDI registries and many articles discussing this topic as old as 2004, just to mention some of them for reference from pluralsight, techtarget or realworldsoa at inforworld).
We are frequently asked by users of seekda Web Services search engine if seekda develops or aims to develop a public UDDI registry. To be more specific what people really mean are UDDI APIs allowing to access seekda in a programmatic way. The short answer is that we are neither doing nor planning to do so in a short term. However at the same time we believe that we can learn a lot from the work done by UDDI designers and creators of public UDDI registries. We do not completely neglect the future possibility of implementing the standardized UDDI APIs (or ebXML registry APIs). Anyway at this stage we do not consider UDDI APIs as a very essential feature which would improve search for public Web Services and the exponential growth of Web of services.
Having these opportunity to talk in this article about drawbacks of public UDDI repositories, we would like to shortly analyze pitfalls of UDDI as identified by us. seekda is already overcoming most of them and going to address remaining in the near future. At seekda we believe that UDDI has not prevailed in the domain of public Web Services for the following reasons:
- UDDI is centered around programmatic access to the registry and only a few mostly technically focused user interfaces are available. There is a considerable learning curve required for somebody not familiar with Web Services to understand the technicalities of UDDI specification. If we use an analogy to Web of pages, all what the new user of Web of pages requires to have is a pre-installed browser to start exploring websites. If it is so simple for the Web of pages, why can it not be as simple for the Web of services? In our opinion it is very important that somebody who learns for the first time about Web Services technologies (or services in general) can start exploring and enjoying them with a few simply steps.
- There are no policies such as availability checks for Web Services in place and thus many services in the public registries are outdated. What is the value of a service in the public UDDI registry if the service itself does not exist any more? A rhetoric question comes – How long would you be using Google if for the first ten queries you make, none of them would return working results. Surely Web is unpredictable and services can appear and disappear (the same as websites), but there must be a mechanism allowing to eliminate these services which are not available any more. Even in Google search results we sometimes find websites which are not working at a particular time, but in the long run, unavailable sites are getting always removed from Google’s index.
- There are no means for community feedback. No service is perfect from the beginning. The most successful websites and portals are very often winning only because their creators are capable to listen to their users and adapt to new requirements and expectations. Why should this not be the case for services? Which feedback currently a potential user of a service can give to a provider of a service using UDDI technology? How can one user of a service interact together with another user using UDDI API? The UDDI specification basically provides no support for community features. Practically there is only one possibility for feedback allowing the user to contact a provider using an email listed in the service description. But in the Web2.0 world it is not enough. While email might work for some particular cases, it does sustain a community around providers of Web Services so in the long run the UDDI model has little applicability to the Web.
- It is hard to expect that users would select a service based just on its WSDL definition and a short description. You need pricing, terms and condition, service level agreements to name just a few. seekda has started to include these and we are working hard on improving it. UDDI as API centric approach neglects that using a Web Service means first understanding it and making a contract – this requires to learn and understand various aspects of the service, not just its interface and short description.
Today, when the time of public UDDI registries is practically over, the process of publishing Web Services is mainly done by providing an access to the interface description and providing a couple of Web pages explaining the peculiarities of a service. This information can be then found by the crawlers of search engines. So is there a future for public UDDI registries and the model proposed within its specification? Surely there is some, but until we can really have the sustainable community which is actually using public Web Services, then regardless on the fact how good are proposed registry APIs, their value to users remain minimal.
At seekda we have looked into the work done in UDDI community and try to learn from it although we follow a different approach when developing seekda Web Services Search engine. We provide a solution, which enables crawling and indexing for public Web Services. We are regularly monitoring Web Services, so in consequence providing a global registry of up-to-date Web Services. We enhance our portal with many community features encouraging our visitors to leave their feedback, alter existing information or make any necessary updates themselves, Many additional community features will become available soon. And the most important - we listen to our users and adjust to what we hear – your feedback is crucial to get seekda better suiting your needs.
Once the Web of services becomes reality, we can consider adding UDDI API (ebXML registry API) programmatic access to seekda registry as well.
You mention the “exponential growth of Web of services” - is the growth really exponential and do you have any evidence to support this?
Hi Duncan,
I was simply trying to explain that we believe that by committing right now an effort to implement UDDI API to access services indexed by seekda, would not help too much with an “exponential growth of Web of services” (hope it is now more clear what I wanted to say :)). That is why this effort is not yet considered so important by us (but it might become in the future).
But answering in general the question about the growth of the Web of services. We were aware of 7K of public Web Services a year ago. Our crawlers discovered 20K more over the last twelve months (we have actually discovered 60K more WSDL files on the Web, but with our technology we do our best to eliminate duplicates). Our crawlers are constantly discovering new services. During a good day we are easily finding 30 new services on the Web. It is not yet exponential, but lets hope that seekda can motivate many organization to expose their services on the Web and this exponential growth would happen soon.
Greetings,
Michal
I’d be very interested if you can publish this data somewhere, the current stats at http://seekda.com/about/web_services are a bit vague. It is useful for getting a handle on how quickly/slowly web services technology is being adopted. Thanks, Duncan.