[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Mike Champion [mailto:mc@xegesis.org]
> Sent: 26 February 2002 17:09
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] MS thinks HTTP Needs Replacing???
>
[...]
> Among the problems with HTTP, said Box, is the fact that it is a Remote
> Procedure Call (RPC) protocol; something that one program (such as a
> browser) uses to request a service from another program located in
> another computer (the server) in a network without having to understand
> network details.
Hmmm...
Fielding: "HTTP is not RPC"
http://www1.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2
> 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 problem, said Box, is that
> the intermediaries -- that is, the companies that own the routers and
> cables between the client and server -- will not allow single
> transactions that take this long."'
Why does something stop 'being' HTTP just because it takes a long time to
get a response? What about persistent connections? What about HTTP Events
(don't have reference to hand)?
"...We at least have to raise the level of abstraction, so that we have an industry-wide way
to do long-running requests -- I need a way to send a request to a server and not get
the result for five days."
Er. Asynchronous messaging?
"Microsoft has some ideas (on how to break the independence on HTTP),
IBM has some ideas, and others have ideas. We'll see," he said. But, he
added, "if one vendor does it on their own, it will simply not be worth
the trouble.""
It's not clear its worth the trouble anyway!
So the process is: build a whole pile of stuff on top of an existing architecture,
but don't play to that architectures advantages. Blame the architecture for not
conforming. Define new architecture.
This would be fine, IFF, the requirements had changed. Personally I don't see
anything in web services that requires new technologies, or fundamental reworkings
other than the possibility to make someone a lot of money.
L.
|