Консультация по дизайну динамических диспетчерских сообщений

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

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

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

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

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

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

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

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

Итак, теперь это моя проблема:

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

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

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

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

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


java architecture design-patterns jms jakarta-ee
person rayman    schedule 01.12.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

person tcarvin    schedule 01.12.2011
comment
Итак, вы говорите, что в файле конфигурации будут перечислены все очереди, которые я использую? вы говорите о xml/текстовом файле? иногда мне нужно также установить разные аннотации, когда я настраиваю очередь со свойствами. не уверен, что его можно записать динамически. - person rayman; 02.12.2011
comment
Если вы действительно не можете использовать конфигурацию, потому что код, который настраивает и записывает в очередь, совершенно уникален (вы можете обнаружить мои сомнения :)), тогда я бы вставил этот код в класс QueueConfigurator (или, скорее, подкласс), который может загружаться динамически а информация, необходимая для загрузки конфигуратора, должна храниться в конфигурационном файле. Таким образом, вы можете отказаться от поддержки новой очереди без перекомпиляции базы. - person tcarvin; 02.12.2011
comment
Я понимаю тебя. еще кое-что. я понимаю, что я не могу полностью избежать прикосновения к коду, так как в будущем, когда будет добавлен новый целевой ключ базы данных, мне нужно будет реализовать различные вставки и логику для кода, который будет требоваться новой базой данных. Как бы вы посоветовали мне эффективно разработать код, чтобы было удобно добавлять новые туннели очереди. подключаемым способом. Спасибо. - person rayman; 06.12.2011
comment
В идеале ваша конфигурация может хранить вставку SQL, поля msg и т. д., чтобы в ответ на получение сообщения обработчик q-to-db просто читал msg, искал информацию о соединении с db, искал базовый SQL для использования, ищет сопоставление msg-column, применяет их к SQL, а затем выполняет оператор. - person tcarvin; 06.12.2011