Сервер приложений - чтобы использовать или не использовать?

Никто не был уволен за использование WebLogic или WebSphere в корпоративной среде. Для крупного бизнеса и менеджеров важны не только технологические аспекты. Эти серверы приложений предлагают полнофункциональные консоли администрирования, которыми легко пользоваться даже неопытным администраторам. Кроме того, легче найти службы поддержки. Компания, которая использует компоненты с открытым исходным кодом, должна вкладывать средства в опытных разработчиков, которые все настраивают и обслуживают. Серверы приложений широко используются в компаниях (например, в банках), бизнес которых не имеет ничего общего с программным обеспечением. Для них имеет смысл покупать все (лицензию на программное обеспечение, установку / настройку, услуги поддержки) у одного поставщика.

Если вам нужно спросить, вы не можете себе этого позволить.

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

Функции кластеризации, переключения при отказе и синхронизации сеансов WebLogic и JBoss по-прежнему делают их полезными в крупных центрах обработки данных.

JBoss, конечно же, использует Tomcat в качестве своего веб-интерфейса, так что это не либо / или.

Я видел, как люди добавляли OpenEJB и ActiveMQ в Tomcat и получали все функции сервера приложений Java EE. Граница довольно размыта.

Сервер Spring DM построен на Tomcat. Будет интересно посмотреть, сможет ли он начать отвлекать внимание и долю рынка от разработчиков сервера приложений Java EE.

Я люблю Spring - это моя любимая среда, но я могу сказать вам, что некоторым людям это утешает. Java EE - это стандарт, внедренный несколькими поставщиками серверов приложений. Если вы не используете расширения для конкретных поставщиков, теоретически ваш код может быть перенесен из WebSphere в WebLogic в JBoss без изменений. Некоторым крупным ИТ-магазинам это нравится. Они избегают Spring, потому что это не стандарт. Это детище Рода Джонсона и его команды. Если вы решите, что вам не нравятся их материалы, вам больше некуда идти.

В разработке находится новый стандарт Java IoC / DI. Род Джонсон и Боб Ли работают над этим. Может быть, это начнет успокаивать некоторые из существующих страхов.

Several reasons, most of which may or may not apply to a particular need.

1) Support. Many enterprises like to have a support contract with the vendor who developed the server. With an open source solution you are pretty much "on your own."

2) Full Java EE / EJB support. While I don't find this particularly useful myself, these features are widely used by commercial applications. If you need them, there's really no alternative. If you don't need them, they're a waste.

3) Good administration consoles. Tomcat has an admin console that will allow you to add and remove applications. As far as I am aware, that's about as far as it goes. WebSphere has that (though not very streamlined), but you can also alter connection pool sizes, data sources, thread pool sizes, change the logging configuration (very high granularity), and activate memory and JVM profiling. Mostly without restarting the App Server. Supposedly, clustering is relatively easy to set up as well. The ability to install a .EAR file is notably missing from tomcat as well, and if you have multiple inter-related applications to install, it becomes a real pain to manage them all.

You can do (at least) most of (3) in tomcat as well, but not through the admin GUI. Some people like to have a nice GUI.

Некоторым нравится иметь поддержку EJB (спецификация Java EE) «на всякий случай»

Сервер приложений - это архитектурное решение. Вы должны использовать его, если собираетесь продумывать различные повторно используемые модули своего приложения. Если вы не возражаете, что ваши службы должны быть реализованы через стек HTTP, EJB должен быть вашим вариантом по умолчанию. С AS у вас уже есть готовое решение для решения передовых практик архитектурным способом. Вы можете использовать очереди, темы, jms и т. Д. Прямо из коробки, и все это стандарты Java EE. Но я думаю, что вы должны продумать все свое приложение в этой архитектурной шумихе , чтобы иметь возможность судить о решении AS.