The value of two phase commit transactions has always been that programmers can write applications that access data spread across multiple databases and be confident that any updates that are made will be consistently reflected in all of the databases, or none, at the end of the transaction.

Clearly, the reality underlying this observation is that data is split across multiple stores. And how! As project-based applications are built, or bought, data about a single business entity (let's take "customer" as an example) become diffused over many back-end systems, and before long the poor guy is on the phone, complaining that you got his personal details wrong, despite his having informed you of his change of address five times in the last six weeks. But that's just the customer perspective. All sorts of other people feel this pain; managers can't get consolidated views of the things they care about: customers, products, sales, you name it they are doubtless populating their own personal spreadsheets with data gleaned from five or six different back ends in order to inform their usual run of day-to-day decisions.

So, the IT department set off in response on a crusade to build a portal to centralize access to the data, which is good as far as it goes - at least now the code that is the equivalent of that spreadsheet is managed somewhere on a server (although the manager may debate this as a benefit, since now he can't change anything for three months, while he waits for a developer to become free). All this turns out to be a mirage in the longer term as well - as the data landscape changes at the back end, unpredictable quantities of this front-end data integration logic gets broken, and needs rework; not to mention the fact that almost none of it is reusable - a million different little queries for a million different specific purposes, and growing fast.

This landscape is about as far from the "service-oriented architecture" vision as it is possible to be - all of the pain of a stovepiped approach to functionality (and therefore data) in one painful place. It is because of the importance of logically organized, coherent data, and the grim reality of its fragmented storage that a data services layer is one of the first architectural layers that gets looked into as IT departments start to review their desired reference architecture for a move to SOA.

In the past, this problem has been addressed by building data-mart type intermediate databases, drip-fed via ETL of data from the fragmented data sources of record. This does provide for a consistent data model to query, but at the cost of building and maintaining the ETL and with the requirement that the data cannot HAVE to be absolutely up-to-date. After all, you are querying a consistent view of the data, but it's a snapshot - not the real thing. Just imagine if there were an infrastructure that could do for the logical presentation of data what the transaction manager does for its transactional consistency...

Well, there is! And as with all of the best and most creative artists, it has recently changed its name. The product formerly known as Liquid Data - now called AquaLogic Data Services - is an infrastructure that provides for a systematic solution to these issues.

Enter ALDS
At the root, you model your data as you'd like it to appear (the logical data model, canonical data representation, call it what you will) your data as it physically exists (be that data held in relational schemas, applications, Web services, or whatever) and then you declaratively define how the physical data elements relate to the logical data model using the W3C standard XQuery language. In this way, you have solved the fundamental problem of understanding where the data you want to look at comes from, and you have done it in a systematic, managed way. So, looks as good as the portal vs. spreadsheet phase of evolution then?

Actually, it looks a lot better. Recall that all we did so far is declare how the data is built up via relationships. The actual execution of the queries is managed at runtime by the ALDS query engine, which is guided by your declared relationships. What you run queries against is the logical data model, and what that physically causes to happen is driven by what data you are looking for - if you look for a single element of data that comes ultimately from a single back-end database or application, the query that actually runs will just retrieve the necessary information, not all that it would take to populate the entire logical data model. We have achieved, therefore, not only centralized management of data relationships, but reusable relationships - instead of the million aforementioned combinations of data retrieval for a million different specific purposes we have one declared relationship with as many different filters applied to it at runtime as are needed to address all of the different use cases. Wow, reuse! Sounds like a bit of a SOA to me! Maybe it's not an accident that the name changed and the product became part of BEA's new AquaLogic Service Infrastructure product family!

And because the queries are being pushed down to the data sources of record at runtime, the data we see is absolutely up-to-date, removing another of the problems with the "just add another database" technology elastoplast traditional solution to this problem. Finally in addition to all this, ALDS allows you to model the relationships between your physical data sources, so as the back ends change, you can do quick impact analyses of what will be impacted (and, of course, the impact will be restricted to the ALDS tier - the front ends will continue to work against the same logical data model).

But that's not all: the product allows updates as well as queries - updates are decomposed and pushed to the back-end data sources by the query engine, and there is an update framework where you can manage the consistency of updates across multiple stores as appropriate

And what's the role of the transaction manager in all of this? Well, if all your data sources are xa compliant, ALDS can use it to give you update capability with no need to write any code. Magic, I'll have one!!

In conclusion, I would encourage anybody who is grappling with these types of issues to give ALDS a test run. Because it's an innovative approach to the distributed data problem, a lot of people's initial reaction to it is "oh, it won't go fast enough" or some such. In practice, I have never failed to see these same individuals hearts melted as they see the power (and efficiency) of the product and its approach to data integration. Go on... Give it a spin! You know it makes sense! Read more about the ALDS product at http://dev2dev.bea.com/dataservices/.