Некоторые java-программисты относятся к EJB несколько предвзято, предпочитая использовать заменяющие технологии (напр. Spring). Их можно понять, если говорить о EJB версий 1.х и 2.х, но ведь предвзятое отношение часто переносится и на версию 3.х, что приводит к вот таким (например) высказываниям - 11548196 .

Давайте в этой теме обсудим EJB 3.x и смежные технологии звена бизнес-логики - CDI и JPA.

Расскажите, что вам не нравится в EJB (CDI и JPA) и мы попытаемся разобраться, насколько претензии обоснованы.


Пара популярных мифов о EJB:

Миф 1. "EJB это сложно".

На самом деле, простейший EJB проще чем можно себе представить:
Добавив аннотацию @Stateless к обычному java-классу, мы превратили его в Stateless Session Bean, и сделали метод method() транзакционным. По необходимости класс может имплементить интерфейс (например, если метод нужно вызывать удалённо или для уменьшения зависимостей).

Миф 2. "Сервера приложений для Java EE очень жирные и тормозные".

На самом деле, посмотрим на этот обзор - http://agoncal.wordpress.com/2011/10/20/o-java-ee-6-application-servers-where-art-thou/
Жирная там только IBM Websphere (это же IBM, несолидно весить меньше 2-ух гиг). Все остальные (GlassFish, Resin, JBoss, TomEE, Geronimo, etc) небольшого размера и запускаются за секунды.

BlazkowiczSession Beans ведут себя не тривиально в случае многопоточности. Stateful тупо сериализуют запросы. Stateless выдают инстансы из пула.
Как раз ведут себя предсказуемо, программисту вообще не нужно волноваться о конкурентности.

BlazkowiczКак с таким поведением воспользоватся всеми прелестями java.util.concurrent ?
Используйте @Singleton с @ConcurrencyManagement(ConcurrencyManagementType.BEAN) - и пользуйтесь прелестями java.util.concurrent.

BlazkowiczКак связать EJB и HTTP?
Можно подробнее, что имеется в виду?

Ну и простейший пример - http://www.adam-bien.com/roller/abien/entry/ejb_3_1_killed_the

BlazkowiczНа самом деле упрощен только синтаксис.
+ интуитивно-понятное поведение (дефолтовое вообще без конфигурирования).

BlazkowiczРазве не так? JBoss 4 или WebSphere CE сами по себе без дополнительных приложений стартуют пол минуты. За это же время разворачивается проект на Spring+Tomcat+MINA.
Не будем вспоминать древности.

Blazkowiczо! Свежие данные. Показывают очевидное превосходство томката над остальными бесплатными контейнерами.
Да, только в проект на томкате ещё нужно добавить несколько метров хибернейта, несколько метров спринга, и т.д.

vimbaНе нравиться в EJB отсутствие пассивного разрешения зависимостей в DI. Какой там финансовый и гос. сектор, открываем абсолютно любой учебник для школоты по басику и там будет написано, что конфигурацию нужно выносить из кода.
Можно вынести в beans.xml. Там можно указать alternatives и stereotypes.

vimbaНе нравиться Local и Remote интерфейсы, я чо попугай что-ли повторять одно и то-же по два раза, есть сервис он может делать что-то полезное, а могу я до него рукой достать или мне нужно сделать пару шагов, меня как разработчика это интересовать не должно, это опять же дело конфигурации, которая должна быть вынесенна из кода.
Ну да, конфигурируется всё.

vimbaНе нравяться тормоза. Тут конечно Вы придеретесь, как это так, ведь EJB всего лишь спека, а документ тормозить не может, но абсолютно все реализации EJB конкретным производителем которые я видел, без единого шанса сливали спрингу.
Нет, не придерусь. Но интересно узнать что тормозило.

vimbaНе нравится несовместимость конфигов для разных серверов.
Разное там конечно есть, но не так уж много. Навскидку login configuration и описание datasource. Дальше что?... persistence.xml, application.xml и beans.xml от сервера не зависят.

