Заметка «Spring не является Java EE технологией и почему EJB идеологически лучше»
Denys BezsmertnyiОпубликовано 12.11.2008 в Статьи
Комитет JCP в спецификации JSR 244: JavaTM Platform, Enterprise Edition 5 (Java EE 5) определил набор JSR спецификаций, которые включаются в Java EE платформу. Задача комитета JCP — издавать спецификации на основе которых Open-Source сообщества, а также коммерческие организации создают реализации. Spring Framework не является реализацией JSR спецификации и, поэтому, не включен в список стандартных JEE технологий.
Spring Framework используется для разработки Java/Java EE приложений, таким образом он становится частью Java EE приложения, но не является Java EE технологией.
Используя, к примеру, реализацию стандартной Java EE технологии Enterprise JavaBeans (EJB) предоставляемую сервером приложений BEA WebLogic, вы можете перенести ваше приложение на сервер Apache Geronimo, и тем самым использовать реализацию EJB от компании Apache, которая может быть производительней или не содержать существенных ошибок. Если вы используете Spring Framework, то при миграции вы всегда используете одну реализацию от компании SpringSource, и если она содержит существенные ошибки или не удовлетворяет вас по другим критериям, вам приходится либо исправлять ошибки самому, либо искать обходные пути, либо отказаться от данного фреймворка.
Данная заметка указывает лишь на идеологический недостаток Spring Framework, т.к. на практике Spring Framework успешно используется для разработки приложений разной сложности. Также данной заметкой я не умаляю достоинства технологии EJB, которая так же успешно может быть использована.
EJB, J2EE, Java, Java EE, Spring, фреймворк
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
SpringFramework это фактически IOC фреймфорк плюс набор других полезных-разных компонент. Spring вполне чудесно может работать и вместе со EJB, и не понятно что мешает включать jar файлы в один пакет. Однако EJB, скорей противосопоставляют POJO, в силу того, что EJB слишком монстроидальный и громоздкий. Вы первый человек, кто сумел сравнить несравнимое.
Коммунизм идеологически лучше капитализма, поскольку при нем социальная защита населения выше
Alex, вы не поняли сути, и здесь фактически нету никакого сравнения, только в названии - и то для медитаций.
Основная цели заметки:
- показать что Spring не является Java EE технологией, т.к. часто его ставят именно в этот ряд.
- и почему EJB идеологически лучше - указывает на то что Spring не отвечает Java EE идеологии, где плюсы у EJB, которая часто заменяется Spring.
Это уже вторая подряд полезная и информативная статья. Так держать!
+1
А зачем публиковать это в разделе статьи? ИМХО, очень уж коротко для статьи. Может лучше в Планету?
to Макс, как написано в заголовке - это не статья, а заметка
Может просто написать Spring - это не Java EE? Самого от EJB тошнит, даже от 3 версии.
Неужели сайт ДОУ был одобрен ВАКом и автор решил заработать себе на кандидатский минимум по Computer Science?
Следующая заметка будет “почему Cobol идеологически лучше Java?” Или просто “Важность идеологии для развития програмирования”
Перенесите заметку в планету, не стоит она внимания
>>почему EJB идеологически лучше
И давно программисты и архитекторы руководствуются идеологией? =)
Андрей, а Java EE - это не конкретное понятие.
Конкретно будет Java EE приложение, или Java EE технология - о чем и говорится в заметке.
Несколько опубликованных статей Дениса всесте с реакцией читателей думаю дают более-менее четкую картину по поводу того, какого рода статьи стоит писать дальше. Спасибо за участие в бета-тестировании.
Вот только эта переносимость по большей части гипотетическая…
.Net программистам наверное в этом смысле проще - не нужно думать какой сервер и чью реализацию выбрать. При этом не думаю что они каждый день просыпаются в холодном поту от кошмара в котором рухнул Майкрософт.
це несерйозно
грамотна стаття Spring vs EJB3 була б цікава і корисна, а тут незрозуміло що… просто комент що Spring не є де юре Java EE технологією - ну так це і так відомо
мені допустимо спрінг не дуже подобається
Як на мене перед тим як застосовувати spring треба думати не менше довго, ніж перед прийняттям рішення застосувати EJB
+1
Мне не приходилось тесно работать с EJB, только как клиент, но я воспользуюсь случаем и задам вопросы по EJB и Spring.
1. Позволяет ли EJB (по спецификации) автоматически блокировать одновременное использование (change, например) отдельных entity бинов в многопользовательской среде, т.е. предотвращать ситуацию гонок?
Речь не идет об управлении блокировками на уровне базы данных - вопрос именно о функциональности специфической уровню EJB. Или же упор идет только на транзакции БД?
2. Имеет ли Spring какие-либо компоненты для управления блокировками.
Я читал немного о том как это сделана поддержка блокировок в Hibernate - в принципе, Spring ведь нередко используют в связке с Hibernate.
3. Известны ли Вам какие-либо frameworks для управления блокировками (пессимистичные/оптимистичные) сложной(!!!) структуры взаимосвязанных объектов в многопользовательской среде?
Думаю, что ответы будут интересны многим.
Кстати, ведь Spring + Hibernate можно использовать под .NET , а это уже плюс если вы работаете с несколькими языками;
Spring - .NET 1.2.0
NHibernate - .NET Framework 1.1 or 2.0
Что Вы об этом думаете? Насколько это практично?
Что Вы об этом думаете? Насколько это практично?
В .NET Spring нужет как собаке пятая нога. Там есть свой исторический IoC контейнер Windsor, как про меня - удобнее Spring. Да и Unity от Майкрософта развивается. А вот с ORM - у .NET полная жо. Майкрософт умертвил свой LINQ to SQL в угоду глюкавому Entity Framework, с которым вменяемые люди отказываются работать. Поэтому кроме NHibernate ничего не остается, еще пожалуй ActiveRecord от CastleProject.
Относительно concurency в EJB - стантарт дает большую свободу в выборе способа согласования Entity Beans. Тоесть на каком уровне - зависит от вендора аппсервера.
Например в Вэблоджике например 6.1 в целях оптимизации синхронизацию/блокировку перенесли на уровень базы по умолчанию, но можна поменять настройкой на управляемый контейнером EJB как в 5 версии .
2 Сергей Волошин, +1
Для Microsoft справедливо правило: нету Microsoft - нету и .NET.
Все помним что Стив Балмер ответил на вопрос студенки “Почему Microsoft не портирует .NET на MacOS?” на конференции в институте им. Т. Шевченко.
А если нету Oracle, то есть IBM и OpenSource.
bullshit. Не видел ни одного JavaEE-приложения без vendor-specific дескрипторов.
2http://slonopotamus.livejournal.com/, обычный сервлет, запущенный на сервере приложений считается Java EE приложением - никаких нестандартных дескрипторов.
2 http://slonopotamus.livejournal.com/
Собственно и в EJB 3.0 дескрипторы не нужны вобщем..
2 Сергей Волошин
это прикол такой что-ли? если это был эксперимент, то явно неудачный…
у меня уже давно мысли на эту тему гложут.
Эксперимент - набор действий и наблюдений, выполняемых для проверки (истинности или ложности) гипотезы.
Поделитесь плз, можно по почте.
вот-вот. действия выбраны неправильные
как созрею окончательно - поделюсь, канешн.
2COTOHA, Сергей Волошин:
Во-первых, это был никакой не эксперемент и не бетта-тестирование - это обман. Это фишка ДОУ. Если бы рейтинг был хороший, никаких бы слов бетта вы бы не увидили.
Все помним что ДОУ искали Java-авторов. Я предложил написать пару статей.
Первую статью я решил написать про очень простую технологию, про которую можно почитать и на их сайте, просто я написал проще.
На мое удивление эта статья попала в топ статей.
Потом я решил написать статьи на те темы, по которым сейчас явно выявляется невежество в java сообществе, т.к. многие думаю что Spring - это Java EE технология, а чем контейнер сервлетов от сервера приложений отличается - не знают.
Признаюсь, я не ожидал что встречу столько невменяемых ответов - никто не смог раскритиковать содержимое, но хамили, да ещё под какими-то левыми никами - на данный момент это яркая черта, которая отличает нас от развитых стран.
И это болото в котором сидит большинство украинцев. Не все, конечно. Некоторые здесь писали вполне нормальные комментарии/вопросы/критику.
Во-вторых, кто эти все люди, которые пишут невменяемые комментарии и ставят единицы. Джава программисты? Большинство - нет. А даже те кто были джава программистами, многие не поняли сути и путают, к примеру, javaee приложение с javaee технологией.
Единственное что я вижу неправильным - это то что этому сайту не подходят глубокие статьи, а больше - поверхностные, и где слов современных побольше, вроде GlassFish, JBoss и т.д.
т.е. этот сайт не только для Java программистов.
for I. Kovalchuk
EntityManager.lock(Object entity, LockModeType lockMode) - разве не для этого? По спецификации ДОЛЖЕН избавить от Dirty read и Non-repeatable read. А как это будет реализовано зависит от вендора. Большинство вендоров действительно все сводят к БД. На уровне выше БД можно использовать JBoss Cache, например, в качестве кэша второго уровня для Persistance, в качестве framework “вручную” (ответ на вопрос 3).
2Denys Bezsmertnyi:
…
Я не вижу обмана
Я вижу то что вы опубликовали несколько статей которые кардинально отличаются друг от друга, и увидели реакцию читателей, притом что эту реакцию Вам например предугадать наперед было сложно. Но если бы эта реакция была известна с самого начала, то наши действия могли бы быть иными. В моем понимании это больше эксперимент чем обман.
2Сергей Волошин, изначально это было не бета-тестирование, которое сейчас вы пытаетесь перевести в раздел вашего понимания эксперемента.
Продолжать не будем.
Для полноты картины можно заметить что реакция на статью на RSDN тоже была неоднозначной.
Для полноты картины можно почитать форум
http://www.developers.org.ua/forum/topic/104
Сергей Щетинин пишет:
“Из-за ряда сомнительных модераторских решений и низкопробных публикаций, я с сайта сваливаю. Свои серии статей собираюсь закончить, но где-нибудь еще. Всем привет!”
+1, сваливаю с сайта из-за неадекватной администрации ну и судя по 80% комментариев, мне кажется, что с их авторами лучше не пересекаться, т.е. адекватные люди, скорее всего, будут избегать этот сайт, т.к. тут слишком много негатива сливают.
Денис, вы действительно считаете, что две ваших последних статьи - качественные?
2Всеволод Соловьёв, я ничего не считаю про свои статьи.
Мне просто было неприятно общаться с теми, о ком я упомянул в предыдущем сообщении.
Предлагаю дальнейшую критику/административные вопросы продолжить здесь -
http://www.developers.org.ua/forum/topic/177 “Развитие ресурса - статьи о Java и не только”
2 Denys Bezsmertnyi
OMG!
вы что первый раз в инете? как можно обижаться на негативные отзывы?
2I. Kovalchuk, попытаюсь ответить
1) Да, это функционал, который предоставляет API javax.persistence.EntityManager. Как было уже отмечено моим коллегой, реализация зависит от вендора сервера приложений и довольно часто “перекладывает” блокировки на уровень транзакций БД. С точки зрения использования это не должно становиться проблемой (и чаще всего ею не становится)
2) Разумеется нет. Основная цель Spring это dependency injection. Этой цели подчинена основная функциональность фреймворка. Массу вещей, в том числе и работу с persistence уровнем, Spring не реализует out of the box. Фрэймворк предоставляет программистам возможность инжектировать уже работающий и сконфигурированный объект, который в свою очередь, и предоставляет интерфейс работы с persistence. Иначе говоря, для Hibernate — это инициализированная Session, для JDO — JDOManagerFactory, для JPA — EntityManagerFactory, для JDBC — JdbcTemplate. Больше всего кода от SpringGroup в JdbcTemplate. Но и там не реализуются стратегии блокировок. Все механизмы работы с данными реализуются стронними фрэймворками.
3) Разумеется. Hibernate, JPOX, Oracle TopLink, iBATIS SQL Map, Apache ObJectRelationalBridge… И конечно любой полноценный J2EE сервер приложений.
2Denys Bezsmertnyi, простите, Денис, Вам не кажется, что как-то не очень умнО ожидать, что Ваша статья непременно всем понравится? И Вы, судя по комментариям, не питаете иллюзий относительно толлерантности и терпимости украинского общества? Так чему Вы изволите удивляется? Тому, что люди, которым не понравилась Ваша статья, стали метать в Вашу сторону гуано? Полно Вам, это стандартная реакция, на цивилизованный язык это переводиться примерно так “уважаемый автор, я бы хотел поблагодарить Вас за усилия, которые Вы несомненно приложили при создании статьи. Но мне кажется, что статья вышла не достаточно информативной, тема раскрыта не достаточно полно и объем материала хотелось бы видеть бОльшим. Не могли бы Вы учесть в дальнешем мои пожаленая, как Вашего потенциального читателя и развить тему в последующих статьях? Заранее премного благодарен”. Как видите, букв довольно много и слова могут казаться некоторым молодым людям не совсем знакомыми. Так что бросьте Вы обижаться на критику и перестаньте кормить троллей, мой Вам совет.
Признателен за ответы!!! Посмотрю эти вещи.
2Denys Bezsmertnyi - Все ок! В следующий раз получиться лучьше, ведь мы только начинающие авторы!!!
2I. Kovalchuk, спасибо! Если все мы будем друг друга наставлять с уважением, мы быстрее станем уважаемой нацией.
Думаю, вся эта история со статьями - полезные уроки на заметку о том что публиковать, а что нет
Свои слова по поводу администрации забираю назад.
На мой взгляд, автор решил привлечь внимание громким заголовком, и возможно заработать на баннерах.
При этом трудиться над качественным содержимым не хотелось. Спринг не JavaEE - тоже мне новость.
2 Sergey Bondarenko, какой-то “кривой” у вас взгляд
2Sergey Bondarenko, Вы удивитесь, но для некоторых разработчиков — новость сродни открытию Америки. Подобное понимание конечно слегка удручает, но люди часто путают Spring и J2EE. По принципу, ну ведь в нем [Spring] J2EE технологии работатют, так почему нет? Так что с новостийностью у статьи более-менее, а вот относительно контента мне бы тоже хотелось увидеть обзор Spring vs J2EE. И самое смешное, что, мне кажется, автор способен и на такой обзор, а мы сейчас с упорством, достойным лучшего применения, занимаемся тем, что отбиваем у Дениса всяческую охоту писать для ДОУ.
2 Anton Naumov
100%!!!
Знаете, господа, старый баян: “- А я летать умею!” - “Да ну! Покажи!” - “Не хочу!”.
Мне в-принципе нет дела до способностей Дениса. Другие его заметки читал, есть хорошие. Здесь откровенно на троечку с минусом.
Количество комментариев - 43! У меня стойкое чувство, что автор зарабатывает показы на holy war.
2Sergey Bondarenko: 43 - не рекорд. См.
), при том что часть дискуссии по этому поводу перешла на форум.
http://www.developers.org.ua/blog/most-commented/
Потом довольно много коментариев не о Java EE, а о том что такое хорошо и что такое плохо (в том числе Ваш и теперь уже мой
Автор ничего не зарабатывает на показах (на баннерах не зарабатывает тоже, тут Ваши предположения не верны, к тому же они немного как бы странные и не по теме заметки). Лучше подождать немного заметки которая будет Вам больше по душе (если конечно охота Дениса писать еще не отбита). А еще лучше написать что-то самому (хотя бы за баннер
), чтобы все почитали и оценили. Но быть конструктивным почему-то не модно…
2Sergey Bondarenko, интересно: и где вот здесь можно было найти holy war???
Статья как минимум убогая. Вообще то в JAVA коммьюнити Spring протиставляется J2EE, и некоторые вещи на спринге решаются более елегантно чем в J2EE. И холивар тут существует давно и серьезный. Так что статья по сути о том, что 1 не равно 2. Не понимаю толерантности некоторых комментаторов. Автора я попросил бы в будущем с уважением относится к моему времени и времени читателей сайта которое было потрачено на чтение этой пустой статьи и ее комментированию.
2Sergey Bondarenko, знаете, Сергей, иногда нужно думать не только о том, кто и сколько заработает на показах, но и о человеческих способностях, о человеческом восприятии, о том, какую реакцию могут вызвать Ваши слова. Уверяю Вас, это вещи в жизни гораздо более важные, чем те теоретические копейки, которые автор заработает на банерах. Напишите свою статью, побейте рекорд в 400 комментариев, заработайте сами. А не хотите — тогда перестаньте разводить демагогию “все проплачено”, она актуальна только на территории Российской Федерации.
Ярослав, если вам есть о чем сказать, то только тогда пишите. Иначе - не тратьте своё же время болтая не понятно о чем.
2Ярослав, я прошу меня заранее простить, возможно мой комментарий покажется Вам в чем-то обидным, уверяю Вас, я не испытываю к Вам личной неприязни и не пытаюсь намеренно задеть. Моей целью, в данном случае, является желание продемострировать Вам, как Ваш комментарий воспринимается со стороны.
1) Spring не может противопоставляться J2EE. Это принципиально разные вещи используемые для разных целей. Вы явно ошиблись Java community. Можно пример вещи, которая “на спринге решаются более елегантно чем в J2EE”? Ну хотябы одной? Я осмелюсь предположить, что в данном случае Вы изволили сказать откровенную глупость, но если опровергните примером — готов принести публичные извинения.
2) Холивара тут быть не может по опредению, потому что тема Spring vs EJB не раскрыта. Холиварить не о чем.
3) А Вы кто, простите, такой, чтобы отдельно и специально с уважением относиться к Вашему времени? Вы не умеете управлять собственным временем? Не можете перестать читать статьи, которые Вам не нравятся? Так это глобально Ваши проблемы и решать их придется именно Вам.
Anton Naumov, +1000 про Ярослава
Spring поддерживает EJB, есть специальные классы AbstractStatelessSessionBean, AbstractStatefulSessionBean, AbstractMessageDrivenBean, JtaTransactionManager, JPADaoSupport
Можно начинать делать на Spring, а когда станет ясно что без EJB никак не обойтись то можно
быстро перейти на EJB.
2Сергей Григорьев, давайте все-таки разделять понятия “поддерживает” и “реализует”. В случае Spring, да использование EJB, Hibernate, JDO поддерживается. Но исключительно в виде интерфейсов и адаптеров. Для того, чтобы реализовать, к примеру, JPA с помощью Spring, Вам придется выкачать и добавить в свое приложение довольно много библиотек. Включая собственно реализацию JPA. Тоже самое отноститься и к EJB. Именно поэтому Spring и не является J2EE технологией, что разумеется не умаляет его достоинств.
Я лично считаю, что при использовании EJB Spring можно и нужно использовать для отладки приложений. Как в юнит-тестировании, так и в тестировании функциональном. Это позволит съэкономить огромное количество времени, которое тратиться на развертывание исправленного приложения. Реализовывать же EJB в том случае, когда не известно нужен будет сервер приложений или нет, я не считаю целесообразным. В этом случае лучше обойтись JPA, технология универсальна, автономна и может быть использована как внутри сервера приложений, так и без него с одинаковым успехом. Но это мое мнение, и тут возможны разные подходы.
мне статья понравилась. в Джава я ноль, посему мне интересны небольшие обзоры такого формата.
Денис, нормальная получилась заметка, зачотная!
если после потоков бессознательного в ваш адрес у вас не отобъётся желание писать - мой вам респект и уважуха, я б не смогла, неблагодарное это дело. а за уровень массы - кто сходу скажет чем java-web server отличается от EJB container, и приведет примеры первого, кроме томката?
2Тася 123, если говорить коротко, то “java-web server” понятие не существующее в природе. web server — есть машина, компьютер, который выступает в роли узла сети интеренет. говоря высоким слогом, web server есть совокупность аппаратных и программных средств, обеспечивающих функционирование узла сети интернет. если мы под “java-web server” мы понимаем tomcat, то уместно говорить про отличие servlet container от EJB container. и тут все просто, EJB container должен поддерживать реализацию JSR 220, servlet container — нет. строго говоря это и есть главное отличие. в качестве примера servlet container можно рассмотреть Jetty или Resin (да, я знаю, что они позиционируют себя как application server, это не меняет сути). остальное это экзотика типа Winstone Servlet Container и ему подобных.
2Тася 123 , спасибо большое!
Anton Naumov, получается сравнивается Web Container и EJB container, которые можно использовать вне сервера приложений.
На практике чаще всего используют первый.
Но Тася 123 права, задавая этот вопрос, потому что многие разницы не понимают.
2Denys Bezsmertnyi, действительно, существуют реализации web и ejb containers, которые дествительно можно использовать вне контекста сервера приложений. но подобные ситуации крайне редки. как правило проще и дешевле использовать полнофункциональный сервер приложений для всех операций, если нам необходимо работать с EJB. в тоже время большинство servlet container’s предоставляют свою реализацию http серверов. но справедливости ради стоит заметить, что весьма редки реализации http серверов, которые бы держали нагрузку сравнимую с промышленными http серверами, такими как Apache или IIS. в результате мы приходим к исторически образованным, платформенно зависимым связкам Apache + Tomcat или IIS + Tomcat. является ли Tomcat embedded servlet engine, как в одном из пакетов JBoss, или нет — это уже частности.
ну и разумеется промышленные платформы на базе WebSphere или WebLogic включают в себя реализацию http северов, которая может быть использована самостоятельно.
что касается практики, то тут следует разделять предметные области. если мы говорим о решения аутсорсингового и/или стартапного рынка, то следуя стратегии Fail Fast тут нет или почти нет места тяжеловесным решениям на базе EJB (я говорю прежде всего о спецификациях 2.х). если мы возьмем в качестве объекта большие промышленные legacy системы, то там практика совершенно отличная. банковский сектор, телекомовский сектор — это как правило IBM blue stack или WebLogic + Oracle. иначе говоря, Spring + Hibernate + Tomcat/Jetty быстрее, а следовательно дешевле, чем WebSphere + EJB + DB2. собственно основная проблема украинского аутсорсинга в том, что здесь почти не разрабатываются from scratch системы, расчитаные на использование в течении десятилетий, нагрузку в миллион пользователей и масштабируемость на десяток кластерных серверов. потому и создается иллюзорность того, что EJB есть чисто теоретическая спецификация, которую “никто и никогда не использует”, а это не так.