[
Lists Home |
Date Index |
Thread Index
]
Sean McGrath wrote:
>
> Here is one possible reading of the tea leaves of the HTTPectomy meme.
>
>...
>
> 2) SOAP will be transport independent. Doesn't that sound really appealing?
> This mantra is already gathering pace. The fact that most developers trust deep
> magic to make RPC work over both HTTP and SMTP without
> thinking about the fundamentally different transport model of each is testimony
> to how powerful that mantra is.
You've read my damn mind. Most protocols are transport independent to a
point. They say: "this protocol will run over any other protocol with
the following characteristics." But the SOAP spec says: "this protocol
will run over any othr protocol. Period." This raises the question in my
mind of whether it is really a protocol or a file format. Obviously
SOAP-RPC is a protocol. But if you adhere to the minimum requirements of
SOAP the only guarantee you get is the ability to send an envelope and
body into the ether. You aren't guaranteed a response. The mechanism you
would use to get a response is undefined outside of HTTP. Well, that
sounds a lot like XML or MIME, (i.e. data formats) not like SMTP, HTTP
or POP (which are true protocols).
The other odd thing is this idea of taking a message on one transport
and bridging over to six others. Wasn't that really popular on email
until we moved all of the servers into the same address space? Why do we
want to bring it back? I'm really asking the question. For email, two
protocol hops seems to be sufficient: POP, the pull protocol for the
disconnected machine behind the firewall to talk to the "internet" and
SMTP the push protocol for once it is on the Internet. Why will web
services require more than two (or even one) transport protocol?
> 3) Developers will be urged to write to the SOAP "API"s exclusively in order
> to insulate their systems from transport dependencies. This will be
> marketed as something all conscientious developers should do.
"Develop for our platform so you'll be platform independent."
>...
> It is not that smart people working for the software vendors don't realize
> that RPC sucks.
> They do. But many ordinary developers, short on time or inclination to
> think about the
> future of the systems they are building, are easily enthralled by the
> surface simplicity
> of RPC, and are the guys who buy stuff from vendors.
Guilty!
>...
> By the time they are doing that, I fear the world will have forgotten that REST
> presented an alternative, and I would argue significantly more powerful,
> data-flow based approach to building systems.
I have more faith in the industry's ability to come to its senses. I
also think that there will be a period where the differences in the two
approaches will be stark.
Paul Prescod
|
