【IT168 管理】

意图 

    减少消费者服务（Service）为了准备一次操作的消息（Message）频繁调用生产者服务的负载，简而言之就是把多次调用“打包”。

问题 

    在Fowler, Martin的《Patterns of Enterprise Application Architecture》中提过这样一个应用情景： 

    “When you're working with a remote interface, such as Remote Facade, each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program deed, it's often impossible with languages such as Java that return only a single value.” 

    当我们调用一个远程接口的时候，一般而言代价相对比较大，需要通过一次调用中传递更多数据的办法减少调用次数。虽然一次返回多个参数是一个解决办法，但对于程序而言比较不可取，对于如Java之类的语言返回多个参数又不可能。 

    在SOA环境下，这个调用“打包”的需求更明显，主要原因如下：

•SOA的分布式环境，尤其当调用涉及到Internet调用时，时延更为明显。

•为了服务接口的通用性，很多企业应用都会采用通用的数据参数类型（例如：XmlDocument、string等），但对于最终的调用者而言很多数据对他没有必要，很可能消费者服务需要的就是其中某一个Node，甚至是某个Node的某些Attribute，为了减少不必要的数据传递，需要考虑采用某种措施对数据进行前置处理。

•消费者服务为了执行某个功能可能需要同时调用多个生产者服务。 

    同时这个过程可能是双向的，既存在消费者服务多次从生产者服务获取消息，也存在同时向多个生产者服务发送消息的情况，尤其在异步Web Service情况下，需要进行一个类似组播方式的1：N的消息通知。即总体上看，同时存在write和read操作。

讨论

    为了提高消费者服务的使用效率，这类问题可以通过引入一个服务端数据传输对象解决（DTO：Data Transfer Object），由他将多次调用的工作“打包”成一次调用，他的主要作用是write / read数据，DTO将这些数据作为消费者服务所需要的消息参数，所有的参数都是临时的。从职能上看，DTO同时负责write和read，因此虽然上面3个图有多读、多写、多读多写三种方式，但对于DTO而言，设计出一组R/W的Property或Indexer即可。（对于Java等没有Property和Indexer的语言，可以通过一组set（）/get（）实现，两种实现见附件部分。） 

    由于DTO的主要目的是完成分布式环境下的一次性调用要求，因此如果部署上每个生产者服务本身位于不同的物理服务器的时候，DTO本身并不会对性能体带来明显的提升，整个DTO会退化为一个近似多次调用的Remote Facade。