Java EE/Glassfish Application Logic

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Вы можете создать EJB Timer, который будет вызываться периодически. Если вам нужна модель для загрузки один раз в памяти, я бы посоветовал вам посмотреть на beans также Singleton. С EJB 3.0 проблема была в том, как start the timer automatically, но я думаю, что они улучшили это в EJB 3.1, а таймеры могут быть started automatically by the application server, когда приложение развернуто с помощью аннотации @Scheduled. Таким образом, он может каким-то образом предоставить вам желаемую начальную точку, как вы задали в своем предыдущем вопросе.

Вы можете отправить сообщение JMS от любого bean-компонента. 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) и Message-Driven Beans (напрямую используйте JMS API). Приложение OSGi становится немного похоже на ядро ​​Linux и процесс загрузки, причем службы развертываются и запускаются в соответствии с уровнями выполнения. Захватите Apache Felix и посмотрите.

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

** 1) ВС принял '2' из аббревиатуры с введением EJB3 *

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