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