We are designing a system that is web based but also uses NServiceBus and Azure Service Bus to communicate. We have an on premiss server running IIS for the application and also several cloud services running web roles for communicating with external parties (those parties call on a RESTful interface in the cloud and the message is put on the bus or vice versa).
Both the cloud solutions and the on premiss server need to subscribe and publish messages. The publishing does not seem an issue but what happens to those subscriptions if IIS shuts down the processes, do they get woken again when a message arrives or is the service bus really pull based subscription so requiring an active listener.
I have seen questions on here about hosting publishers but nothing about the safety of subscribers.
Extra Info: Quite by chance we noticed that sometimes in our development environment the applications would need to be started a couple of times before the messages would start arriving. However it occurred to me that if there were actually messages already in the queue when the application started then they would be processed and otherwise not. So the restart just means that it sees older messages and processes them then once running it gets on just fine. However another colleague noted that nsb related startup log files were only being generated after he visited the website hosted in the same web application for the first time. I have just had a similar problem, messages were in the queue but the breakpoint on the handler was not being hit. When I hit a webapi method on the same iis application instance suddenly messages were being processed. So my conclusion from this is that no, it is not safe to host a subscriber under iis or in this case even a web role.
I am answering my own question based on my experience rather than any deep knowledge of NServiceBus or Azure Service Bus.
It seems that it is not safe to rely on the service bus listener to be active under IIS or a web role. Both can shut down the process and, as the bus listener relies on polling the service rather than messages being pushed to the listener from the service, so no further messages will be received until the process starts again.
The good news is that the process will be restarted when the associated web site or web service is hit. so if you absolutely know that you will receive more traffic on the site than on the bus then you might take the risk that the bus listener will remain active. However for our project we are in the process of splitting the listener into a separate windows service.