MSMQ, WCF и IIS: как заставить их играть хорошо — Часть 3

Ранее в MSMQ, WCF и IIS: чтобы они хорошо играли:

• В первой части мы создали клиентское приложение и приложение-службу IIS и установили связь между ними через MSMQ с помощью WCM NetMsmqBinding.
• Во второй части мы развернули одно и то же приложение на нескольких серверах и включили безопасность транспорта для MSMQ.

В сегодняшнем захватывающем заключении мы повысим устойчивость решения, перейдя к транзакциям. Пристегните ремни безопасности!

Идут Транзакционные

Прежде чем начать, давайте потратим несколько минут на обсуждение преимуществ и недостатков использования транзакционных очередей сообщений. Преимущества все довольно приятные:

1. Сообщения будут доставлены ровно один раз и по порядку.
2. Сообщения сохраняются на диске, поэтому они не будут потеряны, если сервер выйдет из строя.
3. Отправка и получение сообщений могут происходить в рамках транзакции. Я нашел это наиболее полезным для принимающей стороны: если вы создаете одну транзакцию, которая включает в себя как получение сообщения, так и его обработку, и во время обработки происходит сбой, вся транзакция будет откатываться. Это означает, что сообщение будет возвращено в очередь, а не потеряно.

В это время вы, вероятно, думаете: «Ух ты, все звучит замечательно — почему никто не хочет всех этих?» Основной причиной является производительность — использование транзакционных очередей сообщений обычно во много раз медленнее, чем с их нетранзакционными кузенами. Кроме того, хотя перспектива потери сообщений или получения дубликатов сообщений кажется пугающей, в действительности это может произойти только при крайне редких и неудачных обстоятельствах. Поэтому вопрос здесь должен быть не «хотите ли вы повысить надежность, которую вы получаете из очередей транзакционных сообщений», а скорее «можете ли вы позволить себе жить без него?».

Тем не менее, существует множество сценариев, в которых очереди транзакционных сообщений оправданы, например, хранение записей аудита, обработка финансовых транзакций или отправка приветствий в примерах блога. Итак, начнем!

Создать транзакционную очередь сообщений

Первое, что нам нужно сделать, это создать новую блестящую очередь транзакционных сообщений. Даже если у нас уже есть нетранзакционная очередь сообщений с правильным именем, вы не можете преобразовать нетранзакционную очередь в транзакционную. Таким образом, вам нужно будет бесцеремонно удалить существующую очередь и создать новую личную очередь, которая по-прежнему называется MsmqService / MsmqService.svc . Однако на этот раз убедитесь, что вы установили флажок Transactional .

Теперь, после всех наших усилий по настройке списков ACL в предыдущей очереди, убедитесь, что вы правильно установили их в новой очереди, чтобы избежать более болезненных проблем с разрешениями!

Переконфигурируйте привязки WCF

Еще раз, нам нужно изменить конфигурацию WCF как в клиенте, так и в службе, чтобы использовать новую привязку. На этот раз мы будем использовать MsmqBindingTransactionalTransportSecurity , который будет определен следующим образом:

<binding name="MsmqBindingTransactionalTransportSecurity" exactlyOnce="true" receiveErrorHandling="Move">
  <security mode="Transport"/>
</binding>

ExactlyOnce = «истина» атрибут WCF -говорить для использования транзакционной очереди сообщений. receiveErrorHandlingАтрибут необходим только на стороне службы (хотя он не причинит никакого вреда на стороне клиента). Это говорит WCF, что делать в случае, если он обнаруживает «ядовитое сообщение». Ядовитые сообщения — важная концепция с транзакционными очередями сообщений. Как обсуждалось ранее, если при обработке транзакционного сообщения возникает ошибка, транзакция будет откатываться и сообщение будет возвращено обратно в свою очередь — готово для повторного получения той же службой. Если ошибка была вызвана временным сбоем, сообщение может быть успешно обработано в следующий раз. Однако, если проблема возникла из-за неверно сформированного сообщения или постоянной проблемы с приложением, сообщение будет повторяться снова и снова. WCF и MSMQ 4.0 объединили свои усилия для обеспечения поддержки обнаружения и обработки ядовитых сообщений.Если одно и то же сообщение не удается несколько раз (по умолчанию 3), оно будет считаться «ядом». Что будет дальше, зависит от значенияатрибут receiveErrorHandling . Если вы установите для него значение «Переместить» (мой любимый выбор!), Оно будет автоматически помещено в подпоследовательность под названием «яд», где он может быть обработан вручную кем-то другим.

public class MsmqService : IMsmqContract
{
	[OperationBehavior(TransactionScopeRequired=true)]
	public void SendMessage(string message)
	{
	    if (message == "Bad")
	    {
		throw new InvalidOperationException("Bad!");
	    }

	    Trace.WriteLine(String.Format("Received message at {0} : {1}", DateTime.Now, message));
	}
}