Shadowfax 架构（自己翻译）

早就听说在gotdotnet社区出了个SOA的典范叫Shadowfax（后来叫Enterprise Development Application Framework，好像意思是要扩大它的影响范围了。），但一直没有时间去仔细学习研究一下，今天借第一天申请BLOG的高兴劲，将EDAF wiki上的第一篇文章翻译一下，和大家一起提高一下。在翻译过程中，我倾向于采用候捷的风格，即对很多英文术语不作翻译。原文参考http://weblogs.asp.net/hernandl/archive/2004/02/23/shadowfaxintro.aspx ，这篇文章写于2004年2月。

<!--译文开始-->

我们正在完成微软.NET参考架构（codename是Shadowfax），我们现在已经有了一个稳定的代码库，我现就将开始对这个架构不同方面的特性来表达自己的想法和见识。

SOA已经被广泛的的宣传（一个好的描述是Clemens的blog），现在我们有了一个真实的已经为商业应用做好准备（或者说，基本上已经准备好了）的包容各个方面的优秀架构的实现。如果你是 patterns andpractice以及指引和现成的Application Blocks的关注者，我敢打赌你会猜想这帮人什么时候才能做出一个可以在广泛企业解决方案中应用的完美管制代码的商业架构。

呵呵，这个时候已经到了，Shadowfax将要发布了。但是先等等，如果你认为这个Shadowfax只是对那些Application Bolocks做了一个漂亮的学术形式的包装并附加了一些比较酷的功能，那你肯定错了。当然Application Blocks已经被广泛地使用，但是我后面会说到还有很多事情需要做更多地考虑。这个项目的一个有趣的特点源于它的一个出发点。

在这个项目的最初阶段，即构思和设计阶段，这些架构师决定收集从全世界的微软的合作伙伴和微软的咨询机构中获取最成功的.NET企业架构实现的最佳经验。他们收集了最好的3个（其中一个是我们开发成功的MBI项目）以及这些项目的知识，开始设计一个全新的模型来解决我们下面将要提到的问题。这一点很重要，因为所有这些成功的架构真正解决了客户的需求并且也将成为Shadowfax架构的最重要的目的。

在深入描述之前让我澄清一下，现在这个架构的文档已经有几百页了，一个BLOG帖子是不可能将这个架构描述得更加清楚并给出一个完整的架构图，所以我会非常简单地介绍一下一些主题，其他的一些主题我将做更深入的研究再给出。提醒一下，你可以在Shadowfax 的 gotdotnet的 Workspace中发现一些有用的信息和关于这个架构的有趣讨论和用户反馈。

架构的需求和考虑

Shadowfax服务架构是为了达到几个重要的架构需求和目标而开发的。下面就是一些重要需求的列表：
* 保证稳定的服务接口和易变的不稳定服务实现的分离
* 让程序员实现那种handlers-like的逻辑（如：监控和审计日志）和服务实现逻辑的分离。这种所谓的 Handlers将在pipeline中执行。（不要担心你暂时不懂这些概念，我们下面会详细介绍这些细节）
* 帮助开发人员建立可以被客户端的一种或多种组合传输通道访问的强壮服务。我们现在支持的通道有：Web Services、MSMQ、Remoting、和DCOM。
* 建立一定层次上的在服务调用和服务实现2者间的间接关系来缓冲应用的变化。这就是double pipeline模型。

因为我并不想对这整个架构做过多的展开描述，我倾向于描述一下我所关心的这个项目包含的主题和子系统。

我一直在设计/实现几个Block，我宁可有偏见地写那些内容，所以我会首先罗列出来（用中括号标注）然后等以后发帖子详细描述。我会为这些模块写一些关于性能和安全考虑的主题。

从客户端开始考虑，第一个接入点是Service Interface。Shadowfax框架的这个接口帮助暴露一个建立在多个通道之上的一个服务接口（译者注：原文是【service interface over multiple transports】）。一个服务请求首先是客户端通过多个不同的通道发起如：WebServices、MQ、或者一个.NET Remoting。（甚至是DCOM）

通道的listener接受到请求信息（请求的格式根据通道的选择有所变化），将其放入到叫context的信封中去，并将context传递到一个叫【Service Interface pipeline】的实例中去。

简而言之，pipeline包括消息预处理Handler的序列，跟着是Target（译者注：真正的业务逻辑实现），最后是消息后处理的【Handler】的序列。

一个handler是一个满足一些切入考虑的代码块如：认证、日志、或者是事务支持（事实上会有很多内置的handler将会被实现，至少比现在多一打）。handler有3种风格：原子性、有状态、无状态handler。无状态的handler是在Target之前和之后都将被执行。原子和有状态handler在处理流中仅会被执行一次。之后的handler以链的方式执行，即每个handler调用下一个handler并以同步的方式等待回应。

这个架构有2种pipeline，这2种pipeline给物理/逻辑层之间的分离提供了极大的灵活性（典型的是IIS－DMZ（第一种pipeline）和一个内部应用服务器（第二种pipeline））并且引入了一个“间接层”。然而如果应用不需要分布式的场景，可以仅使用第一种pipeline将满足【Target】的执行要求。

在双pipeline共存的场景下，第一个pipeline，即Service Interface pipeline，是一个和通道有关的并且关注于服务边界的handlers如：认真、监控和请求消息的验证。Shadowfax是高度可配置的，所以一个pipeline可以被配置成以任何顺序处理任何方面（译者注：AOP中的A）。Target的第一个pipeline是一个端口。这个端口的责任是调用第二个pipeline，叫【service implementation pipeline】。

Service Implementation pipeline是一个和服务相关的并关注于业务handler如：触发一个业务事件，记录请求日志或者给事务划分界限。Target的第二个pipeline的责任是调用服务的实现即调用【BusinessActioon】。

一个business action是被请求服务的真正实现。这是一个内部实现的商业组件或者是一个调用远端组件的服务代理。在这2种情况下，它都是最初服务请求的最终Target。在多数情况下，一个business action将产生一个回应。

business action通过工厂模式的风格有3种调用机制：Context，Serialization和Explicit。第一个通过IBusinessAction接口，后两个是通过反射、消息的deserialization后的参数传递、并顺序反射。

一旦一个Business action结束了，这第二个pipeline收到了一个响应，应用一些其他的handlers，然后通过context回应第一个pipelie。然后第一个handler执行剩下的handlers。最后又回应客户端的应用程序。

另外一个重要的子系统是配置子系统，它依赖于CMAB（Configuration Management Application Block）。这个子系统的一个重要优点是支持“on-the-fly”更新，所以配置文件中的一个更新可以在不停止或者重启应用的条件下自动反映到应用程序（不同于ASP.NET中的更新，ASP.NET是通过文件系统）。这个子系统值得关注一下，因为它控制了架构几乎每个方面，包括handler、services，甚至business action。

到现在为止我们已经完成了我前面说到的这个架构的主要模块的简单介绍，不久我将非常愿意地post更多的关于这个架构更加细节的内容。

注意：本帖子中出现的一些术语和名字和最终发布后的术语会有所区别。

<!--译文结束-->