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核心的理解了。

SOA实践方面的资源（本文参考了大量下面所列的资源）：
Getting a little closer to SOA
Are objects with behavior bad for SOA?
Udi Dahan - The Software Simplist
Hernan de Lahitte's blog