[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: MS thinks HTTP Needs Replacing???
[Michael Brennan] > > From: Andrzej Jan Taramina [mailto:andrzej@c...] > > <snip/> > > > One easy way to solve this problem is by decoupling the > > request from the > > response. Send a request (with an indication of how to > > respond....a URL, Web > > Services Callback, and email address etc.) and receive a "transaction > > received" HTTP response (which should be almost immediate). > > Some time > > later the service uses the response indicator info to send a > > "real" response to > > the transaction. Damn....that sure sounds like message > > queuing doesn't it? > > That's the right way when you can get away with it. But some interactions > can't afford an open-ended contract for when the response finds its way back > to the originator of the request. > There's another way to approach it that is more consistent with the HTTP RFC. When you POST data to a server at a URI, one of the possible intended outcomes is that the server should create a new resource that is "subordinate" to the originally addressed one. If so, it should return a CREATED response with a URI for the new resource. For example, if you requested a transaction at http://www.illustations.com/bookstore/the_latest_book you might be informed to look for your results (tracking notification for the shipment, perhaps) at http://www.illustations.com/bookstore/the_latest_book/shipment/some_tracking _number (This certainly should count as a "subsidiary" resource) If the server cannot return a response immediately, then, it fits the concept of operations for the server to return a CREATED message that says when it expects the new resource to contain the data, and what url it will be at. The requestor can then GET that resource whenever it desires, checking to see if it has been completed yet. By the same token, the original POST could have contained a specification of the maximum allowable time for the results to be ready, if that were important. This also would work well with SOAP, letting you use just its messaging capabilities without any RPC function invocations. This fits the RFC conops, the REST architecture, and yet is not message queueing and is a lot simpler than message queueing. Of course, for this to work, both parties must be able to know what to expect and how to designate, for example, the max allowable time. These are a few of the "contract" issues that Len has been emphasizing. Cheers, Tom P
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|