I am not really comfortable with this subject since I always wrote my own logger until now.
I have a WCF REST web service. This service needs to log information from errors to who uses it and when.
To do so the Logging Application Block from Enterprise Library ( 5.0 ) has been chosen. In order to maintain good performance, we decided to use MSMQ. The aim is to store the logs there until we come to put it into file at some point.
I have seen on several websites that we can use WCF to transmit the message to a MSMQ and then use another entity to work with the queue or that we can use MSMQ as a transport protocol to communicate with WCF. Right now I just use the Logger class of LAB to insert the logs in the queue.
I only want to use MSMQ to desync my webservice from the logging functionality.
So here are my questions: What are the cases where MSMQ is useful with WCF ? In the case I describe is it not overkill to use another WCF application just to log some things in a file?
I think you're confusing two things here. The MSMQ transport in WCF is just that, a transport mechanism that can be used instead of HTTP or TCP. Your issue is that (I assume) you want to log asynchronously from the WCF service, which is a good idea. EntLib includes the MSMQ Distributor service, which will pick up logging events written from your application to a queue assuming a properly-configured logging block configuration that specifies MSMQ as the destination. The distributor will then actually write it to the database.
Asynchronous logging is a very smart thing to do, because it ensures that your events are in a persistent medium in catastrophic situations where the DB has done away, for example. Not to mention the database is not accessed as part of normal application operations, which eliminates a potential point of failure.
I worked on a web application once that was using a custom database logging mechanism. There were places where a DB operation would take place within a transaction and upon failure (say a relational constraint error from ADO) would write a message to the log... only to have it roll back along with the main transaction. That's the kind of problem you can get yourself into if you're writing directly to the database as part of your exception handling strategy.
Anyway, I'm not sure if this answers your question. Here's a good overview on how this all works in EntLib.