SOA: A Governance Nightmare

As a graduate student years ago, Layer 7 CTO Dr Toufic Boubez used to have a poster on his wall that read: "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable."

That about sums it up, really, doesn't it? In a few neat words, the poster suggests both how long flexibility has been a dominant theme of software engineering, and — given the vehement response the slogan still gets in seminars and presentations — just what an elusive goal flexibility remains even today. Indeed whenever Boubez repeats the slogan, people all around the room nod their heads in agreement, suggesting brittleness remains one of software implementers' most dominant preoccupations.

In theory, of course, service-oriented architecture (SOA), along with its implementation technologies like Web services, should deliver that long-desired business agility. With an SOA in place, users should be able to look forward to just-in-time integration, more flexible systems achieved by loosening the coupling between software components, reuse of software components across diverse business processes, and late binding and platform interoperability.

Yet as anyone who has headed down the SOA path knows, things are very different in the real world, where real applications live. Whatever the promises of SOA, the reality is brittle interconnections with coding of each endpoint. In fact, Boubez says, to date the promise of loose coupling has only ever proved real for the simplest, most "vanilla" Web services, like those with no security requirements. Constraints and capabilities for services have to be hard-coded, while any changes in these preferences will render your own computer unusable.

"The original goal of the service-oriented architecture concept, and its implementation technologies such as Web services, was to build flexible, loosely coupled systems. But any two components in a system that communicate with each other are by definition coupled to a certain extent," he says.

"The fact is that currently the way we build service-oriented architectures using Web services is pretty tightly coupled for anything that is not just plain vanilla-type Web services. [SOA] works well in the lab: that whole trilogy of Publish, Find and Bind using SOAP [simple object access protocol] and WSDL [Web services description language] and UDDI [universal description, discovery and integration] and so on. It works pretty well under very controlled conditions, but as soon as you start deploying that stuff in the real world — where you need to deal with issues like security models, like identity issues, like access control, encryption, confidentiality, integrity, even routing and encapsulation, all that kind of stuff — there is absolutely no way to deal with it properly right now using any of those mechanisms," Boubez says.

"If you have pilot projects that don't have to deal with these things then loose coupling works pretty well. But any time you have to deal with the real world it breaks down unless you start thinking pretty hard about a policy layer/policy abstraction layer," he says.

So in pursuit of real flexibility, the aim of the game should be to lessen that coupling or, at least, to loosely couple components in systems by removing or lessening the run-time dependencies between them. According to Boubez, the best mechanism to achieve that is to delegate as far as possible the run-time tasks to the infrastructure.

If this is to work, the organization needs to define and automate contracts, requirement and capabilities through a declarative, configurable and manageable mechanism. But while WSDL is the contract language for Web services, Boubez says WSDL is far from being adequate as a contract language for SOA.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark