Ресурсы моделирования развертывания Java EE

Question

Я ищу книги/онлайн-ресурсы о развертывании приложений Java EE. Особенно я хочу знать шаблоны, когда использовать локальные интерфейсы, когда удаленные (сколько узлов мне нужно?). Ключевой вопрос - использовать одиночные EAR (EJB и WAR) или отдельные узлы для EJB и WAR.

Ресурсы, которые я нашел, устарели, они сосредоточены на EJB2 или design patterns. Меня интересуют новые технологии, такие как EJB3, Spring или Seam.

Answer 1

Во-первых, для серверов приложений, таких как WebSphere, у вас может быть один EAR, который содержит одну (или более) WARS и один (или более) JJB JJB, и каждая WAR и JAR может быть развернута на разных серверах. Следовательно, это не должно быть вопросом о том, сколько EAR, шаблон развертывания является отдельной проблемой. Вы можете решить создать два EAR, но это не обусловлено спецификацией Java EE как таковой.

Во-вторых, во время разработки вам необходимо решить, должны ли ваши EJB предоставлять удаленный интерфейс. Это прежде всего дизайнерское решение. API, которые подходят для локального вызова, необязательно могут быть пригодны для удаленного вызова. Например, очень мелкозернистый API может повлечь чрезмерное превышение служебных данных - если -, выставляя удаленный api, тогда мы склонны выступать за крупнозернистые API.

В-третьих, EJB 3.0 принципиально не изменяет архитектурные и дизайнерские решения относительно того, подходит ли шаблон удаленного развертывания. EJB 3.0 дает гораздо более простую модель программирования по сравнению с EJB 2.x, поэтому гораздо меньше кода/XML для записи, но с точки зрения результирующего шаблона развертывания нет никаких реальных изменений в том, что происходит с точки зрения обработки или байтов, проходящих через сети , Не являясь разработчиком Spring или Seam, я не могу быть уверенным, что Spring или Seam будут говорить то же самое, но я предполагаю, что фундаментальные архитектурные решения, такие как удаленные или нет, будут технологически агностическими.

Итак, какие силы могут привести к развертыванию Web и EJB для разных уровней?

Совместное расположение: простота, меньшее количество отказов, уменьшенная сеть над головой.

DITributed EJB/WAR: раздельная масштабируемость (вы можете добавить дополнительную мощность для уровня Web или уровня EJB отдельно), поддержка нескольких клиентов, одна и та же бизнес-логика может быть подвержена другому клиенту (что также может привести к масштабируемости потребности), незаменимые релизы обслуживания (патчи в Интернете не нарушают EJB).