« links for 2007-04-04 | Main | No CSS »

Step 3

James Pasley: "If you’re ever tempted to put a retry loop into your REST client just in case the HTTP connection is refused, then you need to face up to the need for SOAP (with WS-RM of course)."

Alternatively, one could face to up to HTTP, with either HTTPLR, or BTF2.0, depending on whether you want half or full duplex comms. Why stay with HTTP? For one thing, numerous firewall administrators ensure many reliable b2b transmission scenarios have to run over HTTP. But there are other reasons to think a REST based protocol design will be the basis of over-web messaging in the coming years, chief among them, Atom Protocol.

It occurs to me that the next version of HTTPLR should/could extend Atom Publishing Protocol. The Atom Protocol hook into reliability is the fact that each time a document is created its URL is returned in the HTTP "Location:" header. With HTTP, once there is a shared token between the sender and receiver, there is a basis to achieve a reliable once and only once protocol exchange in 3 steps - one, submit the document; two, return the document token; three, acknowledge the token was received. The trick will be distinguishing the the 3rd step (final transmission) from a regular content update. But since Atom Protocol is smart about use of HTTP methods, I think it is a very doable thing to define a reliable state machine on top of it.

There are a number of reasons to choose Atom Protocol as the substrate for web-scale reliable messaging. First, a ton of software will be written to target APP in the next few years, and there is plenty of scope for extending the protocol; this suggests openly available and flexible software stacks. Second, since all document collections in Atom Protocol are served as Atom Feeds, it has inherent support for systems management and end to end reconciliation. Third, Atom entries have identity and are natural envelopes, unlike SOAP, where identity and true enveloping requires further specification (essentially raw Atom presents a better basis for interoperation than raw SOAP). Fourth, Atom Protocol can support binary content transmission not just XML, and thus can transmit arbitrary payloads. Finally, because Atom Protocol respects media types and deployed HTTP infrastructure, independent proxy inspection and security check-pointing can be installed cleanly, also eliminating the need to rewrite 2 stack layers and buy XML appliances to support and secure SOAP backed web services. It seems to be a question of when, rather than if, this will get built out.


April 4, 2007 11:24 PM

Comments

assaf
(April 5, 2007 12:48 AM #)

You could also just put a queue in there.

With all due respect to protocols, let's not confuse them with working products.

Bill de hOra
(April 5, 2007 10:22 AM #)

"You could also just put a queue in there."

Mapping a queue to HTTP is surprisingly awkward.

http://www.dehora.net/journal/2004/11/rest_uris_and_queues.html
http://www.dehora.net/journal/2004/05/activemq_restful_jms_sort_of.html

Assaf
(April 5, 2007 05:56 PM #)

"If you’re ever tempted to put a retry loop into your REST client just in case the HTTP connection is refused"

Whenever you read vendorspeak, it's a safe bet there's a lot of hidden assumptions under the surface, that are left unexplored to drive the statement to its logical conclusion (and inevitable purchase order). And I only know of one way to avoid that trap.

So I'm taking the statement at face value. If you need to retry, and obviously you're not time critical, just put the request in a queue. Have code to pick it up and send it, removing it from the queue once you get a successful response. The queue will handle retries, back-off and eventual failures for you. A WS-RM does not work any better.

Note that at no point do you need to map that queue to HTTP. You're just using it to buffer the code that needs to send a request, and the receiver of that request. Everything else is premature assumptions on some requirement that was not expressed so far. And unless you explore those, all logical fallacies are equally true.

I'm not dealing with HTTP access to the queue itself, that's a separate problem (which WS-RM does not address either, so why go there?) I'm not dealing with duplicate delivery, because no one said anything about the semantic of the message receiver, but if we did, we might want to talk about the benefit of idempotent receivers. And in fact, I ignore assuming any requirement not expressed, because ... see above about logical fallacies.

Toby
(April 11, 2007 12:11 AM #)

Assaf, your suggestion to introduce a 'queue' presupposes that it's not a synchronous request.

If it's a synchronous request, then a simple pure HTTP solution follows along the 3-step lines Bill mentioned.

Assaf
(April 11, 2007 06:54 AM #)

Toby, I beg to differ.

Asynchronous processing can use synchronous protocols, and vice versa. By placing a queue between my application and the sender, I'm simply allowing my application to go about its business, while the sender can figure out the right time to make a request.

In my experience, whenever someone asks for SOAP over JMS or WS-RM, if you dig down and query the actual problem they're trying to solve, most often you land on the need to decouple the application flow from the data exchange.

They want the message to go from one point to the other, ignore downtime and network latency, without blocking the application.

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/2065