Заметка «Spring не является Java EE технологией и почему EJB идеологически лучше»

Комитет 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, которая так же успешно может быть использована.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



38 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Якщо комусь цікаво. Скоро вийде Spring Framework 3.0. Недавно появився третій майлстоун — http://www.rozrobka.com/blog/java/14.html

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 есть чисто теоретическая спецификация, которую «никто и никогда не использует», а это не так.

2Тася 123 , спасибо большое! Anton Naumov, получается сравнивается Web Container и EJB container, которые можно использовать вне сервера приложений.На практике чаще всего используют первый.Но Тася 123 права, задавая этот вопрос, потому что многие разницы не понимают.

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 и ему подобных.

Денис, нормальная получилась заметка, зачотная! если после потоков бессознательного в ваш адрес у вас не отобъётся желание писать — мой вам респект и уважуха, я б не смогла, неблагодарное это дело., а за уровень массы — кто сходу скажет чем java-web server отличается от EJB container, и приведет примеры первого, кроме томката?

мне статья понравилась. в Джава я ноль, посему мне интересны небольшие обзоры такого формата.

2Сергей Григорьев, давайте все-таки разделять понятия «поддерживает» и «реализует». В случае Spring, да использование EJB, Hibernate, JDO поддерживается. Но исключительно в виде интерфейсов и адаптеров. Для того, чтобы реализовать, к примеру, JPA с помощью Spring, Вам придется выкачать и добавить в свое приложение довольно много библиотек. Включая собственно реализацию JPA. Тоже самое отноститься и к EJB. Именно поэтому Spring и не является J2EE технологией, что разумеется не умаляет его достоинств.Я лично считаю, что при использовании EJB Spring можно и нужно использовать для отладки приложений. Как в юнит-тестировании, так и в тестировании функциональном. Это позволит съэкономить огромное количество времени, которое тратиться на развертывание исправленного приложения. Реализовывать же EJB в том случае, когда не известно нужен будет сервер приложений или нет, я не считаю целесообразным. В этом случае лучше обойтись JPA, технология универсальна, автономна и может быть использована как внутри сервера приложений, так и без него с одинаковым успехом. Но это мое мнение, и тут возможны разные подходы.

Spring поддерживает EJB, есть специальные классы AbstractStatelessSessionBean, AbstractStatefulSessionBean, AbstractMessageDrivenBean, JtaTransactionManager, JPADaoSupportМожно начинать делать на Spring, а когда станет ясно что без EJB никак не обойтись то можнобыстро перейти на EJB.

2Ярослав, я прошу меня заранее простить, возможно мой комментарий покажется Вам в чем-то обидным, уверяю Вас, я не испытываю к Вам личной неприязни и не пытаюсь намеренно задеть. Моей целью, в данном случае, является желание продемострировать Вам, как Ваш комментарий воспринимается со стороны.1) Spring не может противопоставляться J2EE. Это принципиально разные вещи используемые для разных целей. Вы явно ошиблись Java community. Можно пример вещи, которая «на спринге решаются более елегантно чем в J2EE»? Ну хотябы одной? Я осмелюсь предположить, что в данном случае Вы изволили сказать откровенную глупость, но если опровергните примером — готов принести публичные извинения.2) Холивара тут быть не может по опредению, потому что тема Spring vs EJB не раскрыта. Холиварить не о чем.3) А Вы кто, простите, такой, чтобы отдельно и специально с уважением относиться к Вашему времени? Вы не умеете управлять собственным временем? Не можете перестать читать статьи, которые Вам не нравятся? Так это глобально Ваши проблемы и решать их придется именно Вам.

2Sergey Bondarenko, знаете, Сергей, иногда нужно думать не только о том, кто и сколько заработает на показах, но и о человеческих способностях, о человеческом восприятии, о том, какую реакцию могут вызвать Ваши слова. Уверяю Вас, это вещи в жизни гораздо более важные, чем те теоретические копейки, которые автор заработает на банерах. Напишите свою статью, побейте рекорд в 400 комментариев, заработайте сами. А не хотите — тогда перестаньте разводить демагогию «все проплачено», она актуальна только на территории Российской Федерации.

