介绍
使用DotNet框架构建分布式解决方案的开发人员和应用程序架构师，本指南可以提供架构和设计层面的指导。
本指南适合你从事以下活动：
l 设计高层次应用或者服务架构。
l 为你的应用程序或服务，推荐合适的技术和产品。
l 做出适合功能性和非功能性（运行）需求的决策。
l 为你的应用程序或服务选择合适的通讯机制。
这个指南可以在开发早期阶段帮助你识别出关键的设计决策，提供一些设计指导帮助你在设计选项之间做出选择。通过引进一致性的架构----构建不同类型的组件，会帮助你完成良好的设计和发挥微软平台的优势，从而帮你演进一整套设计。虽然这个指南不打算提供应用程序每个方面实现层面的指导，但提供在微软模式和实践、MSDN文章、社区站点中指定的讨论细节，这些内容涵盖分布式应用程序设计的各个方面。当你使用微软平台时，你会遇到的许多重要的分布式应用程序设计问题，你可以把这个指南作为一个路线图来考虑。
这个知道关注分布式应用程序和Web Services，它们可能需要提供多个数据源和服务的整合能力，也可能要求一个或者多个设备的用户界面。
这个论述假设你是熟悉DotNet组件开发和分层应用程序设计的基本概念。
内容指引
这个指南有五章组成：
l 第一章，“介绍”：解释应用程序和服务是如何相互关联。
l 第二章，“设计应用程序或服务的组件”：漫游架构，论述每个组件层的角色和设计标准。
l 第三章，“安全，运行管理和通讯策略”：附属于整体应用程序的详细设计问题，比如：异常管理和认证。
l 第四章，“物理部署和运行需求”：解释应用程序的设计是如何影响部署和变更管理，讨论应用在良好构建解决方案中普遍的部署模式。
l 第五章，“附录”：包括参考图形和本指南中使用到的术语表。
按顺序阅读这些章节会获取更多的价值，但每章提供的信息也是相互独立。
本章内容
本章包含以下的章节：
l 分布式应用程序设计的目标
l 服务和服务集成
l 应用程序和服务的组件和层次
l 一个简单的场景
分布式应用程序的目标
对于一个分布式应用程序的设计，我们要考虑它功能如何实现的一些因素，并对这些因素做出决策。这些因素包括：它的逻辑、物理部署架构、技术和基础结构。为了使这些决策有效，你必须彻底理解应用程序将执行的业务过程（它的功能需求），可度量、可用性、安全和可维护性的需求层次（它的非功能的，或者运行，必需的条件）。
你的目标是来设计这样一个应用程序：
l 解决业务问题
l 一开始就从事于安全考虑，做出合适的认证机制，授权逻辑和安全通信的考虑事项。
l 提供高性能，且可以为交叉部署模式优化公共的运行。
l 是有效的和有弹性的，且可以部署在冗余，高有效性的数据中心。
l 对期望的需求是可度量的，支持大量的活动，且使用最小的资源。
l 是易管理的，允许操作员根据适合的情景，来部署，监控和故障修复应用程序。
l 是可维护的。每一个功能将使一个可预期的定位，设计要考虑应用程序大小的变化，具有不同技能的团队，和业务，技术改变的需要。
l 运行在各种各样应用环境和部署模式下。
这个设计指导在后续章节会提供这些目标的每个方面，每当理解他们的背景比较重要的时候，我们就讨论特定设计决策的原因。
服务和服务集成
正如互联网和它相关的技术的发展，许多组织寻求横穿部门和组织边界的集成系统，一个通过基于服务的方法构建的解决方案已经发展起来。从客户的观点看，服务是和传统组件一样的概念，只不过是服务封装了他们自己的数据，严格的来说，不是你应用程序一部分；而是被你应用程序使用。应用程序和服务需要被集成在不同的平台，通过不同的团队，存在不同的进度安排，可以互相独立的被维护和刷新。因此，他们之间可以在最少耦合的情况下进行通讯成为了可能，这种可能对于服务起到了至关重要的作用。
推荐你实现服务之间的通讯，可以通过使用基于消息技术，这个技术提供了高层次的健壮性和可度量性。你可以直接实现消息的通讯（例如，通过写代码发送和接受Message Queuing的消息），或者你可以间接使用基础部分管理通讯（例如，通过使用Microsoft Visual Studio.Net产生的Web Service代理）。
注意：在这个指南中使用的术语“服务”是指任何外部提供业务服务的软件组件。这些包括，但不仅限于XML Web Services。
所有入内的消息都被发送到服务暴露的服务接口中。设置的消息定义必须和一个服务进行交换，这个服务的目的是，执行一个指定业务任务的服务，构成一个契约。你可以把服务接口认为成一个暴露在外边的业务逻辑实现，这个服务是应用于潜在的客户。
例如，我们通过一个客户订购产品的零售应用程序来说明。这个应用程序使用一个外部信用卡认证服务来检验客户的信用卡明细和审核销售。信用卡明细通过核实之后，一个快递服务来进行货物的发送。下面的序列图（图1.1）说明了这个情况。
图1.1 一个使用服务实现的业务处理
在这个场景下，信用卡认证服务和快递服务都在整个采购业务处理中充当一个角色。和平时的组件不同，在应用程序外部的服务是存在于他们自己信赖的边界内且管理着他们自己的数据。所以，当你使用基于服务的方法开发应用程序时，在应用程序和服务之间，你必须保证构建一个安全、可被识别的链接。另外，你可以通过使用基于消息的方法实现通讯，获得更多合适的方法来处理业务过程（有时需要考虑到“业务事务”或者“长期运行事务”）及应付大量公共的，分布式的解决方案的松耦合系统---特别是业务过程涉及到多个组织和多样的平台。
例如，如果基于消息的通讯被用在像图1.1所示的过程，在销售信息被提交后的片刻或者某一固定时间，用户可以收取到订单确认信息，这个要依赖于认证和快递服务的反馈。基于消息的通讯也可以使你的业务逻辑设计独立于服务之间根本的传输协议。
