Вы бы в настоящее время использовали JBoss или Glassfish (или другой) в качестве сервера Java EE для нового проекта? [закрыто]


136

Если вы начали новый проект Java EE сегодня, который должен завершиться примерно через год, какой сервер приложений вы бы выбрали и почему?

Часть вашего ответа должна включать ваши аргументы для вашего решения. А также ваш опыт работы с выбранным вами сервером Java EE и другими доступными на рынке серверами. Это интересно, так как мы все понимаем, что такое расследование, и думаем, что было включено в ваш ответ.

Ответы:


181

За последние 10 с лишним лет я использовал WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat и некоторые другие. Итак, если бы я рассматривал новый проект, я бы сначала задал себе несколько вопросов. Одна вещь, которую я больше не сомневаюсь, заключается в том, что я категорически отказываюсь использовать JSP, если меня не будут пытать, пока я не заплачу за свою маму.

Должен ли я быть совместимым / развертываться с определенным продуктом из-за чьего-либо мандата? Нет ли способа игнорировать их или убедить их в обратном? Если так, то есть твой ответ.

Должен ли я использовать EJB? В самом деле? Избегайте их, если это вообще возможно - они действительно нужны только для очень больших систем корпоративного класса. Помните, что они всего лишь инструменты, и при этом большие (кто-нибудь может сказать «Золотая кувалда»?). Они сильно перегружены, так что действительно, действительно вопрос, нужны ли они вам. Если они вам нужны, тогда это удалит несколько ваших вариантов, включая мой любимый Jetty.

Вам нужно использовать какие-либо другие основные технологии J2EE, такие как JMS, ESB и т. Д.? Если это так, и вы действительно не можете обойтись без этого, то вы снова ограничены полноценным контейнером J2EE. Тщательно продумайте и исследуйте, прежде чем приступить к BPM, например, и избегайте AquaLogic BPM при (почти) любых затратах - это безобразно до крайности.

Если вам действительно необходимо использовать полноценный J2EE-контейнер, сначала рассмотрите возможность использования открытого исходного кода, поскольку он более надежен, лучше поддерживается и более рентабелен. У них большая клиентская база и более открытое взаимодействие со службой поддержки, поэтому они стремятся быстрее находить лучшие исправления. Тем не менее, Resin является незрелым, и я бы избегал его по сравнению с GlassFish или JBoss - я нашел его проблематичным для развертывания и поддержки. Я бы предпочел JBoss из-за его более широкой клиентской базы, зрелости и т. Д. GlassFish сложнее включить в автоматизированный процесс сборки / развертывания, но он может быть лучше для некоторых его специфических функций (если они вам нужны).

У меня есть особая причина, чтобы нуждаться в Apache? Затем наклонитесь к Tomcat, возможно, плюс что-то.

Могу ли я обойтись только с сервлетами? Тогда я бы использовал Jetty - это самое легкое, быстрое, простое и гибкое решение. Если бы я опирался на возможность пользоваться Jetty, я бы поставил под сомнение все свои предположения о том, почему. ЯГНИ применяется.

Лучше всего использовать StringTemplate / WebStringTemplate на Jetty: чистое, надежное, быстрое и удобное в обслуживании решение без лицензионных сборов, солидной репутации и поддержки и т. Д. Именно здесь я начинаю в настоящее время.

Большинство приложений / систем выбирают множество необычных функций J2EE, когда все, что им действительно нужно, это сервлеты и JDBC с некоторой приличной архитектурой / дизайном. Вопрос, почему вы думаете, что вам нужно больше.

Из полноценных контейнеров я бы избегал WebLogic и WebSphere, если вы не поддерживаете общедоступный веб-сайт MAJOR (веб-сайт моего нынешнего работодателя развернут на WebLogic, и его посещает одиннадцать + миллионов обращений в месяц, другие были сопоставимы). Реальная претензия WebLogic на славу - это их относительно простая кластеризация, но избегайте их фирменных функций привязки к поставщикам практически (почти) любой ценой. WebSphere - это просто кошмар, которого я бы избежал буквально любой ценой - я отказываюсь делать проекты с участием WebSphere после того, как сделал пару в прошлом. Ни один из этих продуктов не стоит огромных лицензионных сборов, если только у вас действительно нет особой потребности, которая стимулирует использование проприетарной функции. За десять лет работы старшим архитектором / инженером во многих компаниях из списка Fortune 500 я еще не видел такой необходимости. С другой стороны,

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

РЕДАКТИРОВАТЬ: еще один кусок, чтобы рассмотреть ...

