Roedy Green wrote:
On 29 Nov 2005 10:16:54 -0800, "Bruce Wood" <br*******@cana da.com>
wrote, quoted or indirectly quoted someone who said :
Binary protocols are efficient and easy to work with until you come up
against a system that has different parts written in different
languages. Then they quickly become a nightmare. For all of its
inefficienci es and problems, SOAP doesn't suffer from that one critical
flaw.
A soap creator/parser is much more complex that a package to deal with
the wrong endianness of data. Just count lines of code to convert
binary to char to byte to char to binary compared with little endian
to big endian network order.
But it's not about just big-endian versus little-endian and low-level
concerns like that.
My point is that tools and frameworks for producing / consuming SOAP /
Web Services on all sorts of platforms and languages are sprouting up
like mushrooms. I don't have to write the bare-bones code that worries
about serialization, transport, and even (latterly) security and
encryption because it's all being done for me by hundreds of vendors.
The beauty of SOAP / WS isn't that it's easy for any particular vendor
to support it on any particular platform. In fact, as you pointed out,
it's not: it's bloody difficult, and getting more difficult by the
month as higher and higher level standards are created.
Instead, the beauty of SOAP / WS is that I as a consumer can buy an
application server that is designed to run services written in Java
from one vendor and a client platform for .NET clients from another
vendor and the two work together. CORBA never managed to get that much
market penetration. So far as I know the field of players trying to do
that sort of thing with RMI or .NET Remoting is thin indeed. If I can
grab products off the shelf and have them interoperate out of the box,
I don't care how much of a pain it was for the vendor to create them.
I'm happy. I'm even happier when vendor #1's client platform turns out
to be crap and I can just dump it and substitute another platform from
a competing vendor and it still works with my server-side Web Services.
I like the security of knowing that my whole system doesn't live or die
based on one vendor's ability to deliver, or even one language's
ability to deliver.
As well, my business partners can choose their own platforms and
languages and call my Web Services without knowing or caring what
language they're written in. Try doing that with .NET Remoting.
There's nothing wrong with RMI / Remoting / CORBA / whatever. They're
great technologies. However, they just don't have the vast market
penetration that Web Services is shaping up to have. As I said, if
interoperabilit y between heterogeneous platforms is high on my list of
requirements, I probably won't be considering Java RMI as my protocol.
If I'm in a closed, all-Java shop, then that changes everything. Use
the right tool for the right job... and there are many jobs for which
SOAP is the right tool.