Как повысить производительность при разработке веб-приложений на основе Java EE

Question

Мне бы хотелось узнать, как вы справляетесь с кажущейся низкой производительностью разработки веб-приложений на основе Java EE по сравнению со стеками других технологий ( Побережье , Ruby on Rails и т. Д.) .

Ограничения:

• Готовое веб-приложение должно быть развернуто в контейнерах приложений, совместимых с Java EE
• Если возможно, предыдущие инвестиции в Java-решения должны быть сохранены, т.е. должна быть обеспечена собственная совместимость с Java-системами и библиотеками
• Из-за организационной структуры предпочтение отдается Java как языку реализации, хотя менее экзотические языки на основе JVM (например, Groovy) также могут быть приемлемыми
• Полученная система должна быть архитектурно устойчивой
• Полученная система должна быть расширяемой и обслуживаемой

Чтобы не пустить это в философскую дискуссию, меня интересуют только предложения, основанные на практическом опыте. Возможные примеры включают доменные языки, фреймворки и MDSD.

Если вы указываете на абстрактный класс решений (например, MDA / MDSD), просьба сообщить подробности о том, как вы его реализовали, а также информацию об общих подводных камнях и передовых практиках.

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

EDIT: Поскольку ответов намного меньше, чем я ожидал, я также приму отчет о неудачных попытках, в основном расширив вопрос: «Как (не) повысить производительность при разработке веб-приложений на основе Java EE?».

Answer 1

Я считаю, что стек Java Java EE на самом деле очень хорош. Есть несколько причин, объясняющих низкую производительность Java EE:

• Будучи «корпоративным стеком», он часто используется для создания скучных, некрасивых, «достаточно хороших» приложений и, в целом, предприятий, как правило, не привлекают великих разработчиков , которые люблю программировать, и думать и заботиться о том, что они делают. Качество программного обеспечения в корпоративном мире не велико.
• Будучи корпоративным стеком, где есть деньги, производители программного обеспечения пытаются им что-то продать. Они создают огромные, сложные и дорогие решения не потому, что они хороши, а просто потому, что могут продавать их предприятиям.
• Предприятия часто очень склонны к риску, и все, что они делают, лучше «стандартизировать». Стандарты создаются либо после , некоторые технологии оказались успешными, либо до . В обоих случаях это плохо для предприятий (и Java). Предприятия заканчивают тем, что применяют либо хорошую технологию слишком поздно, либо совершенно ошибочную технологию Последний случай также очень опасен, потому что он создает ложное представление о том, что технология (в противном случае полный отказ) должна быть полезной, если она стандартизирована и ее используют все.
• Исторически сложилось так, что платформа Java EE, похоже, привлекала множество астронавтов и разработчиков архитектуры в крупных компаниях, которые стали архитекторами, единственной целью которых было создание большего количества слоев, больше структур, больше абстракций и больше сложности.

Дело не в том, что нет хороших инструментов и сред Java; дело в том, что слишком много плохих, слишком много слишком сложных, слишком много бюрократических процессов и методологий, слишком много бесполезных стандартов.

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

Тем не менее, одни только инструменты не сильно изменят вашу производительность, и наоборот, правильные люди могут быть продуктивными и с плохими инструментами.

Мой совет:

• Не используйте технологию только потому, что она стандартная, потому что все ее используют или потому что она официально рекомендована Sun. Используйте технологию, только если вы лично считаете, что это лучший инструмент для вашей работы. Таким образом, вы можете отказаться от таких технологий, как JSF, JSP, Web-сервисы, JMS, EJB, JTA, OSGi, MDA.
• Будьте проще, используйте здравый смысл, задавайте вопросы. Вам действительно нужно опубликовать свои объекты для удаленного доступа? Вам действительно нужно создать еще один слой абстракции, чтобы вы могли переключаться с Hibernate на TopLink? Вам действительно нужно конвертировать ваши данные в / из XML десять раз каждый раз, когда они вам нужны? Вам действительно нужна схема XML? Вам действительно нужно, чтобы все было настраиваемо, взаимозаменяемо? Во время выполнения? Не разработчики?
• Сделайте процесс простым. Быть проворным . Вам действительно нужна эта документация? Вам действительно нужно описать каждый экран в огромной таблице, одобрить его, ввести его в какой-нибудь самодельный инструмент и затем сгенерировать JSP? У вас есть компетентные программисты или вы все сначала разрабатываете, а программисты только «переводят» на Java?
• WYSIWYG-дизайн HTML не работает.
• Графическое программирование вообще не работает. Это включает в себя UML в качестве схемы и UML в качестве языка программирования , MDA, блок-схемы страниц чертежа. Генерация кода плохая.
• Никогда не проектируйте каркас перед его использованием , всегда собирайте каркас .
• Предпочитают фреймворки, которые имеют лишь небольшую конфигурацию XML.
• Стремитесь к низкому количеству LOC. Посмотрите на Actal символов в вашем коде. Важен ли каждый персонаж? Считать. Что вы можете сделать, чтобы сделать ваш код меньше? Вам нужен этот класс? Что оно делает? Зачем тебе это нужно?
• Испытание не священная корова; вам не нужно 100% тестовое покрытие. Тестируйте только то, что имеет смысл. Если это трудно проверить, сделайте это проще; или не проверяйте это вообще. Не проверяйте внешний вид.

