Java Прикладная логика EE/Glassfish
Я пытаюсь понять, где часть моей прикладной логики должна войти в мое JAVA EE-приложение. Я плохо знаком с Java EE и смотрю на загрузку большого количества неструктурированных данных из унаследованной базы данных и создания чистой объектной модели для использования моим приложением. От моего расследования я вижу Java, приложения EE имеют 2 компонента, Компонент уровня предприятия и компоненты веб-приложения. Эта часть моего приложения будет ответственна за загрузку данных, создание объектной модели и отправку сообщений через JMS на основе текущего состояния данных заинтересованным сторонам. Данные будут обновлены синхронизацией с базой данных и из сообщений, полученных через JMS от удаленных JAVA-приложений.
Действительно ли EJB является корректным местом для этого вида функциональности? Как я могу запустить инициализацию своей объектной модели (эквивалентное Приложение Java основного метода)? Какова лучшая практика для создания синхронизированного события, чтобы рассмотреть объектную модель и отправить сообщения через JMS?
Я прочитал много статей о Java EE, Glassfish, EJB's..., но все еще не чувствую, что у меня есть четкое изображение того, где я должен писать эту функциональность. Любые примеры, которые я видел EJB, имеют тенденцию быть вокруг прямого метода, обращается к бобам от клиентских приложений.
В данный момент я чувствую, что JAVA-приложение может сделать задание, но мы смотрим на использование RMI и веб-клиентов в будущем.
2 ответа
Java EE традиционно используется для архитектурного стиля клиента / сервера. Бизнес-логика реализована в сеансовых бобах EJB, которые обычно вызывают либо из веб-запроса, сообщению JMS или удаленного вызова RMI-IIOP.
это EJB правильное место для этого Вроде функциональность?
Логика переходит в EJB. Но есть разные виды EJB.
Как я могу начать инициализацию Мой объект модели (основной метод java приложение Эквивалент)?
Нет такой вещи, как метод Main . Но есть еще несколько способов выполнять некоторую обработку, соответствующую развертыванию приложений и / или недействительной. Вы можете посмотреть ServletContextListener , Модуль жизненного рычага из стекла (нестандартный) или, возможно, вновь введенный Singleton бобы и @startup аннотация.
Какова лучшая практика для Создание мероприятия Timed для просмотра Модель объекта и отправка сообщений через 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 дал вам, было надежным, транзакционным back-end к веб-приложению, используя преимущества MDB и JTA, в то время как в остальном игнорируя как можно большую часть EJB Container*2 (и значительно упрощая юнит-тестирование в процессе). Вы можете использовать этот подход и построить ваше приложение как единый WAR-файл и загрузить ваши внутренние сервисы с помощью Spring.
Интересной альтернативой является полное удаление сервера приложений Java EE и построение вашего приложения на основе фреймворка OSGi. Это "обычное Java-приложение", с запуском OSGi, дающим вам консоль администрирования и возможности горячего развертывания, которые в противном случае вам пришлось бы развернуть свои собственные. Пропущенными битами инфраструктуры являются таймер (используйте Кварц) и бобы, управляемые сообщениями (используйте непосредственно JMS API). Приложение OSGi заканчивается тем, что чувствует себя немного похожим на ядро Linux и процесс загрузки, с сервисами, развернутыми и запущенными в соответствии с уровнями запуска. Возьмите Apache Felix и посмотрите.
Вы не упомянули о масштабе. Если объектный граф имеет огромный , посмотрите на такие технологии, как GigaSpaces или Coherence.
**1) Солнце убрало "2" из аббревиатуры с введением EJB3*
**2). Сущность EJBs 2.x была наихудшей частью. EJB 3 можно рассматривать как в значительной степени попытку "если вы не можете победить их, присоединяйтесь к ним" для стандартизации Hibernate.*
.