Google Analytics

понедельник, 9 мая 2011 г.

Spring 3 или Java EE 6




Намедни мне понадобилось расставить точки над i в вопросе, который задан в заголовке. Выкладываю краткие рассуждение по этому вопросу и выводы к которым я пришёл. Разумеется все рассуждения и выводы сугубо субъективны, часть из них основана на собственном опыте, другая заимствована из различных источников.

Основная сложность вопроса заключается в том, что большинство технологий в Spring Framework 3 и Java EE6 очень сильно коррелируют. И как будто этого мало, могут использоваться совместно. Всё это создает большую путаницу в выборе конкретных технологий для реализации проектов. Разумеется проекты бывают разные, поэтому дальнейшее обсуждение пойдет через призму двух видов: корпоративные системы (Учётные и управленческие. Основная суть: заполнил формочку документа, выполнил операцию, получил отчёт и т.д. Работают преимущественно во внутренних сетях); разнообразные прикладные системы (например системы управления проектами, база знаний, информационный портал и др.). У этих видов очень много общего, но основное различие, которое я выделяю - это связность. Чисто корпоративные системы по своей природе это монолит. Конечно можно выделить различные подсистемы бухгалтерский, управленческий и складской учеты например, но всё равно, как правило, будет существовать единое хранилище данных, как минимум для каждого вида учёта, а то и для всех. И такое хранилище монолитно обрастает приложениями. Разнообразные прикладные системы в свою очередь, более обособлены, конечно возможна и интеграция, но она связывает их менее плотно.

Технологии Java EE6 ориентированы преимущественно на корпоративные приложения (кто бы мог подумать). Spring хоть и нацелен на корпоративный сектор, на мой взгляд, более универсален.

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

Легковесность

Вопрос легковесности для Java EE6 канул в Лету. И по этому я не буду поднимать вопрос о быстродействии EJB bean и Spring bean, в конечно счёте этом POJO и накладные расходы контейнера минимальны (но не равны нулю). Накладные расходы зависят от дополнительных технологий (управление транзакциями, инъекции зависимостей и др.) и конечно реализации. Для больших корпоративных приложений легковесность можно считать идентичной. Это не совсем верно для средних прикладных приложений. Хотя опять же, возможно реализовать монстра как с применением Java EE, так и Spring. Более того, можно реализовать чудище контейнер в контейнере и запустить Spring приложение на сервере приложений Java EE. Разумеется для этого могут существовать явные причины, но при отсутствие таковых эпитет чудище вполне уместен. Таким образом можно считать, что схожие технологии в Java EE6 и Spring 3 имеют сравнимые накладные расходы. Исключением могут быть standalone приложения, реализация которых с использованием Spring более легковесна, благодаря чётко выраженной модульности с возможностью подключения только необходимых элементов. Это не легковесность контейнера, а легковесность компоновки приложения.

Стандарт и реализаций

Как известно спецификация технологий Java EE является стандартом и имеет множество реализаций, как чисто коммерческих, так и open source с различными видами поддержки. Spring хоть и open source продукт с коммерческой поддержкой, имеет всё же более склонную к vendor-lock модель разработки. Хотя сейчас и не возникает серьезных опасений по поводу судьбы как Java EE, так и Spring, планируя проект на несколько лет вперед, да ещё без коммерческой поддержки, стоит принимать данный вопрос в расчёт.

Совместное использование

Совместное использования я допускаю только в крайних случаях. Например уже есть реализованная система на Java EE и крупное приложения на Spring, в этом случае при тесной интеграции имеет смысл рассматривать вариант использования Sping приложений в сервере приложений Java EE. Ещё один пример это необходимость глобальных транзакций на нескольких подсистемах. Вопросы совместного использования очень глубоки и как правило ответы вытекают из предшествующего опыта применения технологий. Я с трудом представляю что-то вразумительное в совместном использовании Spring и Java EE реализованное специалистом с недостаточным опытом.

Инфраструктура

Обе технологии имеют развитую инфраструктуру, большое количество пользователей и кучу информационных ресурсов. Небольшим плюсом для Spring, в определенных ситуациях, может быть наличие большого количества смежных проектов, под крылом springsource. Но в тоже время и во круг Java EE существует большое количество вендоров со своими предложениями.

Заключение

Как это не обыденно, но я повторю - не существует silver bullet для всех случаев применения. Каждый инструмент, в конечном счете, всего лишь инструмент для конкретного применения. Java EE и Spring - всего лишь инструменты! Хотя большие и качественные, но инструменты. Разумеется фактически очень трудно быть экспертом и в Java EE и в Spring одновременно, если ты не какой-нибудь программист-суперзвезда мирового уровня. Но тем не менее, разумный подход в применении технологий поможет достичь хороших результатов. Итак вот итоги:
  • Используйте Java EE и Spring совместно только имея веское основание и четкое понимание что вы делаете;
  • Если уже существует обширная кодовая база с применением какой-то технологии, наиболее предпочтительным решением будет остаться на ней (текущей технологии);
  • Вопрос легковесности компоновки может приниматься в расчет для средних одиночных приложений, а не систем;
  • Java EE имеет в запасе несколько независимых реализаций (Но насколько целесообразен переезд?);
  • Spring более прогрессивен в своем развитие благодаря модели разработки, а Java EE всегда, видимо, будет отставать.

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

Дополнительные источники

3 комментария:

  1. Здравствуйте!

    Во-первых, спасибо за сравнение. Возник вопрос по поводу легковесности: Java EE требует сервер приложений, которые (glassfish, jboss) достаточно неповоротливы. Spring-based приложения в свою очередь можно запустить, например, в Jetty. Именно поэтому лично я всегда считал Spring более легковесным решением.

    ОтветитьУдалить
  2. Вопрос в том, что считать легковестностью. Если рассматривать реализацию крупного приложения на Java EE6 + Glasfish и аналогичного по масштабу приложения Spring + контейнер сервлетов(например tomcat), то в данном случае можно говорить о сравнимом уровне накладных расходов инфраструктурных механизмов. А если речь идёт например о потреблении памяти небольшого приложения Spring+Jetty против Java EE6+Glassfish+надстройки, то безусловно первый вариант будет вне конкуренции.

    ОтветитьУдалить
  3. PS:
    >>Во-первых, спасибо за сравнение.
    Пожалуйста!

    ОтветитьУдалить