SOA 是否支持方法组合？

Question

举了一个很好的例子here:

CRUD x Business logic interface. Suppose that you are working with Invoices. Each invoice consists of an InvoiceHeader and one or more InvoiceLine. If you use a CRUD interface for invoice you will first call CreateInvoiceHeader operation to create InvoiceHeader and then several AddInvoiceLine operations to add all InvoiceLines - that is low level CRUD approach. But if you implement business logic on the service side you will call single CreateInvoice and pass a complex object graph (header with all lines) to the service to create and add what is needed.

为什么是完全合法的方法组合

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

在 SOA 中使用时从性能的角度来看绝对糟糕吗？
无法自动转换为单个服务调用？

为什么必须创建一个复杂的对象图并将其发送到服务方法

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

var Invoice = Service.Create(InvoiceDTO)

并且服务必须遍历整个图并调用相同的服务方法来 assemble 结果发票？

有没有什么方法可以在不使用复杂对象图作为数据传输的情况下使用方法组合来创建复杂的结果？

Answer 1

答案是，对于 SOA 架构，您的性能瓶颈是往返成本高昂。它们会增加延迟，为您的网络工作并 CPU 开销。

有几种基本的缓解策略。

将相互交谈的东西放在一起。在同一个过程中是最优的。在同一台机器上帮助很大。在数据中心附近仍然有帮助。这种方法的缺点是，您可以组合的数量受机器大小的限制。
将工作分成更细粒度的块，以尽量减少往返次数。这种方法的缺点是剩下的交互可能会更复杂（您的 "complex object graph" 就是一个例子）。
使用更高效的协议。真正聪明的人嘲笑 XML 是上个千年的 RPC 协议。聪明人十年前就意识到这是愚蠢的。许多组织仍在使用它。停止。使用 JSON、Cap'n Proto 或其他方式。唯一的缺点是让人们就应该做什么达成一致的组织挑战。
并行调用。那就是不要一次发送 50 个请求。一起发过去，回来处理。不利的一面是，这会大大增加代码的复杂性，并且只会有助于延迟 - 资源消耗无济于事。

您不必在这些选项中进行选择。具有良好 SOA 架构的公司（例如 Google）都做到了这 4.

也就是说，回到你的问题。有一个中间立场。您可以做的不是调用复杂的对象，而是调用创建对象，进行各种调用以构建数据结构，然后调用实际发送它。该代码看起来与您使用低级 CRUD 接口编写的代码完全相同，只是最后有一个 Service.Send() 调用实际发送了请求。

SOA 是否支持方法组合？

Does SOA support method composition?

architecture

algorithm

service

soa