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

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

Подходит ли EJB для такой функциональности?

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

Как я могу начать инициализацию моей объектной модели (эквивалент основного метода Java-приложения)?

Не существует такого понятия, как метод main. Но есть еще несколько способов выполнить некоторую обработку, соответствующую развертыванию и/или отмене развертывания приложения. Вы можете просмотреть ServletContextListener, модуль жизненного цикла Glassfish (нестандартный) или, возможно, недавно представленный < bean-компоненты href="http://blogs.oracle.com/kensaks/entry/singletons" rel="nofollow noreferrer">Singleton и аннотация @Startup.

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

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

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

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

Как вы сказали, примеры, как правило, связаны с прямым вызовом. По моему опыту, это не просто примеры. Ни одно из приложений 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) Entity EJB 2.x были худшей частью. EJB 3 можно рассматривать как попытку стандартизировать Hibernate по принципу «если не можешь победить — присоединяйся к ним».*