SOA Registry

There are many definitions of what goes into a SOA Regisrtry. I fielded my first large scale SOA /Services / UDDI /Federated registry in a large systems environment over 5 years ago. We included all possible entries that clients thought that they wanted / needed at the time and today, the registry is populated with less than 50 entries and for the most part, it remains unused. There were several initiatives to revive this dead dog all to no avail. The SOA registry today is a world different than it was envisioned as evolving to 6 years ago.

What changed? 6 years ago, the services registry was going to be a uddi registry where WEB SERVICES were to be registered. These wenb services were to follow the WS specification, and the registry HAD to be compliant to the uddi specification. What changed was the realization, evolution that there are going to be more than just uddi compliant web services...in speaking, I have said "web services with a capital W capital S" But up from the ashes rose non-uddi (I know here it is the first entry and I a being non-uddi compliant...some one will open a can of butt wuppin on me for this) non-uddi web services web services that when I talk I say "web services with diminutive W, diminutive s". OK let us put this capital W,S , small w and s aside for a moment, I will get back to them. Lets get more basic...What is a services registry and what are the basic functions that it needs to accomplish. Then lets ask the really hard question...what do I need a Services Registry for? With these two answers I can attempt to define a set of requirements for realization. Yes you are correct, I am going to have to define my environment, define the limits of my world.