Comments on: Hypertext is the Transaction Engine http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine Wed, 08 Feb 2012 18:56:31 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Bill Burke http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-50379 Bill Burke Fri, 15 Jan 2010 00:39:57 +0000 http://www.subbu.org/?p=1095#comment-50379 Subbu - You've used some of these "classical" distributed technologies to build some of these facades. You're happy with how they work and used? I'm not... I think REST really has the potential to shine in this space. Subbu – You’ve used some of these “classical” distributed technologies to build some of these facades. You’re happy with how they work and used? I’m not… I think REST really has the potential to shine in this space.

]]> By: subbu http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-50273 subbu Wed, 13 Jan 2010 18:21:07 +0000 http://www.subbu.org/?p=1095#comment-50273 Bill - for cases that involve coordination between several servers, I think it is better to designate some resource one of those servers (or a new one) act as a facade between those other servers. Then that resource is free to use an appropriate technology to coordinate the unit of work (the technology may be classical 2PC or some sophisticated engine). That way you get the best of both worlds - clients and servers use HTTP for what it is good for and the facade and the rest of the servers use whatever transaction/coordination engine. By the way, use of one-time tokens/URIs is a one of the fundamental and recurring patterns that I used to the book. Once we accept the notion that one resource can have several URIs, and that those URIs may be ephemeral opens up lots of new avenues open up. This idea is not new - it is very commonly used for security (hint: nonce). Bill – for cases that involve coordination between several servers, I think it is better to designate some resource one of those servers (or a new one) act as a facade between those other servers. Then that resource is free to use an appropriate technology to coordinate the unit of work (the technology may be classical 2PC or some sophisticated engine). That way you get the best of both worlds – clients and servers use HTTP for what it is good for and the facade and the rest of the servers use whatever transaction/coordination engine.

By the way, use of one-time tokens/URIs is a one of the fundamental and recurring patterns that I used to the book. Once we accept the notion that one resource can have several URIs, and that those URIs may be ephemeral opens up lots of new avenues open up. This idea is not new – it is very commonly used for security (hint: nonce).

]]> By: Bill Burke http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-50251 Bill Burke Wed, 13 Jan 2010 13:51:25 +0000 http://www.subbu.org/?p=1095#comment-50251 Subbu, when you have one client dealing with one service, I believe you can hide the fact that a transaction is occurring (whether this be an acid or compensating tx isn't important, IMO). On the other hand, if a client is coordinating work between different services, the client has to be aware that coordination is happening especially if the client is coordinating totally disparate, isolated, standalone services/resources. Think of a client integrating between a Purchase Order, Inventory, and Billing system. All standalone and unaware of one another. Coordination itself can become non-trivial especially when you factor in long running (days, weeks) interactions, crashes, and recovery. They become even more complicated when you have to guarantee that certain interactions will happen. This is why I believe there is a place for generic middleware services that handle coordination in the RESTful world. (And why REST-* was created by us (rest-star.org)). BTW, I outlined my ideas and directions here: http://bill.burkecentral.com/2009/09/21/credit-cards-transactions-and-rest/ I think links and other RESTful properties can hide a lot of the implementation details and give a lot of flexibility to both the application developer and generic service providers (like a TM or workflowmanager). For example, Mike Amundsen introduced me to the token idea for a problem I had with acknowledgement within REST-* messaging. It worked beautifully to hide implementation details and make the overall service much simpler. BTW, we need more engineers like you and Mike rather than the priests and acolytes that permeate the REST community. I'm really looking forward to your book. Subbu, when you have one client dealing with one service, I believe you can hide the fact that a transaction is occurring (whether this be an acid or compensating tx isn’t important, IMO). On the other hand, if a client is coordinating work between different services, the client has to be aware that coordination is happening especially if the client is coordinating totally disparate, isolated, standalone services/resources. Think of a client integrating between a Purchase Order, Inventory, and Billing system. All standalone and unaware of one another.

