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.

Once you realize you need all this information to support the Service Discovery Process, you'll have to figure out where this will be stored and how it will be maintained.  That is where a service repository becomes paramount.  This is not the same thing as a service directory because the repository is for a provider to store all the information relevant to their services and a directory is just the data that provider wants to publish to potential consumers.  A directory should use a standard, consistent interface for use across a disparate consumer base whereas a repository needs to be extensible and flexible to store any relevant information for a fairly small user base.  Anyone who has gone through the painful exercise of trying to get a service directory to function as a repository knows you simply can't get there from here.  That is why we started from scratch in building a service repository for the Managed Services Engine (MSE) that can store all service metadata.  It is build on a relational data model that can be extended to support new requirements and scenarios.  We then use a pub/sub model to share published information and updates to a UDDI or other service directory of choice.  There is also an API on the MSE service repository that can be used to search for specific operations through any user interface of choice.  With these capabilities, we have found that organizations can have a very rich service discovery process that transcends container visibility to help them quickly determine which service to use and capitalize on the benefits of SOA.