Статья как минимум убогая. Вообще то в JAVA коммьюнити Spring протиставляется J2EE, и некоторые вещи на спринге решаются более елегантно чем в J2EE. И холивар тут существует давно и серьезный. Так что статья по сути о том, что 1 не равно 2. Не понимаю толерантности некоторых комментаторов. Автора я попросил бы в будущем с уважением относится к моему времени и времени читателей сайта которое было потрачено на чтение этой пустой статьи и ее комментированию.

2Sergey Bondarenko: 43 — не рекорд. См.http://www.developers.org.ua/blog/most-commented/Потом довольно много коментариев не о Java EE, а о том что такое хорошо и что такое плохо (в том числе Ваш и теперь уже мой:)), при том что часть дискуссии по этому поводу перешла на форум.

У меня стойкое чувство, что автор зарабатывает показы на holy war.

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

Знаете, господа, старый баян: «- А я летать умею! » — «Да ну! Покажи! » — «Не хочу! ».Мне в-принципе нет дела до способностей Дениса. Другие его заметки читал, есть хорошие. Здесь откровенно на троечку с минусом.Количество комментариев — 43! У меня стойкое чувство, что автор зарабатывает показы на holy war.

2 Anton Naumov

И самое смешное, что, мне кажется, автор способен и на такой обзор, а мы сейчас с упорством, достойным лучшего применения, занимаемся тем, что отбиваем у Дениса всяческую охоту писать для ДОУ.

100%!!!

2Sergey Bondarenko, Вы удивитесь, но для некоторых разработчиков — новость сродни открытию Америки. Подобное понимание конечно слегка удручает, но люди часто путают Spring и J2EE. По принципу, ну ведь в нем [Spring] J2EE технологии работатют, так почему нет? Так что с новостийностью у статьи более-менее, а вот относительно контента мне бы тоже хотелось увидеть обзор Spring vs J2EE. И самое смешное, что, мне кажется, автор способен и на такой обзор, а мы сейчас с упорством, достойным лучшего применения, занимаемся тем, что отбиваем у Дениса всяческую охоту писать для ДОУ.

На мой взгляд, автор решил привлечь внимание громким заголовком, и возможно заработать на баннерах.При этом трудиться над качественным содержимым не хотелось. Спринг не JavaEE — тоже мне новость.

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, простите, Денис, Вам не кажется, что как-то не очень умнО ожидать, что Ваша статья непременно всем понравится? И Вы, судя по комментариям, не питаете иллюзий относительно толлерантности и терпимости украинского общества? Так чему Вы изволите удивляется? Тому, что люди, которым не понравилась Ваша статья, стали метать в Вашу сторону гуано? Полно Вам, это стандартная реакция, на цивилизованный язык это переводиться примерно так «уважаемый автор, я бы хотел поблагодарить Вас за усилия, которые Вы несомненно приложили при создании статьи. Но мне кажется, что статья вышла не достаточно информативной, тема раскрыта не достаточно полно и объем материала хотелось бы видеть бОльшим. Не могли бы Вы учесть в дальнешем мои пожаленая, как Вашего потенциального читателя и развить тему в последующих статьях? Заранее премного благодарен». Как видите, букв довольно много и слова могут казаться некоторым молодым людям не совсем знакомыми. Так что бросьте Вы обижаться на критику и перестаньте кормить троллей, мой Вам совет.

2 Denys BezsmertnyiOMG! вы что первый раз в инете? как можно обижаться на негативные отзывы?

Денис, вы действительно считаете, что две ваших последних статьи — качественные?

2Denys Bezsmertnyi:

Во-первых, это был никакой не эксперемент и не бетта-тестирование — это обман.

...

Первую статью я решил написать про очень простую технологию, про которую можно почитать и на их сайте, просто я написал проще.На мое удивление эта статья попала в топ статей.Потом я решил написать статьи на те темы, по которым сейчас явно выявляется невежество в java сообществе, т.к. многие думаю что Spring — это Java EE технология, а чем контейнер сервлетов от сервера приложений отличается — не знают.Признаюсь, я не ожидал что встречу столько невменяемых ответов — никто не смог раскритиковать содержимое, но хамили, да ещё под какими-то левыми никами — на данный момент это яркая черта, которая отличает нас от развитых стран.

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

for I. Kovalchuk

