Вызов сервисов из уровня оркестрации в SOA?

На сайте Принципов сервис-ориентированной архитектуры говорится, что композиция сервисов - важная вещь в SOA. Но также важна сервисная свободная муфта.

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

Насколько я понимаю, SOA, «уровень оркестровки» «склеивает» все сервисы вместе в одно программное приложение. Я попытался изобразить, что на Рис.А и Рис.Б.

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

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

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

Вызовы службы SOA


person skanatek    schedule 23.06.2012    source источник


Ответы (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.

person Robert-Ryan.    schedule 22.12.2012
comment
Ваш ключ возврата сломан? - person Alex; 26.11.2013