Агрегированный шаблон в сервисе SOA

Question

Я не уверен, что это правильное слово, но на моем предприятии у нас есть два типа услуг: совокупный сервис и элементарный сервис.

Агрегированные сервисы идентифицируются по их интерфейсам, где вход - это список объектов запроса, а ответ - это список.Предполагается, что служба обрабатывает список запросов взаимоисключающим образом, т. Е. Если обрабатывается один объект запроса, служба все равно должна продолжать обрабатывать следующий объект запроса.Обычная причина - повышение производительности - вместо того, чтобы потребитель вызывал сервис в цикле, он просто создает список объекта Request и вызывает сервис только один раз.Другое так называемое преимущество - вы можете группировать несвязанные запросы в один запрос.

Кто-нибудь также использует аналогичные агрегированные услуги?Если да, не могли бы вы предоставить дополнительную информацию / или преимущества этого подхода.

Answer 1

Это обычная практика в разработке услуг, идея заключается в том, что всякий раз, когда вы пересекаете границу обслуживания, вы несете расходы. Помните, что SOA - это передача сообщений между сервисами, а не ссылками на объекты, цена за эту несвязную доброту пересекает границу.

Поэтому, когда вы пересекаете границу, вы должны стараться выжать как можно больше.

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

Вот несколько ссылок на полезные ресурсы о некоторых других идеях проектирования SOA-сервисов.

Я бы посоветовал вам прочитать статьи Thomas Erl и Roger Sessions, это даст вам твердое представление о том, что такое SOA.

Построение SOA

Шаблон проектирования SOA

Достижение целостности в SOA

Почему ваша SOA должна быть похожа на VW Beetle

SOA для вашего босса

Производительность службы WCF