Я недавно столкнулся с терракотой . Я переосмысливаю все и надеюсь развернуть его в значительной системе в ближайшее время. В частности, Terracotta делает кластеризацию лучше, чем что-либо еще, поэтому я бы НИКОГДА не рекомендовал WebLogic для ее кластеризации.


7
Для дальнейшего использования обычно вы можете найти определения аббревиатур с помощью поиска в Google или Википедии. YAGNI = Вам это не понадобится = не переусердствуйте со своим дизайном JMS = Служба сообщений Java ESB = Шина Enterprise Service BPM = Управление бизнес-процессами
Роб Уильямс

21
Ваши комментарии о Java EE и EJB немного устарели. J2EE ?! Это было как 5 лет назад. Взгляните на Java EE 6 и модернизируйте свою точку зрения!
Брайан Литем

6
@Brian: я согласен с Brian, особенно с EJBLite, он стал намного легче.
Тханг Фам

7
@ Брайан, посмотри на пост - он был написан за три года до твоего комментария. И я все еще сказал бы, что Spring легче, чем даже уменьшенная Java EE.
duffymo

2
Какой приговор сейчас в 2012 году? Сможет ли JBoss 7 AS стать королем Glassfish в мире Java 6 EE? Или наоборот?
Роландо

10

Термин «сервер приложений» неоднозначен. С GlassFish v3 вы можете начать с малого, скажем, с традиционного веб-контейнера, и развиваться (используя OSGi и простую функциональность «добавить контейнер»), чтобы добавлять все, что вам нужно: JPA, JAX-RS, EJB, JTA, JMS, ESB и т. д. И все же это тот же продукт, тот же интерфейс администратора и т. д. Является ли это для вас сервером приложений? -Алексис (Солнце)


1
К сожалению, Glassfish больше не является официальным продуктом, а «всего лишь» эталонной реализацией.
Турбьерн Равн Андерсен

9

Первый вопрос, который я обычно задаю себе: «Могу ли я сделать это с Tomcat?». Если ответ отрицательный, потому что мне нужен JMS или JTA, я прибегаю к серверу приложений.

Я использовал WebLogic 8 около 3 лет назад, довольный простотой использования WebLogic и моделью лицензирования / стоимости. Мы использовали его для двух проектов: один был веб-сервисом, а другой - порталом. Ни в одном из этих проектов у нас не было проблем с WebLogic или WebLogic Portal.

Последние два года я работал с WebSphere. Каждый раз, когда я вел переговоры с IBM, это всегда заканчивалось в два раза дороже, чем эквивалент WebLogic, но корпоративная политика диктовала необходимость использования WebSphere. Я обнаружил, что кривая обучения в WebSphere значительно круче, чем в WebLogic, и наш жизненный цикл сборки / развертывания / тестирования был настолько трудоемким, что мы использовали Tomcat в среде разработки. Но самая большая проблема, с которой я столкнулся в WebSphere, заключалась в том, что мы столкнулись с ошибкой, которая вынуждала нас перейти на следующий выпуск патча только для того, чтобы столкнуться с новой проблемой разбора web.xml. Потребовалось 48 часов, чтобы проработать все это.

На данный момент я использую JBoss. Около 3 месяцев назад я собирался начать свой новый проект с Tomcat и Jetspeed 2, но я заметил, что Jetspeed 2 кажется немного застойным, и JBoss Portal 2.7.0 был только что выпущен с поддержкой JSR 286 / Portlet 2.0. Я попробовал JBoss и нашел, что его очень легко настроить и администрировать. Цикл сборки / развертывания / тестирования очень быстрый, и мне редко приходится перезагружать сервер, если я где-то не изменил XML-файл Spring.


Хороший ответ! Вы пробовали Jetty? И что вы думаете об этом на случай, если у вас есть?

7

Я использую jBoss в течение 3-4 лет.

Аргументы для jBoss:

  1. Открытый источник.
  2. Коммерческая поддержка доступна.
  3. Большое, активное пользовательское сообщество.

Аргументы против jBoss:

  1. Нет общего доступа, поддерживается выпуск контейнера Java EE 5.
  2. Много документации, но многословно; может быть трудно найти ответы на "Как я делаю х?"
  3. Административные инструменты для бедных 4.x по сравнению с другими коммерческими предложениями.

Msgstr "Нет общего доступа, поддерживается выпуск контейнера JEE 5." Я думаю, что это уже не так, правильно?
Raedwald

@Raedwald: да, теперь, когда JEE 6 существует уже некоторое время ;-)
ymajoros

4

Оформить заказ GlassFish 3.1! Версия 3.1, построенная на модульном ядре GlassFish v3 на основе Java EE 6, обеспечивает кластеризацию, централизованное администрирование и высокую доступность.

