So why the heck would anyone in their right mind want to choose SOAP over XML-RPC?

Well for one thing, SOAP has more capabilities and supports a document model which is less restrictive than the more typical request and response call patterns typical of XML-RPC. For example, there is no easy way in XML-RPC to return error codes of different types.

Also, SOAP conversations can be designed around multiple service nodes, splitting up and divvying out the various message parts to be taken care of by the most relevant server. Later all of the responses are collected and passed back in a unified message response, just like magic.

Finally, messages can define for themselves what encoding they want to use, e.g. the one that they know is the most appropriate for a given conversation.

Yes, but what about all the extra amount of overhead? Isn't there a big performance hit?

Actually, SOAP is nothing more than a thin additional envelope around XML-RPC. What most people do not realize is that XML-RPC is already based to a large degree on the core elements of SOAP architecture.

The truth of the matter is that XML-RPC was split off from the initial design when someone became impatient with the slow progress of moving on with the original SOAP specifications.

For those of you still awake who find this tantalizing stuff, here is another interesting reference.