From: Gavin Thomas Nicol (gtn@ebt.com)
Date: Thu May 18 2000 - 23:04:20 PDT
> lies about the motives of people you don't know. (Hint: firewalls,
> discoverability, implementability.)
These are all important goals, and XML-RPC and SOAP will be useful because
of them (hey, I built a loosely-coupled message bus using XML-RPC, and
it was great because the messages were "heavy" so the bandwidth used
to effect ratio was high (which is interesting, because CORBA/DCOM have
similar design tradeoffs)).
As such I don't *dislike* SOAP, I dislike it being over-hyped. For quick
and dirty projects, or loose integration where there is little chit-chat
on the wire, SOAP is ok. Otherwise it sucks.
> "smaller": yes, the data is smaller. The implementation is
> much larger.
I debate the latter. Really SOAP et al. are just a tunneling of
a serialized method invocation on top of HTTP. The code for marshalling
and unmarshalling is *at least* as complicated as anything else
if you include the XML parser (which isn't hard, but is non-trivial).
Compare XDR to XML....
I would agree that binary is *harder* to implement.
> "language-independent": XML-RPC has bindings to more languages than ILU
> or CORBA, despite being a fraction of their age.
Yep. Then again though, XML-RPC does less than either of those two so it's
not quite a fair comparison.
Interestingly, I know of a company that had performance problems in
enterprise deployments because their protocol had too much chit-chat.
They decided to use XML-RPC, and the problem became much worse, so they
abandoned it. The problem was that they were solving the wrong problem...
replacing the IPC mechanism instead of fixing interfaces.
This archive was generated by hypermail 2b29 : Thu May 18 2000 - 23:04:31 PDT