One topic I've written about a few times is this concept of using SOA for integration. Despite the fact that many, many companies move to a service-oriented approach because of the integration benefits, the very topic is a huge trigger issue in SOA circles. It creates heated, nuanced debates of the type normally reserved for Windows/Linux discussions.

The opinions run a gamut between those who say SOA is not appropriate for integration and others who say, "Sure, why not use it for integration?"

I see you rolling your eyes, wondering if there are any new LOLcat pictures you could be perusing instead of reading this. But don't worry: I'm not going to get into that big discussion again. If you're really curious, subscribe to the SOA Yahoo Group. Believe me, the topic will come up again sooner or later.

But at least let me say this: During the original heated discussion on this topic, Anne Thomas Manes of the Burton Group coined the term "Service-oriented integration. As she explained in a discussion with me, SOI can be a great way to handle integration, but it's not the same thing as SOA.

This week, enterprise architect Todd Biske posted his thoughts on service-oriented integration. I think he made some points worth consideration, particularly if integration is a big motivator for your SOA efforts.

Biske isn't really saying anything substantially different from Manes – I know, because she told him he was “spot on” during a recent Yahoo Group discussion. But, he does offer details about service-oriented integration that clarify why it's not the same thing as SOA and could even hinder your ability to reap the full benefits promised by SOA.

Biske writes:

SOI, service-oriented integration, is probably best stated as WSOI -- Web Services-Oriented Integration. It’s simply the act of taking the same integration points that arise in a project and using Web services or some other XML over HTTP approach to integrate the systems. Could this constitute a service-oriented application architecture? Absolutely, but in my mind, there is at best incremental benefits in this approach versus some other integration technology.

Why does he say this? Because, really, you're still doing point-to-point integration, here, except using XML and HTTP, which does give you a bit more interoperability, he points out. Still, there isn't a lot of potential for reuse and you've still got to code the integration.

That's also part of the reason it's not SOA if you're just service-enabling an application, or even two.

Biske notes:

To me, SOA must be applied at something larger than a single application to get anything better than these incremental gains.

Manes elaborated on his remarks during a recent SOA Yahoo Group discussion:

SOI is the practice of using service-oriented middleware (e.g., WS-*, ESB, etc) to do integration the same way they would using distributed object middleware, i.e., they aren't rearchitecting their integration approach, and they certainly aren't optimizing their applications architecture to reduce complexity or redundancy.

SOA discussions can seem a bit pendantic, but sometimes they help further the understanding of the solutions and the problems of SOA. It's a complex topic, but I think Biske's recent post sheds some light on why companies are struggling to deliver real business benefits with SOA.