О LAB EntLib, MSMQ и WCF
Мне не очень нравится эта тема, так как я до сих пор всегда писал свой собственный регистратор.
У меня есть веб-сервис WCF REST. Эта служба должна регистрировать информацию об ошибках, кто и когда ее использует.
Для этого был выбран блок регистрации приложений из Enterprise Library ( 5.0). Чтобы поддерживать хорошую производительность, мы решили использовать MSMQ. Цель состоит в том, чтобы хранить журналы там, пока мы не придем, чтобы поместить их в файл в какой-то момент.
На нескольких веб-сайтах я видел, что мы можем использовать WCF для передачи сообщения в MSMQ, а затем использовать другой объект для работы с очередью или что мы можем использовать MSMQ в качестве транспортного протокола для связи с WCF. Прямо сейчас я просто использую класс Logger LAB, чтобы вставить журналы в очередь.
Я только хочу использовать MSMQ для десинхронизации моего веб-сервиса с функциональностью регистрации.
Итак, вот мои вопросы: В каких случаях MSMQ полезен с WCF? В случае, который я описываю, не является ли излишним использование другого приложения WCF просто для записи некоторых вещей в файл?
1 ответ
Я думаю, что вы путаете две вещи здесь. Транспорт MSMQ в WCF - это всего лишь механизм транспорта, который можно использовать вместо HTTP или TCP. Ваша проблема в том, что (я полагаю) вы хотите войти в систему асинхронно из службы WCF, что является хорошей идеей. EntLib включает в себя службу MSMQ Distributor, которая будет собирать события журналирования, записанные из вашего приложения в очередь, при условии правильно настроенной конфигурации блока журналирования, в которой MSMQ указывается в качестве места назначения. Затем дистрибьютор фактически запишет его в базу данных.
Асинхронное ведение журнала очень разумно, поскольку оно гарантирует, что ваши события находятся в постоянной среде в катастрофических ситуациях, когда БД, например, покончила с собой. Не говоря уже о том, что к базе данных не обращаются как к части обычных операций приложения, что исключает потенциальную точку отказа.
Однажды я работал над веб-приложением, в котором использовался собственный механизм ведения журнала базы данных. Были места, где операция БД происходила бы внутри транзакции, и при неудаче (скажем, ошибка реляционного ограничения из ADO) записывала сообщение в журнал... только для того, чтобы оно откатывалось вместе с основной транзакцией. Это та проблема, с которой вы можете столкнуться, если пишете напрямую в базу данных как часть вашей стратегии обработки исключений.
Во всяком случае, я не уверен, если это отвечает на ваш вопрос. Вот хороший обзор того, как все это работает в EntLib.