RPC vs. ServiceBus Style SOA

Question

What would be the pros and cons of these architectures?

1. By RPC I meant remote procedure call services like WCF, WebServices etc.

2. Then on the other side, there's the more message oriented frameworks such as MSMQ, NServiceBus, ServiceStack etc.

3. Then there is the hybrid approach such as WebAPI, which is some sort of a remote Active Record Pattern (Out of the box it only supports a very limited number of verbs such as "Get", "Put" "Post" etc.).

Disregarding, how it's actually implemented (aka. I don't really care about durability, transaction etc. because all that can be implemented regardless of the abstraction), what would be the benefits and drawbacks of these abstractions?

Again, no low level implementation details please, I just want the difference in terms of sound architecture, best patterns and practices, or even circumstances that would be most appropriate to employ each and why.

Filemon

Answer 1

The only benefit of RPC is that it looks familiar and gives developers the illusion that a service call looks and acts just like a normal method call.

Otherwise RPC method signatures are tightly-coupled, fragile and brittle and ties the contract of your service to its single server implementation. Here's an earlier answer comparing the same WCF and Web API RPC services re-written in a message-based service.

For background reading I've described the differences between RPC vs Message based services in the WCF vs ServiceStack interview on InfoQ as well as what a message-based service is and their many advantages.

Waddell