Что такое Enterprise Java Bean на самом деле?

Question

В часто задаваемых вопросах Tomcat говорится: «Tomcat не является сервером EJB. Tomcat не является полноценным сервером J2EE».

Но если я:

• используйте Spring для предоставления контекста приложения
• комментирует мои сущности с помощью JPA аннотации (и использовать Hibernate как JPA провайдер)
• настроить C3P0 как данные пула соединений источник
• комментирует мои методы обслуживания с @Transactional (и использовать Atomikos как провайдер JTA)
• Используйте JAXB для сортировки и сортировки
• и, возможно, добавить мою собственную возможность JNDI

тогда разве у меня нет сервера приложений Java EE? И тогда мои бобы EJBs? Или есть какая-то другая определяющая характеристика?

Что такое сервер приложений, совместимый с Java EE, который вы не можете легко / легко получить от Tomcat с некоторыми сторонними подсистемами?

Answer 1

EJB - это компоненты JavaEE, соответствующие API javax.ejb.

JavaEE - это набор API, вам не нужно использовать их все.

Tomcat - это «частичный» сервер JavaEE, поскольку он реализует только некоторые API JavaEE, такие как сервлеты и JNDI. Это не реализует, например, EJB и JMS, так что это не полная реализация JavaEE.

Если вы добавили несколько дополнительных фрагментов (например, OpenEJB, HornetQ), вы добавите недостающие части и получите полный JavaEE-сервер. Но из коробки Tomcat не тот, и не пытается быть им.

Answer 2

Но если я добавлю (...), разве у меня не будет сервера приложений Java EE? И тогда мои бобы EJBs? Или есть какая-то другая определяющая характеристика?

Нет, у вас нет сервера приложений Java EE, полноценный сервер приложений Java EE - это больше, чем Tomcat + Spring + автономный менеджер транзакций. И даже если вы добавите JMS-провайдера и EJB-контейнер, у вас все равно не будет Java EE-сервера. Склейка между всеми частями важна для IMO и является частью добавленной стоимости контейнера Java EE.

Что касается EJB, спецификация EJB намного больше, чем JPA, и в ней также указываются Session Bean и Message Driven Beans (на самом деле, я не считаю JPA-сущности EJB-объектами, даже если JPA является частью спецификации EJB 3.0 в Java EE 5 по историческим причинам - что больше не соответствует действительности в Java EE 6, JPA 2.0 и EJB 3.1 являются отдельными спецификациями). Также следует отметить, что bean-компонент Spring, помеченный @Transactional, не эквивалентен Session-бину. Контейнер Java EE может делать больше вещей с Session Bean (см. Ниже). Возможно, они вам не нужны, но, тем не менее, они не являются строго эквивалентными.

И последнее, контейнеры Java EE реализуют стандарт, а контейнер Spring - нет, он является собственностью.

Что такое сервер приложений, совместимый с Java EE, который вы не можете легко / легко получить от Tomcat с некоторыми сторонними подсистемами?

Как я уже сказал, я думаю, что "клей" является частью добавленной стоимости и в значительной степени способствует надежности всего. Затем в ответе Эвернли очень хорошо подчеркивалось, чего трудно достичь. Я бы просто добавил:

• Кластеризация и Аварийное переключение (для обеспечения отказоустойчивости)
• Административные средства

Да, хороший сервер Java EE будет делать довольно аккуратные вещи для повышения отказоустойчивости (кластеризация пулов соединений, дерева JNDI, JMS-адресов, автоматическая повторная попытка с идемпотентными компонентами, интеллектуальные EJB-клиенты, восстановление транзакций, миграция служб и т. Д.) , Для «критически важных» приложений - в подавляющем большинстве нет - это важно. И в таких случаях библиотеки поверх API сервлетов являются IMO, а не заменой.

Answer 3

Действительно, если вы приложите достаточно усилий, вы почти превратите Tomcat / Spring в полноценный сервер приложений тяжелого веса :) Вы даже можете встроить переносимый контейнер EJB3 ...

Что такое приложение, совместимое с Java EE сервер дает вам то, что вы не можете легко / легко получить от Tomcat с какие-то сторонние подсистемы?

