自治应用程序的体系结构.docVIP

　　自治应用程序的体系结构 　　没有人会与世隔绝，对于开发人员来说更是如此。软件架构师、设计人员和开发人员需要相互交流才能取得成功。应用程序也一样。过去我们将应用程序视为独立的 (self-contained) 应用程序。大型机应用程序以及小规模的 PC 应用程序都可以包含它们所需要的一切。它们控制用户界面、业务逻辑和数据，无需顾及应用程序以外或者让外界程序介入。 　　但现在就不再是这样了。我们今天构建的应用程序通常需要与现有软件相集成，而且这种趋势还在继续。另外，越来越多的应用程序不再控制用户界面，原因有二：一是用户界面在其他地方设计；二是用户界面通过 Inter 访问应用程序。 　　很显然，在构建和设计应用程序时，我们应该考虑跨计算平台集成的这种需求。幸运的是，我们有一个体系结构解决方案。面向服务的体系结构 (SOA) 将应用程序看作可通过 Inter 发现和访问的服务，而不管使用者在什么平台上运行以及使用什么编程语言来创建使用者。换句话说，服务提供的是与平台和语言无关的服务。icrosoft 架构师 Pat Helland 曾经是自治应用程序第一人，但他已不再是该领域的唯一一人。这是一个合理的概念，我们将在本专栏中向您进行介绍。Pat 使用术语fiefdom来描述自治应用程序，这里我们还将使用这个术语。 　　fiefdom 保存、管理、监视和保护它的主要资源 数据。fiefdom 的数据可以保存在不同类型的数据源中，但在大多数情况下，结构化数据保存在关系数据库中，例如 Microsoft SQL Server。fiefdom 从不允许任何人或任何工具从 fiefdom 外部直接获得其数据。fiefdom 可能允许它外界的某些人访问其数据，甚至以这些人的名义进行操作，但只有该 fiefdom 才能直接访问。 　　fiefdom 不允许外部程序对其任何数据进行加锁。因此，您必须考虑的是使 fiefdom 成为快照的所有数据，而不是实际内容。对于大多数实际用途，当前数据只存在于 fiefdom 内部。您不能期望从 fiefdom 接收到的数据是当前数据，更别说是接收那一刻的数据。fiefdom 内部一些事务可能在您接收到该快照之前已经更改了其数据源中的数据。 　　大多数 fiefdom 仍坚持管理它们自己的事务。fiefdom 不应该允许外部程序控制在 fiefdom 内运行的事务或部分事务。然而，fiefdom 可以公开服务来管理受外部方控制和协调的部分事务，只要这部分事务是补偿事务。fiefdom 独立控制这部分事务，但是将它作为提供给客户端的服务，这就是事务协调器。 　　补偿事务的一个例子是遵守 中已完成事务的影响。补偿方案由本身可能为另一个 fiefdom 的事务协调器调用。调用补偿方案的情况是 fiefdom 已经完成了它的部分事务，但后来协调器发现事务的其他部分执行失败。在这种情况下，必须消除 fiefdom 运行并完成的部分事务所造成的影响，即使它不能回滚。对记录所加的锁已经释放，而其他事务可能已经改变其状态。补偿方案会消除这些影响。 　　并不是所有类型的事务都适合补偿。大部分 fiefdom 并不（也不应该）参与不存在可靠补偿方案的事务。 　　安全的网关 　　在某种程度上，面向服务的性质决定了面向服务的应用程序是安全的。让应用程序为您执行任何任务的唯一方式是向它发送消息，请求执行某一服务。执行还是拒绝请求取决于应用程序。 　　在许多情况下，应用程序会允许某人执行特定一个或一组服务。在这些情况下， 是一个体系结构模式。与其他模式一样，您作为一个软件架构师应该能够说出我想我们应该将这个应用程序设计成一个 fiefdom，同时您身边的人应该能够立即理解您在说什么。这就是模式的强大优势之一；它们有助于您讨论体系结构、在更为抽象的级别设计并使用通用词汇来加以设计。 　　显然，并非所有 fiefdom 都要以同样的方式架构。它们提供的一组服务会影响它们内部需要的组件类型，所以任何 fiefdom 都将在其内部实现中使用其他模式进行架构。例如，大部分 fiefdom 都将使用模式（如使用数据访问器）访问数据库；使用服务代理访问其他服务；使用数据传输对象通过各层传输数据，以及使用实体管理器来支持实体级业务规则。 Emissary　　一些 fiefdom 也会为它的服务提供用户界面 (UI)。这样的 fiefdom 会使用一个 Emissary 模式 一个 emissary 或者一个 issary。Emissary 就像一个销售代理或者一个抵押经纪人。它可以向用户显示参考数据，允许用户从有效的可选方案中选择，而不是键入信息。Emissary 也