Re: Cross-application transactions in middleware systems

> In the web world, the name I always hear is 'BEA' when it comes to TP
> Monitors, so that might be your best bet.

Thanks, I'll try to get something to read on that.

> You might be in for a whole world of expense, though.
In fact, I'm for now just happy to know that it is actually being done at all. I'm just tickled to know how they are doing it.

From my reconing, for a middleware system to offer cross-application transactioning, it would need these applications to expose functionality not available in an environment where transactions are executed within a single application. Fundamentally, the application would have to be implemented with the knowledge that its operations may be part of transactions that function in a context larger than itself.

So the limit is not really on the middleware: you're just moving all the familiar transactioning logic one step up. The problem is the support that needs to be built into the third party applications to allow their rollback/committing/resource locking etc to be controlled from outside. The issue is to what extent the idea of 'transactions-are-larger-than-me' is supported both in database theory and in industry systems.

> And if you're growing disenfranchised with middleware promises - take
> heart. Their biz model is to package up what is 18months behind the
> state-of-the-art on the web and then gouge you on support. So you'll have
> lots of complaints in the future..

*sigh* - the more hype, the more apprehensive I get... :) Is there actually a way of addressing what we've been talking about with web-based protocols?

I've had a quick look at the RosettaNet documentation. It seems that the model does not attempt to provider transparency of service location, and does not provide a protocol for cross-application transactions. Do I understand correctly? Received on Wed Mar 28 2001 - 09:11:53 CEST