Я предполагаю, что вопрос касается среды выполнения, но все же я не понимаю, что означает более легкое приложение. Объем памяти? Время запуска? Время развертывания? Какая у вас проблема на самом деле? И, пожалуйста, определите свет.

Как бы то ни было, я считаю GlassFish 3 легкой средой выполнения, и мой опыт работы с ней очень положительный. Из спецификации продукта:

Oracle GlassFish Server 3 реализует среду выполнения OSGi, которая позволяет динамически добавлять функции к серверу Java по мере необходимости и развертывать минимально возможный стек Java для поддержки приложений. Это помогает максимально сократить занимаемую площадь за счет загрузки только модулей, необходимых для обслуживания развернутых приложений, что сокращает время запуска и снижает использование ресурсов.

Во-вторых, мне лично не нравится подход Франкенштейна, Я считаю что связь между всеми частями, которые вы получаете с реальным сервером приложений, является частью добавленной стоимости, именно поэтому я использую сервер приложений.

В-третьих, я никогда не тестировал OpenEJB, я использовал его только для тестирования и никогда не планировал использовать его в производственной среде, в основном из-за его плохой репутации. См. Этот комментарий о выступлениях Geronimo на TSS (от Хани Сулейман , не удивляйтесь, если он едкий):

Я полагаю, что утверждение, что уровень EJB «приемлемый» - это самое приятное, что вы могли бы сказать.

Насколько мне известно, код geronimo ejb основан на openEJB, который исторически был самым худшим контейнером, который вы могли найти. Чтобы найти его, вам тоже придется довольно сложно поискать, только чтобы наполниться различными степенями сожаления / гнева, когда вы достигнете этой сомнительной цели.

Неудивительно, что производительность G всегда будет ниже среднего. Подход франкенштейна к созданию программного обеспечения - отличный рецепт плохой производительности. Конечно, у вас будет много красивых диаграмм, великолепно выглядящих графиков зависимостей и слабая связь. Все это не имеет значения для пользователей, которым нужен согласованный сервер приложений, который они могут рассматривать как черный ящик.

Возможно, все изменилось, 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 в реальном мире?

Смотрите также

• GlassFish 2 против Tomcat 6
• Запуск GlassFish v3 в производство : Основное руководство по выживанию

Обратите внимание, что комментарий Хани касался 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 Web Profile с Tomcat + OpenEJB, который теперь называется Apache TomEE.

Сертифицированный и с более понятным названием, мы надеемся, что это упростит понимание и сравнение стека.

Лично я считаю, что комментарии в этой ветке являются одним из основных факторов, побуждающих к переходу на сертификацию. Спасибо всем в StackOverlfow за отзывы, которые я считаю обнадеживающими и обосновывающими. Связь с этим сообществом привела к таким позитивным изменениям в OpenEJB / TomEE.

В своих кратких тестах я обнаружил, что glassfish недостаточно легкий для моих нужд (время запуска и использование памяти). До сих пор я был доволен openejb.

Действительно интересный пост. Таково было мнение нашей (компании) перед тем, как попробовать OpenEJB 3.0 три или четыре года назад!

Теперь у нас есть хороший опыт работы с OpenEJB, и он широко используется в производстве / разработке. Он действительно легкий и простой в использовании. Благодаря OpenEJB разработчики экономят много времени (сообщения Мэтью Б. Джонса также являются хорошим откликом).

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

И, наконец, что не менее важно, выступления на самом деле великолепны!

Жан-Луи

OpenEJB как легкая и встроенная альтернатива автономным серверам приложений. Мы без особых проблем портировали наше приложение с JBoss и Weblogic (он должен был поддерживать оба) на Tomcat / OpenEJB. Тесты производительности показали прирост или не худший результат.

Самое большое ограничение OpenEJB - неполная документация. Его веб-сайт в порядке (на самом деле он довольно приличный для проекта с открытым исходным кодом), но он не может сравниться с JBoss, Glassfish и т. Д.

Еще одна вещь, о которой вам следует знать, - это то, что он использует ActiveMQ в качестве поставщика JMS, который является еще одним проектом с открытым исходным кодом. Интеграция с ActiveMQ хороша, но имеет некоторые ограничения. Например, вы не можете просто обновить ActiveMQ до последней версии.

Опять же, как всегда в открытом исходном коде, отсутствие поддержки и документации компенсируется свободным доступом к источникам и разработчикам, которые это пишут.

Я думаю, что поддерживаю Дэвида Блевинса в том смысле, что Glassfish теперь означает Oracle, и все мы знаем, какое наследие они оставили с OC4J. Я боюсь, что Glassfish может потребовать все больше и больше оборудования для одной и той же службы.

В любом случае лучший совет: настройте тест и попробуйте оба решения самостоятельно, это вопрос не более 20 часов экспертной работы.