Я не знаю EJB и JSF

Как то так сложилось что при моем примерно 7-летнем опыте коммерческой разработки на Java я почти не имею опыта в EJB. Хотя это первое что спрашивают на собеседовании, я ведь проверял не так давно. Самое интересное, кстати, в том что многие собеседователи после кучи вопросов по опыту в EJB/WebSphere/JMS/пр., о том как это все им важно и пр., рассказывая о своих проектах, говорят что на практике все их проекты разрабатываются без какого либо EJB и прекрасно работают по Tomcat, а WebSphere получается лишь для веса. Возможно и потому что не серьезно сейчас предлагать решение без WebSphere/WebLogic + Oracle.

А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.

EJB немного был когда я работал в Luxoft, но это почти мимо меня прошло. К EJB как таковому у меня отношение отрицательное из-за больших объемов лишней работы, я считаю что простые вещи должны делаться просто. Для EJB это не выполнялось, простые вещи делались сложно. Да и, честно говоря, сложные вещи делались не сложно, а очень сложно. Тоже самое касается и JSF. Система становится всеобъемлющей, делает все что можно, но, как результат комплексности, делает «все» одинаково плохо. Говорят с EJB 3.0 все лучше стало, т.к. изучили опыт аналогов (читай стараются догнать). Но это немного поздно, и с учетом инертности крупных разработчиков все совсем плохо.

Все это рассчитывалось на то что с этим сможет работать совершенно некомпетентный специалист, который возьмет какую либо GUI рисовалку и, не понимая базовых принципов, наклепает работающее приложение. В результате совершенно непонятно как вся эта хренотень может работать, и требует огромных компьютерных ресурсов. Хотя для последнего всегда проще купить HP Superdome и не парится (к тому же часто наоборот, сервера уже стоят, а загружены на 10%, но это уже решается другими методами). На самом деле я даже согласен, часто действительно лучше и гораздо дешевле поставить железо мощнее, но только когда это не вызвано уродством архитектуры. Т.е. когда мы пишем сервер на Ruby (например) и получаем красивое технологически решение, поддерживаемое и легко расширяемое, то потребность в больших ресурсах вполне себе оправдана, но когда говорят «а нафиг нам пул соединений с БД? без него точно все работает, а с ним вдруг что случится? у нас сервер хороший и без пула потянет!» то тут уже не сервер ставить, а архитектора увольнять. Хотя и мысль теоретически даже правильная, но не в том месте.

JSF больше страдает клиентской избыточностью, но для intranet на это еще можно забить. Я даже пару раз пытался использовать это, но так и не понял вкуса. К тому же если нужно создавать хороший интерфейс не заморачиваясь с html/javascript, то надо использовать GWT, а не JSF. Но это, конечно, если нет в требованиях пункта «поддержка Netscape Navigator 3.0», что еще было обязательным года 3 назад, надеюсь сейчас эти «компьютеры» уже окончательно доломались и на замену поставили те где можно поставить браузер посовременней.

А то к чему приводит разработка лишь на JSF могу проиллюстрировать тем что на очередном собеседовании с большим недоверием отнеслись к тому что я могу редактировать JSP/HTML в текстовом редакторе, вместо положенного WYSIWYG редактора. Очень удивились тому что я могу предполагать как изменится внешний вид в браузере после редактирования исходного HTML этой страницы. Я по своей наивности считал это вполне обыденной вещью, которую можно поручать даже школьнику-верстальщику. Ладно хоть не сказал что, к примеру, еще понимаю как HTTP протокол организован и на сайты хоть телнетом ходить могу.

