use System.Messaging.MessageQueue or WCF for MSMQ?

5 years ago i've developed a program which used MSMQ.

Back then, i used the System.Messaging.MessageQueue and the System.Messaging.MessageQueueTransaction to put items on the msmq.

Nowadays i see people using WCF, and i'm confused wether to use WCF.

First of all most of the code examples only show how to put items ON the queue using WCF, and not get the OFF, but more important: when i use the WCF/MSMQ solution, i have to create an extra project, namely the wcf service.

Creating a wcf service of course is not the problem, but i also have to install it on production.

So i am wondering: why should i use wcf to put items on the queue, and not the solution with the .Net objects?

Or am i incorrect that i assume that when i use scf, that i need an EXTRA app to deliver, namely the wcf app?

EDIT: The scneario is this: we have a websi开发者_如何学Cte where people can unsubscribe. In stead of hitting the database directly (to unsubscribe) we put the unsubscribe request on a queue and another service (windows service or console app) will get the items from the queue and do the database actions

Using WCF to wrap MSMQ means that you are abstracting away the transmission mechanism, which allows you to change it later if you want.

Your current solution has a web site that puts a request in the queue, and a windows service that gets the request from the queue then hits the database. That is perfectly acceptable if you know that you will always use MSMQ for ever and ever, Amen.

However, you could change it as follows:

• Your windows service now hosts a WCF service (no extra project required here). The WCF service exposes an Unsubscribe method (the method name describes the logical action, not how it's accomplished).
• Your web site now acts as a WCF client that references the service (no extra project required here). The web site code calls the Unsubscribe method.
• You configure the WCF bindings to use MSMQ.

If in future you decide that MSMQ is unnecessary, or you think of a better way, you can just change the WCF bindings to use something else, and the code will remain the same.

Been through a similar question myself recently. Personally, I don't ever want to write another application in WCF. Its overly complex, and if you get a config setting wrong, or combinations thereof, you can spend hours trying to google your way out of it. I just wrote a simple app that pulls from the queue in a multithreaded fashion, and pushes to it from the web. That may be overkill for you. There are simple examples out there that will get you up and running, like this.

Perhaps think of it like this: MSMQ is a resource for messaging, just like SQL Server is for relation data storage. Applications of all kinds can leverage this service (.NET console, web, service, etc., and of course other MQ vendor products).

It happens that Microsoft tightly integrated MSMQ into WCF, and demo projects show this. The issue with reading+writing to the queue isn't a concern. Any project type can read from and write to MSMQ equally.

I don't believe you need a separate project for your WCF service - I guess it depends on the nature of your application. For example, there's no reason you can't have WCF services within a web app, all in the same project.

But to your question, WCF's support for MSMQ is meant to provide a unified way of messaging for applications, whether it's via web services, traditional services, COM+ (what's that??) or queuing.

If your queuing is completely within your application, then I'm not sure it's needed.

If your application exposes queues for others to write to, then having a WCF service in front may make sense. It would shield your users from knowing what queue to write to, etc. They just have to connect to a service to send the message. So I think this is very nice and hides some implementation details from the user, which is a good thing.

If you could provide more detail about the nature of your app, I can provide some more detail.