Плюсы / минусы различных стратегий упаковки Java - PullRequest
5 голосов
/ 30 января 2012

Допустим, я пишу бэкэнд Java для некоторого инструмента GUI (Swing). Этот бэкэнд будет состоять из множества различных типов EJB-компонентов для промежуточного программного обеспечения / бизнес-логики, а также некоторых веб-сервисов, которые фильтруют и перенаправляют запросы на эти EJB-компоненты.

Что касается упаковки и развертывания, у нас есть несколько возможных стратегий:

  • 1 монолитный сервер приложений EAR / 1 - упаковать все EJB-компоненты в JAR-файлы, а веб-службы - в WAR-файл и упаковать их все в 1-й монолитный EAR; этот EAR затем развертывается на сервере приложений (скажем, GlassFish)
  • Многие крошечные сервер приложений EARs / 1 - упаковывают каждый компонент (каждый EJB и каждый веб-сервис) в свой собственный JAR / WAR, а затем каждый JAR / WAR в свой собственный EAR; таким образом, между компонентом и EAR существует соотношение 1: 1; каждый EAR затем развертывается на том же приложении сервер
  • Множество крошечных EAR / Множество серверов приложений - то же, что и выше, за исключением того, что каждый "крошечный" EAR развертывается на своем собственном сервере приложений; таким образом, между компонентом и сервером приложений существует соотношение 1: 1
  • Нет EAR / Множество серверов приложений - то же самое, что и выше, за исключением удаления "промежуточных" EAR и просто развертывания каждого упакованного JAR / WAR на свой собственный сервер приложений

Каковы плюсы / минусы каждой из этих 4 стратегий? Некоторые из них более безопасны? Производительный? Более благоприятны для кластеризации / репликации? Являются ли некоторые из этих стратегий просто глупыми?!?

Заранее спасибо!

1 Ответ

2 голосов
/ 30 января 2012

Упаковка приложений никак не влияет на безопасность. число предоставляемых услуг, отдельных серверов, конечных точек запросов и т. Д., А также то, каким образом службы обращаются к ресурсам, которые должны быть защищены, - это то, что касается безопасности, а не то, как что-то упаковано.

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

В частности, вы увидите:

  1. Масштабируемость - многие мелкие элементы более гибки в масштабировании, поскольку вы можете масштабировать каждый фрагмент самостоятельно.
  2. Сложность. Объединение небольших служб позволяет значительно упростить отдельные службы, поскольку им приходится беспокоиться о меньшем количествевещи
...