Rethinking SOA and Integration

Are you comfortable with your understanding of SOA and its role in integration? You are. Great!

Ronald Schmelzer of ZapThink says you're wrong.

OK -- that's not completely fair. He didn't say you, personally, are wrong. But he definitely has a bone to pick with a whole lot of techies (and techie writers) who are pursuing SOA projects "as if they were point-to-point integration projects."

I'm not going to lie: I was surprised by Schmelzer's lengthy analysis, published recently as a ZapFlash, and I'm guessing I won't be alone -- especially given a whopping 75 percent cited "integration" as the "issue SOA best addresses" in a recent AmberPoint survey. Not only are they using it for integration, but they're apparently doing so with great success, since the same survey showed only 1.5 percent of SOA projects were considered failures.

But according to Schmelzer, most SOA integration projects aren't actually SOA at all. If you're using middleware -- usually an ESB -- to manage service communications, then you're practicing Enterprise Application Integration (EAI) 2.0, not service-oriented architecture, he contends. The ESBs are actually being used as an EAI hub-and-spoke or message-bus brokers facilitating Web services integration, which, he stresses, is not the same thing as a SOA.

His argument is long and complex, so I'm not going to try to give you a summary here. Suffice to say this isn't just about what you call these projects or how you define SOA -- although it is partially about that. Schmelzer is trying to help you avoid costly mistakes with SOA. You'd do well to read the full article and overlook his occasionally condescending tone toward techies with integration backgrounds.

So, where does this leave us in terms of SOA? Again, I'm not trying to capture the whole of his piece, but here are a few key points:

1. Services are an abstraction -- not an application programming interface (API).
2. In a SOA, you should not connect the service consumers (users and other services) directly to the service providers, which can be internal or external. That will just cause you more problems down the line, if, say, the service provider moves or the service contract changes.
3. He stresses the one thing you should not do -- and what most people are doing -- is to use a vendor's "black box" technology, aka the ESB, to manage communications between the service consumers and providers.
4. He outlines other solutions, including an optimal solution that uses "registry-based 'late binding' to help the service consumers find proxies and also to help them resolve service providers to WS-Addresses."