Does Effective SOA Governance Require a Registry and a Repository?

As a seasoned service architect I become more tired and tired with stuff like above. I see dramatical gap between theorists and people doing this stuff actually. Governance is not about tools at all - it's not what You can buy. It's about process, it's about the way You act, not about tools. So answering question if SOA governance requires repository or registry - the answer is as simple as this: NO IT DOESN'T - whatever ivory tower analysts say. If You feel that having repository/registry in place would automatically mean that You have SOA 'governance' also - You are missing the point completely. Also the opposite is not true. Implementation of effective 'governance' doesn't require specific tools. As I said it's about process - not about tools. The most so called repositories/registries - whatever they are - impose their vision (or vendor vision) how the process should look like. Sure You can customize some aspects of this, but in the end I feel this as a one another pain, costly pain point. The brilliant example is this quote from above article:

SLDC tools (intended to support the creation of IT work products) are not really appropriate for service governance, which requires a close cooperation of both IT and business people.

Rolling your own service catalogue is certainly easier than learning a vendor product. The problem you will run into is when you try to expose your catalogue to random programs throughout your organization. UDDI is not purely theory and there are products from IBM, Microsoft, and Oracle which can use that API. Because of that I would recommend having something in place. If you don't want to pay for the products you can use open source. Java has completely open APIs to access a UDDI registry as does C# so you're covered on the client side. I think you'll find that the time spent learning the API will be a total waste, and you can do runtime lookups for your endpoints when you get it configured. I don't think a Wiki entry will be accesible in that manner without some html scraping.

Kevin

Sure, there are products around, however it doesn't mean that their existence constitutes their usefulness. UDDI is brilliant example. Even its parents: IBM, Microsoft and SAP closed UBR (UDDI Business Repository) in 2005. Basically UDDI was a failed experiment in all possible aspects, especially with it's original promise: *runtime* service discovery. Initially UDDI was thought to be 'mediation' layer between consumer (machine) and service provider (machine). Not end user - that 'SOA repository' is all about. Virtually all modern repositories comes with something *drastically* simpler, better and well thought... and coincidentally its REST. You even don't need "API"s to access it. Just standard URL API in java.

Couldn't agree more, Artur ... Much of the SOA "governance" space is simply about tools vendors pushing complex and costly tools to "solve" what are fundamentally simple and age-old problems - how to capture, document and revision manage interfaces within a system.

SOA and enterprise architects would do well to refer to simple and time-tested agile engineering formulas like "Kelly Johnson's Rules" (Kelly was the driving force behind Lockheed Skunk Works for years and built the U2, the SR-71 and many other novel aircraft). Just scanning across the rules now, a couple stand out:

"Rule Number 2
Strong but small project offices must be provided both by the military and industry.

...

Rule No. 4
A very simple drawing and drawing release system with great flexibility for making changes must be provided."

and so on.

This accords with exactly what Artur has stated above - a "simple documented catalogue of services" etc.

This is the difference between "analysts" who write white-papers for consumption by non-technical audiences and "architects" / "engineers" like us on the ground dealing with the daily reality of managing complexity and delivering useful projects on-time and on-budget.

And those with long memories will recall that before UDDI for the WS space there was the "trading service" in CORBA - same idea and also a failure. And similar things have been tried in COM/DCOM and also earlier middlewares like DCE. When has this ever worked? When has the idea of dynamic service discovery ever proven useful outside of a university research lab or obscure PhD dissertation? :)

So somebody in the organisation is going to write code that sends well-formed XML to consume the web service and process the data returned, yet sending them the endpoint URL is too complicated?

I'm not saying UDDI is great, but it does work. I've been able to successfully deploy client code against multiple registries to query for an endpoint at runtime. I'm all for a better standard, but does one exist that is widely supported? I think the current state of the market is that you have to do a vendor specific implementation if you want something other than UDDI. The other thing to think about is that programs like Eclipse, RSA, .NET Studio, and even Microsoft Office support UDDI.

Kevin

UDDI is just set of specifications and API. Historically, as David said, it had been aimed at trading services. This idea didn't take off, so vendors started desperately seeking new 'emperor clothes' and now we see them monetize their investments revitalizing UDDI as a governance tool. It's brilliant example of solution looking for a problem. Sure - You can successfully register services (and their metadata) through UDDI. You can even try to find them, however this is *horribly* complicated. Have You ever read UDDI spec set? I did. It's more than 200 pages, and it has references to WSDL, SOAP, WS-Policy and WS-Addressing specs as well. It's a bit too much just to publish some service and metadata. This actually brings some light how those vendor SOA governance tools looks like. You're right most of them use UDDI (however most of them provide some kind of RESTfull API). And most of them are like UDDI. Overengineered, complicated yet bringing almost no value. Those tools needs consultant to setup them, and moreover to use them. To make my point clear - I'm all for tools which do all SOA governance stuff as advertised - magically, automatically, nice and all. Unfortunately I'm yet to see such a tool, and I've seen and seriously evaluated probably most of key players in this area and it's just snake oil. Expensive snake oil.

what are fundamentally simple and age-old problems - how to capture, document and revision manage interfaces within a system.

Steve

Corporate merges happened Years ago, even before anyone have heard about SOA, and sure, that was, and ever be very complicated problem. I believe that we all, actually agree that we need some tools to deal with this complicated scenarios. The only thing we differ on is - whether those, specialized tools bring some added value over simple tools, we use for years with success. Having seen evaluated or used top 4 leading products in this area (according to gartner magic quadrant) I can, with complete confidence say: no.

Artur,
Certainly corporate mergers have been occurring for ages, however I believe the I.T. ramifications of such mergers have become much more complicated as business become more dependent upon their I.T. infrastructure.
You had earlier mentioned a wiki as an example of simple tool which could potentially be used in lieu of a UDDI based repository. Do you have any other examples of simple tools which might be more capable of handling hundreds of services? I am truly interested. I find UDDI to be an abomination but as Kevin pointed out it is at least functional, and the client side tools available today abstract a great deal of the complexity away from the developer. Thanks...

Steve

As I said. UDDI is just spec. An API. The way You can programatically add, manage ad search some service metadata. Nothing more actually. This is, in my opinion least important thing in the whole SOA governance landscape. But if You asking me about alternative? I prefer and successfully use REST. It's way more simpler, consistent and standard. You actually need only web browser to access REST resources.