I'll share the sentiment, “just use JSON.”

SOAP, quite frankly, is massive overkill. Ditto WSDL. Why? Because, in the real world (imho...), things don't actually “change” much and thus you almost never have a need to “discover” anything about the server/service with which you desire to communicate. It's not a moving target:   it's a fixed target. (At least for your expected tenure with the company.) :-)

In any case, if and when the interface between the two parties does change, it'll take much more than “a new WSDL” to actually make it work. Let's face it:   you're gonna have to change the code.

In the real world, programs simply don't say, “gee, I'd like to do 'this'... so let me discover something that does 'this,' and then discover how to talk to it, and actually succeed in doing so.” Even though the WSDL specification et al are designed for more-or-less that scenario ... it just don't happen in real life, and so it is nothing more than a solution in search of a problem.

Nearly all the time, “RPC” means “a web browser program, written in JavaScript, talking AJAX.” On the very rare occasions when it doesn't, the two machines in question are sure to be engaging in exactly the same conversation for many years to come. Ergo, the added complexity of XML RPC is simply wasted.

I am a firm believer in shooting for “a complete and thorough solution to your problem,” but not for “a complete and thorough solution to more than your problem.” A committee dreamed up RPC XML. One guy dreamed up JSON. I think that means something really important ...