是否支持SOA的方法组成？ [英] Does SOA support method composition?

问题描述

这里有采取一个很好的例子的：

  

CRUD x业务逻辑接口。假设你正在使用发票。每个发票由一个InvoiceHeader和一个或多个InvoiceLine的。如果你使用一个CRUD接口的发票，你会先打电话CreateInvoiceHeader手术创造InvoiceHeader然后几个AddInvoiceLine操作，以添加所有InvoiceLines - 那就是低水平的CRUD方法。但是，如果你实现在服务端的业务逻辑，你会打电话给单CreateInvoice和一个复杂的对象图（与所有行头）传递到服务，创建并添加需要的是什么。

为什么一个完全合法的方式组成

  VAR发票=
    Service.CreateInvoice（
        Service.CreateInvoiceHeader（...）
        {
            Service.CreateInvoiceLine（...）
            Service.CreateInvoiceLine（...）
        }
    ）
 

在SOA中使用时
1. 从性能上看绝对可怕吗？
2. 在不能自动转化为一个服务调用？

为什么必须在一，而不是创建一个复杂的对象图，并将其发送给服务方法

  VAR InvoiceDTO =新InvoiceDTO（
    新InvoiceHeaderDTO（...）
    {
         新InvoiceLineDTO（...）
         新InvoiceLineDTO（...）
    }
）

VAR发票= Service.Create（InvoiceDTO）
 

和服务必须遍历整个图，并调用一样的服务方法来组装所产生的发票？

有没有办法使用方法，组成创建复杂的结果，而无需使用复杂的对象图作为数据传输？

解决方案

答案是，有一个SOA架构的性能瓶颈是，往返是昂贵的。他们增加延迟，工作网络和CPU的开销。

有几个基本的缓解策略。

1. 把事情互相交谈并拢。在同一进程中是最佳的。在同一台机器上有很大帮助。在数据中心附近还是有帮助。这种方法的缺点是多少，你可以放在一起是由机器尺寸的限制。

2. 中断工作纳入更细致的块，以尽量减少多少往返会发生。这种方法的缺点是，离开了相互作用可能会更复杂（你的复杂的对象图就是一个例子）。

3. 使用更有效的协议。真正聪明的人嘲笑XML在上个世纪的RPC协议。聪明的人在十年前，这是愚蠢的实现。很多企业仍然使用它。停止。使用JSON，头儿原，还是其他什么东西。唯一不足的是让人们同意做什么，而不是组织的挑战。

4. 请在并行调用。也就是说，不发送50个请求一次一个。发送它们放在一起，处理他们，当他们回来。不利的一面是，这大大增加了code复杂性，不仅有利于与延迟 - 资源消耗没有帮助

您不必在这些选项中进行选择。公司以良好的SOA架构（如谷歌）做4。

这是说，回到你的问题。有一个中间地带。而不是拨打电话与一个复杂的对象，你可以做的就是打个电话来创建一个对象，进行各种呼叫建立的数据结构，然后拨打电话，以实际发送。在code看上去完全像你写了低级别的CRUD接口，只可惜是在最后一个 Service.Send（）通话实际上将关闭请求。

There is a good example taken 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.

Why a perfectly legal method composition

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

1. is absolutely awful from performance point of view when used in SOA?
2. can't be translated automatically into a single Service call?

Why must one instead create a complex object graph and send it to the service method

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

var Invoice = Service.Create(InvoiceDTO)

and the Service must traverse the whole graph and call just the same Service methods to assemble the resulting Invoice?

Is there any way to use method composition to create complex results without using complex object graphs as data transport?

解决方案

The answer is that with a SOA architecture your performance bottleneck is that round trips are expensive. They add latency, work for your network and CPU overhead.

There are several basic mitigation strategies.

1. Put things that talk to each other close together. In the same process is optimal. On the same machine helps a lot. Close by in the data center still helps. The downside of this approach is that how much you can put together is limited by machine size.

2. Break work into more granular chunks to minimize how many round trips will happen. The downside of this approach is that the interactions left are likely to be more complicated (your "complex object graph" is an example).

3. Use more efficient protocols. Really smart people laughed at XML as an RPC protocol in the last millennium. Smart people realized a decade ago that it was stupid. A lot of organizations still use it. Stop. Use JSON, Cap'n Proto, or something else. The only downside is the organizational challenge of getting people to agree on what to do instead.

4. Make calls in parallel. That is don't send 50 requests one at a time. Send them together and process them when they come back. The downside is that this adds considerably to code complexity and only helps with latency - resource consumption is not helped.

You do not have to choose among these options. Companies with good SOA architectures (eg Google) do all 4.

That said, back to your question. There is a middle ground. Rather than making a call with a complex object what you can do is make a call to create an object, make various calls to build up the data structure, and then make a call to actually send it. The code looks exactly like what you wrote with the low level CRUD interface, except that there is a Service.Send() call at the end which actually sends off the request.

这篇关于是否支持SOA的方法组成？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！