>  > 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


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>