Варианты связи между WAR в одном EAR

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

РЕДАКТИРОВАТЬ: Причина связи заключается в том, что модули используют некоторые общие функциональные возможности, и мы хотим разместить эти функциональные возможности только в одном месте, поскольку это требует значительного количества ресурсов. Также для этого требуется синхронное общение.

11.12.2008 14:34:07
Для двух войн общаться без веб-сервисов явное требование кажется немного странным - если вы можете сказать, почему у вас есть это требование?
cynicalman 11.12.2008 14:45:07
cynicalman: WS не исключены - операционист попросил другие альтернативы.
BraveSirFoobar 11.12.2008 14:53:57
Я второй @ cynicalman - зачем вам общение?
johnstok 11.12.2008 15:00:22
4 ОТВЕТА
РЕШЕНИЕ

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

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

Если клиент службы и сама служба находятся внутри одного и того же уха, вы можете избежать некоторых издержек, вызвав службу «напрямую», например, используя функцию родительского контекста Spring: http://springtips.blogspot.com/2007/06/ using-shared-parent-application-context.html, но я бы не советовал уплощать службу, потому что вы потеряете различные преимущества, которые, в первую очередь, обеспечивает обслуживание, такие как управление, управляемость и т. д.

1
11.05.2009 16:23:31

На ум приходят две вещи

  1. Есть JMS для отправки сигналов.
  2. EJB может записывать общую информацию.
  3. Библиотека JAR в каталоге lib EAR.

Если вам просто нужны общие методы, 3 - это то, что вы хотите. Но ваши точки редактирования говорят мне, что у вас есть общая функциональность, которая работает с общими данными. Например, у вас есть пользовательские записи, которые доступны и обновляются как в WAR-файлах. Если это так, вы хотите EJB.

0
11.12.2008 22:51:06
На самом деле нет необходимости использовать любой из них для доступа к общему ресурсу, когда это можно сделать напрямую. Это просто добавляет накладные расходы.
Robin 11.12.2008 17:37:55

Почему бы не поместить общие классы в JAR и работать с ними напрямую? Или чуть более тяжелый вес делают обычные занятия сессионными бобами?

0
11.12.2008 15:11:35
Разве у каждой WAR не было бы своего собственного сеанса и не было бы доступа к сеансам другого веб-приложения / WAR?
matt b 11.12.2008 15:30:44

Поскольку ваши изменения, по-видимому, подразумевают, что обмен данными между WARS на самом деле не требуется, но оба должны получать доступ к одним и тем же общим ресурсам. Самым простым решением было бы поместить файлы JAR для этого ресурса в EAR и добавить зависимость для этих файлов JAR в оба веб-проекта, чтобы они использовали общий ресурс.

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

Просто помните, что общий ресурс должен быть потокобезопасным.

Подобный вопрос здесь .

1
23.05.2017 11:51:59