嗯，先解释一下Enterprise Development Application Framework，EDAF是这个项目提供的一个企业级开发平台和框架，开发人员可以基于EDAF来进行企业级应用的开发。EDRA则是对使用EDAF进行开发的一个参考、描述、规范...
先看看EDRA的Architecture Overview图片：
EDRA可以算是非常典型的SOA架构。可以看到图上被分为了两大块，Service Interface和Service Implementation，根据名字我们就能够大致猜出它们各自的作用和地位。在实际的应用中，我们通常可以将Interface和Implementation部署到不同的Tier，以获得更好的扩展性。我们根据这张图来从上往下的走一遍吧。:)
首先，Client App发出一个Request给Service Interface，这个Request可以是多种协议的，WebServices、MSMQ、Remoting，每种协议都对应一个Interface Transport，Transport负责接受Request，并传递给各自对应的Adapter。
Adapter对于Request可以做出一些初始化的处理，比如安全验证什么的，然后，Adapter会创建一个Context对象，将这个Request放在Context对象里面，然后将Context对象传递给Service Interface里面的Pipeline。
Pipeline是一个配置性很高的组件，它根据配置文件，来载入各种Handler，包含了Request内容的Context对象就依次被这些载入了的Hander处理、传递，并最终到达一个Interface Pipeline Target，这个Pipeline Target是一个Dispatching Target，它可以根据配置，使用不同的协议将Context传递给Service Implement部分（Web Service、MSMQ、DCOM、或者Inproc直接调用）。
Context首先到达的也是Service Implement部分的Dispatching Transport（类似Service Implement，也有多种Transport来接收多种协议的请求），每个Transport同样有一个Adapter，然后Adapter创建出Pipeline，将Context传进去。Context在Service Implementation的Pipeline里面做得事情和前面差不多。最终，Context到达了一个Business Action Target，这个Target负责调用“真正”的Business Action。
Business Action根据包含在Context中的Request执行相应的操作，然后生成一个Response，将这个Response放进Context里面，然后将Context返回给Business Action Target。
Context对象沿着来时的路线又一路返回，返回的路上也可能被经过的各个Handler进行一些处理，最后，Context返回到了创建它的Interface Transport Adapter。
Adapter这时需要查看Context中是否包含了异常信息，并分辨异常信息是属于业务逻辑执行上的异常还是EDAF本身所产生的系统异常，如果是前者，将被直接返回给Client App，如果是后者，则进行一些Log或者其他操作后，返回一个包装好的安全的错误信息给Client App。
在EDRA的主页上，同时还提供了一个Global Bank Reference Implementation，使用EDRA来构建的一个银行系统的示范项目。EDRA Wiki上也有不少有意思的内容。
最后，如果对这样的架构和框架感兴趣，那么还可以去看看微软的另外一个项目：FABRIQ，FABRIQ是一个高性能的的、单向的、基于队列的一个Messaging Architecture实现。