Why I Love NServiceBus

NServiceBus was designed around the fallacies of distributed computing and faces each fallacies head-on rather than trying to sweep the them under the rug and hide from them while pretending that they don’t exist.  It is only by acknowledging and addressing these fallacies that our systems become truly and effectively distributed.  This is one the foundational principle of NServiceBus.  It’s not just about plugging in the WCF MSMQ  binding and somehow magically request/response will bring scalability.

In a nutshell, all of the learning and hard lessons discovered through the school of hard knocks and best thinking of distributed systems (rather than whimsical, so-called vendor best practices) are baked into the heart and core of NServiceBus.

vs. Web Services

Previous to going to his class I had already done a decade of web services using SOAP and REST and I kept running into the same types of problems over and over again.  I’ve read all of the best practices of the vendors and so forth, but the thing that always bugged me was how everything related to these "best practices” (if it’s even appropriate to call them that), always pointed us back to purchasing more licenses—such as database licenses, OS licenses, etc.  If you want an eye opener and sample of what Udi brings to the table, take a look at his Reliability, Availability, and Scalability webcast.  The biggest problem with with web services is that they run afoul of practically all of the fallacies.

So where do web services fit in?  As integration points with 3rd parties that connect across the web.  They’ve worked great in that arena and will continue to work well into the foreseeable future.  Furthermore, a “web service” AJAX call from a browser into a service may also be appropriate.

vs. WCF

Essentially WCF is just a way of wrapping all of Microsoft’s myriad of integration and communication technologies under one API.  The problem is that all of these technologies, with the exception of MSMQ, were built upon the paradigm of RPC—remote procedure call.  Essentially, it’s all about blocking communication.  Could you imagine a world in which 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.

Read more: Inversion of Control Freak

Posted via email from .NET Info