JBOWS

Joe McKendrick has an interesting post on opportunity areas for SOA. One in particular I would like to expand on. Here is his quote:

An effective, functioning service-oriented architecture requires governance, and the ability to share services across multiple business units and enterprises. It’s easy to build Web services. You could build 10 of them in an afternoon. But, then you end up with a JBOWS architecture (Just a Bunch of Web Services), which will grow into a different sort of SOA — a Spaghetti-Oriented Architecture. SOA requires orchestration between the services and governance. This is an opportunity for those proposing or offering governance tools and methodologies as a way to clean up a growing tangle of point-to-point services.

I have a very difficult time when talking with developers about this topic. Most developers I speak with are very creative. They like to write code and there is a strong since of ownership. There is really no faulting them for this. These are traits normally seen as good in an individual developer. However when taken in the Enterprise context, they can be a harmful factor. These code warriors are very distrustful of third party solutions that have to be intermixed with their own solutions. Things come up like: Unnecessary hops, transaction overhead, more failure points, span of control, I can do it better myself, etc.

These are all valid concerns. However as we move into the SOA world, the role of the intelligent intermediary is crucial. Having each developer write their own policy management implementation, their own content based router, their own security handler, their own orchestration engine seems to make little sense. What about the governance aspect around service registration and usage? How do you know who is using what and in what context? Where is the latest version of the interface spec?

My position is without the intelligent intermediary (Both tools and people) in the SOA infrastructure, you will end up with the same brittle architecture that is represented so well in the traditional spaghetti diagrams. However the impact to the enterprise will be far greater than before.

Here is a simple example of the problem. Let's say I create a nice interface into my trouble ticketing system. The trouble ticket vendor is following the Web Services trend so they expose their API via Web Services. I pass along the interface definition (The WSDL) to the team that commissioned my work. All is well and good.

The team being the sharing type (stop laughing) decides to share the WSDL with anyone who asks. And they tell two friends and they tell two friends and so on and so on. I now have a lot of very different uses of the original interface of which I know about only one.

So now let's say the original team now comes back and wants a modification or it's time to upgrade the trouble ticketing system or there is a planned outage/maintenance. Who do I notify? How critical are the other applications that are using the interface? What context are they using it in? How do we regression test all that stuff we don't know about? This isn't some code someone has checked out and incorporated into their own. This is a live running interface. The impact is immediate.

The intermediary is critical in helping establish the governance for SOA. It plays many roles and may consist of multiple products. It may also be played in part by people. Web Services Management, ESB's, Registry/Repositories, Policy Enforcement, Governance, XML Appliances are all things that make up what I consider the intelligent intermediary. Without governance (both runtime and design time), a Service Oriented Architecture is doomed to repeat the past.

This probably seems obvious to most but in practice it is more difficult than one would think.