In the services world, there has been a lot of attention on discovery: the need to discover the existence of services through a directory or tool. UDDI attempted to solve this problem with limited success, but has gained “checkbox status” among organizations looking for SOA products and solutions. I have seen organizations have more success with custom portals and wiki’s because they are easily stood up and supported. However, the real value from these approaches is the inclusion of additional content such as descriptions, samples, tips, and faq’s. I think this points to a bigger need for service consumers – aiding them in their decision on whether to use the service. I think the whole idea of service discovery has really gotten off track because it over-simplifies the discovery process and obscures the significant milestones in the lifecycle of service consumption. This is one of the biggest reasons organizations aren’t seeing the level of service adoption or reuse that they anticipated. Discovering that something exists requires much more than visibility. It involves discernment, evaluation, and implementation. Most approaches today actually do a very poor job of providing visibility and then jump to the implementation stage of the cycle. Again, I go back to UDDI which allows you to search for a service and then provides a WSDL so you can implement it. Most of the custom solutions take a similar approach, but any additional content often improves the implementation experience. I believe both approaches miss something very fundamental by skipping the discernment and evaluation stages of service discovery. They actually get off on the wrong foot by providing visibility at the wrong layer. Most consumers aren’t looking for a Web service, they are looking for a discrete operation. The Customer service may or may not be useful to somebody looking for getCustomerOrder . Perhaps the Order service would be more appropriate. The bottom line is that service containers are arbitrary and discovering one is about as useful as coming across a bucket. You know there is something in it, but you aren’t sure what until you take a closer look (usually via the WSDL). Well, if you had a 100 buckets, you’d be pretty frustrated by the time you got around to the 50th bucket and had yet to find what you were looking for. The same principle applies to services. We need to allow service consumers to discover operations so they can discern the service they will need for accessing that operation. Then we get to the evaluation stage. Just because something is a functional match doesn’t mean that it is appropriate to use. What does it cost to use the service? Can it handle the load, meet the appropriate response requirements, or support the necessary security model? Does the service have a track record of successful usage or recurring outages? These are just some of the factors that go into a well-formed decision on whether to use a given service and none of them are supported by the current approaches to service discovery. Publishing a policy can support some of these requirements, but how many examples have you seen where policy was utilized for this purpose? I think we still have a lot to learn concerning the content and makeup of this information, but we won’t learn that until we start providing any information.