Та вот, к чему я. В начале заголовок статьи был «Я не использую EJB и JSF», сейчас заменил на «Я не знаю EJB и JSF». Т.е. это скорее не принципиальное решение, а ситуация. Ведь может быть действительно моя проблема в том что я не знаю их? Может там есть очень серьезные плюсы? Серьезные выигрыши для проекта, для архитектуры, по сравнению с теми же Spring, Hibernate и пр.? Снижение каких то рисков? Если в случае EJB еще более-менее понятно, само по себе оно нужно, как минимум все части по отдельности востребованы. Вопрос в том нужны ли столь тяжеловесные решения иногда для простых задач, когда есть прекрасные и удобные альтернативы. Иногда конечно стоит взять готовую коробку от IBM, Oracle или BEA, вместо набора различных OS кубиков типа Mule, ActiveMQ, JBoss, Hibernate, Spring и т.д. Это касается EJB, а вот в случае JSF мне вообще непонятно как оно до сих пор существует и кому это надо, неужели JSF дает что-то такое что разработка становится настолько дешевле?

  • http:// Михаил

    Иногда это неплохо, не иметь опыта с EJB — слышал о работодателях, которые сразу отправляли в карзину резюме, где EJB был один из ключевых навыков. Так же видел неодного товарища, которые «сильны» в EJB настолько, что без EJB 2+2 посчитать не могут.

    Но с другой стороны, если рассматривать EJB как удобную прослойку между внешним миром и бизнес-логикой, то получается удобно. К примеру, чтобы сделать код доступным по RMI намного удобнее написать Session EJB, чем самостоятельно реализовывать поддержку регистрации классов в RMI Registry. Entity Beans, конечно, очень спорная концепция, которую, тем не менее, с помощью JPA довели до приемлимого состояния. MDB тоже неплохи, когда стоят простые STP задачи. Для сложных случаев, правда, уже не хватает контроля и нужно все делать руками, включая многопоточное сканирование очереди. Так что недурной конструктор, EJB 3.

  • http://artamonov.ru splix

    Так, подождите, Spring разве не предоставляет тех же возможностей по связыванию через RMI? Помнится я связывал спринговые бины на разных машинах, и все это делалось лишь изменение XML для уже существующего и изначально не рассчитанного на такие финты приложения.

    Т.е. изменения в коде и так не было, что в данном случае еще даст EJB? Элементарная ведь задача, ну как минимум для спринга. В EJB 2 помнится надо было всякие интерфейсы реализовывать и прочий ненужный геморой. На EJB 3.0 уже надеюсь не придется что то в коде городить для этого, тратить дополнительно время и пр.?

  • http:// A_Gura

    Каждый инструмент решает свою задачу.

    JSF, видимо, решает задачу маркетинговую 🙂

  • http:// And

    JSF сам по себе действительно мрачноватая штука, особенно его navigation-rules :). Хотя сейчас использую его в качестве слоя отображения в системе под управлением SpringWebFlow 2.0, и мне нравится 🙂

  • http://artamonov.ru splix

    Да, помнится я как то запарился с этими navigation-rules. Хотя вообще к ним претензий особо нет, идея полезная.

    А вот Spring WebFlow не смотрел, если честно, все как то руки не доходили.

  • http:// Daniel

    Вообще забавно, что в webflow имеет яркую направленность на JSF (по крайней мере поддержку).

    Для себя так и не решил, как же использовать webflow.

    Весьма интересно зачем сделали ограничение на количество «ходов» (которое, впрочем, можно сделать бесконечным, но зачем-то же они ограничили).

    О JSF и EJB только читал теорию.

  • http:// Vadim

    У меня полностью аналогичная ситуация.

    Но где-то пол-года назад я прийшел работать на проект, в котором большая часть архитектуры состояла из EJB2.1

    Прийшлось срочно подучиться. Так вот выводы сделал абсолютно аналогичные вышим.

    А с началом перехода на EJB3 как-то даже и втянулся: JPA стал сердцу мил, нет мегабайтов XML, легко тестируется.

  • http:// Александр Савченко

    Да просто сотрудникам, которые проводят собеседование гораздо проще задать стандартный набор вопросов типа:

    знаете ли Вы EJB/JSF/Weblogic и т.д. чем разбираться по сути — сможет ли кандидат работать на данной должности ли нет 🙂

    Так что тут вопрос не в технологиях...

  • http://artamonov.ru splix

    Саша, поясни плиз, не совсем понял твою мысль.

    Ты имеешь ввиду что все эти вопросы и требования в вакансиях лишь шаблон не имеющий ничего общего с действительностью? В таком случае не понятно что заставляет использовать эти шаблоны, вместо того чтобы задать вопросы которые действительно интересуют компанию?

  • http:// Armen

    Ну про EJB я согласен полное дермо, но EJB3 это уже другая теxнология и самая лучшая как таковая.+JPA/JPQL

    JSF плоx когда используеш не правильным образом, JSF надо интегрировать с facelets it.d...

    А так же надо интегририовать JSF/EJB3>>>>>>>>>.

    Websphere это дерьмо настоящее, реклама и все.tejolaja, tolstaja............

  • http:// Сергей

    EJB3 имеет право на жизнь. Последний год реализовал на нем high-load проект. Простота использования позволяет легко масштабировать систему, распределять физически ресурсы баз данных, организовывать балансер нагрузки. Когда маленькому проекту необходимо нарашивать мускулы, то EJB3 в самый раз. Единственное здесь надо прочуствовать архитектуру EJB3, так как если, неумело организовать структуру проекта, то в дальнейшем придется мучится, в общем главное чтобы тимлид был адекватным и не городил че попало.

    Насчет связки EJB3 & JSF => Seam (Jboss), конечно придется приноровится, но лучше чем заново изобретать связку.

  • http://artamonov.ru splix

    Я прекрасно понимаю что дает EJB. Мне больше интересно чем оно лучше других решений, типа упомянутых Spring + Acegi + Hibernate.

    Как минимум пару я вижу:

    1. единая коробка все в одном

    2. известный солидный бренд

    Хотелось бы еще

  • http:// ig78

    Насчет jsf. думаю, он повторит историю ejb, т.е. его первые версии будут мрачноватыми (как и первые версии ejb), а дальше в один прекрасный момент все изменится в лучшую сторону (как изменилась технололия ejb с появлением ejb3).

  • http:// c0nst

    Сложные тяжелые технологии (EJB, ESB, Oracle) используются для увеличение стоимости проекта. Не знаю ни одного человека, который для своих проектов такое использует. Но в случае с продажами перед заказчиком звучат слова reliability, flexibility, robustness и так далее.

    Против этого не попрешь.

    Для своих проектов использую — jetty (не tomcat и тем более не вебсферу), h2 database (не oracle и не DB2), ant (не maven). Список можно продолжать.

  • http:// den

    Незнаю JSF это стандар а GWT всего лиш очередная реализация java+AJAX

  • http:// Jurgen

    Если предполагается работа проекта на одном сервере то связки Spring (with modules) -Hibernate/JPA-Tomcat вполне достаточно. Если предполагается использование кластера под тяжелой нагрузкой, то тут предпочтительней EJB и только из-за того что распределенную среду на JBoss/WebSphere/BEA etc построить проще.

  • http://artamonov.ru splix

    А проще ли?