Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > This works for small transactions asking for Web pages, but when Web > > services start running transactions that take some time to complete over > > the protocol, the model fails. "If it takes three minutes for a > > response, it is not really HTTP any more," Box said. The implicit assumption is that the request and response need to be tightly coupled, with a corollary that the transport layer (HTTP in this instance) should resolve the conundrum for you. Soldiers in passes indeed! 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? Box's implication is that HTTP should do this for you. I disagree. Someone said that it is best not to hide network plumbing issues from developers (due to latency, unreliability, etc.)....so I think the implication is a poor one. At least until network bandwidth becomes virtually infinite with zero latencies. I'm not going to hold my breath... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
|
