SOA's Dirty Little Data Integration Problem

Loraine Lawson

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.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


More from Our Network
Add Comment      Leave a comment on this blog post
Jul 12, 2007 9:36 AM Gabriel Andersson Gabriel Andersson  says:
HiAll of a sudden things wasnt so easy after all. The concept of SOA is really more of a vision then a "technology" just like you cant say LEGO is a toy but what you build out of it. The "dataintegration" portion is always there and as an old EDI "worker" I have basically only seen changes in the "abstraction layer" moving from EDI to SOA. At the end of the day there is a great deal of pluming to do.. Reply
Jul 12, 2007 7:55 PM Dave Wright Dave Wright  says:
I am not sure if I even get the problem. The core of any SOA approach is data services; if you want customer data, you use a Customer Data Service. No other service has access to this data. If your SOA environment is not managing the single instances of your enterprise data, what the heck IS it doing? Reply
Jul 14, 2007 7:41 PM Loraine Lawson Loraine Lawson  says:
As I understand it, it's more about what happens when the data passes through an app or service - and then needs to be moved on to another application. When you're dealing with solutions from different vendors, one service may not present the results in a data format that the next application, (or, I suppose, possibly the next service), can recognize. This is when you're using SOA to integrate across completely unrelated systems, as in a merger. Here's the telling quote:"Services need to be architected so that they yield data that can be consumed by various applications, although iWay's Service Manager manages much of that task. "Or, at least, that's the problem as it's presented in the article. It seems like a data service layer would fix this problem. See Richard Manning's recent discussion at Arch2Arch - http://dev2dev.bea.com/blog/rmanning/archive/2007/03/iWay's Service Manager is an ESB. And the other solution discussed is Web services. But it seems Data Service Layers are something else altogether. I haven't actually listened to this yet, but perhaps this webinar looks like it might provide some insights:http://www.ebizq.net/webinars/7995.htmlI'll try to follow up on this in a future post.Like I said, I found the article a bit confusing. I'd hoped someone might chime in with real world experience with this issue. Reply
Apr 7, 2009 10:57 AM GUIDO CUCCHIARA GUIDO CUCCHIARA  says: in response to Loraine Lawson

dear all,

as for EDI and SOA, I see it this way.

We have four people in a room: one is french, one is spanish, one is italian and one is german; no one knows any of the other languages and they need to talk.

They all learn english and then are able to talk: THAT'S EDI

They all try toghether to invent a new language (but how can they understand each other in the first place ?): THAT IS SOA



Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.