登录模块加载中...
会员投稿 投稿指南 今天是:
打印本页 | 关闭窗口 | 双击滚屏 您的位置首页>>网页制作学习园地>>NET教程>>WebService开发>>浅析Web Service数据转换器对象
浅析Web Service数据转换器对象
来源: ‖ 作者: ‖ 点击: ‖ 时间:12-09-26 11:44:21 ‖ 【 】‖ 我要投稿

 

【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。

Data Transfer Object与消费者服务的对应关系

    由于消费者服务可能会同时与很多领域的业务对象进行交互,因此如果为每个业务领域的调用设计一个独立的DTO,这样会引发消费者服务与过多的DTO对象间产生耦合,这时候可以考虑增加一个类似DTO容器的集合类型来管理,由于DTO中的数据都是临时性的,因此这个DTO集合包括的内容可以做的大一些(,毕竟数据也都是中转而已),然后这个集合同时服务于多个消费者服务,每个消费者仅仅从这个集合中获取自己需要的一组DTO对象。演化关系如下。

1:1:1组合

    这种方式适于目标服务相对数量很少,而且调用中需要用到“打包”情况不多的情况,采用一事一议的办法,为每类需要“打包”的业务领域对象包装一个DTO,客户程序调用这个DTO。(如果业务领域对象非常有限的时候,也可以采用一个DTO通过几组get()/set()分别的办法。)

1:N:N组合

    当一个客户应用的需要同时使用多个Web服务的内容时(尤其是根据某些条件,有选择的使用时),可以考虑建立一系列的DTO对象,分别对应不同的业务领域对象。

1:1:N:N组合

    当消费者服务需要同多个DTO交互的时候,为了简化这种耦合关系,提取一个集中的DTO集合类型,由他集中管理某个消费者服务需要的一组DTO对象,这样把消费者服务与DTO间1:M的关系,变成1:1:M。不过这由于DTO集合相对更为固定,因此消费者服务自身不需要根据DTO频繁修改。

M:1:N:N组合

    对于一个企业而言,DTO集合可以不仅仅面向一个消费者服务使用,它本身的作用就是一个DTO字典,因此可以把DTO集合适当扩大,令其可以同时服务与多个不同的消费者服务。

部署设计考虑

    与DTO不同,DTO Collection可以位于生产者服务端,也可以位于消费者服务端,因为它仅仅负责管理一组DTO对象的引用,考虑到组件实际执行能力的不同,消费者服务方可以仅仅保存抽象的DTO接口,而在具体业务领域对象一端保存实体DTO实现对象。

加入收藏:  加入收藏夹  | 发送给好友:  发送给好友
责任编辑:admin
相关文章列表
请文明参与讨论,禁止漫骂攻击。  
网友评论