vimbaНе нравятся многочисленные лисопеды типа пула stateless объектов, для спрингера это полный идиотизм держать в памяти много полностью идентичных объектов, пул которых еще и может стать бутылочным горлышком, маразм да и только.
Как раз за счёт пула мы получаем скорость, не нужно при каждом вызове создавать объекты, это же маразм - создавать stateless объекты при каждом вызове, правда?

vimbaВы это на полном серьёзе заявили, или Вам на выходных заняться нечем?
Да.))

vimbaJPA скопипижжен с hibernate, и постоянно отстаёт от hibernate, так как физически невозможно украсть идею быстрее чем она опубликованна
Значит JPA так же хорош как hibernate! (раз скопипижжен.) Более того, неудачные моменты убираются в процессе стандартизации!

BlazkowiczCriteria API, видать, вообще не удачная фича целиком и полностью, раз в JPA сразу не включили.
Видимо, им не нравилось, как она в hibernate реализована.
Не скажу, что в JPA критерии выглядят хорошо. Скажу даже, что они выглядят ужасно.))
Но это оттого, что они хотели чтоб с помощью метамодели можно было проверять корректность запросов на этапе компиляции. И это работает.
Я сам очень хорошо отношусь к hibernate, и при необходимости использую фичи хибернейта из JPA, благо
сделать не сложно.

BlazkowiczИнтересно почитать про EJB в качестве бэкенда к GWT и Flex. Был уже у кого опыт?
Тут сказать ничего не могу, не знаком с GWT и Flex.
BlazkowiczSpring 3, например, REST JSON и Hessian Remoting из коробки поддерживает.
Hessian-а, конечно нет. Но REST JSON разве EE6 не поддерживает?

Например такой класс автоматом выдаст хеш-таблицу в виде JSON:

vimbaЕсть у меня интерфейс сервиса для справочников допустим: записать, создать, удалить, найти по критерию. Он универсальный интерфейс и у него возможно и реализация одна, но в рабочем приложении нужно 20-30 экзепляров, короче по числу справочников, каждая реализация сконфигурированна конкретным ДАО которое умеет работать с конкретной сущностью. Как я с помощью альтернатив опишу тридцать реализаций одного и того же интерфейса? Допустим сервис для клиентов представляется как стандартный справочник и мне нужно заинжектить в него в сервис для накладных:

Хороший вопрос. Пока ответить не могу, постараюсь разобраться и скажу, можно ли так сделать с помощью CDI.

vimbaЯ под столом. Насколько же нужно быть упоротым на EJB, чтобы в упор не замечать что этот пул вообще не нужен, что он является издержками джамшутовского дизайна, ведь достаточно только одного объекта на каждом экземпляре в кластере.
На одном экземпляре мы не получим возможность использования instance variables, т.к. они могут быть модифицированы разниыми тредами, а стандарт гарантирует, что никто не тронет ваши instance variables пока идёт выполнение бизнес-метода.
Тут вы можете сказать, что просто не нужно использовать instance variables, нужно обойтись локальными и всё будет хорошо. Однако, представьте, что ваш бизнес-метод вызывает ещё много приватных методов - и если нужно передавать между ними много параметров, то проще использовать именно instance variables, чтобы не описывать кучу аргументов для каждого приватного метода. Так что без пула никак. А один объект на каждом экземпляре в кластере - это уже синглтон получается.

BlazkowiczНа самом деле вопрос стоит не совсем верно. Очевидно что EJB становится всё лучше и вкуснее. Но на данном этапе актуальным вопросом становится "а что мне такого может дать EJB, если всё что мне нужно я имею в Spring/Hibernate и не жалуюсь". Spring уже давно доказал своё превосходство и отвоевал свою нишу. Поэтому вопрос о том чем EJB хуже - не актуален. Даже если он не хуже (а corner cases в проприетарном API никто не отменял), то он и ни чем не лучше.
ну вот, практически закрыли тему. (((