Spring vs Jboss

Question

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

Answer 1

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

• Websphere
• Glassfish
• JBoss

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

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

• рамки безопасности
• Инверсия управления
• Dependency Injection

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

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

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

[надрез ]

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

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

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

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

Answer 5

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

Answer 6

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