EJBs и современная разработка Java

Question

Я новичок в Java EE и вижу, что EJB являются живыми и хорошо подходят для чистого сообщества Java/Oracle. Однако каждый на работе проявляет отвратительный взгляд на лицо, когда кто-то еще произносит фразу «EJB», что заставляет меня думать, что они либо исчезли, либо были заменены современными командами разработчиков с некоторыми другими технологиями промежуточного программного обеспечения.

Точно так же, как JSP уступил место технологиям JSF-ориентированного просмотра, то же самое верно для EJB? В любом случае, какие популярные альтернативы EJB и как они отличаются? Какие преимущества или возможности они предлагают для EJB?

Answer 1

Первая версия EJB была представлена ​​еще в конце 1990-х годов.

Отвратительный взгляд на лицо ваших коллег, когда упоминается EJB, может быть следствием очень сложных и неприятных шаблонов использования первых двух версий EJB (например, сложных дескрипторов развертывания xml).

3.0 и 3.1 были основными улучшениями относительно простоты использования.

Популярный альтернатива Spring framework + Hibernate/JPA

Answer 2

Когда они были введены, EJB были решением в поисках проблемы, и в этом был high-end.

Предполагалось, что EJB предоставит возможность программам определять единицу работы таким образом, чтобы сервер приложений, содержащий «EJB», обрабатывал все более сложные биты, такие как балансировка нагрузки, местоположение, отказ, безопасность, удаленный доступ и т. д. На самом деле, когда разработчики все загорались на блестящем новом языке, реализации не были действительно готовы для всех тяжелых грузовиков, они, возможно, воспользовались функциями, но конфигурация и развертывание были, безусловно, кошмаром. Это не помогло, что спецификация EJB была в движении в течение времени, и производительность основного кандидата на случай использования, Entity Bean, была сильно лишена.

В моем случае мы разработали EJB для обработки того, что всегда было пакетным процессом - один раз в день получаем набор транзакций, делайте некоторые материалы базы данных, а затем отправляете результат различным заинтересованным сторонам и создавайте отчеты. Нам не нужна ниточная или балансировка нагрузки, не говоря уже о большинстве других функций EJB. То, что использовалось больше всего, было веб-ориентированным подходом к приложениям. Приложение whold могло быть сделано с некоторыми пакетными заданиями и несколькими веб-страницами.

Answer 3

Ваши сотрудники могли видеть только EJB2 и раньше, что на самом деле были нечистые животные, что очень немногие люди пользуются помощью.

В EJB2 Для простейших вещей, имеющих очень инвазивные рамки, должны быть реализованы интерфейсы с безумными жизненными циклами, для которых разработчик должен был обеспечить реализацию, но не имеющую ничего общего с целями (бизнесом) разработчика. Необходимо было предоставить несколько таких артефактов.

Кроме того, каждый бит должен храниться в синхронизации с записями в очень подробном и трудно читаемом дескрипторе развертывания (файл XML). Как будто это было недостаточно оскорбительно для разработчика, специальные инструменты должны были использоваться для «улучшения» компонента и создания прокси-классов, скелетов и заглушек. Общие вещи OO, такие как наследование, не поддерживались. Там была какая-то инъекция, но странная, которая существовала для того, чтобы помещать вещи в своего рода карту (на самом деле директорию), связанную с каждым компонентом.

Оригинальная модель EJB 1 принудительно передала всю связь удаленно и все объекты, подлежащие распределению (EJB изначально считались только технологией удаленного доступа).Чтобы получить преимущества EJB, вы также были вынуждены распределять свою архитектуру, даже если это было совершенно не нужно.

Возможно, самым большим оскорблением была концепция Бина Сущности (не путать с сущностями JPA). Ошибки с этим типом бобов были настолько велики, что даже самые большие сторонники EJB в то время едва могли рекомендовать его кому-либо.

Тогда, как очень практичная проблема, совместимость между реализациями EJB была не очень хорошей, если не сказать больше. Особенно Entity Beans требовало огромного количества специфической конфигурации поставщика.

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

Неудивительно, что эта технология не понравилась среднему разработчику.

Солнце как раз вовремя осознало, что технология движется в совершенно неправильном направлении и совершает поворот на 180 °, и запустил массивный реинжиниринг.

В результате EJB 3 (2006) - очень разумный и легкий подход. Для реализации нет необходимых интерфейсов интерфейсов, нет требуемого XML, только один бит должен быть закодирован (просто простой POJO), повсеместно применяются стандартные значения по умолчанию (условная конфигурация), не требуются специальные инструменты (обычный javac будет do), и использование простых бобов локально на самом деле является общим случаем.

Сущность Бобы были настолько ошибочными, что их полностью отбросили и заменили на более здравый подход, рекомендованный TopLink и Hibernate среди других.

Объедините это с широким выбором бесплатных, легких и с открытым исходным кодом в сочетании со многими известными блоггерами, выступающими за технологию (например, Адам Бьен, Режа Рахман, Гэвин Кинг), и возвращение к популярности легко объяснить ,

Недавно было опубликовано несколько руководств по миграции «Весна-Ява», которые получили очень благоприятное количество голосов на разных новостных сайтах, и многие люди выражают свою поддержку EJB как очень хорошей технологии сейчас , Это было бы немыслимо полвека назад (когда EJB 3 был только что выпущен и еще не был очень известен).

Наиболее распространенной альтернативой EJB является весеннее ядро ​​(весенние бобы). На данный момент я думаю, что нет никаких особых преимуществ Spring над EJB и наоборот. Эти две технологии очень похожи. Spring предлагает несколько дополнительных утилит, в то время как EJB концептуально более легкий (без XML). Оба преимущества несколько субъективны. Они, как правило, вдохновлены функциональностью друг друга, а кто немного впереди, часто зависит от того, какая технология в последний раз выпустила крупную новую версию.