Должен ли я использовать обмен сообщениями вместо базы данных

Question

Я разрабатываю систему, которая позволит пользователям брать данные из одной системы и отправлять в другие системы. Одна из систем назначения имеет сложную SOA (веб-службы), а другая - мэйнфрейм, который принимает плоские файлы для ввода.

Я создал базу данных, в которой есть таблица PublishEvent и таблица PublishEventType. Существуют также нормализованные таблицы, которые относятся к типу публикуемого события.

У меня также есть таблица «interface», которая представляет собой выпуклую версию нормализованных таблиц данных. У конечного пользователя есть процесс, который помещает данные в интерфейсную таблицу. Я не уверен в точном процессе - я думаю, что это какое-то приложение для составления отчетов, которое может экспортировать результаты в таблицу SQL. Затем я использую пакет служб SSIS, чтобы извлечь данные из интерфейсной таблицы, поместить их в нормализованную структуру данных и создать новые строки в таблице PublishEvent. Я использую плоский стол, потому что когда я впервые показывал им реляционные таблицы, они казались очень запутанными.

У меня есть служба Windows, которая отслеживает новые строки в таблице PublishEvent. Служба Windows расширена за счет плагинов (с использованием инфраструктуры MEF). Выбор подключаемого модуля зависит от значения поля PublishEventTypeID в строке PublishEvent.

PublishEventTypeID 1 вызывает подключаемый модуль, который считывает данные из одного набора таблиц и вызывает веб-службу SOA. PublishEventTypeID 2 вызывает подключаемый модуль, который считывает данные из другого набора таблиц и создает плоский файл для отправки на мэйнфрейм.

Похоже, я внедряю анти-шаблон "База данных как IPC". Должен ли я изменить свой дизайн, чтобы использовать систему, основанную на обмене сообщениями? Является ли процесс помещения данных в плоскую таблицу в нормализованные таблицы излишним?

РЕДАКТИРОВАТЬ: Это разрабатывается в .NET 3.5

Answer 1

A MOM , вероятно, является лучшим решением, но вы также должны учитывать следующие моменты:

1. У вас уже есть система на основе сообщений, как часть вашего архитектура клиента? Если нет, может быть, введение это излишество.
2. Есть ли у вас опыт работы с системами на основе сообщений? Как Джейсон Правильно указано планка, необходимо учитывать конкретные шаблоны для них, такие как необходимость обеспечения хронологического порядка сообщения, управление пустыми каналами и т. д. (см. это книга для более).
3. Вы упомянули систему мэйнфреймов, которая, по-видимому, варианты взаимодействия с. Кто позаботится о слое, который превратит «сообщения» (на основе БД или MOM) в нечто что мейнфрейм может переварить? Предполагая, что это вы, это будет проще (для вас) сделать это путем доступа к БД (возможно, у вас есть уже работал над проблемой в прошлом) или усилия будут отличается в зависимости от использования БД или MOM?

Подводя итог: если вы чувствуете себя более уверенно, выбирая маршрут БД, возможно, лучше сделать это, даже если - как вы правильно предположили, это немного «анти-паттерн».

Answer 2

Посмотрите nServiceBus, Mass Transit или RhinoServiceBus, если вы используете .Net.

Answer 3

Некоторые ключевые моменты, которые следует иметь в виду:

1. Согласованность порядка строк. Зависит ли ваша модель данных от порядка генерируемых данных? Если да, обеспечивает ли ваша схема активность паба и подгруппы в одном и том же порядке создания исходных данных?

2. Есть ли у вас столбцы идентификаторов с обеих сторон? Они представляют собой проблему, поскольку их значение постоянно меняется в зависимости от порядка вставки данных. Если столбец Identity является единственным первичным ключом (суррогатным ключом), изменение его значения может привести к невозможности использования данных.

3. Как доказать, что вы не потеряли запись? Это самая сложная часть решения, особенно если у вас миллионы строк.

Что касается архитектуры, вы можете проверить протокол XMPP - Smack для клиента (если Java) и eJabberD для сервера.