Mark said:
Thanks. I once saw a thick book on XML at the office, but soon put it
back as there was an aweful lot to it. But looking at XML-RPC, I saw
how easy it was to implement RPCs. It's so fuss-free and generic that
its difficult to imagine wanting to use any other mechanism.
Kinda makes you wonder what the whole point of .Net is.
It hinges first around MSIL, a bytecode similar to the Java's VM but
with some enhancements to make it more suitable for "ahead-of-time"
(installation time) compilation to machine code, as well as for some
slightly less-traditional languages (e.g., tail-recursion optimization
for Scheme and many other such languages); secondly around the CRL,
Common Runtime Library, and many other libraries (for windowing, both
local and on-net; database access; etc, etc) extending it; thirdly
around web services (centered on the more ambitious SOAP protocol as
"designed-by-committee" richer successor of XML-RPC); and keeps layering
on top of this. FWIW, I do agree that SOAP is much more complicated
than XML-RPC, and that this is an important disadvantage, but no doubt
the vast committee (of which MS was but a part) could not reach any
agreement for simpler things -- it IS harder to make something "so
simple it obviously has no deficiencies", so it ends up instead being "so
complicated it has no obvious deficiencies", as Hoare put it -- and this
goes double with design-by-committee.
".NET" is a huge, vastly layered (and sometimes not WELL layered) blob
of things kept together first and foremost by marketing needs (but is
J2EE really ALL that different in this respect...?-). Using SOAP
instead of XML-RPC is a drop in the .NET ocean, IMHO.
Alex