简介
本页内容
 | 应用程序概念： “概念性结构” |
| 基于服务的应用程序结构 |
| 服务 |
| 消息 |
| 协定 |
| 策略 |
| 状态 |
| 处理 |
| 应用程序 |
本文介绍 Microsoft 的应用程序体系结构的概念视图。本文的目标读者是那些希望理解 Microsoft 处理企业、应用程序及技术体系结构的方法的业务、软件和基础体系结构架构师。 “应用程序体系结构”和“概念视图”等术语在 “Microsoft 体系结构概述”一文中介绍，该文涵盖了各个层面的体系结构术语、模式、概念和定义。
Web 服务的出现对其中的一些体系结构层产生了相当大的影响，并且为在概念层工作的 class=GramE>架构师提供了一组新的基本体系结构元素。 这些元素包括 Web 服务、消息、状态和处理，本文档将对它们进行详细定义和讨论。
本文重点介绍应用程序概念或“概念性体系结构”。 应用程序模式、技术概念和相关的技术模式将在其他文档中介绍。
应用程序概念： “概念性结构”
过去，应用程序的构建是通过集成本地系统服务（如文件系统和设备驱动程序）来实现的。这种模型在访问丰富的开发资源以及精确控制应用程序的行为方面提供了很大的灵活性，但同时也容易出错、成本较高并且较为费时。
现在，可以通过集成整个网络上现有的应用程序和服务，然后使用诸如业务实体、数据实体和其他方面在其上提供独特的附加价值，来构造复杂的分布式应用程序。这就使开发人员能够将注意力集中于提供业务价值上，从而减少进入市场的时间，提高开发效率，并且最终开发出高质量的软件。多年来，这一直是一个强大的体系结构模型，但它产生了 “应用程序通风口”或“信息孤岛 ”，而这在体系结构重用中会引起重大问题。
现在，我们进入了下一个计算阶段。这个阶段通过 Internet 和 Web 服务概念来实现，能够创建可以由任何人、在任何地点使用的功能强大的应用程序。它增加了应用程序的应用范围，并且可以不断交付软件。在这种情况下，软件即服务 — 一种通过通信网络来订购和使用的服务。
Microsoft .NET 通过集成n层计算的高效的紧耦合特点以及 Web 以信息为导向的松耦合概念，来推进这种理念。 这种计算样式被称作 XML Web 服务，它代表应用程序开发的下一次革命。 Web 服务是一种应用程序，它使用标准 Internet 协议，通过 Internet 或 Intranet 以编程方式公开其功能。
Web 服务为在概念层构造应用程序提供下面一组新的基本元素。
基于服务的应用程序结构
本文所提供的应用程序体系结构使用软件服务来提供易于集成和满足一致性操作要求的跨组织的功能要求公文包。基于服务的体系结构大大提升了代码重用的抽象级别，允许应用程序绑定到随着时间的推移而不断演变和改善的服务，而无需修改使用服务的应用程序。 服务为在组织内部和跨组织边界集成软件系统提供了清晰的模型。
下一节简要介绍主要概念，随后介绍体系结构的详细信息。
服务
软件服务是应用程序逻辑的离散单元，它们提供了基于消息的、适合通过网络访问的接口。通常，服务既提供业务逻辑，也提供与要解决的问题相关的状态管理。在设计服务时，目标是有效地封装与现实世界中的过程相关的逻辑和数据，对要包括在内的内容和要作为 独立服务实现的内容 作出明智的选择。
状态处理由业务规则来管理。业务规则是相对稳定的算法（例如从商品清单汇总出发票的方法），一般是作为应用程序逻辑来实现的。
服务由策略来管理。与业务规则相比，策略的稳定性较差，并且可能是区域性的或针对特定客户的。策略一般是通过在运行时查阅表格来驱动的。
因此，服务的更完整的定义应该是：“服务是能在网络上运行的软件单元，它通过消息来实现逻辑、管理状态和通信，并且由策略来管理。 ”
图 1. 服务
消息
服务通过交换消息来进行交互。 在所提供的服务模型中，服务完全由其所接受和生成的消息（包括这些消息的排序要求）来定义。 在服务之间成功路由消息是一个复杂的过程，此过程最好由在组织公开的服务之间共享的消息处理基础结构来处理。
协定
当两个服务进行交互时，消息会在二者之间来回发送。 这两端都需要确切知道它们要发送什么内容、如何发送它、期望获得什么内容以及如何期待它。 不仅有必要定义可发送的消息、此消息应当采用的格式及其发送方式，而且一定还要指定这些消息的发送顺序。 协定是对在两个服务之间发送的全部内容以及如何发送它们的定义或绑定协议。
策略
不同的部门不仅对业务逻辑不同的部分承担职责，而且还对不同服务承担职责，每个服务通常由组织内的不同部门或角色来管理。 其中的每个组都将具有单独的职责： 一个组可以负责定义安全规则，而另一组需要确保系统的正常运行时间和响应。 这些管理规则通常需要在项目的设计阶段考虑，并且由于这些解决方案通常不够灵活，因此无法适应以后的变动。 使用策略，可以设置运行时规则，以控制通信和服务行为。 使策略成为设计过程的一部分会提高灵活性并增强管理功能。
状态
服务管理状态；此状态通常正是服务存在的原因。 服务监视此状态，并通过它们的业务逻辑确保状态保持一致且准确无误。 此状态是唯一真实的当前信息源。
几乎所有的服务都管理持久状态，即存储在某个持久介质（例如，文件系统或数据库中）的状态。 服务接收另一个服务的请求，从这个持久介质中检索某个状态，然后生成响应或更新状态。 这个持久状态非常重要；服务可能会被关闭，而且当它们被再次启动后，持久状态将仍在原处并继续运行，就好像未发生过任何事情一样。 服务尽可能使这个持久状态保持一致；它们还将使其自身的应用程序状态在内存中保持一致，但是，如果出现了问题，它们只是放弃处理，忘记应用程序在内存中的状态，并使用这个持久状态设置一个新的状态。
处理
业务处理或处理，控制执行某项工作和将系统从一个状态转移到另一个状态的逐步操作。 它在每一步都可以调用一个业务操作。 这些处理可以宿主在业务处理服务或处理服务中。 类似处理服务中的处理发送一则消息，以调用某个服务中包含的业务操作，然后继续执行下一步，这可能需要使用另一个服务。
处理服务使用业务服务，此类业务服务可作为多层系统进行构建。
业务服务可以遵循传统的设计；包括处理服务的服务结构将这些系统连接在一起。 通常，业务服务本身就是更紧密耦合的系统；服务之间的耦合较为松散。 服务结构以松散方式耦合紧密耦合的系统。
其中的每个概念都将在本文档的其余部分更详细地加以介绍。
应用程序
应用程序由处理服务以及业务和用户接口 (UI) 服务组成。 处理服务控制业务和 UI 服务之间的交互。 业务服务通常由四层组成： 服务接口层、业务处理层、业务实体层和数据表示层。
此模型对于传统的应用程序（有一个与业务服务进行通信的用户接口）和企业对企业方案（业务服务之间进行通信）均有效。
1439
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
