| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > jboss или jboss + tomcat |
| Автор: Nookiem 27.4.2011, 22:53 |
| Доброго времени суток. Я новичок, объясните как лучше сделать. Начал делать такую связку, на tomcat'e сервлеты, они конектятся к jboss as - ejb, получается 2 архива диплоится, один *.war на tomcat, второй *.ear на jboss. Я использую Intellij IDEA, все автоматом запускает и деплоится, без проблем и даже работает. Но попробовал я задеплоит и war и ear оба на jboss, получается тоже все работает... тока теперь без tomcat. Не могли бы вы мне пояснить у какого подхода какие преимущества? |
| Автор: MisterCleric 28.4.2011, 08:53 |
| Привет. А секрет таков: в JBOSS, как полноценный J2EE сервер, встроен сервлет-контейнер, который является (внимание!) - TOMCAT. Разницу в подходах опишу чуть позже |
| Автор: MisterCleric 28.4.2011, 09:45 |
| Разделение приложения на разные независимые модули, которые можно задеплоить индивидуально делают в том случае, когда хотят защититься от доступа из вне. И тогда размещают разные компьютера с серверами приложений в милитаризированной и демилитаризированной зоне соответственно. На firewall между ними дают разрешение на доступ конкретному компьютеру на конкретный порт из демилитаризированной зоны в милитаризированную. Это один вариант. Второй таков: У тебя, на пример, на JBOSS, крутится очень много всяких нагруженный долгоживущих бизнес-процессов. А из клиента (tomcat) редко проходят запросы на уровень бизнес логики (EJB). Тогда мы выигрываем в производительности, что разные процессоры на разных машинах занимаются разными задачами. И есть еще вариант - политический. Мы разделяем свои приложения на BL (слой бизнес логики) и PL (слой представления - web-клиент). И поставляем заказчику два JBOSS, за что наше приложение становится дороже (по крайней мере представляется так заказчикам). Минусы такого подхода очевидны: - нужны два (и более) компьютера - нужно саппортить два сервера приложений - да и при Remote вызовах происходит сериализация и десериализация передаваемых данных. Второй вариант, естественно, имеет все обратные минусы и плюсы от первого подхода. Какой вариант выбирать при разработке приложения не всегда понятно на этапе проектирования: одни утверждают, что лучше сразу разделить, так как потом можно эти модули разрабатывать отдельно, но как показывает практика - любое желание заказчика обычно затрагивает все слои приложения. (Может неправильно что-то проектирую?..) Другие говорят, что разрабатывайте все сразу - легче потом с релизами и саппортом. Но как по моему мнению, то лучше проектировать, а потом разрабатывать так, чтобы разбиение на модули было макисимальным. Т.е. как можно больше дробить свое приложение на какие-то независимые самодостаточные модули, чтобы их потом можно было деплоить как на один сервер приложений так и на разные, а связь между ними должна быть "loosely coupled". Но это уже отдельная история... |