Звонки с уровня Orchestrating в SOA?

Question

Принципы сервисной ориентированной архитектуры site говорит, что Service Composition является важной вещью в SOA. Но Service Loose Coupling также важна.

Означает ли это, что «Орфографический слой» должен быть единственным, кому разрешено совершать вызовы служб в системе?

Как я понимаю, SOA, «Orchestrating layer» «склеивает» все сервисы вместе в одно приложение. Я попытался изобразить это на Fig.A и Fig.B.

Разница между ними заключается в том, что на рисунке.A приложение составлено из сервисов, и вся логика выполняется в «Orchestrating layer» (все вызовы услуг выполняются только из «Orchestrating layer»). На рисунке B приложение составлено из служб, но один сервис вызывает другую услугу.

Является ли архитектура на Fig.B нарушением принципа «Service Loose Coupling» SOA? Может ли служба вызвать другую службу в SOA? И в более общем плане, может ли архитектура на Fig.A считаться выше, чем на рис. B, с точки зрения обслуживания свободной связи, абстракции, повторного использования, автономии и т. Д.?

Я предполагаю, что архитектура A гораздо более универсальна, но она может добавить некоторые ненужные передачи данных между слоем «Orchestrating layer» и всеми вызываемыми сервисами.

Answer 1

Предполагая, что все, что ниже услуг 1 и 2 инкапсулируется за их контрактов, то они слабо связаны между собой. Однако B не использует способность оркестрового уровня освобождать Службу 1. Нет никаких явных прав или недостатков A против B, но есть компромиссы. Рис. A требует еще нескольких усилий по разработке, потому что детали того, что B возвращает A, должны быть извлечены до уровня оркестровки - и если есть списки данных, то B необходимо разрешить передачу параметров параметров в качестве критериев. Это, однако, позволяет svc 1 ничего не знать о svc 2. Поэтому, если услуги принадлежат и управляются двумя разными командами, то A собирается позволить этой команде работать автономно. Например, если svc 1 является службой информации о клиентах (CIS), а svc 2 является платежным сервисом, тогда уровень оркестровки может сшивать данные CIS вместе с Svc 2, чтобы вернуть список имен клиентов и их последние платежные данные. С фиг. A соединение с памятью используется в слое оркестровки для выполнения строчки. Затем клиенты называют уровень оркестровки. С помощью B клиент может напрямую позвонить в службу 1, но если вы начнете разрешать услуги звонить друг другу, вы можете получить неприятный график зависимости, включающий возможность повторных вызовов. Если ваша команда мала и владеет как svc 1 & 2, тем они могут отслеживать эти зависимости. Однако, когда у вас есть разные команды, вы можете обнаружить, что зависимости не легко известны или хорошо управляются в B.