My comments on “Why I Love NServiceBus” from @jonathan_oliver

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”…


via Inversion of Control Freak: Why I Love NServiceBus.

2 thoughts on “My comments on “Why I Love NServiceBus” from @jonathan_oliver

  1. RPC definitely has a place but it’s within a service boundary or for 3rd party integration where the only thing you’ve got is a web service/REST endpoint. For communication outside of your service boundary use messaging. It doesn’t have to be pub/sub, but at least use something asynchronous where you send a message to it without waiting for a response. That’s the key point of my paragraph above. If you’re waiting around on hold/blocked, you cannot, by definition, scale.

    The problem with WCF is that is promotes RPC but doesn’t necessarily give any guidance as to where it should and shouldn’t be used. Because of this, most developers are happy to use it everywhere.

    1. Jonathan, thanks for your response.
      If I would to summarize my comment it would be something like this:
      All interactions should be asynchronous and both Pub/Sub and Request/Response semantics should be available.

      Great content on your blog, btw…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: