Would someone be able to shed some light on the differences between the newly release Windows ServiceBus (on premise, not Azure) and NServiceBus?
Looking for a detailed answer what the windows SB may be missing as I'm familiar what NSErviceBus can do:
Is it a real service bus and not just a message broker that uses queues?
Can it support message polymorphism? (Messages subclassing other
messages and handlers supporting this hierarchy
Long running processes and correlation
Scale out
I'm responsible for the Windows Azure ServiceBus support in NServicebus. And in my opinion this new Windows Server Servicebus provides the exact same capabilities as the Azure ServiceBus. So in my opinion it will be a good match with NServiceBus instead of a competitor (just as the Windows Azure ServiceBus is) and could be used instead of msmq.
To answer your questions
The new servicebus is a broker that uses queues
Messages on the servicebus are just strings in the end, the servicebus itself has no additional support for message types, hierarchies, handlers etc. Typically you would use WCF or NServiceBus for this.
There is no support for long running processes nor correlation. It does have some feature overlap with NServiceBus though as it can do subcriptions/topics, it can also do deferral of messages as well as filters.
It's designed to scale out.
Hope this helps?
Kind regards,
Yves
Related
sorry if now I can't provide all the details, but I'm trying to use NServiceBus on Azure Service Bus using the Basic configuration. NServiceBus fails on start because it tries to create a Topic and a Queue, and Basic mode of Azure Service Bus doesn't suport Topics. Any help or workaround? Thanks!
I think you're talking about Basic Tier (pay).
Not with the current version of the ASB transport. Current version of transport only has one topology QueueAndTopicByEndpointTopology which is creating topics by default. You have two options: switch to Paid Tier or implement an alternative topology and use that (not a trivial task). Next version of transport will support more topologies and allow better mechanism to plug custom implementations.
But have you considered the following: without Topics you cannot have pub/sub. This would be a severe limitation when using bus architecture.
As Sean outlined, basic tier is currently not possible out of the box. But I'm curious to know why prefer Basic tier over Storage Queues?
We are building Workflow Foundation service with .NET 4.5 and are attempting to use MSMQ to deliver messages that Workflow Service should process.
We have enabled Allow Buffered Receive in order to have messages wait for Workflow to be able to process them.
However, we've ended up with some weird kind of locks in our message folders (see the pictures).
There is no documentation whatsoever to explain this. What is this? Is it related to WF, WCF, MSMQ? Where to look for solution?
I have no idea about the locks but I decided to implement my own queuing solution within my workflow outside of MSMQ due to past issues with MSMQ. I found the following article that helped me implement a queuing solution using SQL Server Implementing Message Queues in Relation Databases
Using a variant of this technique, IIS 7.5 AutoStart, WWF bookmarks and Context Based Correlation I was able to implement a persistent queue within my workflow without using MSMQ. The nature of workflow makes queuing within the workflow very doable.
NServiceBus Distributor/Worker pattern makes perfect sense for MSMQ due to the hard requirement of local input queues.
But this is not the case with RabbitMQ, I am trying to understand how and when the NServiceBus distributor is relevant with RabbitMQ. With RabbitMQ multiple workers can read from the same remote queue.
The actual scenario is similar to using an AWS auto-scaling group to scale out workers pointing to a high available RabbitMQ cluster. Now avoiding distributor altogether makes the setup much simpler to build, test and provision.
Thoughts?
As RabbitMQ transport falls into the broker style bus, so, in your use case, it would make more sense not to use the distributor.
The same goes for all broker-style transports, where you can use a competing consumer pattern to scale out.
NServiceBus is an excellent system and does wonders in most message queuing system where you don't have an integrated distributor (which you do with exchanges in RabbitMQ). We use NServiceBus here at our company.
Azure Queues and MSMQ are perfect examples of such queuing technologies.
NServiceBus handles the distribution internally and therefore reproduces this capability for you.
However... If you are blessed with the possibility of imposing what queuing technology you can use, then I would highly encourage you to look into RabbitMQ and a product (Open Source) called MassTransit
http://masstransit-project.com/
MassTransit can in turn function in the two modes and will either delegate or simulate the distribution for you - however I nonetheless have a soft spot for NServiceBus as do our senior devs here.
Per this page...
http://docs.particular.net/nservicebus/load-balancing-with-the-distributor
Using the distributor is only useful when using MSMQ - if you aren't using MSMQ then there is no point. RabbitMQ and other transport will allow access to the same queue from multiple consumers, while MSMQ will not. The distributor in a nutshell will take messages from the main queue and distribute them across multiple worker queues as they report that they are done with whatever they are working on.
We are looking at using ActiveMQ as the message transport with NServiceBus, instead of MSMQ, to enable Java endpoints to directly integrate with .NET endpoints over ActiveMQ.
By default NServiceBus endpoints run in a distributed transaction involving MSMQ and SQL Server. Is there the same level of support for distributed transactions in NServiceBus when the message transport is ActiveMQ? Are there any other drawbacks to using ActiveMQ with NServiceBus as compared to MSMQ?
We've actually uncovered issues with the .net client of ActiveMQ - it doesn't support distributed transactions well enough. While we've tried to work with the committers over there, we still haven't been able to get this fully resolved.
At this point in time, if you want to use ActiveMQ on .net (with or without NServiceBus) you'll have to take care of deduplicating any messages flowing through your system.
We're working hard to build this kind of infrastructure-level deduplication logic into NServiceBus such that queues like RabbitMQ and Azure Service Bus that don't support distributed transactions give the same behavior as MSMQ.
From the book Learning NServiceBus by David Boike:
Like MSMQ, ActiveMQ supports the DTC which ensures that our message handlers remain fully transactional.
As far as drawbacks go:
ActiveMQ server does not support DTC transactions for deferred messages.
Other issues are reported on the NServiceBus.ActiveMQ GitHub site. I recommend perusing the list.
I am wondering if there is a way to setup NServiceBus so that the machine actually getting the message from a publisher does not have the InputQueue on it. Also, I would like to publish to a general queue (though this can be accomplished with a web service.)
I am thinking I may use this to allow client machines to post and receive events. But the client machines are fairly locked down. If I need to have queues created on them I can, but it would be easier to have the queues uniquely named and in a more central location.
I am new to NServiceBus and pub/sub in general. So if I am off base on what I want please say so.
This sounds like the perfect candidate for an alternate queuing infrastructure beyond MSMQ--such as Azure Queues or Amazon SQS. With those types of queues you have no infrastructure to install on the client machines and everything is much more centralized.
Before you go down that road though, you'll want to get the basics of publish/subscribe under you. Pub/sub using MSMQ and NServiceBus has a decent learning curve to it and if you aren't familiar with how things work at that level then moving to cloud queues may be even more tricky.