Сравнение OpenEjb и Glassfish

можем ли мы заменить Glassfish на Tomcat / OpenEJB для более легких приложений? Какова производительность OpenEJB по сравнению с glassfish в качестве контейнера EJB.

каковы ограничения OpenEJB вместо glassfish?

в отношении

9
containers ejb glassfish java-ee openejb

6 ответов

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

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

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

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

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

Я бы предположил, что говоря, что EJB tier is 'acceptable' - это о самое приятное, что ты можешь сказать.

из того, что я знаю, код EJB Джеронимо основан на openEJB, который имеет, исторически сложилось, что bean худший контейнер вы, возможно, найдете. Тебе придется его тоже трудно найти, только ... быть заполненным с различными степенями сожаление / ярость, как только вы достигнете этого сомнительная цель.

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

все могло измениться, OpenEJB, вероятно, улучшился, по крайней мере, немного, но все же:

  • OpenEJB не полностью поддерживает EJB 3.1.
  • Tomcat + OpenEJB по-прежнему не является полной реализацией Java EE, вы возможно, Вам все равно придется добавить некоторые части к вашему существу (даже не упоминая Java EE 6).
  • а как насчет администрирования, кластеризации и т. д.?
  • Если вам не нужен полный профиль Java EE 6, есть веб-профиль Java EE 6
  • я доволен GlassFish 3, я не нахожу его "тяжелым" (и я предлагаю попробовать).
  • я знаю, что он может выполнять хорошо.

по всем этим причинам я бы не рассматривал Tomcat+OpenEJB вместо GlassFish, особенно если нет никакой проблемы для решения.

вопросы

см. также

5

обратите внимание, что комментарий Хани был в отношении Geronimo 1.0 / OpenEJB 2.0. Хани ошибся в комментарии Франкенштейна как OpenEJB 2.X codebase была построена полностью с нуля для Geronimo, и в результате она работала только в Geronimo; встроенные, tomcat и автономные режимы были потеряны. Мы обнаружили, что комментарий Хани был прав в том, что выступление было не очень хорошим.

Для OpenEJB 3.x мы отказались от 2.x codebase и подобрал вещи с того места, где мы остановились в OpenEJB 1.x и довел его до сертификации EJB 3.0. 2.x и 3.х нет кода. В большинстве случаев 3.x получился очень хорошо, и проект довольно быстро растет с момента первого выпуска 3.0 в 2008 году. Встроенный контейнер EJB 3.1 и EJBs .особенности wars пришли из OpenEJB. У нас была первая реализация @Singleton и мы надеемся завершить остальную часть EJB 3.1 и сертифицировать веб-профиль к Q4 в этом году. Отказоустойчивость и мониторинг JMX находятся под интенсивным развитием с января, теперь завершены и будут выпущенный в 3.1.3 через пару недель. Отработка отказа фактически является вторым поколением, первая поддержка отработки отказа была выпущена в 3.1.1. В выпуске 3.1.1 была проделана значительная Удаленная работа по производительности, а также доведение вызовов RPC до среднего значения 7300 TPS в нашем бенчмаркинге.

менее важно для некоторых, но очень важно для других, Apache OpenEJB не является корпоративно контролируемым проектом с открытым исходным кодом. Большинство коммиттеров-это пользователи, которые заработали commit и используют OpenEJB на работа. У этого есть свои преимущества и недостатки, но суть в том, что OpenEJB заполнен людьми, которые его любят и используют, и сообщество так же открыто, как и источник.

обновление

в октябре 2011 года мы получили сертификацию веб-профиля Java EE 6 с "Tomcat + OpenEJB", теперь называемую Apache TomEE.

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

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

9

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

4

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

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

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

и последнее, но не менее, выступления на самом деле большие!

Жан-Луи

4

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

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

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

еще раз, как всегда в open source отсутствие поддержки и документации компенсируется свободным доступом к источникам и разработчикам, которые ее пишут.

3

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

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

2