Когда Spring + Tomcat не достаточно мощный?

Question

В последнее время я читал / узнавал больше о Spring и о том, как использовать Spring в сочетании с другими инструментами с открытым исходным кодом, такими как Tomcat и Hibernate. Я оцениваю, может ли Spring MVC стать возможной технологией замены для проекта, над которым я работаю, который использует WebLogic и МНОГО пользовательского кода Java EE. Дело в том, что я всегда подозревал, что наше решение чрезмерно спроектировано и НАМНОГО сложнее, чем нужно. Удивительно, но сейчас 2009 год, и все же мы пишем свои собственные классы обработки транзакций и потокового пула. И это не значит, что мы Amazon, eBay или Google, если вы понимаете, о чем я. Таким образом, я исследую вариант «проще - лучше».

Итак, вот мой вопрос: я хотел бы услышать мнения о том, как вы принимаете решение о необходимости полноценного сервера приложений Java EE или нет. Как вы «измеряете» размер / нагрузку / спрос в приложении Java EE? Количество одновременных пользователей? Всего ежедневных транзакций? Насколько «тяжелым» должно быть приложение, прежде чем вы сдадите руки и сдаетесь и скажете: «Хорошо, Tomcat просто не режет его, нам нужен JBoss / WebLogic / WebSphere»?

Answer 1

Я не думаю, что решение использовать полноценный сервер Java EE или нет должно основываться на количестве пользователей или транзакций. Скорее это должно основываться на том, нужна ли вам функциональность.

В моем текущем проекте мы на самом деле переходим от JBoss к обычному Tomcat, потому что мы поняли, что в любом случае не используем какую-либо функциональность Java EE, кроме базовых сервлетов. Мы, однако, используем Spring. Между базовым управлением объектами Spring, обработкой транзакций и возможностями JDBC мы не видим острой необходимости в EJB. В настоящее время мы используем Struts 2, а не Spring MVC, но я слышал об этом много хорошего. В любом случае, Spring хорошо интегрируется с рядом веб-фреймворков Java.

Answer 2

Spring не пытается заменить некоторые расширенные части спецификации JavaEE, такие как JMS и JTA. Вместо этого он опирается на них, делая их совместимыми с «весенним путем» и в целом облегчая их использование.

Если вашему приложению требуются возможности, подобные JMS и JTA, вы можете легко использовать их через Spring. С этим проблем нет.

Answer 3

Я категорически не согласен со всеми ответами, приведенными здесь.

В Tomcat можно добавить все, включая EJB, CDI, JTA, Bean Validation, JAX-RS и т. Д.

Вопрос: вы этого хотите? Вы хотите собрать все эти зависимости в правильных версиях и проверить, что все это работает вместе, когда другие уже сделали это?

Давайте проясним: никто не использует только Tomcat! Каждый всегда добавляет веб-фреймворк, контейнер ioc, orm, менеджер транзакций, веб-сервисы и т. Д. И т. Д.

Облегченные серверы Java EE, такие как TomEE, уже включают все это и позволяют полностью интегрировать все эти возможности.

Answer 4

Единственная причина для использования полноценного сервера Java EE - если вам нужны распределенные транзакции XA, если вам не нужны транзакции XA, вы можете использовать Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java почта.

Также сервер Java EE должен реализовывать JMS, но не имеет смысла запускать сервер JMS в той же виртуальной машине, что и остальная часть сервера приложений, поэтому, если вам нужен JMS, у вас должен быть отдельный сервер JMS.

Answer 5

То, что не предлагает tomcat, кроме более экзотических элементов Java EE, - это сессионные компоненты (также известные как EJB). Сессионные компоненты позволяют вам эффективно изолировать вашу обработку. Таким образом, у вас может быть одно поле для внешнего интерфейса, другое для сессионных компонентов (бизнес-логика) и другое для базы данных.

Вы хотите сделать это как минимум по 2 причинам:

1. Производительность; Вы обнаруживаете, что одна коробка, которая обрабатывает все, загружает коробку слишком много. Разделение разных слоев на разные блоки позволит вам масштабироваться. Сессионные бины также могут загружать баланс на более мелком уровне. Tomcat и другие подобные веб-сервисы не имеют кластеризации из коробки.
2. Гибкость; Теперь, когда вы перенесли свою бизнес-логику в собственную среду, вы можете разработать альтернативный интерфейс, который бы использовал тот же уровень, но, скажем, был, например, интерфейсом с толстым клиентом. Или, возможно, другие контексты хотели бы использовать сессионные компоненты.

Хотя я, вероятно, должен указать, что если вы используете веб-сервисы для связи с этим средним уровнем, он также может быть на tomcat!

Answer 6

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

Возвращаясь к актуальному вопросу, Walmart.com, etrade.com, The Weather Channel и довольно много других просто используют Tomcat. Парни из IBM по маркетингу и продажам, возможно, заставят вас поверить в другое, но для Tomcat нет предела.

За исключением EJB, я не уверен, чего не хватает Tomcat, и я не фанат EJB.

Answer 7

Может быть, это может быть интересно:

http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html

НТН