Don't Fret Debate: You've Got to Take Care of You and Your SOA

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

If you've never seen "O Brother, Where Art Thou," by the Coen Brothers, you should. Not only does it include some amazing Bluegrass music -- which originated in my home state, thank you very much -- but it includes incredibly funny lines such as this gem, spoken by one Washington Hogwallop to his prison escapee cousin, Pete, after he's turned Pete and his friends in to the police:

"Sorry Pete! I know we're kin! But they got this Depression on, and I gotta do fer me and mine!"

What's that got to do with technology? Well, I'll tell you.

Lately, there's been a huge debate over the proper role of ESBs. I mean, forget the presidential race, this is where you'll find the real drama. It started with a TechTarget article, "SOA Complicated by ESB Proliferation," but really picked up steam after InfoWorld's David Linthicum wrote that he had been warning us about this problem for some time.

And it blew up from there. Joe McKendrick had a nice synopsis, if you're curious.

"But, Loraine," you may say, "I don't care about all that pie-in-the-sky, ivory tower debating. I just want to know what's right for me."

Exactly. Just like Washington Hogwallop, you've got this recession on and you've got to do for you and yours. If I may again quote "O Brother!" -- I'm with you fellas.

So, instead of getting in a tizzy about the ESB debacle, may I suggest you read ZapThink's recent whitepaper, "Design and Validate SOA in a Heterogeneous Environment?"

It's written to walk you through designing your own SOA. And -- this is my favorite part -- it tells you how you can use the technology you already have on hand. According to the whitepaper, you can use:

  • An integration server for SOA service externalization, core information mediation, management of information flow, registry/repository support, and connectors, adapters and APIs;
  • An application server for SOA service externalization, service development, some core integration capabilities, registry/repository support, SOBA development and some process integration capabilities;
  • and, gasp, an ESB! An ESB can be used for SOA messaging processing and management, service externalization, registry and repository support, some core integration capabilities, and connectors, adapters and APIs.

Who could've dared written such a revolutionary document, you might rightly ask? David Linthicum -- that's right, the same man who was practically burned at the stake for suggesting too many ESBs in a SOA might be a problem.

Yeh, I know. I've mentioned Linthicum a lot this week. My editors may taunt me, but to be fair, he does some good stuff on integration and SOA. And, in many cases, it's free -- which is unusual for good material.

Speaking of free -- did I mention this whitepaper is free? You just have to register with ZapThink, which is also free.

The paper doesn't just discuss technology, of course. That wouldn't be Linthicum's style. It also walks you through:

  • Understanding and identifying the core set of requirements for your SOA;
  • Design time and runtime SOA governance and how to determine whether you need one or both;
  • SOA testing, a much neglected and critical issue; and
  • Developing core services and service externalization.

There's also a brief section on how you can use iTKO LISA for service virtualization. I'm guessing there's some sort of sponsorship there, but I couldn't find a disclaimer about it, so maybe not.


Bottom line: Nobody's going to build your SOA for you -- unless, of course, you're willing to pay about $500 an hour, and then, yeah, OK, you're off the hook. But that's not the point. The point is, you've got to find a solution that takes care of your business needs.


No doubt, mistakes will be made. But to quote "O Brother!" one last time:

"...first you must travel a long and difficult road, a road fraught with peril. ... I cannot tell you how long this road shall be, but fear not the obstacles in your path."

And good luck.