Cart
[Home] [By Thread] [By Date] [Recent Entries]
1/21/2002 9:37:18 PM, Mark Baker <distobj@a...> wrote: > >You'd be surprised. The architectural style used to craft HTTP is >certainly capable of a lot more than what HTTP can currently do. OK, I think something is beginning to penetrate ... REST is an "architectural style" of which HTTP is an instance. A reliable messaging infrastructure for web services could be described in that architectural style, but that is not the same as saying that HTTP as implemented in IIS/Apache/etc. could support that messaging infrastructure. Is that more or less correct? Sorry if I'm being dense .... As a concrete example, consider Miles Sabin's scenario of a web service that takes hours to complete because of some human intervention being required. It *would* be easy to envision this being implemented with an SMTP message invoking the service and another SMTP message returning the result. On the other hand, this could be implemented as an HTTP PUT of the request to the provider's server follwed by a PUT of the response to the requestor's server. Or the requester periodically doing a GET to the requestors server to see if the response is done. Sounds a lot like SMTP and POP to me ... am I missing some fundamental reason why SMTP/POP is "asynchronous" and HTTP is "synchronous?" Doesn't the intrinsic sychronousness adhere in the application level, not the protocols themselves? Anyway, my point here is that it would seem that reliable messaging infrastructures for web services don't need new underlying protocols, they need a different coordination mechanism, i.e., queuing, caching, forwarding, filtering.... rather than a simple RPC of POSTing a SOAP mesage, and the HTTP response is the returned value. What am I missing here?
|
