Опции связаться между ВОЙНАМИ в том же EAR
Это работает для меня:
<?php
$login = 'login';
$password = 'password';
$url = 'http://your.url';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_setopt($ch, CURLOPT_USERPWD, "$login:$password");
$result = curl_exec($ch);
curl_close($ch);
echo($result);
4 ответа
Во-первых, вы должны четко понимать, чем вы делитесь. Вы должны различать сервис и библиотеку. Библиотека позволяет вам использовать общие функции, это то, чего вы добиваетесь, например, используя библиотеку log4j. В этом случае вы устанавливаете log4j в каждом проекте, который его использует. С другой стороны, у вас может быть централизованная служба ведения журнала, которая имеет собственную конфигурацию ведения журнала и позволяет вам управлять ею из одного места. В этом случае вам нужно поделиться службой.
Вы можете поделиться библиотекой, поместив сосуд внутри каждой войны или в ухо. Вы можете поделиться услугой, будучи ее клиентом. Итак, ваши веб-службы могут использовать другую службу. В этом случае одна веб-служба является клиентом другой, достигая композиции службы (общий шаблон в корпоративной разработке)
. Если и клиент службы, и сама служба находятся в одном ухе, вы можете избежать некоторых накладных расходов, вызвав службу. «Напрямую», например, используя функцию родительского контекста Spring: http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html но я бы не советовал сглаживать обслуживание, потому что вы потеряете различные преимущества, которые в первую очередь предоставляет обслуживание, такие как управление, управляемость и т. д.
Почему бы не помещать общие классы в JAR и работу с ними непосредственно? Или немного более тяжелый вес делает общие бобы сессии классов?
Так как Ваше редактирование, кажется, подразумевает, что связь на самом деле не требуется между ВОЙНАМИ, но обеими потребностями получить доступ к тем же совместно используемым ресурсам. Простое решение состояло бы в том, чтобы поместить банки для этого ресурса в EAR и добавить зависимость для тех банок к обоим веб-проектам, таким образом, они используют совместно используемый ресурс.
Если существует код с сохранением информации в обоих веб-проектах, которые должны быть обновлены, то Ваша единственная опция состоит в том, чтобы позвонить сервлету для веб-проекта (предполагающий, что код с сохранением информации содержится в рамках веб-проекта).
Просто помните, что совместно используемый ресурс должен быть ориентирован на многопотоковое исполнение.
Подобный вопрос здесь.
Две вещи приходят на ум
- Существует JMS для отправки сигналов.
- EJB мог записать общую информацию.
- Банка lib в каталоге lib EAR.
Если Вам просто нужны совместно использованные методы, 3 то, что Вы хотите. Но Ваши монтажные точки говорят мне о совместном использовании функциональности, которая воздействует на совместно используемые данные. Например, у Вас есть пользовательские записи что оба ВОЕННЫХ доступа и обновление. Если так, Вы хотите EJB.