RPC and SOA ServiceBus Style SOA

Question

What are the pros and cons of these architectures?

• By RPC, I meant remote procedure call services such as WCF, WebServices, etc.

• Then, on the other hand, there are more message-oriented frameworks such as MSMQ, NServiceBus, ServiceStack, etc.

• Then there is a hybrid approach, such as WebAPI, which has some kind of remote active recording template (out of the box it only supports a limited number of verbs, such as "Get", "Put", "Post", etc.).

In addition to how it is implemented (aka. I really do not need strength, transaction, etc., because everything that can be implemented regardless of abstraction), what would be the advantages and disadvantages of these abstractions?

Again, no low-level implementation information, please, I just want the difference in sound architecture, best practices and practices, or even the circumstances that are most suitable for everyone to use and why.

Answer 1

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

Otherwise, the signatures of the RPC method are closely related, fragile and fragile, and bind the contract of your service with its only server implementation. Here's an earlier answer comparing the same WCF and RPC Web API services rewritten in a message-based service .

For reading in the background, I described the differences between RPC and message-based services in an interview with WCF and ServiceStack in InfoQ , as well as the message-based service and its many advantages .