Если вы сегодня запустили новый проект Java EE, который должен быть завершен примерно через год, какой сервер приложений вы бы выбрали и почему?
Часть вашего ответа должна содержать ваши аргументы для вашего решения. А также, сколько опыта у вас есть с выбранным сервером Java EE и с другими доступными серверами на рынке. Это интересно, поскольку все мы понимаем исследование и думаем, что было поставлено на ваш ответ.
Я использовал WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat и несколько других за последние 10+ лет. Итак, если бы я рассматривал новый проект, сначала задал себе несколько вопросов. Одна вещь, о которой я больше не стану сомневаться, это то, что я бы отказался использовать JSP, если бы меня не пытали, пока я не заплакал за свою маму.
Должен ли я быть совместимым/разворачиваться на конкретный продукт из-за мандата? Нет ли способа игнорировать их или убеждать в противном случае? Если да, ответьте.
Нужно ли использовать EJB? В самом деле? Избегайте их, если это вообще возможно - они действительно нужны только для очень больших систем корпоративного класса. Помните, что это всего лишь инструменты, и большие в этом (может ли кто-нибудь сказать "Золотая кувалда"?). Они сильно злоупотребляют, поэтому действительно, действительно сомневайтесь, нужны ли они вам. Если они вам понадобятся, то это удалит несколько ваших опций, включая мой любимый, Jetty.
Вам нужно использовать любые другие основные технологии J2EE, такие как JMS, ESB и т.д.? Если это так, и вы действительно не можете обойтись без этого, то вы снова будете привязаны к полномасштабному контейнеру J2EE. Внимательно подумайте и исследуйте, прежде чем совершать BPM, например, и избегайте AquaLogic BPM по (почти) всем затратам - это крайне уродливо.
Если вы действительно должны использовать полноразмерный контейнер J2EE, сначала рассмотрите open-source, потому что он более надежный, лучше поддерживается и экономичнее. У них более широкие клиентские базы и более открытое взаимодействие с поддержкой, поэтому они стремятся быстрее исправлять ошибки. Тем не менее, смола незрелая, и я бы избегал ее относительно GlassFish или JBoss - я счел проблематичным развертывание и поддержку. Я бы предпочел JBoss из-за его более широкой клиентской базы, зрелости и т.д. GlassFish сложнее включить в процесс автоматической сборки/развертывания, но для некоторых его специфических функций (если они вам понадобятся) может быть лучше.
Есть ли у меня специальная причина для Apache? Затем наклониться к Tomcat, возможно, плюс что-то.
Могу ли я заниматься только сервлетами? Тогда я буду использовать Jetty - это самое легкое, быстрое, самое простое и гибкое решение. Если я склоняюсь против возможности использовать Jetty, я бы поставил под сомнение все мои предположения о том, почему. YAGNI применяется.
Лучше всего использовать StringTemplate/WebStringTemplate на Jetty: чистое, надежное, быстрое, поддерживаемое решение без каких-либо лицензионных сборов, солидной репутации и поддержки и т.д. Вот тут я и начинаю.
Большинство приложений/систем выбирают множество фантастических функций J2EE, когда им действительно нужны сервлеты и JDBC с некоторой достойной архитектурой/дизайном. Вопрос: почему вы думаете, что вам нужно больше.
Из полноразмерных контейнеров я бы избегал WebLogic и WebSphere, если вы не поддерживаете основной веб-сайт MAJOR (мой текущий сайт работодателя развернут на WebLogic, и он получает одиннадцать миллионов просмотров в месяц, другие сопоставимы). WebLogic настоящая претензия к славе - это относительно простая кластеризация, но избегать их собственных функций блокировки вендора (почти) всех затрат. WebSphere - это просто кошмар, который я бы избегал буквально любой ценой - я отказываюсь делать проекты, связанные с WebSphere, после того, как сделал пару в прошлом. Ни один продукт не стоит огромных лицензионных сборов, если у вас действительно нет особой необходимости, которая управляет использованием запатентованной функции. За десять лет, как старший архитектор/инженер для многих компаний из списка Fortune 500, я еще не видел такой необходимости. С другой стороны, я видел БОЛЬШИЕ боли из-за выбора таких проприетарных продуктов.
Даже для действительно большого, высокого трафика, общедоступных веб-сайтов запатентованная продукция по-прежнему вызывает сомнения. Я бы предпочел потратить эти многомиллионные доллары в год на лицензионные сборы за хорошее оборудование и некоторое время от нескольких действительно хороших консультантов для решения простого решения масштабируемости. Дополнительные миллионы в год можно было бы использовать для производства чего-то, достойного продажи на этом приятном сайте...
РЕДАКТИРОВАТЬ: еще один вопрос, который нужно рассмотреть...
Недавно я столкнулся с Terracotta. Я переосмысливаю все и надеюсь развернуть его в значительной системе. В частности, Terracotta делает кластеризацию лучше, чем что-либо еще, поэтому я бы НЕ ДОЛЖЕН рекомендовать WebLogic для ее кластеризации.
Термин "сервер приложений" неоднозначен. С GlassFish v3 вы можете начать с малого, скажем, с помощью традиционного веб-контейнера и развиваться (используя OSGi и простые функции "добавить контейнер" ), чтобы добавить что угодно: JPA, JAX-RS, EJB, JTA, JMS, ESB, и т.д. Но это тот же продукт, тот же интерфейс администратора и т.д. Соответствует ли это вам сервер приложений? -Алексей (Солнце)
Первый вопрос, который я обычно задаю себе, - "Могу ли я сделать это с Tomcat?". Если ответ отрицательный, потому что мне нужна JMS или JTA, я прибегаю к серверу приложений.
Я использовал WebLogic 8 около 3 лет назад, довольствуясь простотой использования WebLogic и моделью лицензирования/стоимости. Мы использовали его для двух проектов: один из них был веб-сервисом, а другой - порталом. У нас не было проблем с WebLogic или WebLogic Portal в любом из этих проектов.
В течение последних двух лет я работал с WebSphere. Каждый раз, когда я обсуждал с IBM, он всегда стоил в два раза больше, чем эквивалент WebLogic, но корпоративная политика диктовала использование WebSphere. Я нашел кривую обучения в WebSphere значительно более крутой, чем WebLogic, и наш жизненный цикл build/deploy/test был настолько трудоемким, что мы использовали Tomcat в среде разработки. Но самой большой проблемой, с которой я столкнулся с WebSphere, было то, что мы столкнулись с ошибкой, которая заставила нас перейти на следующий выпуск патча, чтобы запустить новую проблему, анализируя web.xml. Это заняло 48-часовой переход, чтобы все это проделать.
В данный момент я использую JBoss. Около 3 месяцев назад я собирался начать свой новый проект с Tomcat и Jetspeed 2, но я заметил, что Jetspeed 2 кажется немного застойным сейчас, и JBoss Portal 2.7.0 был только что выпущен с поддержкой JSR 286/Portlet 2.0. Я дал JBoss отскок и нашел, что его очень легко настроить и администрировать. Цикл build/deploy/test очень быстрый, и мне редко приходится перезапускать сервер, если я не изменил XML файл Spring где-нибудь.
Я использую jBoss в течение 3-4 лет.
Аргументы для jBoss:
Аргументы против jBoss:
Оформить заказ GlassFish 3.1! Построенная на основе модульного ядра GlassFish v3, основанного на Java EE 6, версия 3.1 обеспечивает кластеризацию, централизованное администрирование и высокую доступность.
Подробнее см. http://blogs.oracle.com/nazrul/entry/glassfish_3_1.
Другой вопрос, который здесь не обсуждался, - это производительность. Если это вызывает беспокойство из-за типа обслуживания или из-за количества пользователей, то применимы следующие действия:
Обратите внимание, что G-WAN использует только JVM: он не использует никаких дополнительных контейнеров (если не указано явно), поэтому вы можете зарезервировать его для важных для производительности веб-приложений.
Поскольку G-WAN поддерживает другие языки (C, С++, С#, D, Objective-C), вы можете обрабатывать некоторые части приложений в raw C, сохраняя Java для других задач.
Я мог бы включить вашу предпочтительную ОС в качестве критериев принятия решений. Это должно облегчить поддержку, если вы используете одного и того же поставщика для ОС и сервера приложений. Если у вас уже есть отношения с одним или обоими поставщиками, подумайте, с чем они справляются.
С технической точки зрения я бы выбрал GlassFish, потому что он поддерживает более свежие нововведения. Я не думаю, что JBoss плох, так или иначе, это просто не так актуально.
Большая часть моего опыта связана с WebLogic, но я использовал JBoss и GlassFish. Я только что выпустил новый сайт в полном стеке с открытым исходным кодом (OpenSolaris, GlassFish, MySQL), и это был отличный опыт с небольшими разочарованиями.
Я все еще думаю, что WebLogic - лучший сервер приложений Java EE на рынке. Я думаю, это стоит того, если вы можете позволить себе эти лицензионные сборы.
Я был удивлен, увидев, как далеко вы можете объединить Tomcat, OpenEJB и ActiveMQ. Это мне показалось бы дешевой альтернативой.
Я также заглянул в сервер Spring dm. Это основано на Tomcat, но я думаю, что часть OSGi, которую они добавили, может быть повсюду в короткие сроки. Если это будет сделано с тем же качеством, что и структура Spring, это будет очень хорошо.
Альтернатива: вообще не используйте сервер приложений.
Отъезд http://www.atomikos.com/Publications/J2eeWithoutApplicationServer.
Для веб-проектов держите легкий веб-контейнер, если вам нужно, в сочетании с чем-то вроде Wicket, чтобы избежать сложности JSP/JSF или расположений.
НТН Гай