Coordination itself can become non-trivial especially when you factor in long running (days, weeks) interactions, crashes, and recovery. They become even more complicated when you have to guarantee that certain interactions will happen. This is why I believe there is a place for generic middleware services that handle coordination in the RESTful world. (And why REST-* was created by us (rest-star.org)). BTW, I outlined my ideas and directions here:

http://bill.burkecentral.com/2009/09/21/credit-cards-transactions-and-rest/

I think links and other RESTful properties can hide a lot of the implementation details and give a lot of flexibility to both the application developer and generic service providers (like a TM or workflowmanager). For example, Mike Amundsen introduced me to the token idea for a problem I had with acknowledgement within REST-* messaging. It worked beautifully to hide implementation details and make the overall service much simpler.

BTW, we need more engineers like you and Mike rather than the priests and acolytes that permeate the REST community. I’m really looking forward to your book.

]]> By: Peter Williams - What are links http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49724 Peter Williams - What are links Thu, 07 Jan 2010 05:56:33 +0000 http://www.subbu.org/?p=1095#comment-49724 [...] To make the issues a bit clearer let me use and example lifted from the article that got me thinking about this most recently.1 [...] [...] To make the issues a bit clearer let me use and example lifted from the article that got me thinking about this most recently.1 [...]

]]> By: subbu http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49670 subbu Wed, 06 Jan 2010 16:40:26 +0000 http://www.subbu.org/?p=1095#comment-49670 Thanks for pointing out to your post. Thanks for pointing out to your post.

]]> By: Guilherme Silveira http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49655 Guilherme Silveira Wed, 06 Jan 2010 12:49:12 +0000 http://www.subbu.org/?p=1095#comment-49655 Hello Subbu! Nice (and short) description! I believe it goes along with what I mentioned on "transaction do not exist in a restful world".... its a matter of thinking about your semantics and hypermedia instead of abstract transactions concepts: http://guilhermesilveira.wordpress.com/2009/12/17/transactions-do-not-exist-in-a-restfulie-world Nice post... Guilherme Hello Subbu!

Nice (and short) description! I believe it goes along with what I mentioned on “transaction do not exist in a restful world”…. its a matter of thinking about your semantics and hypermedia instead of abstract transactions concepts: http://guilhermesilveira.wordpress.com/2009/12/17/transactions-do-not-exist-in-a-restfulie-world

Nice post…

Guilherme

]]> By: Mike Amundsen http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49639 Mike Amundsen Wed, 06 Jan 2010 08:29:28 +0000 http://www.subbu.org/?p=1095#comment-49639 " Essentially the link represents the state of the transaction in an opaque manner, and may contain identifiers, security tokens and other validators." no disagreement here as i've used the same approach in my example. ” Essentially the link represents the state of the transaction in an opaque manner, and may contain identifiers, security tokens and other validators.”

no disagreement here as i’ve used the same approach in my example.

]]> By: subbu http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49638 subbu Wed, 06 Jan 2010 08:16:13 +0000 http://www.subbu.org/?p=1095#comment-49638 The fact that there is a transaction is an implementation detail in itself. Essentially the link represents the state of the transaction in an opaque manner, and may contain identifiers, security tokens and other validators. The fact that there is a transaction is an implementation detail in itself. Essentially the link represents the state of the transaction in an opaque manner, and may contain identifiers, security tokens and other validators.

]]> By: Mike Amundsen http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49635 Mike Amundsen Wed, 06 Jan 2010 08:07:52 +0000 http://www.subbu.org/?p=1095#comment-49635 i understand the clarification, now. so what data regarding transactions might you encode in a link that should not be leaked to the client? i understand the clarification, now.

so what data regarding transactions might you encode in a link that should not be leaked to the client?

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2010/01/hypertext-is-the-transaction-engine/comment-page-1#comment-49634 Subbu Allamaraju Wed, 06 Jan 2010 07:42:37 +0000 http://www.subbu.org/?p=1095#comment-49634 Clarified the text. Clarified the text.

]]>