Re: REST based reliability, transactions

> As I've mentioned, there are many different types of transactions, and
> we'd have to design a very general model (like everything else on
> the Web).

This really depends upon what you mean by a "general model". It's true that
one size doesn't fit all, otherwise there would only ever be one
"transaction" model. There are over a dozen at last count, each aimed for a
specific problem domain (e.g., teleco's, banking, ...) Just as it's wrong to
try to shoe-horn ACID transactions into every area where someone thinks
"transactions", it's wrong to try to shoe-horn any of these protocols into
areas they weren't designed for. There was some interesting work done in the
OMG (!) on defining a general extended transaction framework (actually more
a general coordination and context propagation framework) that different
models could be implemented on top of to solve different problems; in a
nutshell, the framework was pretty dumb and relied on higher-level services
to interpret messages, whereas all it did was reliably disseminate those
messages  which were again generated by a higher-level. Importantly, the
principles are not CORBA/OMG specific and have applicability elsewhere.

> I honestly don't know what that would look like though, I'm
> no transaction guru.  I have some ideas, but my company's current market
> focus doesn't require such a technology, so I haven't had the
> opportunity to test them out.

If you're interested (and have the time) it may be useful to talk about the
principles involved in the above framework and whether it's applicable to
the REST architecture.

All the best,

Mark.

----------------------------------------------
Dr. Mark Little (mark_little@hp.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2606216
Fax   +44 191 2606250

Received on Thursday, 30 May 2002 09:39:27 UTC