Хорошая стратегия для очереди сообщений?
В настоящее время я разрабатываю приложение, которое в конечном итоге я хочу переместить в Windows Azure. В краткосрочной перспективе, однако, он будет работать на сервере, который я буду размещать сам.
Приложение включает в себя несколько отдельных веб-приложений - некоторые из них, по сути, являются службами WCF, которые получают данные, а некоторые являются сайтами, позволяющими пользователям управлять данными. Кроме того, в фоновом режиме должна быть работающая служба, которая будет обрабатывать данные различными способами.
Я очень хочу использовать для этого развязанную архитектуру. В идеале я хочу, чтобы компоненты (то есть веб-приложения и рабочий сервис) знали как можно меньше друг о друге. Похоже, что использование очереди сообщений будет лучшим решением: веб-приложения могут помещать сообщения с рабочими единицами в очередь, а рабочая служба может выбирать их и обрабатывать по мере необходимости.
Тем не менее, я хочу разработать хороший набор технологий для этого, имея в виду, что в конечном итоге я перейду на Azure и хочу минимизировать объем переделок, которые мне понадобятся при переходе на облако , Azure имеет встроенный компонент Queue, который выглядит идеально для моих нужд. То, что я хотел бы сделать, это создать что-то сам, что будет подражать этому как можно ближе.
Похоже, есть несколько вариантов (я использую .NET в Windows, с серверной частью SQL Server 2005) - те, которые я нашел до сих пор:
MSMQБрокер служб SQL ServerМой собственный, используя таблицу базы данных и несколько сохраненных процедурМне было интересно, есть ли у кого-нибудь какие-либо предложения по этому поводу - или кто-то сделал что-то подобное и есть советы о том, что делать / избегать. Я понимаю, что каждая ситуация отличается, но в этом случае я думаю, что мои требования к очередям довольно общие, поэтому я хотел бы услышать чьи-либо мысли о том, как лучше всего это сделать.
Заранее спасибо,
Джон