Data Is King: Columnist Says SOA and XML Fall Short

Loraine Lawson

If you've been following service-oriented architecture for any amount of time, you know that data integration is a problem. How do you apply SOA to data technologies?


Finally -- we have an answer, from Jeff Pollack, a veteran technologist and senior director of Fusion Middleware at Oracle.


Pollack's answer: You don't. Forget about it.


SOA is great for a lot of things, but it's not the best fit for ETL (extract, transform, load); master data management; business intelligence and data integration, Pollack writes in "The Case for Enterprise Data Services in SOA," published recently on ebizQ.


Of course, he's not the only or even the first one to notice that there was a problem. But he's certainly gone over the idea as firmly and completely as anyone to date.


He particularly takes aim at XML and the perception that it's a panacea for data integration. XML and Java-based containers are the current market definitions of data services, but neither are robust enough to handle data transformation on an enterprise scale, argues Pollack.

"The simple and unfortunate reality is that enterprise data requirements are hard, and the dreams of SOA only solution for all enterprise data are likely to remain dreams."

That's the "bad" news.


The good news is that we already have data services and we did even before SOA was a glint in the milkman's eye, according to Pollack. SOA could be used as a control point - not a replacement - for data infrastructures. In this scenario, SOA data services refers to "decoupled end-points that expose highly optimized components for working on all types of data."


Pollack reminds companies that all of this enterprise infrastructure is ultimately about handling the massive amounts of data. Given that fact, why not spend some time evaluating and planning your data services infrastructure? He spends a substantial part of this seven-page article detailing what an architect should include when planning a data services infrastructure.


IT executives and managers will be more interested in how he sees the two coming together for the business:

"A modern Data Service architecture should support synchronizing data grids with master data, publishing high quality canonical data within a messaging infrastructure, and expose control points for commanding BI and data warehouse systems as loosely-coupled services. This vision is not so much a dream, as it is a requirement for modern information-centric businesses that hope to use IT as a competitive edge within their industries. Yet regardless of how grand the IT strategy might be, a good Data Services plan will first solve fundamental tactical issues that simplify the use of data throughout enterprise architectures."

Add Comment      Leave a comment on this blog post
Mar 4, 2008 7:25 AM Kirstan Vandersluis Kirstan Vandersluis  says:
Pollack is simply pointing out that there exist many data problems that should not be solved using SOA and XML. Need to move a couple gigabytes from one database to another? Don't use XML. Pollack may confuse the casual reader by calling this an "average data integration problem", when really its more precisely called an ETL problem. Most implementors would not seriously consider an XML-based solution for this case. Pollack is very clear that SOA and XML are successful in the realm of real-time data integration previously dominated by message queing and transaction processing systems: "...the main tooling for SOA can finally supplant the long-held dominance of MQ and TPS systems".In the end, Pollack reminds us that the world of data processing is vast, and that architects need a variety of tools to address the breadth of enterprise problems. No single technology will solve every data-related problem. Reply
Aug 18, 2008 1:45 AM Stephen Lahanas Stephen Lahanas  says:
The viewpoint of what constitutes "Data Services" is perhaps a bit more expansive than Mr. Pollack has described above. In 2003, as part of an enterprise initiative for AF Logistics, we began offering "BI services" and then opened up other layers of the data architecture for similar services provision or access.The concerns regarding XML however are very accurate. Rather than providing an integration resolution mechanism, XML often adds layers of confusion to an already complex data architecture which requires translation and de-confliction. Data Integration is really about Semantic Integration and the focus from COTS-specific target layers such as ETL or standards mediums such as raw XML is about to change... Reply

Post a comment





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



Subscribe to our Newsletters

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