当前位置:编程学习 > XML/UML >>

SOA实践

答案:     SOA的理论已经够多了,也许我们可以来实践着在项目中采用SOA架构。
  
  下面来自我自己的经验和理解,一家之言。
  
  1、DTO
  
  Data Transfer Object,或者叫Entity、Data Object。DTO是指在一个对象里面只包含所表示的实体的数据,而不包含任何操作行为。传统的OOP理论认为建立这样纯粹只包含数据的实体类是不正确的,而SOA架构为了能够在分布的、异构的平台上能够顺利的传递数据,则正需要这样的DTO对象。
  
  SOA对DTO的要求是使用方式是:在系统的各个Layer之间传递的,就是DTO,从DAL到BLL,从BLL到各种Service Facade,从Service Facade到外面的服务消费者(包括PL),都传递着DTO。因为这个要求,DTO必须要可被序列化。
  
  2、Layer结构
  
  BLL是不直接对外公开的,对外公开的是在BLL之上的Service Facade,Service Facade里面通常只包含static方法,供服务消费者调用。Service Facade传递和返回的基本上都是DTO,比如:
  
  OrderInfo GetOrder(Int32 orderID);
  void UpdateOrder(OrderInfo order);
  
  OrderInfo就是一个DTO。
  
  3、Service Facade的通道多样性
  
  在作为对外的服务接口上,可能提供多种通道的界面,比如可以接收WebService、.Net Remoting、MSMQ、DCOM等等方式的调用,还可能是同步的、异步的调用。所以可能需要提供各种的Service Facade。
  
  ShadowFax通过双重Pipe解决这个问题,第一个管道专门接收各种各样调用请求,然后统一传递给第二个管道,第二个管道再通过调用BLL来处理请求,然后将结果传给第一个管道。
  
  4、每个Service尽量细化
  
  比如有一个Service,调用它必须对调用者进行验证,那么不如再做一个单独的Authentication Service来专门提供验证服务,因为这个单独的Authentication Service可能以后将可以提供给其他的Service使用。
  
  5、Service各自独立(解耦)
  
  可以想象,在一个大型的系统(甚至可以大到整个Internet)里面,如果每个模块、子系统都以Service的方式来提供给外部的服务消费者,那么各个模块和系统都是直接可扩展、可重用的。他们相互相对独立。
  
  好像太简单了一点哈,但这就是我对SOA核心的理解了
  http://blog.joycode.com/kaneboy/

上一个:“简”话设计模式(2)
下一个:架构设计中的方法学(2)——敏捷视图(1)

CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络,