Messaging vs. RPC: It starts at design-time

Chris Kinsman comments:
I have been looking at both but I have yet to see a compelling treatise that indicates why/how a non-RPC model makes sense. Folks talk about it but I have yet to see .NET code that doesn't just give lip service to messaging but instead does something with it that can't be done in the RPC model.

IMO, the difference between messaging and RPC starts at design time. When designing a distributed app using RPC, you design classes, interfaces and object interactions. When designing a messaging app you focus on the message structure (schema). Objects, methods and serialization/deserialization all become implementation conveniences rather than how you design your system. (I'm sure Chris remembers me preaching message-based design in the workshops we did together :-))
I have personally been involved in three large Web services projects that started out with RPC design and quickly ran into problems. In all three projects, the message structure was important (either for interop or because they were implementing a pre-existing contract). All three projects had to go back and start from message schema.
On the second point: Part of the reason there's little or no .NET code that shows messaging is that asmx exposes an RPC-based programming model and the tools (VS .NET) makes it really easy to start with classes and methods and ignore message schema.

Comments

• Anonymous
  March 26, 2003
  Your last sentence nails it. You have to go out of your way to go the message route in .NET 1.0. Hence most folks go the RPC route.
• Anonymous
  March 27, 2003
  The comment has been removed