RESTful Tuplespaces: Feedback

I promised some analysis and a summary of feedback on my previous post. The holidays caused some delay, but I might as well wrap this up.

First, I have to come clean and admit that "RESTful tuplespace" is an oxymoron. There are probably several senses in which this is true, but the most basic is that tuplespaces violate the REST constraint of statelessness. Because of this, server scalability is a real problem, and this is what drives the ongoing search for a viable distributed tuplespace architecture. In my example, I simplified greatly by leaving out any considerations of resource management on the server side (leasing, for example), simply because it's such a nasty problem. At best what I have really done is demonstrate how one might construct a gateway between a hypothetical Tuplespace Transfer Protocol (TTP) and HTTP.

As far as feedback goes, much of it consisted of general expressions of interest in the exercise. On one hand, REST is a hot topic in web services architecture discussions these days (see, for example, Adam Bosworth's "Learning to REST", or this discussion of REST and SOA on the SOA mailing list). On the other hand are questions about whether space-based programming models might help solve some synchronization and coordination problems in Web Services. Mike Champion seems particularly interested in this question. I also had to laugh when I read Bill de hÓra's comment about the ability of tuplespaces to "help defer orchestration hell". I chuckled because I am also prone to this sort of magical thinking. (More on that another time...)

Finally, on the more practical side, Bryan Thompson offered this promising suggestion for solving the atomic GET+DELETE problem using ETags. With his permission, I'll quote his message at length:

I approach the need for an atomic GET+DELETE (as an locking mechanism) using ETags. You can specify that the ETag has not changed on the DELETE operation as a means for a client ot reliably know if it was successful in DELETEing the resource whose representation it read with a prior GET. If the DELETE fails, then some other client has the resource's representation.

The resources accessed in the manner are essentially locks that contain the URI of the resources that the client wants to process. Those locks are stored in a workflow queue, which is just an indexed view of the child resources of the queue.

See http://wiki.cognitiveweb.org/WorkflowQueues

Except that it does not discuss the use of ETags on that page. (I need to update it for a couple of things. Adding an ETag discussion is one of them.)

Thanks,

-bryan