Does Effective SOA Governance Require a Registry and a Repository?

| by Boris Lublinsky Follow 0 Followers on Dec 23, 2009. Estimated reading time: 2 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

A recent Forrester report describes service repositories as the foundation for service governance:

The vision and purpose of effective service management is to efficiently develop, operate, and deliver services with value and alignment to the business. To do this, IT must transform itself from an organization with many silos of technical and functional silos into a business with reliable and cost-effective service offerings. The attitude, behavior, and culture of the organization must shift to a service provider organization. The first step in this transformation is to develop a service catalog that describes the IT services supporting the business services and in turn the business process.

Although WebLayer's Chandu Natarajan agrees with this statement:

There's no question that a registry and a repository can play a critical role in the success of service-oriented architecture. After all, as part of a larger governance strategy, a registry and a repository can be key to managing service artifacts and their lifecycles, eliminating redundancies and encouraging reuse.

In his opinion the necessity for deploying of a full fledged registry-repository depends on the size of the company and the amount of services that the company has.

Based on customer experiences and feedback, a registry and repository is optimal in environments that need to:

Manage more than 50 services that are either created

  • in house or will traverse the architecture through external sources.
  • Dynamically discover services located throughout the organization.
  • Expose services to public registries for community reuse.
  • Adhere to extensive compliance regulations using advanced security, policy enforcement and auditing capabilities.
  • Perform extensive and continuous auditing and logging of these services, check against SLAs at runtime etc.

According to Chandu, existing enterprise code repositories (such as a source control system), which are used to store SDLC artifacts during design time can, in many cases, be used for management of services, service related metadata and additional artifacts associated with services.

Of course, governance can and does complement a registry and repository. However, a governance strategy doesn't require a registry and repository to help architects enforce policies and obtain greater visibility to mitigate the risks associated with developing software that's designed to support the business goals of the SOA.

And so, the quest for simplifying SOA implementations continues. Of course one can argue that as long as SOA governance is in place, it does not matter what tools are used:

... govern any way you can, but govern

But this is not really a point. Firstly, service registries and repositories are very different and serve completely different purposes in SOA governance. Secondly, it is questionable whether 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. And finally, why the tipping point is 50? What is so special about it?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

SOA governance is not about tools by Artur Karazniewicz

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.

Have You actually worked in real, business oriented (non technical) company? I can assure You that from business perspective SDLC and 'service registry' are equally wrong tools for 'governance' purpose. The chances that somebody from business will ever look at registry/repository is exactly the same that the same business person will check out anything from Your source code repository. Close to null.

From business perspective - You (yes, *You* - Architect or Analyst) are the 'registry'. Business is interested in doing what business knows best... doing business. They have their own problems and the very last thing they want is to deal with yet another technical solution - i.e. 'registry'...

So let's put business aside. They want to know about services - but their interface between services and them is You, not repository. The real question is whether You need repository/registry for being effective SOA 'registry' in front of business? Having worked with few of commercial registries and repositories, from my perspective I don't need this stuff, neither I can see much value added over the inflexibility and hassle it comes with. At the end of the day, instead of promised 'agility' that should come with SOA, You will end up with yet another big, heavyweight brick somewhere in the IT together with ESB stuff etc. My advice is to keep thing simple, unless You really, really find in the position that this simplicity comes at a price. But even at this point I don't believe that Vendor provided 'repository' could help somehow. So sum up:

* have simple documented catalogue of services
* make them open and easily accessible (I personally use wiki)
* have process - but Yours not Vendors one
* use tools You have already probably (You can monitor SLAs easily with HTTP proxies, without need to put half-backed proprietary intermediaries in between etc.)
* consider simple stuff like REST which comes with natural solutions for most problems that SOA governance tools tries to solve

Re: SOA governance is not about tools by Kevin Grainer

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.

Re: SOA governance is not about tools by Artur Karazniewicz


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.

Re: SOA governance is not about tools by David Peterson

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.

Re: SOA governance is not about tools by David Peterson

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? :)

Re: SOA governance is not about tools by David Peterson

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?

Re: SOA governance is not about tools by Kevin Grainer

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.

Re: SOA governance is not about tools by Artur Karazniewicz


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.

Re: SOA governance is not about tools by Steve Snodgrass

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

In my opinion this is neither an age-old problem nor a simple one. Corporate mergers and acquisitions which require integrating enormously complicated systems are the reality these days. For a small company with a limited number of systems and development teams, something as simple as a wiki might work. When you are dealing with a Fortune 500 company that has dozens of development teams and hundreds if not thousands of services you will need something more complicated if you want to maintain any sense of control. In that environment, a system's integration solution which doesn't use a registry/repository is definitely going to be simpler and quicker to implement, and therefore more likely to be on-time and on-budget but in the long run the company would have been better served if a service registry/repository was put in place.

Re: SOA governance is not about tools by Artur Karazniewicz


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.

Re: SOA governance is not about tools by Steve Snodgrass

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...

Re: SOA governance is not about tools by Artur Karazniewicz


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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

12 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you