Сравнение OpenEjb и Glassfish
мы можем заменить Glassfish Tomcat/OpenEJB для более легких приложений? Какова работа OpenEJB по сравнению с glassfish как контейнер EJB.
Каковы ограничения OpenEJB вместо glassfish?
С уважением
5 ответов
Думаю, вопрос в среде выполнения, но все же я не понимаю, что означает более легкое приложение . Объем памяти? Время запуска? Время развертывания? Какая у вас проблема на самом деле? И, пожалуйста, определите свет.
Как бы то ни было, я считаю GlassFish 3 легкой средой выполнения, и мой опыт работы с ней очень положительный. Из спецификации продукта :
Oracle GlassFish Server 3 реализует среду выполнения OSGi, которая позволяет динамически добавлять функции к серверу Java по мере необходимости и развертывать минимально возможный стек Java для поддержки Приложения. Это помогает максимально сократить занимаемую площадь за счет загрузки только модулей, необходимых для обслуживания развернутых приложений, что сокращает время запуска и снижает использование ресурсов.
Во-вторых, мне лично не нравится подход Франкенштейна, Я считаю, что связь между всеми частями, которые вы получаете с реальным сервером приложений, является частью добавленной стоимости , именно поэтому я использую сервер приложений.
В-третьих, я никогда не тестировал OpenEJB, я использовал его только для тестирования и никогда не планировал использовать его в производственной среде, в основном из-за его плохой репутации. См. Этот комментарий о выступлениях Джеронимо на TSS (от Хани Сулеймана, не удивляйтесь, если он едкий):
Я полагаю, что высказывание, что EJB уровень «приемлемый» - это примерно самое приятное, что вы могли сказать.
Насколько мне известно, код ejb geronimo основан на openEJB, который, исторически, фасоль - худший контейнер вы могли бы найти. Тебе бы пришлось поискать его тоже довольно сложно, только быть наполненным различной степенью сожаление / ярость, когда вы достигнете этого сомнительная цель.
Неудивительно, что Джи производительность всегда будет ниже номинальной. Подход франкенштейна к программному обеспечению строительство - отличный рецепт плохого представление. Конечно, у вас будет много красивые диаграммы, великолепно выглядящие графы зависимостей и слабая связь. Все это не имеет отношения к пользователи, которым нужен согласованный сервер приложений что они могут рассматривать как черный ящик.
Все могло измениться, OpenEJB, вероятно, улучшился, по крайней мере, немного, но все же:
- OpenEJB не полностью поддерживает EJB 3.1.
- Tomcat + OpenEJB все еще не является полной реализацией Java EE, возможно, вам все равно придется добавить некоторые части в свое существо (не говоря уже о Java EE 6).
- А как насчет администрирования, кластеризации и т. Д.?
- Если вам не нужен полный профиль Java EE 6, есть веб-профиль Java EE 6
- Я доволен GlassFish 3, я не Не считаю это "тяжелым" (и предлагаю попробовать).
- Я знаю, что он может хорошо работать.
По всем этим причинам я бы не стал рассматривать Tomcat + OpenEJB вместо GlassFish, особенно если нет проблем, которые нужно решить.
Связанные вопросы
- Какие технологии поддерживает Tomcat
- Что такое Enterprise Java Bean на самом деле?
- Сравнение Glassfish и JBoss 5 в реальном мире?
См. Также
Обратите внимание, что комментарий Хани относился к Geronimo 1.0 / OpenEJB 2.0. Хани ошибся в комментарии франкенштейна, поскольку кодовая база OpenEJB 2.x была создана полностью с нуля для Geronimo, и в результате она работала только в Geronimo; были потеряны встроенный, Tomcat и автономный режимы. Мы обнаружили, что комментарий Хани был правильным в том смысле, что выступление было не лучшим.
Для OpenEJB 3.x мы отказались от кодовой базы 2.x и продолжили работу с того места, где остановились в OpenEJB 1.x, и довели его до сертификации EJB 3.0. 2.x и 3.x не имеют общего кода. OpenEJB 3.x оказался очень удачным, и проект довольно быстро рос с момента выпуска первой версии 3.0 в 2008 году. Встроенный контейнер EJB 3.1 и EJB в функциях .wars пришли из OpenEJB. У нас была первая реализация @Singleton, и мы надеемся завершить оставшуюся часть EJB 3.1 и сертифицировать веб-профиль к четвертому кварталу этого года. Отказоустойчивость и мониторинг JMX интенсивно разрабатываются с января, теперь они завершены и будут выпущены в версии 3.1.3 через пару недель. На самом деле аварийное переключение относится ко второму поколению, первая поддержка аварийного переключения была выпущена в версии 3.1.1. В выпуске 3.1.1 была проделана значительная работа по удаленной производительности, а в нашем тестировании средняя скорость вызовов RPC составила 7300 TPS.
Менее важно для некоторых, но очень важно для других, Apache OpenEJB не является корпоративным проектом с открытым исходным кодом. Большинство коммиттеров - это пользователи, которые заработали коммит и используют OpenEJB на работе.Это имеет свои преимущества и недостатки, но суть в том, что OpenEJB наполнен людьми, которые любят его и используют его, и сообщество открыто, как и исходный код.
ОБНОВЛЕНИЕ
В октябре 2011 года мы получили сертификат веб-профиля Java EE 6 с «Tomcat + OpenEJB», который теперь называется Apache TomEE.
Сертифицированный и с более понятным названием, мы надеемся, что это упростит понимание и сравнение стека.
От себя лично, я рассматриваю комментарии в этой ветке как один из основных мотиваторов для шага сертификации. Спасибо всем в StackOverlfow за отзывы, которые я считаю обнадеживающими и обосновывающими. Связь с этим сообществом привела к таким позитивным изменениям в OpenEJB / TomEE.
В моих кратких тестах я обнаружил, что стеклянная рыбка недостаточно легка для моих нужд (время запуска и использование памяти). До сих пор я был доволен openejb.
Я думаю, что поддерживаю Дэвида Блевинса в том смысле, что Glassfish теперь означает Oracle, и мы все знаем, какое наследие они оставили с OC4J. Я боюсь, что Glassfish может потребовать все больше и больше оборудования для одной и той же службы.
В любом случае лучший совет: настройте тест и попробуйте оба решения самостоятельно, это вопрос не более 20 часов экспертной работы.
Действительно интересный пост. Таково было мнение нашей (компании) перед тем, как попробовать OpenEJB 3.0 три или четыре года назад!
Теперь у нас есть хороший опыт работы с OpenEJB, и он широко используется в производстве / разработке. Он действительно легкий и простой в использовании. Благодаря OpenEJB разработчики экономят много времени (сообщения Мэтью Б. Джонса также являются хорошим откликом).
Сообщество активно, открыто и всегда готово помочь и улучшить продукт с помощью полезных функций, полученных на основе реальных отзывов пользователей.
И, наконец, что не менее важно, выступления на самом деле просто великолепны!
Жан-Луи