dev@jsr311.java.net

Re: JSR311: Transactions and JAX-RS

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 01 Jul 2008 09:22:13 -0400

Roy T. Fielding wrote:
> On Jun 30, 2008, at 1:25 PM, Stephan Koops wrote:
>> I do not fully understand what you mean, but: You CAN'T see
>> transaction in a REST system, because they are not allowed.
>> Transacation requires session state, and session state is not allowed
>> in REST. So if you have Tx, you don't have REST, if you want to have
>> REST, you coud not have Tx. Or do I miss something?
>
> Umm, session state refers to the meaning of requests being dependent
> on the state of prior requests (think FTP commands being relative
> to the CWD). The only comparison in HTTP would be if a cookie were
> used in the request and the server ignores the method or URI based
> on the content of the cookie.
>
> Transactions are another thing entirely -- they are a deliberate
> decision by the server to separate the client's actions in a parallel
> universe of resources until some commit action is made to merge the
> universes. They can easily be done in a RESTful manner without any
> changes to the protocols -- just include a commit button that has
> the effect of making the private resource set public.
>
> Transactions are not typically used in RESTful systems, aside
> from the simple type of preview/commit changes in wiki edits,
> because they don't provide any benefit. Outside of some rather bad
> textbooks and some very fragile internal systems, transactions
> are avoided in practice by real distributed systems because it is
> far simpler and more reliable to design the interaction such
> that transactions aren't necessary. For example, by building a
> contract on the client that doesn't rely on server state and
> posting the final contract for approval, or using separate
> staging servers or publish toggles for content management, or
> by using journaled deltas rather than global state, etc.
>

I agree whole heartedly, but...

Some set of users will still want/need DTX, and I'd rather them have a
RESTful way of doing it than having to install a SOAP stack or ORB on
both the client and server.

I had a similar argument with Mark Little awhile back over Business
Activity:

http://bill.burkecentral.com/2007/09/18/distributed-compensation-with-rest-and-jbpm/
http://bill.burkecentral.com/2007/09/18/marks-rebuttal-on-compensations-with-rest-and-jbpm/

What I got out of the conversation was that you need solid design
patterns and you need a trusted coordination service. IMO, the RESTful
community really needs to nail down how BA and even governance should be
done, as IMO, a resource-oriented approach is much more scalable and
flexible than what currently is being done in the SOA world.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com