Those of us in the "trenches" of integration efforts have learned that SOA and its various components mean different things to different people and in fact one person's SOA may be someone else's Web Services, EAI, ESB or other acronym. Terminology confusion aside, many enterprises are beginning to realize the benefits of SOA and the modular approach to enterprise architecture.

The big question for enterprises is "what is the right SOA approach for my environment?" At the highest level, the fundamental challenges are the same. It's tough to get data to and from different systems in different formats. It's tough to migrate large volumes of data from legacy systems onto new systems without service disruption. And it's tough to juggle the ongoing churn of legacy applications and new services that need to be wired together.

What I find concerning about the SOA market hype is that there have been some gross oversimplifications propagated about "the right" approach. Just like with all integration challenges, finding the right fix is a matter of breaking down the existing technologies in the environment and weighing the implications of going different routes.

Web Services: Not the Silver Bullet

Web Services have commonly been pitched as the cure-all for solving interoperability issues that organizations face across different environments and platforms. This sort of pie-in-the sky integration silver bullet vision for Web Services has in fact caused a lot of folks in the market to view Web Services as being synonymous with SOA.

However - as most large scale enterprise developers would attest - the problem with Web Services is that the user often faces a big performance hit when they wrap all their messages in XML headers. Often (and certainly in financial services institutions) they can't afford that overhead of passing that message and trying to figure out where to send it next. Typically the routing message has to be stored outside of the message for performance reasons. There are numerous other practical performance hits that one must take into consideration before using Web Services for SOA messaging. There was an excellent article on InfoQ by Stefan Tilkov recently if you seek further information.