[
Lists Home |
Date Index |
Thread Index
]
> > 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
|
