1
votes

Scenario : I want to implement an MSMQ in which users input message through System.Messaging API's. And there should be a listener which always observes this queue so when ever there is a message in queue I want to make a database updation.

My first approach was to implement MSMQ trigger. I was able to implement a COM interop dll trigger. But I wasnt able to do database operation and I couldnt figure out what was wrong, I tried a lot . Then I came to know about this WCF MSMQ binding. As I am new to this WCF I have some doubts.

Which is the best approach to host WCF for this case. Is it IIS with WAS or Windows service?

And for this kind of listener service is a client necessary or can we write the database operations directly under the Service host operations without client invocation?

1
What database are you using ?Kenner Dev
I was using SQL server. And I was trying to refer entity framework in COM trigger.Jamshi Bp
Both IIS and a Windows service are viable options. With IIS, just note that in some cases the processing of your queues might get stuck, because the worker process got cleaned up by IIS and no new process is being spawned (but doing a HTTP request once in a while, to get the metadata for example can do the trick to keep it all alive).Styxxy
So we dont require a client to consume this service at allJamshi Bp

1 Answers

1
votes

Then I came to know about this WCF MSMQ binding. As I am new to this WCF I have some doubts

Well, that's valid. WCF has a fairly steep learning curve, is very config-heavy, and is not everyone's cup of tea.

However, if you're integrating to MSMQ, WCF has very good support and is rock solid in terms of the way it is implemented.

Which is the best approach to host WCF for this case. Is it IIS with WAS or Windows service?

Unless you're hosting exclusively on a web environment, I would choose a windows service every time. Using something like topshelf, the deployment and management overhead is tiny, and there are no external dependencies.

Remember to use msmqIntegrationBinding rather than netMsmqBinding, as the latter relies on WCF at both ends, whereas the former supports System.Messaging on the client, or even better, use WCF on the client and then you can use netMsmqBinding which support "typed" messages.