Что такое Боб Java Предприятия действительно?
На Tomcat FAQ это говорит: "Tomcat не является сервером EJB. Tomcat не является полным сервером J2EE".
Но если я:
- используйте Spring для предоставления контекста приложения
- аннотируйте мои объекты аннотациями JPA (и использование В спящем режиме как поставщик JPA),
- настройте C3P0 как источник данных организации пула подключений
- аннотируйте мои сервисные методы @Transactional (и используйте Atomikos в качестве поставщика JTA),
- Используйте JAXB для маршалинга и немаршалинга
- и возможно добавьте мою собственную возможность JNDI
затем у меня эффективно нет сервера JAVA EE-приложения? И затем разве моими бобами не является EJBs? Или там некоторый другой определяет характеристику?
Что, Java EE совместимый сервер приложений дает Вам, что Вы не можете легко/с готовностью добраться от Tomcat с некоторыми сторонними подсистемами?
7 ответов
Но если я добавлю (...), разве у меня не будет фактически сервера приложений Java EE? И тогда разве мои EJB-компоненты bean не являются? Или есть какая-то другая определяющая характеристика?
Нет, у вас нет сервера приложений Java EE, полноценный сервер приложений Java EE - это больше, чем Tomcat + Spring + автономный диспетчер транзакций. И даже если вы добавите поставщика JMS и контейнер EJB, у вас все равно не будет сервера Java EE. Клей между всеми частями важен для ИМО и является частью добавленной стоимости контейнера Java EE.
Что касается EJB, то спецификация EJB - это гораздо больше, чем JPA, и она определяет также сессионные компоненты и компоненты, управляемые сообщениями (на самом деле, я действительно не рассматриваю объекты JPA как EJB, даже если JPA является частью EJB 3.0 в Java EE 5 по историческим причинам - что больше не соответствует действительности в Java EE 6, JPA 2.0 и EJB 3.1 являются отдельными спецификациями).
Я также должен упомянуть, что компонент Spring, аннотированный @Transactional , не эквивалентен Session Bean. Контейнер Java EE может делать больше с сессионными компонентами (см. Ниже). Возможно, они вам не понадобятся, но, тем не менее, они не строго эквивалентны.
И последнее: контейнеры Java EE реализуют стандарт, а контейнер Spring - нет, он проприетарный.
Что дает вам сервер приложений, совместимый с Java EE, чего нельзя легко / легко получить от Tomcat с некоторыми сторонними подсистемами?
Как я уже сказал, я думаю, что «клей» является частью добавленная стоимость и вносит большой вклад в надежность всего. Затем в ответе Эвернли очень хорошо подчеркивается, что трудно достичь. Я бы просто добавил:
- Кластеризация и отказоустойчивость (для достижения отказоустойчивости)
- Средства администрирования
Да, хороший сервер Java EE будет делать довольно изящные вещи для устранения сбоев толерантность (кластеризация пулов соединений, дерево JNDI, назначения JMS, автоматическая повторная попытка с идемпотентными bean-компонентами, интеллектуальные клиенты EJB, восстановление транзакций, миграция служб и т. д.). Для «критически важных» приложений - а подавляющее большинство - нет - это важно. И в таких случаях библиотеки поверх Servlet API не заменяют собой ИМО.
1) Вы путаете сущности JPA с EJBs. Хотя JPA входит в спецификацию EJB3, он всегда задумывался как самостоятельная технология.
2) EJBs бывают: stateless beans, stateful beans и message driven beans. Хотя каждая из этих функций может быть легко реализована с помощью Spring, Spring просто не использует эту терминологию. В Spring у вас нет POJO + "магия", как в EJBs, в Spring это POJO + ваша собственная конфигурация (которая иногда тоже кажется магией). Основная разница в том, что Spring делает больше, а сервер приложений - меньше, вот почему приложения Spring довольны tomcat, а приложениям ejb3 нужен "настоящий" сервер приложений.
На мой взгляд, 90% приложений можно развернуть с помощью spring + tomcat, ejb3 нужен редко.
Действительно, если вы приложите достаточно усилий, то сможете превратить Tomcat/Spring в полноценный тяжелый сервер приложений :) Можно даже встроить переносимый контейнер EJB3...
Что такого дает вам сервер приложений, совместимый с Java EE? сервер дает вам то, что вы не можете легко и просто получить от Tomcat с
Есть еще несколько возможностей, которые трудно получить с помощью сторонних модулей:
- stateful session beans (SFSB)
- extended persistence context
- application client container / java web start
- clustering depending on the app. сервер
- совместимость с CORBA
- интеграция JCA ~
- удаленное управление ~
- управляемые контейнером транзакции ~
- достойное управление распределенными транзакциями (например, восстановление эвристического tx)
Записи с ~ также поддерживаются Spring, но не так тривиально, по крайней мере, насколько мне известно.
Еще несколько деталей в этом ответе: EJB против Spring
Помимо строгого определения того, что является EJB, а что нет, вы добавляете много чего в Tomcat. Даже если у вас есть сервер EJB, это уже не совсем обычный Tomcat.
FAQ правильный: Tomcat не является сервером EJB. Однако это может быть и то, и многое другое, если вы накопите достаточно дополнительных библиотек и кода.
EJB-компоненты - это компоненты JavaEE, соответствующие API javax.ejb .
JavaEE - это набор API, вам не нужно использовать их все.
Tomcat является «частичным» сервером JavaEE, поскольку он реализует только некоторые API-интерфейсы JavaEE, такие как сервлеты и JNDI. Он не реализует, например, EJB и JMS, так что это не полная реализация JavaEE.
Если вы добавили некоторые дополнительные части (например, OpenEJB, HornetQ), вы добавили бы недостающие части, и в результате вы получили бы полноценный сервер JavaEE. Но из коробки Tomcat не такой и не пытается им быть.
Реализация EJB представляет собой компонент, написанный и упакованный для работы на любом совместимом сервере EJB. Если вы сделаете то, что описываете, это может сработать, но не будет переносимым на сервер приложений другого поставщика.
Таким образом, EJB - это стандарт, который соответствует определенной спецификации и поэтому является переносимым.
На практике многие EJB не полностью совместимы или не нейтральны к серверу приложений. Однако в основном это так, поэтому небольшие несовместимости будет намного проще исправить, если вы смените поставщика сервера приложений, чем пытаться перенести описанную вами архитектуру на сервер GlassFish, JBoss или Weblogic.
РЕДАКТИРОВАТЬ: В ответ на ваш комментарий у вас не было бы EJB, должным образом аннотированного и / или настроенного через XML таким образом, чтобы код, обращающийся к нему совместимыми с EJB способами, мог бы использовать его без изменений.
Ваш комментарий имеет два аспекта. Во-первых, какую функциональность вы потеряете при развертывании на JBoss или любом другом вместо Tomcat? Скорее всего, ничего, если вы взяли с собой все фреймворки, на которые полагались. Однако, если вы хотите переместить свой код в Weblogic, например, чтобы использовать некоторые из его функций, тогда в ваш код потребуются некоторые существенные изменения, чтобы не отставать.
Я не говорю, что вы не можете воспроизвести всю функциональность EJB (определенно подмножество, которое вам нужно) другими способами, просто это не спецификация и, следовательно, не независимая от реализации.
тогда разве у меня нет Java EE? сервер приложений? И тогда не мой фасоль EJB's? Или есть другие определяющая характеристика?
Быстрый ответ EJB-компоненты на самом деле должны соответствовать спецификации Java EE. Tomcat - это контейнер Java EE, а не сервер приложений.
Что такое приложение, совместимое с Java EE? сервер дает вам то, что вы не можете легко / легко получить из Tomcat с помощью какие-то сторонние подсистемы?
Быстрый ответ на ваш второй вопрос. В вашем случае скорее всего ничего.
EJB-компоненты, как правило, являются действительно тяжелыми объектами, и люди в конечном итоге использовали их для решения проблем, когда они были, по сути, излишними. Такие фреймворки, как Spring, были созданы для решения этих проблем без использования EJB. Я думаю, что первая книга, в которой был представлен Spring, даже называлась «Разработка J2EE без EJB».