Tuesday, February 3, 2009

Data Services presentation at The Open Group Conference

I did a presentation about Data Services yesterday at the Open Group Conference in San Diego. The session went very well and we had a series of good questions / feedback:
  • How is security managed in a DSP?
  • What about transaction management?
  • Is that a good platform for mobile applications?
  • Where are metadata deployed?
  • Can we call this a Data Hub?
  • What about deployment of a DSP within an ESB?
  • What are the real infrastructure costs of WOA and how to compute/compare them?
  • What is the link between a DSP and MDM? (see my recent article about this subject)

Seems the benefits of a Data Services Platform are now widely accepted.

Data Services presentation at The Open Group Conference

I did a presentation about Data Services yesterday at the Open Group Conference in San Diego. The session went very well and we had a series of good questions / feedback:
  • How is security managed in a DSP?
  • What about transaction management?
  • Is that a good platform for mobile applications?
  • Where are metadata deployed?
  • Can we call this a Data Hub?
  • What about deployment of a DSP within an ESB?
  • What are the real infrastructure costs of WOA and how to compute/compare them?
  • What is the link between a DSP and MDM? (see my recent article about this subject)

Seems the benefits of a Data Services Platform are now widely accepted.

Pseudo transactions with non-XA resources

I've seen this article about Pseudo-transactions with non XA-resources on TheServerSide. Well, basically what they do is a manual compensation of the non-transactional resources. There are many ways to implement this, some of them could be quite operational, but this is not my point today.

It is quite possible in the future that we'll have to think differently about transactions. First of all, because it will be always difficult to manage non-transactional resources. Second, the real problems will raise when we'll start to deal with asynchronous data access patterns, e.g. when you call a data services and you don't wait for the answer, you'll get it later (maybe).

The multi-agents systems and the actor languages give interesting ideas about this. An actor language is like an object language in which every method call is asynchronous by default, any required synchronisation having to be explicitely defined and managed (continuations, etc.).

I've recently read interesting articles about this. Some people are saying we can just drop the whole notion of transactions. It could be shocking at the beginning but they have good arguments. Other ones think we must change the problem until we can have atomic transactions: see for instance "Life beyond distributed transactions" by Pat Helland (from Amazon) or the Saga transaction system from Arnon Rotem.

Pseudo transactions with non-XA resources

I've seen this article about Pseudo-transactions with non XA-resources on TheServerSide. Well, basically what they do is a manual compensation of the non-transactional resources. There are many ways to implement this, some of them could be quite operational, but this is not my point today.

It is quite possible in the future that we'll have to think differently about transactions. First of all, because it will be always difficult to manage non-transactional resources. Second, the real problems will raise when we'll start to deal with asynchronous data access patterns, e.g. when you call a data services and you don't wait for the answer, you'll get it later (maybe).

The multi-agents systems and the actor languages give interesting ideas about this. An actor language is like an object language in which every method call is asynchronous by default, any required synchronisation having to be explicitely defined and managed (continuations, etc.).

I've recently read interesting articles about this. Some people are saying we can just drop the whole notion of transactions. It could be shocking at the beginning but they have good arguments. Other ones think we must change the problem until we can have atomic transactions: see for instance "Life beyond distributed transactions" by Pat Helland (from Amazon) or the Saga transaction system from Arnon Rotem.