Recently, my team had a lot of discussions about the value of pub/sub paradigm. Last two years we used this approach on all new applications and although we like it, we’ve cooled down quite a bit comparing to beginnings… So when I read this post from Oliver, I felt that although I’m the last person to defend WCF (and RPC paradigm), I do want to comment. Here is the part that pushed me over the edge:
“… were built upon the paradigm of RPC—remote procedure call. Essentially, it’s all about blocking communication. Could you imagine a world where you called someone on the phone and waited on hold until you received the information you needed? RPC is just like that. Your servers are at 0% CPU, but you have no threads left to serve because they’re all blocked waiting for remote services to respond. The MSMQ binding helps, but not if you use it in a synchronous blocking manner with an RPC-type interaction.”
This is just simply not true – it is possible to write scalable server code with WCF (and other platforms that are not strict Pub/Sub). RPC (Request/Response) applications do not have to be written in a synchronous blocking manner.
I like pub/sub paradigm for a couple of reasons, mainly:
– (local) store and forward,
– ease of group communication
– and more dynamic network topologies…
The other side of the coin is that with pub/sub in big applications you can end up with so many messages that it is no longer possible to figure with ease what is the sequence of the control flow.
So… There is no (one) “Silver Bullet”…