1. Позволяет ли EJB (по спецификации) автоматически блокировать одновременное использование (change, например) отдельных entity бинов в многопользовательской среде, т.е. предотвращать ситуацию гонок? Речь не идет об управлении блокировками на уровне базы данных — вопрос именно о функциональности специфической уровню EJB. Или же упор идет только на транзакции БД?

EntityManager.lock (Object entity, LockModeType lockMode) — разве не для этого? По спецификации ДОЛЖЕН избавить от Dirty read и Non-repeatable read. А как это будет реализовано зависит от вендора. Большинство вендоров действительно все сводят к БД. На уровне выше БД можно использовать JBoss Cache, например, в качестве кэша второго уровня для Persistance, в качестве framework «вручную» (ответ на вопрос 3).

Эксперимент — набор действий и наблюдений, выполняемых для проверки (истинности или ложности) гипотезы.

вот-вот. действия выбраны неправильные:) как созрею окончательно — поделюсь, канешн.

это прикол такой что-ли? если это был эксперимент, то явно неудачный...

Эксперимент — набор действий и наблюдений, выполняемых для проверки (истинности или ложности) гипотезы.

у меня уже давно мысли на эту тему гложут.

Поделитесь плз, можно по почте.

2 Сергей Волошин

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

это прикол такой что-ли? если это был эксперимент, то явно неудачный... у меня уже давно мысли на эту тему гложут.

bullshit. Не видел ни одного JavaEE-приложения без vendor-specific дескрипторов.

Что Вы об этом думаете? Насколько это практично? В.NET Spring нужет как собаке пятая нога. Там есть свой исторический IoC контейнер Windsor, как про меня — удобнее Spring. Да и Unity от Майкрософта развивается. А вот с ORM — у.NET полная жо. Майкрософт умертвил свой LINQ to SQL в угоду глюкавому Entity Framework, с которым вменяемые люди отказываются работать. Поэтому кроме NHibernate ничего не остается, еще пожалуй ActiveRecord от CastleProject.Относительно concurency в EJB — стантарт дает большую свободу в выборе способа согласования Entity Beans. Тоесть на каком уровне — зависит от вендора аппсервера.Например в Вэблоджике например 6.1 в целях оптимизации синхронизацию/блокировку перенесли на уровень базы по умолчанию, но можна поменять настройкой на управляемый контейнером EJB как в 5 версии.

.Net программистам наверное в этом смысле проще — не нужно думать какой сервер и чью реализацию выбрать. При этом не думаю что они каждый день просыпаются в холодном поту от кошмара в котором рухнул Майкрософт.

Вот только эта переносимость по большей части гипотетическая...

Неужели сайт ДОУ был одобрен ВАКом и автор решил заработать себе на кандидатский минимум по Computer Science? Следующая заметка будет «почему Cobol идеологически лучше Java? » Или просто "Важность идеологии для развития програмирования"Перенесите заметку в планету, не стоит она внимания: (

А зачем публиковать это в разделе статьи? ИМХО, очень уж коротко для статьи. Может лучше в Планету?

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

>> почему EJB идеологически лучшеИ давно программисты и архитекторы руководствуются идеологией? =)

Неужели сайт ДОУ был одобрен ВАКом и автор решил заработать себе на кандидатский минимум по Computer Science? Следующая заметка будет «почему Cobol идеологически лучше Java? » Или просто "Важность идеологии для развития програмирования"Перенесите заметку в планету, не стоит она внимания: (

Может просто написать Spring — это не Java EE? Самого от EJB тошнит, даже от 3 версии.

А зачем публиковать это в разделе статьи? ИМХО, очень уж коротко для статьи. Может лучше в Планету?

Коммунизм идеологически лучше капитализма, поскольку при нем социальная защита населения выше

+1

Это уже вторая подряд полезная и информативная статья. Так держать!

Коммунизм идеологически лучше капитализма, поскольку при нем социальная защита населения выше

SpringFramework это фактически IOC фреймфорк плюс набор других полезных-разных компонент. Spring вполне чудесно может работать и вместе со EJB, и не понятно что мешает включать jar файлы в один пакет. Однако EJB, скорей противосопоставляют POJO, в силу того, что EJB слишком монстроидальный и громоздкий. Вы первый человек, кто сумел сравнить несравнимое.

Підписатись на коментарі