Подтвердить что ты не робот

Spring MVC с JBoss vs Tomcat - Преимущества/Практика

Хорошо. Это опять-таки вопрос отраслевой практики.

  • Tomcat = веб-контейнер
  • JBoss, WebLogic и т.д. = Серверы приложений, в которых есть веб-контейнер внутри (для JBoss, его разветвленный Tomcat)

Spring не нужен сервер приложений, такой как JBoss. Если мы используем корпоративные сервисы, такие как JMS и т.д., Мы можем использовать независимые системы, такие как RabbitMQ, ApacheMQ и т.д.

  • Вопрос: почему люди по-прежнему используют JBoss и другие сервисы приложений для приложений на основе spring?
  • В чем преимущества spring могут использоваться с помощью серверов приложений? Как объединение объектов? Какие особые преимущества предлагает Application Server? Как настроены эти настройки?
  • Если не для spring, для каких целей используются серверы приложений для Spring/Hibernate, etc stack? (Использование случаев)
4b9b3361

ОТВЕТЫ

Ответ 1

На самом деле, я бы сказал, что прослушивание JMS - лучшая причина для сервера приложений. Автономный брокер сообщений не устраняет проблему, так как вам по-прежнему нужен компонент, который прослушивает сообщения. Лучший способ сделать это - использовать MDB. В теории вы можете использовать Springs MessageListenerContainer. Однако это имеет несколько недостатков, таких как JMS, только поддерживает блокирование чтения, а Spring поэтому необходимо развернуть свои собственные потоки, которые полностью не поддерживаются (даже в Tomcat), и могут прерывать транзакции, безопасность, именование (JNDI) и загрузку классов (что в свою очередь может сломать удаленный доступ). Адаптер ресурсов JCA может делать все, что захочет, включая разворот потоков через WorkManager. Вероятно, база данных используется помимо JMS (или другого адресата), в этот момент вам нужны XA-транзакции и JTA, другими словами сервер приложений. Да, вы можете исправить это в контейнере сервлета, но этот момент он становится неотличимым от сервера приложений.

ИМХО - самая большая причина для серверов приложений - это долгие годы после публикации спецификации (которая также требует много лет), пока severs не реализуют спецификацию и не устранят худшие ошибки. Только сейчас, прямо перед публикацией EE 7, мы начинаем появляться серверы EE 6, которые не полностью пронизаны ошибками. Это становится смешно, когда некоторые производители больше не исправляют ошибки в своей линии EE 6, потому что они уже заняты предстоящей линией EE 7.

Edit

Длительное объяснение последнего абзаца:

Java EE во многих местах зависит от контекстной информации. Информация, которая явно не передана в качестве аргумента от сервера/контейнера к приложению, но неявно "там". Например, текущий пользователь для проверки безопасности. Текущая транзакция или соединение. Текущее приложение для поиска классов для ленивой загрузки кода или десериализации объектов. Или текущий компонент (сервлет, EJB,...) для просмотра JNDI. Вся эта информация находится в локаторах потоков, которые сервер/контейнер устанавливает перед вызовом компонента (сервлет, EJB,...). Если вы создаете свои собственные потоки, сервер/контейнер не знает о них, и все функции, основанные на этой информации, больше не работают. Вы можете уйти от этого, просто не используя какие-либо из этих функций в потоках, которые вы создаете.

Некоторые ссылки

http://www.oracle.com/technetwork/java/restrictions-142267.html#threads http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html#spring-4

Если мы проверим спецификацию Servlet 3.0, мы найдем:

2.3.3.3 Асинхронная обработка

Возможности Java Enterprise Edition, такие как раздел 15.2.2, "среда веб-приложений" на стр. 15-174 и раздел 15.3.1 "Распространение идентификатора безопасности в вызовах EJBTM" на стр. 15-176 доступны только для потоков, выполняющих первоначальный запрос или когда запрос отправляется в контейнер через метод AsyncContext.dispatch. Функции Java Enterprise Edition могут быть доступны для других потоков, работающих непосредственно с объектом ответа через метод AsyncContext.start(Runnable).

Это касается асинхронной обработки, но для пользовательских потоков применяются те же ограничения.

public void start (Runnable r). Этот метод заставляет контейнер отправлять поток, возможно из пула управляемых потоков, для запуска указанного Runnable. Контейнер может распространять соответствующую контекстуальную информацию на Runnable.

Опять же, асинхронная обработка, но те же ограничения применяются для пользовательских потоков.

15.2.2 Окружающая среда веб-приложений

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

Non-portable означает, что он может находиться на одном сервере, но не в другом.

Если вы хотите получать сообщения с JMS за пределами MDB, вы можете использовать четыре метода на javax.jms.MessageConsumer:

  • #receiveNoWait() вы можете это сделать в потоке контейнера, он не блокируется, но это похоже на подглядывание. Если сообщение отсутствует, оно просто возвращает null. Это не очень хорошо подходит для прослушивания сообщений.
  • #receive(long) вы можете это сделать в потоке контейнера, он блокирует. Обычно вам не нужно блокировать ожидания в потоке контейнера. Снова не очень хорошо подходит для прослушивания сообщений.
  • #receive(), это возможно, возможно, бесконечно. Снова не очень хорошо подходит для прослушивания сообщений.
  • #setMessageListener() это то, что вы хотите, получите обратный вызов, когда поступит сообщение. Однако, если библиотека не может подключиться к серверу приложений, это не будет потоком контейнера. Крючки на сервере приложений доступны только через JCA для адаптеров ресурсов.

Итак, да, это может сработать, но это не гарантируется, и есть много вещей, которые могут сломаться.

Ответ 2

Вы правы, что вам действительно не нужен настоящий сервер приложений (реализующий все спецификации Java EE), чтобы использовать Spring. Самая большая причина, по которой люди не используют настоящие приложения Java EE, такие как JBoss, это то, что они были медленными, как # [email protected]#% при холодном запуске, что создавало боль (горячее развертывание все еще не так хорошо работает).

Вы видите, что есть два лагеря:

  • Java EE
  • Spring Framework.

Один из лагерей верит в процесс спецификации/комитета, а другой верит в доброжелательный диктатор/органический процесс OSS. У обоих есть люди с их "повестками дня".

Вероятно, вы не получите очень хороший непредвзятый ответ, поскольку эти два лагеря очень похожи на войну Emacs vs VIM.

Отвечайте на свои вопросы без смещения Spring

  • Потому что он теоретически покупает ваш менее блокирующий поставщик (хотя я считаю это противоположным).
  • Spring самым большим преимуществом является AspectJ AOP. Безусловно.
  • Я думаю, ответьте Филиппу.

(начало разговора)

Так как @PhilippeMarschall защитил Java EE, я скажу, что выполнил маршрут Tomcat + RabbitMQ + Spring, и он работает очень хорошо. Обсуждение @PhilippeMarschall действительно, если вы хотите надлежащую JTA + JMS, но с правильной настройкой с Sprig AMQP и хорошей транзакционной базой данных, такой как Postgresql, это не проблема. Также он неверен в отношении того, что транзакции очереди сообщений не привязаны/синхронизированы с транзакциями платформы, поскольку Spring поддерживает это (и IMHO гораздо элегантнее с @Transactional AOP). Также AMQP просто превосходит JMS.

(конец разговора)

Ответ 3

Мы используем JBoss над tomcat для источников данных JNDI и объединения. Это делает так, чтобы программист не знал ничего о базе данных, но ее имя JNDI