自治应用程序的体系结构

　　没有人会与世隔绝，对于开发人员来说更是如此。软件架构师、设计人员和开发人员需要相互交流才能取得成功。应用程序也一样。过去我们将应用程序视为独立的(self-contained)应用程序。大型机应用程序以及小规模的 PC 应用程序都可以包含它们所需要的一切。它们控制用户界面、业务逻辑和数据，无需顾及应用程序以外或者让外界程序介入。

　　但现在就不再是这样了。我们今天构建的应用程序通常需要与现有软件相集成，而且这种趋势还在继续。另外，越来越多的应用程序不再控制用户界面，原因有二：一是用户界面在其他地方设计；二是用户界面通过 Internet 访问应用程序。

　　很显然，在构建和设计应用程序时，我们应该考虑跨计算平台集成的这种需求。幸运的是，我们有一个体系结构解决方案。面向服务的体系结构 (SOA) 将应用程序看作可通过 Internet 发现和访问的服务，而不管使用者在什么平台上运行以及使用什么编程语言来创建使用者。换句话说，服务提供的是与平台和语言无关的服务。Web 服务只是其中一个例子。

        什么是 Fiefdom？

　　服务应该是完全自治的应用程序。但它不是个孤岛，因为您可以让它为您执行服务。但它的自治性表现在它完全控制其数据并拒绝外界直接访问该数据或直接访问其对象。访问其资源的唯一方式是向其发送消息以请求为您执行任务。如果它不喜欢您的请求方式或者不喜欢您，它就会拒绝执行服务。没有人会以它的名义做决定，它自己做出决定。

　　Microsoft 架构师 Pat Helland 曾经是自治应用程序第一人，但他已不再是该领域的唯一一人。这是一个合理的概念，我们将在本专栏中向您进行介绍。Pat 使用术语“fiefdom”来描述自治应用程序，这里我们还将使用这个术语。

　　fiefdom 保存、管理、监视和保护它的主要资源 — 数据。fiefdom 的数据可以保存在不同类型的数据源中，但在大多数情况下，结构化数据保存在关系数据库中，例如 Microsoft SQL Server。fiefdom 从不允许任何人或任何工具从 fiefdom 外部直接获得其数据。fiefdom 可能允许它外界的某些人访问其数据，甚至以这些人的名义进行操作，但只有该 fiefdom 才能直接访问。

　　fiefdom 不允许外部程序对其任何数据进行加锁。因此，您必须考虑的是使 fiefdom 成为快照的所有数据，而不是实际内容。对于大多数实际用途，当前数据只存在于 fiefdom 内部。您不能期望从 fiefdom 接收到的数据是当前数据，更别说是接收那一刻的数据。fiefdom 内部一些事务可能在您接收到该快照之前已经更改了其数据源中的数据。

　　大多数 fiefdom 仍坚持管理它们自己的事务。fiefdom 不应该允许外部程序控制在 fiefdom 内运行的事务或部分事务。然而，fiefdom 可以公开服务来管理受外部方控制和协调的部分事务，只要这部分事务是补偿事务。fiefdom 独立控制这部分事务，但是将它作为提供给客户端的服务，这就是事务协调器。

　　补偿事务的一个例子是遵守 Web 服务事务规范第二部分：业务活动 (BA) 的事务。这样的事务有两个不同的方案。标准方案执行由事务指定的操作。补偿方案执行另一组操作，其作用是删除 fiefdom 中已完成事务的影响。补偿方案由本身可能为另一个 fiefdom 的事务协调器调用。调用补偿方案的情况是 fiefdom 已经完成了它的部分事务，但后来协调器发现事务的其他部分执行失败。在这种情况下，必须消除 fiefdom 运行并完成的部分事务所造成的影响，即使它不能回滚。对记录所加的锁已经释放，而其他事务可能已经改变其状态。补偿方案会消除这些影响。

　　并不是所有类型的事务都适合补偿。大部分 fiefdom 并不（也不应该）参与不存在可靠补偿方案的事务。

　　安全的网关

　　在某种程度上，面向服务的性质决定了面向服务的应用程序是安全的。让应用程序为您执行任何任务的唯一方式是向它发送消息，请求执行某一服务。执行还是拒绝请求取决于应用程序。

　　在许多情况下，应用程序会允许某人执行特定一个或一组服务。在这些情况下，Web 服务需要做的仅仅是将作业委派给适当的组件，然后将响应传递给客户端。在其他情况下，Web 服务可能需要验证用户的身份以确定他是否被授权执行该服务。这可以是仅在网关处针对 Active Directory 或 SQL 数据库进行简单的检查，也可以在应用程序的不同级别结合使用安全技术（例如模拟或委派）和基于角色的安全检查。请记住，必须始终注意拒绝服务攻击、试图入侵系统的黑客以及其他恶意威胁所造成的风险。

体系结构模式

　　很显然，fiefdom 是一个体系结构模式。与其他模式一样，您作为一个软件架构师应该能够说出“我想我们应该将这个应用程序设计成一个 fiefdom”，同时您身边的人应该能够立即理解您在说什么。这就是模式的强大优势之一；它们有助于您讨论体系结构、在更为抽象的级别设计并使用通用词汇来加以设计。

　　显然，并非所有 fiefdom 都要以同样的方式架构。它们提供的一组服务会影响它们内部需要的组件类型，所以任何 fiefdom 都将在其内部实现中使用其他模式进行架构。例如，大部分 fiefdom 都将使用模式（如使用数据访问器）访问数据库；使用服务代理访问其他服务；使用数据传输对象通过各层传输数据，以及使用实体管理器来支持实体级业务规则。

　　有些发送给 fiefdom 的请求要求保存或删除数据。如果没有根据安全策略对请求本身并根据业务规则对其数据进行仔细验证，fiefdom 就不应该接受这样的请求。这就是业务规则和策略规则属于 fiefdom（由 Pat Helland 定义）并位于服务（由 SOA 定义）的原因。

　　与客户端松散耦合

　　fiefdom 与其客户端进行松散耦合。通常在客户端向 fiefdom 发送消息以建立连接之前，客户端和 fiefdom 之间并没有任何连接。fiefdom 处理该消息并发送响应给客户端。响应可以是请求操作的结果，也可以是对执行服务的拒绝。在任何一种情况中，都是只要 fiefdom 响应完毕，就断开客户端和 fiefdom 之间的连接，就像 HTTP 消息交换一样。正如 HTTP 一样，有多种方式可以在整个会话期间保持连接，但通常只限于一个完整的消息周期。

　　松散耦合对可扩展性而言是有好处的。它使得任何客户端连接到系统并使用系统资源的时间最少。松散耦合和一次