The only minuses I can think of related to JSON-RPC is that it’s hard to sell it as enterprisey and it doesn’t have a native date representation. Other than that, on the pluses side, it has a smaller footprint, it is easier to parse/process, it provides some rudimentary type safety (although not as good as XML-RPC) at the protocol leve, there are parsers/encoders available for pretty much any imaginable language, it happily bypasses any firewall allowing regular http traffic, and it is definitely the most natural choice for web apps.

Doesn’t change the discussion of interconnects as that’s mostly a discussion of languages to write the program in, not which standard to pick, no?

I am just learning Erlang now – it’s a very different programming model and syntax than I am used to but I was able to build a simple server-and-client passing messages back and forth as my second toy project, that took under an hour – with the help of the book! Total lines of code = maybe 30.

Erlang’s programming model obviates most problems encountered when working with multiple threads and processes. Once I got my head wrapped around it, it’s easy to program in, at least as far as I’ve gotten.

Not sure you’d want to leave that number of sockets open all the time anyway. (UDP!)

Messaging is also nice to send commands to nodes that might be offline or temporarily unreachable. In the case of mobile devices, they won’t always be able to be contacted.

rpc/encoded is extremely verbose and unwieldy

document/literal is a much more efficient and flexible format.

so your assessment above should really treat these two flavours of SOAP as different and assess them individually.