[
Lists Home |
Date Index |
Thread Index
]
1/21/2002 9:37:18 PM, Mark Baker <distobj@acm.org> 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?
|
