A recent article published in InformationWeek brings to light a seldom-discussed problem with SOA: the question of how you integrate data across services.
To be honest, I found it a bit confusing - not just the article, but the solution offered, which seems to fly in the face of SOA's high-level, re-use philosophy.
The gist of the problem seems to be that SOA blurs the distinction between data and applications. Suddenly, it's not so easy to tell when you're passing along something that's actual data or something that's application logic.
But the water really gets muddied by the two types of solutions used to "solve" this problem. The first solution is to use a library of adapters. What confuses me about this is it really looks like you're right back at enterprise application integration, with a little bit of code for every single thing that needs to be tied together.
In fact, the adapter approach grew out of EAI, according to the InformationWeek article. The adapter model is offered by iWay, Software AG and others, but the article focuses iWay as an example.
Essentially, these adapters - and there are 300 in iWay's library - connect applications to data sources or other apps. It's apparently fast - in only six months, fragrance and personal care products company Coty had managed to integrate its customer systems with another cosmetics business's customer systems.
But isn't this approach antithetical to the whole philosophy of SOA?
Critics note that this adapter library approach does not create data that can be consumed across all services.
The alternative to this approach is to separate data presentation from the actual data and its retrieval. You can achieve this with open source or proprietary solutions, which usually means some sort of Web services standard to transform and transport the data.
This section of the article ties back in to the type of solutions normally mentioned when you talk about SOA and data integration. The article doesn't delve too deeply into the problems with this approach, except to say it's much slower. But you probably already know what stinkers Web services standards can be.