Есть еще несколько функций, которые трудно получить с помощью сторонних модулей:

• сессионные компоненты с состоянием (SFSB)
• расширенный контекст постоянства
• контейнер клиента приложения / запуск Java-приложения
• кластеризация в зависимости от приложения. Сервер
• Совместимость CORBA
• JCA интеграция ~
• удаленное взаимодействие ~
• транзакции, управляемые контейнером ~
• достойное управление распределенными транзакциями (например, восстановление эвристического TX)

Записи с ~ также поддерживаются Spring, но не так тривиально, по крайней мере, насколько мне известно.

Еще несколько деталей в этом ответе: EJB против Spring

Answer 4

1) Вы путаете сущности JPA с EJB. Хотя JPA относится к спецификации EJB3, она всегда была автономной технологией.

2) EJB: bean-компоненты без состояния, bean-объекты с состоянием и bean-объекты, управляемые сообщениями. Хотя каждая из этих функций может быть легко достигнута с помощью пружины, пружина просто не использует эту терминологию. Весной у вас нет POJO + "магия", как в EJB, весной это POJO + ваша собственная конфигурация (которая иногда тоже кажется волшебством). Основное отличие состоит в том, что Spring делает больше, а сервер приложений делает меньше, поэтому приложение Spring доволен tomcat, в то время как приложению ejb3 нужен «настоящий» сервер приложений.

На мой взгляд, 90% приложений могут быть развернуты с помощью Spring + Tomcat, ejb3 требуется редко.

Answer 5

Помимо строгого определения того, что является и не является EJB, вы добавляете много вещей в Tomcat. Даже если у вас есть сервер EJB, он больше не является простым Tomcat.

Часто задаваемые вопросы верны: Tomcat не является сервером EJB. Однако это может быть то или иное, если вы накапливаете достаточно дополнительных библиотек и кода.

Answer 6

тогда у меня не будет Java EE сервер приложений? И тогда не мой бобы EJB? Или есть какой-то другой определяющая характеристика?

Быстрый ответ EJB на самом деле должны следовать спецификации Java EE. Tomcat - это контейнер Java EE, а не сервер приложений.

Что такое приложение, совместимое с Java EE сервер дает вам то, что вы не можете легко / легко получить от Tomcat с какие-то сторонние подсистемы?

Быстрый ответ на ваш второй вопрос. В вашем случае скорее всего ничего.

EJB, как правило, являются очень тяжелыми объектами, и люди в конечном итоге использовали их для решения проблем, когда они были по существу излишними. Такие фреймворки, как Spring, были созданы для решения этих проблем без использования EJB. Я думаю, что первая книга, в которой был представлен Spring, даже называлась «Разработка J2EE без EJB».

Answer 7

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

Итак, EJB - это стандарт, который соответствует определенной спецификации и поэтому переносим.

На практике многие EJB не являются полностью совместимыми или нейтральными для сервера приложений. Однако, в основном они таковы, поэтому небольшие несовместимости будет гораздо легче исправить, если вы поменяете поставщиков серверов приложений, чем пытаетесь перенести описанную вами архитектуру на сервер GlassFish, JBoss или Weblogic.

РЕДАКТИРОВАТЬ: В ответ на ваш комментарий вы не будете иметь EJB, должным образом аннотированный и / или сконфигурированный с помощью XML таким образом, чтобы код, который обращался к нему с помощью EJB-совместимых способов, мог использовать его без изменений.

У вашего комментария есть два угла. Во-первых, какую функциональность вы потеряли бы при развертывании на JBoss или любом другом, а не на Tomcat? Скорее всего, ничего, если вы взяли с собой все фреймворки, на которые опирались. Однако, если вы хотите переместить свой код в Weblogic, например, чтобы использовать некоторые его функции, то для продолжения вашего кода потребуются некоторые вероятные существенные изменения.

Я не говорю, что вы не можете реплицировать все функциональные возможности EJB (безусловно, подмножество, которое вас интересует) другими способами, просто это не спецификация и, следовательно, не зависящая от реализации.