Шаблон проектирования Java EE для MDB

Question

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

Некоторые из них функциональны, такие как проверка XML, а некоторые - как аспекты, такие как ведение журнала, записи MIS и т. Д.

Редактировать:

Типы сообщений могут различаться в зависимости от таких функций, как упорядочение или выявление ошибок, или информационных служб, таких как поиск по почтовому индексу.Они также различаются для вызывающей стороны, поэтому заказ для вызывающей стороны A отличается от B, но в основном структура XML должна быть одинаковой.

Каждая из них будет проходить через функциональные единицы работы, такие как проверка отправителя, проверка продуктакоды (при размещении заказа), проверки безопасности (на основе IP), регистрация в нашей БД, если она действительна, очередь ошибок, если нет, и т. д.

У меня вопрос, поскольку мы хотим сделать функциональные биты модульными, чтобымы можем построить один MDB, который выполняет функции A, B, C, и другой MDB для выполнения B, C, D и т. д. в зависимости от типа сообщения и от того, какие задачи являются общими для всех типов сообщений.

Какой шаблон проектирования я должен использовать для этого?

Во-вторых, есть ли способ настроить эти функции в файле XML, чтобы MDB считывал XML, чтобы увидеть, какие функции он имеетвыполнить и в какой последовательности?Это как альтернатива наличию модулей в вспомогательных POJO или сессионных компонентах, связанных с основным MDB, о чем мы сейчас думаем.

Answer 1

@ shinynewbike: для вашей проблемы было бы лучше использовать MDB, чтобы просто прочитать сообщение и определить тип сообщения, а затем MDB может обратиться к классу фабрики, чтобы вернуть список обработчиков, реализующих тот же интерфейс и которые MDB может перебиратьболее, чтобы позвонить ... так что в основном шаблон проектирования команд.Пример конфигурации XML: -

<configuration>
<handler name="A" class="A"/>
<handler name="B" class="B"/>
...


<handlers-stack name="stack1">
 <handler ref="A">
 <handler ref="c">
</handlers>

<message type="X" handlers-ref="stack1"/>
<message type="Y" handlers-ref="stack2"/>
</configuration>

Answer 2

Помимо шаблонных терминов, мы стремимся, чтобы наша компания не использовала бизнес-логику в классе MDB. Это работает очень хорошо для того, что вы пытаетесь построить здесь, что почти похоже на шаблон Service Gateway (ESB). Проверьте следующие ссылки из MSDN (хорошая страница, хотя это не Java) и Мартин Фаулер .

Я бы рекомендовал разрешить MDB принимать сообщения. Затем вы можете использовать другие шаблоны (Command, Strategy, Factory и т. Д.) Для выполнения реальной работы. Или основной MDB может выяснить, куда следует переслать сообщение, а затем переслать сообщение в очередь, предназначенную для определенного типа функции.

Это добавляет некоторые административные и ресурсные издержки с точки зрения большего количества очередей и MDB. Но это также добавляет немного больше различий между различными логиками для разных сообщений (то есть разделение интересов). И это также дает вам возможность по-разному регулировать различные очереди «реализации» в зависимости от требований к производительности, вместо того, чтобы одна очередь была узким местом для всех.

Существуют соображения производительности при добавлении новых очередей. Хотелось бы дать вам конкретный ответ относительно того, «сколько», но я не могу, поскольку это зависит от того, что вы решите использовать для своего сервера приложений и вашего JMS и / или поставщика сообщений. И, к сожалению, не существует волшебного «числа» для того, что правильно. Вы действительно должны сесть и обсудить с другими архитекторами, сколько очередей вам нужно. Лучше всего сделать это заранее с вашим дизайном. Это выбьет любое количество очередей. Далее попробуйте выяснить нагрузку на систему. Насколько большими будут ваши сообщения? 100KB? 1 МБ? 5МБ? больше? меньше? И затем, сколько сообщений будет проходить через систему одновременно? С такими числами вы можете пересмотреть свое решение о количестве очередей и посмотреть, имеет ли оно смысл. Вы также можете попросить администраторов серверов приложений / сообщений (или вас, если это происходит у вас) регулировать очереди с различными настройками конфигурации, чтобы обеспечить более плавный обмен сообщениями через вашу систему. (Вам также может понадобиться настроить параметры кучи JVM серверов приложений и сообщений в зависимости от того, с чем вы столкнулись).

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

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

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

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

Answer 3

Стратегия , вероятно, с той причудой, что каждый MDB может иметь несколько стратегий. Если вы хотите сконфигурировать набор стратегий, которые бин использует в файле (или в env-записи, или в аналогичных элементах), вам придется получать ссылки на стратегии через JNDI, а не вводить их, что является второстепенным боль.

В мире, не относящемся к EJB, я бы предложил Наблюдатель , но с EJB я думаю, что довольно трудно заставить один компонент дать другому долговременную ссылку на себя. Если только они не @Singleton, а MDB - нет.

Answer 4

Хотя я понимаю, что это не дает прямого ответа на ваш вопрос, вы, возможно, захотите взглянуть на цепочку Apache Commons