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

Ответ 1

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

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

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

Последняя вещь: контейнеры Java EE реализуют стандарт, контейнер Spring не является, он является проприетарным.

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

• сеанс с состоянием beans (SFSB)
• расширенный контекст сохранения
• клиентский контейнер приложения/веб-запуск java
• кластеризация в зависимости от приложения. сервер
• Функциональность CORBA
• Интеграция JCA ~
• удаленный ~
• транзакции, управляемые контейнером ~
• достойное управление распределенными транзакциями (например, восстановление эвристического tx)

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

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

Ответ 5

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

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

Ответ 6

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

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

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

EDIT: в ответ на ваш комментарий у вас не будет EJB, соответствующим образом аннотированный и/или настроенный с помощью XML таким образом, чтобы код, который обращался к нему по EJB-совместимым способам, мог бы использовать его без изменений.

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

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

Ответ 7

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

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

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

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

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