svenom1) Что использует приложение? Если ему нужно EJB, JPA с XA транзакциями, то что проще - купить ту же WebSphere с уже готовыми реализациями EJB, JPA и иже с ними, где IBM их будет вылизывать с ного до головы, оперативно реагировать на баги и предоставлять прочие плюшки лицензионного ПО, или же взять Томкат, в который потом запихнуть какой-нибудь опен-сорсный OpenEJB, разработчики которого вам ничего не должны + хз, как оно вообще заведется с томкатом? Если приложение мелкое, а бабал нет - не вопрос, мудимся с Tomcat, если с деньгами нормуль - покупаем готовое коробочное решение, вместо попыток скрестить коня с ослом.
В такие плюшки AppServer-ов входят EJB, JDBC - всякие коннекшн пулы, WebService - с кучей всякий плюшек по всяким WS-Security, WS-Adressing и прочих WS-*, JMS и т.д.SpringSources предоставляет саппорт и на сам Спринг и на Tomcat под него. Сами же еще и "облачные" системы предлагают поверх этого.

Если приложение завинчено на EJB то никуда от JavaEE не деться. А если пишете сами, то что удобнее использовать "универсальный самосвал на 100 тонн" или "скрестив два колеса с двигателем получить мотоцикл" - тут уже выбор архитектора. Что ему больше нужно для решения - многотоннажный самосвал или спортивный байк ;)

svenom2) Возможности инфраструктуры. Вот нужно моему приложению работать с MQ, оно заведется на Tomcat? Ну, с кучей возни и проблем, гляди и заведется. А в сфере заводится с пол-щелчка, используя все плюшки и особенности MQ.
А вот мне надо приложение воткнуть в ESB-шину. Что делать? В той же сфере шина поднимается в лет, мгновенно интегрируется со всякими security realm'ами и JMS'ами. А томкат что? MQ заводится на Spring + Tomcat в той конфигурации в которой нужно. А можно вообще вынести MQ на отдельную машину и разгребать месседжи с нескольких нод.

svenomДалее - кластеризация и кеширование, high availability. У каждого вендора свои плюхиСтоит знать, что Spring также предлагает подобные возможности ;)

svenom4) Чуть не забыл - а как с еарниками то быть? при работе со спрингом можно работать и с WAR и с EAR. Tomcat это способ запустить Спринг попутно получая бонусы. Можно и на полноценном JavaEE гонять Spring. Вопрос - нужно ли?

ИМХО если проект не очень архитектурно странный, то проще его запилить в виде WAR и гонять на более легких серверах нежели WebSphere.


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

justforsqlruПросто часто слышу типа "нахера эти сервера приложений" взял томкат прикрутил spring и все работает.Tomcat + Spring это конструктор который при должном умении позволяет собрать мотоцикл, гоночный болид или кран. А может самолет или самосвал - зависит от задачи.

Сервера приложений - это собранные за вас самосвалы.

Что вам больше подходит решение собранное специально под вас или коробка, где все запаяно и закрыто - решать только вам.

justforsqlruВот и интересно стало если сервера приложения все же живы значит кто то их юзает.Кому то стабильность нужна намного сильнее чем скорость работы или скорость разработки. К примеру банки. Вот они и покупают готовые решения.

Еще коммерческие (сильно платные) сервера приложений могут работать в едином кластере, когда версии серверов входящих в кластер - различны. Это позволяет произвести миграцию на новую версию серверов без остановки кластера.

В Spring подобное тоже реализуется, но это потребует усилий. Ибо нужно заранее просчитать такой вариант и подготовиться.

svenomОк, ИМХО, так ИМХО.это мое мнение сложившееся за то время пока возможности были в Spring и отсутствовали в JavaEE. И поддержанное некоторыми Sun-инженерами. Когда еще был Sun.

svenomВы можете пояснить, почему оно не будет работать? И как спринг магическим образом эту проблему решает? ты прав :) спринг это делает удобным. посмотрев что удобно JPA использовать в WAR без дополнительного секса - это перенесли в JavaEE. Опять же я не говорю, что это принципиально не удобно. Мысль, что идея EJB Lite была навеяна под вилянием Spring.

svenom
Class B = new ClassB();
b.call();

1) Определяли ли мы в контексте бин, соответствующий классу B? (Моя догадка: нет)
2) Загружен ли у нас класс B в JVM по итогам работы сниппета выше? (Моя догадка: да)
Еще раз - спринг вообще никак не управляет загрузкой компонентов.Пример довольно кособок увы. А где применение IoC? Или вы EJB через new создаете?

В данном примере Spring вообще не нужен как и JavaEE.

Теперь вас один вопрос:
Вы Spring хотя бы год-два в продакшен проектах использвали? (Моя догадка: нет).

svenom



Попробую набрость прямо здесь пример (в виде псевдо-кода).



Теперь конфиг:



Вопросы:
будет ли класс B загружен класслоадером? очевидно нет - не одного запроса на загрузку не пошло.
почему в вашем случае класс B был загружен? очевидный ответ - класс B был инстанциирован напрямую.

PS сорри если где криво набросал - писать код в браузере то еще удовольствие.

svenomЯ выше приводил мотивацию использования серверов приложений. Их мотивация мне не известна, вполне вероятно, как и вам. Состояние рынка труда я привел выше - делайте выводы, что сдувается, а что нетИх мотивация мне понятна :) поработав и с тем и с другим я сделал выводы.

рынок труда вещь странная - ее нужно анализировать оченьаккуратно. к примеру у нас в вакансиях обычно значятся Tomcat, JBoss, WebSphere. Вы нас наверное во все три группы впишите... только проектов на Tomcat+Spring около десятка, а WebSphere - один. JBoss вообще указан как самый часто используемый ибо флагман открытых АппСерверов, но у нас он не применяется.

justforsqlruНу т.е. как я и говорил апп сервера - это понты ?Эм. Это однобокое понимание проблемы.

АппСервера имеют свои преимущества, кастомные решения на Spring - свои.

Если мне поставят решение собрать кластер "по быстрому" - я соберу на JBoss минут за 20 с учетом скачивания и инсталляции.
А если "по грамотному", то я же буду долго и вдумчиво медитировать над конфигурацией кластера и сделаю за месяц на Spring с нагрузочным тестированием и проверкой сколько параллельных обращений он выдержит.

Есть и нюансы типа того, что GWT на некоторых АппСерверах не дружит с JPA Entity. Т.е. чтобы передать данные на клиента их приходилось перекладывать в вид промежуточных DTO. Баг довольно известный. Потому при работе с GWT я возьму Spring.

svenomМожно ссылочку на эту "возможность" спринга? Спринг мне может кластер организовать?Спринг это конструктор. Под него можно подложить EhCache или Terracotta.

svenomМожете привести критерии "странности" проекта?то что не может быть выполнено в рамках WAR-ника

grasoff.netVoDAСервера приложений - это собранные за вас самосвалынет, их можно тюнить.Я специально более гротескные примеры давал, чтобы можно было проще понять.

Конечно АппСервера можно тюнить. Тот же JBoss имеет несколько заранее подготовленных конфигураций для разных случаев.