XML-RPC is vastly underpowered for many tasks (for instance, any that require strings in a language other than English) whereas SOAP is perhaps overcomplicated for many jobs. There is, however, a convenient middle ground. The really key idea of both SOAP and XML-RPC is that you can pass an XML document over the web using HTTP POST. The exact format of that data doesn’t really matter much as long as both client and server agree on what it is and what it means.

For example, if an online broker such as Ameritrade wanted to provide its clients specialized trading software, it could use any XML format it wanted to send the data back and forth. It might choose to ignore the SOAP envelope completely and just send the getQuote and Buy elements I’ve been placing in the body of the SOAP requests.

There are still a lot of advantages to using a standard format for exchanging data rather than rolling your own every time you need one. Most importantly, a standard format like XML-RPC or SOAP makes it much easier for other developers to integrate their systems with yours. Furthermore, if your system can be easily modelled as a set of procedure calls, then choosing XML-RPC or SOAP allows you to pick from a variety of implementations that take care of a lot of the details for you. Therefore, you shouldn’t go the custom protocol route without some serious thought as to whether it’s truly appropriate. Nonetheless, if a custom XML vocabulary does seem to suit your problem, feel free to define one.