It's always the same: "Industry Standards" are propagated, regardless
of actual performance or suitability. Just because SOAP is the hype,
all major vendors seem to promote it, without even thinking about
alternatives....
Publishing a "custom" client class library (for all major programming
languages) instead of WSDL would provide a tenfold better performance.
I wonder when the anti-SOAP backlash will happen....
sure a custom or lightweight standard would give much higher
performance, but then we run into all kinds of problem areas:
technology - .net apps talking to mainframes...
Platform mapping - endianness
Language mapping - Java int is signed 32 bits, C++ has un/signed 1/2/4
bits depending upon complier.
etc...
All of these areas have been addressed in various ways by the various
comms standards: DCOM, CORBA, RMI, SOAP, etc..
Hell, most of the custom lightweight standards I've seen go over TCP/IP,
yet there are times when its preferable for sending data over raw UPD
sockets (as I've had to do in real time Telecoms apps).
What this boils down to, is that there is no 'Right' or 'OneTrue' way.
Each application needs to chose the right distributed technology for its
own characteristics.
Soap allows multiple different technologies, languages, platforms and
environments to communicate via a neutral 'self describing' means - but
this comes with a price - as you say slow performance.
but keep in mind, this slow performance may not actually be the bottle
neck within the system, so 'curing' it would be a false victory.
Andrew