Динамическая диспетчеризация сообщений, консультация дизайна - PullRequest
0 голосов
/ 01 декабря 2011

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

Я использую Weblogic 11g, EJB3.0

У меня есть система, которая предназначена для получения и отправки сообщений на несколько ресурсов (базы данных).

Каждое сообщение содержит информацию и целевой ключ базы данных.

Итак, вот пример потока:

Я получаю от веб-службы сообщение и ключевую цель. Я анализирую сообщение и отправляю его в нужную базу данных через ключевую цель.

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

Если в одном из ресурсов происходит сбой вставки, произойдет откат, и повторная попытка выполнит всю операцию заново.

Так что теперь это моя проблема:

Должен ли я сделать количество очередей в качестве количества моих ресурсов? (и выделил каждую Очередь определенному ресурсу)

(В этом случае я анализирую каждое сообщение и просто отправляю его в нужную очередь, пока MDB прослушивает и выполняет вставку в нужную базу данных)

Если я сделаю это таким образом, я не смогу сделать его динамическим , то есть каждый раз, когда новый ресурс будет добавляться / удаляться в будущем , мне потребуется откройте код и внесите необходимые изменения.

Что вы, дизайнеры, думаете? Как я мог бы реализовать это лучше динамически?

спасибо за вашу помощь лучей.

1 Ответ

0 голосов
/ 01 декабря 2011

Я думаю, что использование очереди для каждого целевого ресурса (базы данных) хорошо.И вам не нужно менять код для добавления и удаления этих конечных точек, если они выводятся из файла конфигурации.Ваш диспетчер должен иметь конфигурацию, в которой перечисляется очередь назначения для каждого «целевого ключа базы данных».Процессы / компоненты, которые читают, контролируют очередь конечной точки, так же нуждаются в конфигурации, такой как строка соединения db или что-то еще.

Теперь добавим новый тип ресурса , который потребует от вас изменения вашего кода.Но этого и следовало ожидать.

...