И, наконец, некоторые конкретные рекомендации Java:

• Для слоя презентации попробуйте Гобелен . Почему я люблю это? Потому что с Tapestry вы можете создать красивый код. Он разработан специально для этого, так что ваш код может быть красивым . Ваш код. Под красивым я подразумеваю все, что имеет значение - оно короткое, легко изменяемое, легко читаемое, легко создавать абстракции и все же гибкое, оно не пытается скрыть тот факт, что вы разрабатываете для Интернета. Конечно, все еще вы делают ваш код красивым.
• Не стесняйтесь использовать Hibernate, особенно для CRUD и больших приложений. Не беспокойтесь о JPA. Хотя это не серебряная пуля, с ORM вы всегда будете обменивать один набор проблем на другой.
• Только немного Spring, вам не нужно много, так как вы тщательно избежали всех ловушек Java EE. Используйте инъекцию зависимости экономно.
• После всего этого вы можете найти язык Java слишком многословным и не очень полезным при абстрагировании копируемого / вставляемого кода. Если вы хотите экспериментировать, попробуйте Scala. Проблема в том, что главное преимущество Scala в том, что вы получаете все преимущества современных языков, сохраняя при этом безопасность типов, и в то же время поддержка IDE solid отсутствует. Будучи использованным для супер-крутых Java IDE, нет смысла переключаться на Scala, если нет поддержки IDE, которая является стабильной и надежной. Достаточно стабильно недостаточно.

Answer 2

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

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

Кстати, мой опыт работы с MDA противоречит повышению производительности, поэтому я не буду их упоминать (на самом деле, MDA убивал нашу производительность).

Answer 3

Javarebel может значительно сократить время, затрачиваемое на веб-разработку с использованием Java.

Позвольте мне процитировать здесь официальный сайт:

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

Answer 4

Один важный момент при обсуждении производительности Java EE: вы должны использовать Java EE 5 и EJB3.x, поскольку они обеспечивают новый уровень производительности (и функциональности) по сравнению с предыдущими выпусками.

Абсолютно важно придерживаться стандартных спецификаций Java EE, например, использование Hibernate вместо JPA не выгодно для производительности. При использовании JPA нет никаких ограничений на использование функций Hibernate, но при использовании Hibernate вместо JPA вы получаете доступ к единственному поставщику персистентности без дешевого выхода. Идея использования стандартов в целом одна и та же: концептуальная гибкость (путем включения различных реализаций) с доступной расширяемостью (при использовании проприетарных расширений, если это абсолютно необходимо). Java EE 5 и EJB3 - огромные шаги в этом направлении. Конечно, вы хотите свести к минимуму любые проприетарные функции, но если некоторые кажутся абсолютно необходимыми, это хороший знак того, что они будут частью спецификации в следующем выпуске ...

Основные препятствия для производительности Java EE находятся в его корпоративной ориентации (предлагает намного больше, чем требуется для большинства проектов) и в ее наследии (обратная совместимость). На уровне представления информации с помощью JSF и управления состоянием еще многое предстоит сделать - обратите внимание на JSR-299 , чтобы решить эти и другие улучшения.

Answer 5

Grails - это фреймворк Java для веб-приложений, очень похожий на Ruby on Rails, с аналогичными принципами (DRY, CoC) и повышением производительности, но основанный на существующих Java-фреймворках (Spring, Hibernate, несколько других).

Я работаю над исследовательским проектом с использованием Grails уже несколько недель (без опыта в Grails или Groovy), и я весьма впечатлен. Есть несколько грубых краев - он не такой зрелый, как RoR, но вы можете получить результаты быстро, и никогда не возникает ощущение, что фреймворк мешает вам.

Возможно, это лучше всего иллюстрирует этот конкретный пример: я хотел отредактировать 2D-массив объектов домена в сетке на одной веб-странице и обнаружил, что автоматическое сопоставление результирующих данных запроса HTML с объектами домена (предоставлено Spring MVC , Я думаю) была ошибка, из-за которой некоторые данные отображались на неправильные объекты. Я часом смотрел в Интернете, но, видимо, никто не сталкивался и не решил проблему. В конце концов я решил отказаться от автоматического отображения и сделать это «вручную», а затем обнаружил, что мне понадобилось не более 10 строк кода ...

Answer 6

