Содержит ли метод поддержки SOA?

Question

Существует хороший пример, взятый here:

CRUD х Бизнес-логика интерфейса. Предположим, что вы работаете со счетами-фактурами. Каждый счет-фактура состоит из InvoiceHeader и одной или нескольких InvoiceLine. Если вы используете интерфейс CRUD для счета-фактуры, вы сначала вызываете операцию CreateInvoiceHeader для создания InvoiceHeader, а затем нескольких операций AddInvoiceLine, чтобы добавить все InvoiceLines - это подход CRUD на низком уровне. Но если вы реализуете бизнес-логику со стороны службы, вы будете называть единый CreateInvoice и передавать в объект сервис-объект (заголовок со всеми строками) для создания и добавления того, что необходимо.

Почему совершенно законна композиция метод

var Invoice = 
    Service.CreateInvoice(
     Service.CreateInvoiceHeader(...), 
     { 
      Service.CreateInvoiceLine(...), 
      Service.CreateInvoiceLine(...) 
     } 
    ) 

1. абсолютно ужасно с точки зрения производительности при использовании в SOA?
2. не может быть автоматически переведен на один служебный вызов?

Почему необходимо один вместо создания сложного объекта графа и отправить его в сервисный метод

var InvoiceDTO = new InvoiceDTO(
    new InvoiceHeaderDTO(...), 
    { 
     new InvoiceLineDTO(...), 
     new InvoiceLineDTO(...) 
    } 
) 

var Invoice = Service.Create(InvoiceDTO) 

и служба должна пройти весь граф и называть только те же методы обслуживания, чтобы собрать полученный счет-фактуру?

Можно ли использовать композицию метода для создания сложных результатов без использования сложных графов объектов в качестве переноса данных?

Answer 1

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

Существует несколько основных стратегий смягчения последствий.

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

2. Перерыв на работу в более узкие куски, чтобы свести к минимуму количество поездок в оба конца. Недостатком этого подхода является то, что оставшиеся взаимодействия, вероятно, будут более сложными (примером может служить ваш «граф сложных объектов»).

3. Используйте более эффективные протоколы. Действительно умные люди смеялись над XML как протокол RPC в прошлом тысячелетии. Умные люди поняли, что десять лет назад это было глупо. Многие организации все еще используют его. Стоп. Используйте JSON, Cap'n Proto или что-то еще. Единственным недостатком является организационная задача заставить людей договориться о том, что делать вместо этого.

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

Вам не нужно выбирать один из этих вариантов. Все компании с хорошей архитектурой SOA (например, Google) выполняют все 4.

Это же, вернемся к вашему вопросу. Есть средняя почва. Вместо того, чтобы делать вызов сложным объектом, вы можете сделать вызов для создания объекта, сделать различные вызовы для создания структуры данных, а затем сделать вызов, чтобы отправить его на самом деле. Код выглядит точно так же, как вы написали с интерфейсом CRUD низкого уровня, за исключением того, что в конце есть вызов Service.Send(), который фактически отправляет запрос.