Spring против Jboss

В чем преимущества и недостатки для Spring и Jboss для корпоративного веб-приложения.

Ответы

Ответ 1

Как уже было сказано, но позвольте мне просто повторить точку. JBoss - это сервер приложений. Некоторые серверы приложений Java включают

  • Websphere
  • Glassfish
  • JBoss

Spring является основой. Довольно большая структура, которая предлагает совсем немного, но для меня одной из главных особенностей является MVC. MVC - это шаблон дизайна, в котором вы отделяете свою модель от вида от своего Contoller. Модель представляет собой представление данных. Это может подкрепляться такими вещами, как базы данных или файлы XML. Представление - это то, что используется для просмотра модели. Это может быть веб-интерфейс или приложение Windows. Пользователь будет взаимодействовать с представлением. Пользователь выражает желание обновить модель. Здесь находится контроллер. Мы используем contoller, чтобы сообщить модератору обновить. И поскольку представление основано на модели, представление также обновляется. Это упрощает, но в двух словах. Другая структура MVC, на которую вы можете смотреть, - Struts.

Как я уже говорил ранее, есть другие функции, которые Spring предлагает, например

  • Структура безопасности
  • Инверсия управления
  • Инъекция зависимостей

Ответ 2

Это хороший вопрос. Некоторые из них неправильно заявили, что это сравнение яблок с апельсинами, т.е. Jboss является контейнером, а Spring представляет собой просто структуру, такую ​​как Struts. Однако причина, по которой это немного запутанно, заключается в том, что как JBoss, так и Spring значительно расширились от их первоначального, простого происхождения и, таким образом, приближаются друг к другу. Один простой способ понять JBoss заключается в том, что имя было оригинальным "EJBoss", и оно предназначалось для того, чтобы быть сервером приложений J2EE с открытым исходным кодом, поэтому у него было преимущество перед tomcat за то, что он служил контейнером EJB и таким образом мог конкурировать с WebSphere и другими собственными серверами приложений.

И Spring был каркасом IoC (теперь называемым "Injection Dependency" ), по существу factory для объектов, чтобы вы могли следовать более "слабо связанному" дизайну.

Однако с их популярностью оба продукта расширялись. Например, у JBoss теперь есть собственный контейнер IoC: JBoss IoC

JBoss предоставляет собственный легкий контейнер IoC под названием JBoss Microcontainer. Микроконтейнер JBoss - легкий, инвертированный Контейнер для контроля/зависимости Инъекция, аналогичная концепции Spring, Pico Container и Plexus.

И хотя Spring может работать отлично, сосуществует (в основном) с JBoss, ему не нужен полноэкранный EJB-контейнер, он может легко работать в tomcat. Вся цель дизайна Spring основывалась на идее легкого дизайна и использования POJO, а также на отсутствии требований к контейнеру с тяжелым весом, что было очень противоречивым EJB, и, таким образом, казалось бы, это противоречило бы с JBoss.

Rod Johnson указал, что нет причин, по которым вы не можете запустить Spring в JBoss:

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

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

Что будет дальше - это что угодно, кроме разрядки, как JBoss и Spring Source битва за все от XML до интеграции с инструментами в конечном итоге виртуализация, сама.... ее здоровая конкуренция,

[надрез]

Только время покажет, но я думаю, что эта битва только делает вещи лучше для разработчиков, больше вариантов, чем .Net и многое другое инновации вокруг Java, это будет жесткая проверка для JBoss, но одна что они могут справиться, если исполнение безупречно, иначе, ищите Spring Источник для вождения клина между воспринимаемыми и реальными преимуществами JEE 6... скорее, чем позже, переносимость приложений будет должны быть продемонстрированы, чтобы противостоять проприетарным моделям, и этого не произошло,

Для более современного взгляда на соблюдение различных стандартов Java, посмотрите запрос обратной связи на Spring 5. Вы можете получить представление о ограничениях, с которыми сталкиваются дизайнеры Spring, а также подчеркнуть тот факт, что для рынка Spring важно обеспечить, чтобы Spring поддерживал различные серверы EE:

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

Ну, безусловно, поднимитесь на Servlet 3.0+ (от нашего настоящего сервлета 2.5 совместимость во время работы), но не выше, чем wed, как Spring 5 приложений для работы на базовых серверах EE 6. Смотрите мой предыдущий блога для обсуждения того, почему это неизбежно, учитывая рыночной ситуации с Java EE 7 и множеством серверов, которые все еще основанный на API Servlet 3.0. [snip] Его просто стыдно, что мы должны поддерживать API JMS 1.1 в стиле 2002 года... Wed как поднять до JPA 2.1+ и Bean Проверка 1.1+, но наши руки выглядят для привязки: TomEE 1.7 и JBoss EAP 6.4 имеют жесткий JPA 2.0 и BeanAPI-интерфейсы Validation 1.0, а WebLogic 12.1.3 - JPA 2.1, но нет Bean API проверки Validation 1.1 (несмотря на то, что они связаны).

Ответ 3

Вот мое мнение:

Spring представляет все, что хорошо в Java EE, тогда как JBoss представляет все, что плохо.

Ну... это не так хорошо (не так, как я думал). Я просто говорю, что я никогда не выберу JBoss для размещения любого приложения. Он просто такой неуклюжий и тяжеловесный, и ничего особенного не делает. Мне нравится Spring, потому что он чувствует себя менее монолитным и неуклюжим. Конечно, Spring не является контейнером приложения, но его можно использовать для создания большей части инфраструктуры, необходимой для размещения приложения - вам просто нужно подключить его к контейнеру, а Spring - к остальным.

Ответ 4

JBoss - это контейнер, spring - это то, что работает внутри контейнера. Вы сравниваете яблоки с апельсинами.

Ответ 5

Поскольку java6 и CDI (посмотрите на @inject), ваше мнение это неверно, spring уже не единственный. Был правдой 15 лет назад с EJB2 (и даже EJB3) но сегодня код CDI управляется в websphere, weblogic, jboss, glassfish,... любом сервере приложений, который вы хотите.

Ответ 6

Приложения запускаются на JBoss как монолитные (один процесс JVM делает все), где вам понадобится вертикальный/горизонтальный кластер для масштабирования, где, когда использование spring можно настроить, также реализует архитектуру микросервисов.