Часто упоминается, что RoR и подобные платформы, основанные на динамических языках, являются более производительными средами, но мне действительно интересно знать, есть ли надежные данные, подтверждающие это. Это будет нелегко, так как нужно быть уверенным, что она не сравнивает яблоки с апельсинами. Такие вещи, как тип проекта (web 2.0, корпоративное приложение) и размер команды должны быть приняты во внимание. Однако для небольших проектов более чем очевидно, что такие интегрированные среды действительно намного более продуктивны, чем Java EE. Итак, это короткий список аргументов, используемых для поддержки этого, и того, что вы можете сделать для них в мире Java.

Ruby - более понятный и лаконичный язык. Вы можете сделать то же самое с гораздо меньшим количеством кода.

Я не думаю, что вы можете иметь то же самое в Java, если, конечно, вы не используете динамический язык, который работает в JVM (JRuby, Scala, Groovy). В противном случае ваша IDE может помочь. В Jave IDE является важным инструментом, и он окупит вас, если вы научитесь правильно его использовать (генерация кода, фрагменты кода, рефакторинг). На самом деле есть много вещей, которые вы можете сделать с помощью Java IDE, которые просто невозможно сделать с Ruby или Python IDE. Плюс у вас есть преимущества статического типизированного языка. Печатание может занять больше времени, но это поможет вам избежать распространенных ошибок.

Руби гораздо веселее в использовании. Делает разработчика счастливее и продуктивнее.

То же, что и выше. Хотя, на мой взгляд, весьма субъективный аргумент.

Соглашение о конфигурации делает вещи быстрее

Может помочь инфраструктура внедрения зависимостей, такая как Spring или Guice

Леса, MVC уже там для вас.

Опять же могут помочь фреймворки Java MVC

Базы данных легко. Загружать элементы базы данных как объекты. Можно изменить базу данных на лету.

Может помочь Hibernate, iBatis или другая платформа ORM. С Hibernate Tools вы можете добиться аналогичной функциональности с тем, что есть в RoR с файлами yml

Мгновенная загрузка новых модулей

Maven или Ant Ivy могут помочь

Простое развертывание для тестирования

Ваша IDE или Jetty могут помочь. На самом деле отладка проще с Java

Тестирование интегрировано с фреймворком. Использование макетов облегчает тестирование

Среда внедрения зависимостей может помочь с фиктивными объектами. JUnit был пионером модульных структур. Я не думаю, что Java труднее тестировать.

Answer 7

За последние пару лет я использовал Jboss Seam и считаю его очень продуктивным способом разработки в Java EE (с использованием EJB3, Hibernate, Facelets). Я также немного прибегаю к PHP-кодированию и могу честно сказать, что я более продуктивен с Seam (хотя это, вероятно, также свидетельствует о моих навыках PHP).

Для меня пара основных моментов будет:

• Горячее развертывание кода (абсолютно необходим)
• СУХОЙ с Facelets
• Конфигурация на основе аннотации
• Обширные вставные компоненты (особенно ajax4jsf)
• Поддержка IDE от Jboss Tools

В IDE и в командной строке есть инструменты для создания кода скелета аналогично RoR.

Answer 8

Используйте AOP (Aspect-Oriented Programming) для сквозных аспектов, таких как регистрация, авторизация и т. Д. Вы можете использовать Spring AOP или AspectJ. Это делает код беспорядочным и легким в обслуживании.

Answer 9

Просто хотел внести еще одну идею ... вы можете использовать JRuby и Rails (аналогично предыдущему комментарию о Django и Jython).

Если вы используете JRuby с Rails и JRuby Rack (и, может быть, с некоторыми другими утилитами ... Первоначально интеграция была не единственной), вы можете развернуть дополнения JRuby Rails в существующем веб-приложении Java. У нас есть устаревшее приложение JSP, развернутое с Tomcat, и теперь мы начинаем добавлять новые страницы с использованием Rails только с этой настройкой (в дополнение к расширению стороны JSP, когда это необходимо). До сих пор он был довольно успешным, хотя у нас не было ни одной из основных страниц с высоким трафиком, реализованной в Rails, поэтому я не знаю, насколько хорошо она будет масштабироваться.

У нас есть полный доступ к сеансу, и мы даже настроили механизмы для вызова JSP из страниц Rails (такие как существующий тип JSP верхнего и нижнего колонтитула). Чтобы полностью интегрировать 2, требуются определенные усилия, проб и ошибок, но если Rails и JRuby - вариант, я настоятельно рекомендую это (как личный поклонник Ruby).

Коллега баловался с JBoss Seam, который является фреймворком Гэвина Кинга (парня, который принес нам Hibernate), который должен был подражать Rails. Видя и то, и другое, я чувствую, что Rails намного проще в разработке.

Answer 10

Начиная с Jython 2.5 вы можете использовать django для удовлетворения перечисленных вами требований. Довольно просто генерировать военные файлы из проектов django и развертывать их на серверах приложений J2EE.