如果你的应用程序使用一个外部服务，这个服务的内部实现和你的设计是不相关的----只要服务做了它应做的职责就可以。你只需要简单地知道这个服务提供的业务功能和它要求的契约明细，这个契约明细是为了和它通讯（诸如，通信格式，数据结构，认证机制，等等）。在零售应用程序的例子中，信用卡认证服务提供一个接口，通过它，销售和信用卡明细可以通过服务，且做出一个反馈，表明这个销售是否被认可。从零售应用程序设计者的角度看，在信用卡认证服务内部发生什么并不重要；而关注的仅是需要的数据是否被发送到服务，从服务处接受什么样的反馈，和如何和服务进行通讯。
在内部，服务包括许多种类的组件，这些组件和传统应用程序所作的一样（这个指南的其余部分关注于各种各样的组件和它们在应用程序设计中的角色）。服务包含逻辑组件---由他们执行的组件进行编排，包含业务组件---实现服务的真实的业务逻辑，包含数据访问组件---访问服务的数据存储。进而，服务通过服务接口暴露他们的功能，服务接口还处理隐含在业务逻辑下的暴露的语义。你的应用程序也会通过“服务代理”调用其它服务，“服务代理”代表正在调用的客户端应用程序和服务进行通讯。
虽然基于消息的服务可以被设计为所谓的同步，对于构建异步服务接口也是很有优势，异步服务接口为分布式的应用程序开发提供更有利的松耦合方法。异步通信的松耦合可以把存在的服务组合起来，为构建高可用性、可升级的和长期持久运行的解决方案提供了可能性。然而，异步设计在一些方面不都是能够方便使用，使用同步通讯意味着你需要关注一下特别的注意事项：消息的相关性、乐观数据并发管理、业务过程补偿和外部服务的无效。
注意：第3章，“安全，运行管理和通讯策略，”讨论实现服务通讯的问题明细。
有关服务及相关概念，详见“应用程序概念视图（http://msdn.microsoft.com/library/en-us/dnea/html/eaappconland.asp）。
应用程序和服务的组件及层次
你想使你的分布式设计成为一个公开的、广泛接受的原则，你将把它们分隔成不同的组件，这些组件提供展现、业务和数据服务。执行相似功能的组件可以被组合到一个层次中，大部分情况下，以书架的方式进行组织，使某些层上面的组件方便使用这些层提供的服务，一个给定的组件运行它的功能，会使用在它自己层的其它组件提供的服务，和在它下面其它层提供的服务。
注意：这个指南使用术语“逻辑层（layer）”指的是组件类型，使用“物理层（tier）”指的是物理分布模式。
应用程序的这个分隔观点也适应于服务。从高层面看，一个基于服务的解决方案可以被看作是多个服务的组合，它们通过消息彼此通讯。在概念上，服务可以被看作整体方案的组件集合。然而，在内部，每个服务和其它应用程序一样，是由软件组件构成的，这些组件也是按逻辑被组织成展现、业务和数据服务，正如图1.2所示。
关于这个图注意以下要点：
1、 通常服务被设计成和最可能少的耦合服务进行彼此通讯。使用基于消息的通讯可以帮助减弱服务之间的可用性和可度量性的耦合。这个要依赖于行业标准，如，XML Web services 允许和其它平台和技术进行集成。
2、 每个服务有一个应用程序组成，这个应用程序拥有他们自己的数据源，服务逻辑和用户界面。一个服务可能有相同的内部设计，如传统的三层（物理层）应用。如上面图中的（2）和（4）服务。
3、 你也可以有选择的构建和暴露一个没有和它直接相关联用户界面的服务（这样的服务被设计成被其它应用程序通过程序接口调用）。这个如上图的服务（3）。要注意的是，构建成一个服务的组件和构建成应用程序的业务逻辑层的组件，在设计上会采用一样的方法。
4、 每个服务封装自己的数据，管理他自己数据源的原子事务。
更需要注意的是，构成应用程序或者服务的软件组件，仅仅是从逻辑上组合成逻辑层。对于组件执行的不同类型任务之间，这些组件对区分它们是有帮助的，使解决方案融合了更流畅的可重用性设计。每个逻辑层包含了大量分散在子逻辑层的组件，每个子逻辑层负责执行一个指定的类型的任务。通过识别在大多数解决方案中的通用类别的组件，你可以构造一个应用程序或服务的地图，然后，使用这个地图作为你设计的蓝本。
图1.3 展现了一个应用程序和它的逻辑层的简单视图
图1.3 按照它们的角色组件被隔离到不同的逻辑层。
一个分布式解决方案可能需要跨越多个组织或物理层，在这样的情况下，必须拥有它们自己应用程序安全、运行管理和通讯的策略。这些可信赖的单元，或者区域，可能是物理分层，一个数据中心，或者一个部分，区域，或者公司，这些地方都已有定义的策略。综合考虑，被部署的应用程序，应用程序和服务的物理层如何通讯形成一个环境，这些策略为这个环境定义规则。这些策略横跨整个应用程序，它们被实现的方法影响每个物理层的设计决策。它们彼此也会有冲突（例如，安全策略决定一些通讯策略的规则）。
注意：关于安全、运行管理和通讯策略设计的更多信息，详见第3章，“安全、运行管理和通讯策略”。