Обратитесь к http://blogs.oracle.com/nazrul/entry/glassfish_3_1 для получения дополнительной информации.


3

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

  • Tomcat, кажется, медленнее, чем Glassfish
  • Glassfish, кажется, медленнее, чем смола
  • Смола намного медленнее, чем G-WAN + Java

Обратите внимание, что G-WAN опирается только на JVM: он не использует никаких других контейнеров (если не указано явно), поэтому вы можете зарезервировать его для критически важных частей ваших веб-приложений.

Поскольку G-WAN поддерживает другие языки (C, C ++, C #, D, Objective-C), вы можете даже обрабатывать некоторые части приложений в необработанном C, сохраняя Java для других задач.


2

Я мог бы включить предпочитаемую ОС в качестве критерия принятия решения. Это должно облегчить поддержку, если вы используете одного и того же поставщика для ОС и сервера приложений. Если у вас уже есть отношения с одним или обоими поставщиками, подумайте, хорошо ли с ними иметь дело.

С технической точки зрения я бы выбрал GlassFish, потому что он поддерживает более поздние инновации. Я не думаю, что JBoss плох в любом случае, это просто не так актуально.

Большая часть моего опыта связана с WebLogic, но я использовал JBoss и GlassFish. Я только что выпустил новый сайт для полного стека Sun с открытым исходным кодом (OpenSolaris, GlassFish, MySQL), и это был отличный опыт, с небольшими разочарованиями.


ОС на самом деле не проблема, если у вас нет очень специфических бинарных зависимостей (что не должно быть в большинстве проектов Java). Мы разрабатываем для Windows, 32 и 64 бит, и развертываем на Glassfish на Solaris. Большинство разработчиков на самом деле не знают и не должны заботиться. Пользователи этого не видят (большинство наших разработок - веб-приложения).
ymajoros

2

Я до сих пор считаю, что WebLogic - лучший сервер приложений Java EE на рынке. Я думаю, что это того стоит, если вы можете позволить себе эти лицензионные сборы.

Я был удивлен, увидев, как далеко вы можете пойти, объединив Tomcat, OpenEJB и ActiveMQ. Мне кажется, это недорогая альтернатива.

Я бы также посмотрел на Spring dm Server. Он основан на Tomcat, но я думаю, что часть OSGi, в которую они добавили, может быть повсюду в любом месте. Если это сделано с тем же качеством, что и среда Spring, это будет очень хорошо.


2
Проблема, с которой я столкнулся в WebLogic, заключается в блокировке поставщика, это неприятная таблетка, которую нужно глотать, когда вам действительно не нужно!
Маниус

1
Это относится ко всем известным мне поставщикам Java EE, а не только к WebLogic. Если вы используете какие-либо специфичные для поставщика функции, в которых вы заблокированы. Нужно написать код когда-нибудь.
duffymo

3
WebLogic предназначен только для коммерческого использования - вот к чему я стремлюсь - как только вы напишете большой чек, вы будете «заблокированы» в большей степени, чем альтернатива с открытым исходным кодом. Очевидно, что если вам небезразлична независимость от платформы, вы не будете использовать специфичные для поставщика функции, поэтому я не об этом. На самом деле опрос, который я прочитал, сказал, что разработчики считают, что предотвращение вендоров - это преимущество № 1 в открытом коде (а не в затратах).
Маниус

Полная чушь? Считаете ли вы, что подписание многомиллионного контракта с поставщиком не блокирует вас? Вот твои доказательства.
duffymo

@ymajoros Вы имели в виду «не должно» иметь привязку к поставщику? Честно говоря, я не могу понять ваш комментарий.
Патрик М

1

Альтернатива: вообще не использовать appserver.

Проверять, выписываться http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

Для веб-проектов используйте легкий веб-контейнер, если это необходимо, в сочетании с чем-то вроде Wicket, чтобы избежать сложности JSP / JSF или распорок.

HTH Парень


Если вы не хотите учиться с помощью инструментов, не используйте их. Или попытайтесь стать квалифицированным профессионалом и инвестировать в свое окружение, вы будете вознаграждены. Должен признать, что я сделал это для некоторых проектов. В тех же проектах не было ни одного сервера приложений, ни собственного клиент-сервера в Spring, ни чистого Java EE и Glassfish. Не хотелось бы возвращаться назад, первое решение было на самом деле слишком сложным, оно настолько простое, насколько это возможно сегодня (и стандартно, будет развернуто на любом сервере приложений Java EE без особых изменений).
ymajoros

хороший ответ, плохой способ получить документ
msangel
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.