I've seen almost all of these features spread out across a couple of different products, but I think eventually you will need these in order to have a successful SOA implementation. Each of these items deserves a whole post, so I'll keep it brief in this post.
A last note before I start enumerating is that I think SOA Registries are more useful at the private/internal/enterprise rather than the outdated public UDDI model of 5 years ago. Registries needed to enable an enterprise's modular development, but aren't required for locating public services as it's pretty much impossible to get all the different providers together in one registry.
- Service Level Agreements- the SLAs available for the service should be listed out so an architect or program manager can search based on what is compatible with their system needs.
- Security - what kind of authentication is needed for the consumer to implement. Here's where you get all the various metadata that tells potential service consumers the kludgy way that userids. Until an enterprise gets their single sign-on, SAML compliant wonderland authentication framework in place, you can look to the registry to see if a service needs basic auth (and where to get a userid), digital certificates (and where to get a cert), custom headers, etc etc.
- Data classification - what kind of data is passed in the service. I'm currently dealing with this in the public health sector as there are special regulations that kick in when you deal with Personally Identifiable Information (PII).
- Endpoint - of course this is in the WSDL, but for non-WSDL services, you have to have the endpoint.
- Service Interface/Schema - again, another item in WSDL, but this needs to be available for POX, etc.
- Examples & Documentation - essential to have links to example client calls and user documentation on how to use the service. This sounds like a no-brainer, but every time I've had a "WSDL only registry" there is always reams of extra work that goes into demonstrating how to call the service. An even better way of documenting the service is to provide test programs/classes that a potential user can download and play around with. Don't assume that all your users have fully licensed SOA tools.
- Approval Level/Rating - this should show what approvals and governance checks the service has gone through. Is this a demo service? Or does it meet all the necessary service characteristics that the service governance center came up with. Think of this as a stamp of approval. You don't have to limit this to just a formal approval, think of a digg/reddit type rating where users in your systems can add their thumbs up to a service. Word is going to get out if developers across your company like the service anyway, make it easier for them.
- Providing organization- who built this service. This is especially important in a federated repository where it is not necessarily clear who is responsible for maintaining a service.
- Version/last updated - not only showing the current version but other related versions.
- Timeliness- how long is this version guaranteed to be supported.
- Keywords/tags - service provisioners should add keywords to allow for easier searching and finding of related services.
- Usage statistics- how many executions per time period, average time of execution. Stuff like this. Implement service performance measurement and publish the results as part of the registry.
- RSS for updates and announcements - allow consumers to subscribe to a service's feed to see when a new version is coming out, known issues, etc etc.
- Cost/chargeback model- if your enterprise charges for services (which has its pluses and minuses as Nick Malik pointed out) then go ahead and show it as part of the registry. Buy 1,000 transactions, get 1 free.
So that's a couple of useful things that I'd like to see in my service registry. It goes beyond what some of the big vendors are selling by adding in some user centric features. Don't think that this is all based around bottom-up as there is still governance and all the other stuff that goes into the review a service is put through so that it can make it into the registry.