servicebus

I have heard talk about the NServiceBus , but I haven't really understood what it is. They claim to be "The most popular open-source service bus for .net". So; what is a "service bus", and when do I need one? You can think of a service bus as the Ethernet of SOA. First and foremost, it introduces a language of identifying things, like an IP address in Ethernet. This name isn't something inherently physical. Next, you have something physical involved on each node, like a queue in the case of a bus for supporting semi-connected communication, or an Ethernet card in the metaphor. Beyond just the

Just doing some quick spikes into possibly using a messaging system to process files that are in a nicely decoupled work flow system. What are the pro's and cons that people have found of using each of the above frameworks? What are the advantages of using these versus a hand-rolled MSMQ system with the WCF bindings and/or non-MSMQ solutions?? I'd recommend staying away from hand-rolled solutions as there is a bunch of somewhat difficult stuff that needs to be gotten just right - like how transactions are handled, how exceptions cause rollbacks, how to stop rolling back endlessly (poison

As I know, in AWS, if there's a new message in queue, AWS SNS can call my web API to inform me to get the message, so I don't need to get message by polling the queue to check if there is new message. Does Azure Service Bus topic/subscription has this similar function? Or I only can get the message by polling the subscription to check if there are new messages? Thanks Not via Web API, but via .NET client library. This is named there the "Event Driven Programming model". And is in .NET Client library since April'2013. You can read more here: http://msdn.microsoft.com/en-us/library/azure

If there are no longer any publishers or subscribers reading nor writing to a Queue, Topic, or Subscription, because of crashes or other abnormal terminations (instance restart, etc.), is that Queue/Topic/Subscription effectively orphaned? I tested this by creating a few Queues, and then terminating the applications. Those Queues were still on the Service Bus a long time later. It seems that they will just stay there forever. That would be wonderful if we WANTED that behavior, but in this case, we do not. How can we detect and delete these Queues, Topics, and Subscriptions? They will count

The scenario I have in mind is this: Service Bus is used for instance-to-instance communication, so a Subscription is unique per service instance. The end result is that if an instance does not shut down gracefully, its subscription does not get deleted. When a service instance "dies" and restarts, previous contents of the subscription are irrelevant and can be discarded. So, is there a way to set a "time to live" for Service Bus Subscription or simulate something similar, without having to resort to some custom orphan detection mechanism? that exact feature is on the backlog for one of the