WAS hosting for services with multiple msmq binding endpoints - not ideal!

I have been looking into this issue of hosting a service with multiple message queue endpoints with WAS for sometime. One thing that kept bothering me is that the SVC file name of the service needed to match the name of the queue. Furthermore, it was not just the name of the queue, but the name of the virtual folder + the queue name so the activation service will detect messages in my queue and then activate my service.

Once I got all the pieces to work, I renamed my SVC file, checked the permission of my queue to allow the activation service to peek into it, and got the service hosted in WAS, I realized that I can't get another queue on the same service to work. Considering the SVC file needs to match the queue, only one endpoint is satisfied, having another queue endpoint is possible, but the activation service will not look at it. This means that the service will process messages of another queue, but the service will not be activated based on these other queues. So you will need to first activate the service using the SVC named queue, and then the other queues will work.

This means that if you try to host a service with multiple queue endpoints, you must choose which queue will be responsible for the activation of the service. Only one must be chosen (and that queue needs to have the SVC file name renamed after it). Other queues, will not force activation of the service.

I have confirmed this to be true with Micrsofot support. They couldn't even give a good explanation why this was done this way. Why do you need to rename the SVC file? why can't you just use a configuration? or read the metadata of the service... I can think of many other ways to handle activation of queues, without the limitation of one queue per service, and forcing the user to rename his SVC file.

So how do you handle a service with multiple queue endpoints? Well, one simple way is not to use WAS hosting and use Windows Service Hosting, this problem does not exist with non-was hosting, but you loose on the activation model. You can make your own activation model, but that's like re-doing WAS.

Another option if you like using WAS, is to create multiple SVC files, one named after each queue within your service. The SVC files will all point to the same service class / assembly, but it will cause multiple service instances to be created depending on which queue forced the activation. You place all these SVC files within the same virtual folder. This might work only if the service is completely stateless.

Other work-around is to make sure the idle timeout is really large, so your service is only activated once, and then stays alive "forever". But, that just takes the activation out of WAS, which at that point, you may as well host it within a windows service.

Microsoft support also told me, that you can "ping" your service, to make sure it is activated, but that's just crazy... so I will not write more about that option.

Or... you can simply avoid having multiple queues in the same service (if you are planning to host your service under WAS).

I plan to update this post with an official KB article explaining this issue. Microsoft Support told me they will send it to me once they all agree this is a limitation by design.

Although this is not a popular feature of WAS, I feel there might be others out there trying the very same thing I am trying. I hope this helps them a little bit.