Логика приложений Java EE / Glassfish

Question

Я пытаюсь понять, куда должна идти некоторая логика моего приложения в приложении Java EE. Я новичок в Java EE и смотрю на загрузку большого количества неструктурированных данных из устаревшей базы данных и создание чистой объектной модели для использования моим приложением. Из моего исследования я вижу, что приложения Java EE имеют 2 компонента: компоненты корпоративного бина и веб-приложения. Эта часть моего приложения будет отвечать за загрузку данных, построение объектной модели и отправку сообщений через JMS на основе текущего состояния данных заинтересованным сторонам. Данные будут обновляться путем синхронизации с базой данных и из сообщений, полученных через JMS от удаленных приложений Java.

Является ли EJB правильным местом для такого рода функций? Как я могу начать инициализацию моей объектной модели (основной метод, эквивалентный Java App)? Каков наилучший способ создания синхронизированного события для проверки объектной модели и отправки сообщений через JMS?

Я прочитал ряд статей о Java EE, Glassfish, EJB ... но все еще не чувствую, что у меня есть четкое представление о том, где я должен писать эту функциональность. Любые примеры EJB, которые я видел, обычно связаны с прямыми вызовами методов в bean-компонентах из клиентских приложений.

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

Answer 1

Java EE традиционно используется для архитектурного стиля клиент / сервер. Бизнес-логика реализована в сессионных компонентах EJB, которые обычно вызываются из веб-запроса, сообщения JMS или удаленного вызова RMI-IIOP.

Является ли EJB правильным местом для этого вид функциональности?

Логика входит в EJB. Но есть разные типы EJB.

Как начать инициализацию моя объектная модель (основной метод Java App эквивалент)

Не существует такого понятия, как main метод. Но есть еще несколько способов выполнить некоторую обработку, соответствующую развертыванию и / или отмене развертывания приложения. Вы можете посмотреть ServletContextListener , Модуль жизненного цикла Glassfish (нестандартный) или, возможно, недавно представленные Singleton bean-компоненты и @Startup аннотацию.

Какая лучшая практика для создание синхронизированного события для просмотра объектная модель и отправка сообщений через JMS

Вы можете создать EJB Timer , который будет вызываться периодически. Если вам нужно, чтобы модель была загружена один раз в память, я бы посоветовал вам взглянуть также на Singleton bean-компоненты. В EJB 3.0 проблема заключалась в том, как запускать таймер автоматически , но я думаю, что они улучшили то, что в EJB 3.1 и таймеры могут автоматически запускаться сервером приложений при развертывании приложения используя аннотацию @Scheduled. Так что это может как-то дать вам желаемую отправную точку, как вы задали в предыдущем вопросе.

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

Ваше приложение не будет традиционным клиент-серверным приложением с веб-EJB-базой данных, но оно должно быть осуществимо с Java EE, который, безусловно, является очень гибкой моделью.

Answer 2

Как вы сказали, примеры, как правило, связаны с прямым вызовом. По моему опыту, это не только примеры. Ни одно из приложений Java EE * 1, которые я видел, не использует график долгоживущих объектов, как вы описали, вместо этого они обычно работают с одной записью (+ дочерние / связанные) в ответ на веб-запрос, вызов веб-службы или сообщение JMS. ,

Ваши требования нарушают то, что пресс-форма и Java EE могут не подходить наилучшим образом. По сути, тип кода, который вы описываете, принадлежит к EJB-контейнеру, но у этого контейнера отсутствует хороший долгоживущий контекст, к которому можно привязать граф объекта. Веб-контейнер имеет такой контекст, но не имеет средств для таймеров, обработки сообщений и тому подобного. Стоимость отказа от J2EE и использования простого Java-приложения, конечно же, приводит к потере возможностей сервера приложений для администрирования, развертывания и мониторинга.

Хорошим выбором может быть возвращение к тому, что сделало Spring Framework большим. Я не знаю, знакомы ли вы с историей J2EE, но внезапная огромная популярность Spring Framework и Hibernate по сути была восстанием сообщества против контейнера EJB, версии 1.x / 2.x. Spring WebApplicationContext дал вам надежный транзакционный сервер для веб-приложения, использующий преимущества MDB и JTA, в то же время игнорируя как можно большую часть EJB-контейнера * 2 (и значительно упрощая модульное тестирование в процессе). Вы можете воспользоваться этим подходом и создать свое приложение в виде единого файла WAR и загрузить свои фоновые службы с помощью Spring.

Интересной альтернативой является полное отключение сервера приложений Java EE и построение вашего приложения поверх платформы OSGi. Это подход «обычного Java-приложения», когда среда выполнения OSGi предоставляет вам консоль администрирования и функции горячего развертывания, которые вам пришлось бы использовать самостоятельно. Недостающие биты инфраструктуры - это таймер (используйте Quartz ) и управляемый сообщениями компонент (используйте напрямую JMS API). Приложение OSGi в конечном итоге немного напоминает ядро ​​Linux и процесс загрузки, службы развертываются и запускаются в соответствии с уровнями выполнения. Возьмите Apache Felix и посмотрите.

Вы не упомянули масштаб. Если граф объектов огромный , обратите внимание на такие технологии, как GigaSpaces или Coherence.

** 1) Sun вычеркнула «2» из аббревиатуры с введением EJB3 *

** 2) Объектные EJB 2.x были худшей частью. EJB 3 можно рассматривать как в значительной степени «если вы не можете победить их, присоединяйтесь к ним» как попытку стандартизировать Hibernate. *