[Zope3-dev] RE: Web Service-ish Transactions (was re:UI effort at Sprintathon )

[sean.upton@uniontrib.com]

Ugh... though the problem with this at the web-services level is that an
XML-router or HTTP load-balancer might redirect some of these calls to
different cluster nodes.  I guess this is true with any "transaction" that
spans requests: they need to be cluster-safe in a production environment.
Something like ZODB versions handles this within a ZEO cluster (thankfully),
but high-level application transactions would likely have to go to the same
node.  The same problem might exist between threads. I guess it is hard to
keep this from getting messy, without reverting to a tried-and-true
replicated transaction framework, which is likely to be running lower at the
storage level...

I guess I'm wondering this because, in a current Zope2 project, I am using a
storage (DirectoryStorage) that does not (at the moment?) support ZODB
versions; in the long-run for this app, I eventually want to build-out into
a custom fat-client that to some extent stateful in its dealing with changes
to data stored in the object database, and I can't think of how to do it
without leveraging ZODB versions...

Sean

-----Original Message-----
From: Jeffrey P Shell [mailto:jeffrey@cuemedia.com]
Sent: Thursday, October 24, 2002 1:21 PM
To: sean.upton@uniontrib.com
Cc: zope3-dev@zope.org
Subject: Web Service-ish Transactions (was re:UI effort at Sprintathon)


On Wednesday, October 23, 2002, at 09:08  PM, sean.upton@uniontrib.com 
wrote:

> On a tangent, but... this thread bring up something else I've thought 
> about
> Zope UIs beyond simple HTML: it sure would be nice to have a way to do
> long-running transactions for fat clients that may perform a single
> transaction across several, spaced-out requests (say, via XML-RPC).  I
> suppose one way to do this is ZODB versions, but I'm curious as to 
> other
> ideas for accomplishing this (perhaps with a higher level component)?
>
> For example, a simple HTML form with several fields could have a 
> get/set
> method associated with that field, upon a change event for a field 
> 'foo',
> the browser JavaScript would trigger XML-RPC call to server to call the
> setFoo() method, and so on, and finally do a permanent commit with some
> possible before-commit method call to the item.  This would mean that
> unfinished work that isn't fully committed is both stateful and 
> recoverable,
> I think?

There are various (and probably overly complicated) Web Service based 
transaction models and specs floating around out there like 
WS-Transaction [1] (which I haven't read over).  I recall reading 
somewhere that the traditional ACID style transaction wasn't as 
applicable in Web Service scenarios.  I don't know if they were talking 
about transactions at the business-process level, or at a level like 
you describe where a lot of Web Service calls (be they XML-RPC, SOAP, 
or some other similar protocol) may occur between a client and one or 
more servers that need to be wrapped up into a single transaction unit.

.. [1] http://www-106.ibm.com/developerworks/library/ws-transpec/

Interesting results pop up on Google:
http://www.google.com/search?q=Web+Services+ACID+Transactions