Я думаю, что знаю ответ на этот вопрос, но я только заметил, что кто-то делает прямо противоположное - кто очень опытный разработчик, они просто плохой день?
Q: Можно ли вызвать службу из службы в SOA-архитектуре?
Я подозреваю, что нет, но я все равно спрошу...
Определенно да. Этот шаблон SOA обычно называют хореографией, где обрабатывается один веб-сервис, а затем передает сообщение другому по конвейеру обработки. Google это и вы найдете хорошие ссылки.
Другим случаем может быть более техническая причина, такая как маршрутизация, где у вас есть веб-службы frontend, которые направляют ваши сообщения в разные бэкэнд-сервисы на основе политики безопасности, контента, подключения различных технологий или транспортного протокола и т.д.
Я не могу думать ни о какой причине, почему нет. Я могу думать о нескольких причинах, по которым услуга может вызвать другую услугу. Я архивировал и реализовал несколько сервисов, которые это делают. Я также знаю другие архитектуры, которые создали такую систему.
Ответ на это, как всегда, "это зависит...", позвольте мне объяснить, что я имею в виду.
Вызов другой службы в SOA - это, конечно, абсолютно приемлемая вещь, поэтому в основе SOA лежит возможность создавать новые вещи из существующих сервисов.
Более важной частью является то, как вы называете сервисы, рассмотрите систему SOA, в которой несколько служб взаимодействуют в цепочке вызовов, каждая из которых завершает другую транзакционную область. Выполнение такого рода операций без тщательного планирования окажет огромное влияние на производительность вашей системы. Та же цепочка вызовов, разработанная с использованием хорошо распределенных служб, которые ограничены в правильной единице работы, страдает меньше.
Рассмотрим системную надежность, в типичной архитектуре одна услуга имеет тенденцию становиться более популярной, чем другие, и приземляется, когда многие другие службы называют ее. Сбой этой службы снижает всю систему из-за того, что все другие службы зависят от вызова этой услуги.
Учитывайте разницу между синхронными и асинхронными вызовами, когда вы используете что? Это влияние каждого?
Как вы проектируете и разделяете службы, чтобы ограничить стоимость пересечения границы обслуживания при каждом вызове?
Множество вопросов, но если вы посмотрите вокруг, есть много мест, где можно найти ответы, я предлагаю начать с них.
Я бы предложил вам прочитать статьи Томаса Эрла и Роджера Сессий, это даст вам твердую информацию о том, что такое SOA.
Почему ваша SOA должна быть как VW Beetle
подумайте об архитектурной цели "разделения проблем". вместо того, чтобы каждый сервис знал, как делать все, он может полагаться на другие специализированные службы для общих частей функциональности.
У меня есть другой сценарий. Что делать, если вы хотите внедрить кластеризацию уровня обслуживания в своей SOA? Например, говорят, что служба сохранения сохраняется на одном компьютере и отвечает за обработку всех задач сохранения в кластере. Таким образом, на другой машине, которая нуждается в функциональности сохранения, необходимо подключиться только к этой машине (игнорировать сбойный коэффициент).
Теперь при входе в систему, если служба пользователя имеет экземпляр службы Persistence напрямую, вы не сможете реализовать кластеризацию уровня обслуживания.
У нас есть наше промежуточное ПО SOA, и я напрямую звонил в службу. Но когда мы реализовали кластеризацию уровня обслуживания с использованием JMS/ActiveMQ, мы столкнулись с проблемой для этих взаимосвязанных сервисов.