走向ASP.NET架构设计——第六章：服务层设计（前篇）
本篇主要是为后文做铺垫，所以理论的东西相对而言比较的多一点！
服务层的概述
首先解释一下什么是”服务Service”，从广义来讲：只要是你使用了别人的东西，那么你就在使用别人提供的服务。在这里，服务就是指可能被一个或者多个系统使用的核心的业务逻辑，我们可以把服务简单的想象成为一些可供调用的API。
在之前的第四章中，我们讲述了如何组织业务逻辑，第五章讲述了在业务层的设计中可以采用的一些模式。但是还有一个问题需要大家考虑的是：如何把业务层提供给其他的层来调用？
可能认为这个问题有莫名奇妙—不是只要引用业务层的组件就行了吗。但是仔细想想，却不尽然：因为在很多系统中，我们不是直接把业务层的组件引用就可以了的，特别是在分布式的系统中，我们往往在服务端暴露一些服务接口，让其他的子系统或者外部系统来调用提供的服务。
一般来说，服务层处于业务层和显示层之间(当然服务层也可以处于系统和系统之间)。服务层往往提供了一些供外部调用的服务接口，这些接口往往是一些粗粒度，或者说提供了一些简单易用，功能强大的接口，当客户端调用这些接口服务之后，服务层那边就开始处理比较复杂的一些业务逻辑，验证规则，以及持久化数据等。
服务层内的逻辑的组织形式有点类似我们之前在第四章中讲述的Transaction Script模式。
我们可以简单的把服务层看成是一个中介：从客户端接收请求，通过一系列的步骤之后，请求就到了服务层，服务层就开始协调和组织所需要的业务类，把请求的的具体处理交给那些业务类来做，最后把结果返回给客户端。
在服务层的逻辑组织往往是比较过程化的，但是和Transaction Script有一点不同的是：Transaction Script的每一个方法处理一个比较细（比较具体的，小的）的业务流程和逻辑。但是服务层的一个接口的方法往往是处理一个比较大的流程（这个大的流程可能包含很多的小的流程）。
下面我们就来就从一个例子来看看SOA。
SOA架构讲述
我们首先来看一个例子：
上面的图就是一个电子网站的系统架构图。可以看出，在这个系统中，又包含很多其他的小的子系统，而且每一个子系统都有自己的业务逻辑。同时每一个系统都连接搭配同一个数据库，所有的子系统也都同时使用一个SMTP服务器。而且还有一些系统，如Order Management还需要链接第三方的WebService(PayPal).
这种错综复杂的系统架构存在一些问题：
1． 因为整个大的系统中存在很多的子系统，而且这些子系统都有自己的业务逻辑层，这样就导致了相同的业务逻辑在很多的其他子系统中重复，维护起来很困难。而且相同的业务流程在一些子系统中重复出现。例如，在Customer Management中，需要查看一个客户的所有的订单，那么这个逻辑和Order Management中的一些逻辑重复。
2． 各个系统和底层的数据结构紧耦合。因为这些系统都是用的是同一个数据库，有着各自的业务逻辑和数据访问层，那么一旦要对数据库做一点点的改动，那么就会牵连很多的子系统做相应的改变。
3． 审计跟踪比较的麻烦。因为很多的子系统各自可以操作数据库，所以记录操作系统比较麻烦。
通过SOA可以解决上面提到的一些问题(当然，不仅仅只是上面提到的一些问题)：把所有的业务处理放在一起，进行统一管理和控制（而不是像上面的设计那样—零散的到处分布），并把业务逻辑的通过服务的形式暴露会给外界，让其他的子系统调用。
上面改良后的系统的好处如下：
1． 系统的业务逻辑等的维护变得容易，因为改变只是发生在一个地方。
2． 并且服务都是通过接口的形式暴露给外界的，那么这就为以后的扩展提供了可能。例如我们可以在接口不变的前提下，替换现有的一些业务流程处理方式。
3． 日志，审计跟踪容易实现。
4． 对外界隐藏了数据层的实现。只要接口之前定义的数据的scheme，或者说数据契约不变，服务层可以任意替换数据存储设备和方式。
5． 各个系统与服务层的交互是基于粗粒度的接口，避免了系统直接和数据库频繁的交互，减小了通信的成本，也减轻了数据库的压力。
SOA的基本原则
SOA架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。那些保证服务的灵活性、松散耦合和重用能力的设计原则，对SOA架构来说同样是非常重要的。
结构上，服务总线是SOA的架构模式之一。关于服务，一些常见和讨论的设计原则如下。
1) 无状态。以避免服务请求者依赖于服务提供者的状态。
2) 单一实例。避免功能冗余。
3) 明确定义的接口。服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式(Schema)用于定义所交换的消息格式（即服务的公共数据）。
使用者依赖服务规约调用服务，所以服务定义必须长时间稳定，一旦公布，不能随意更改：服务的定义应尽可能明确．减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
4) 自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
5) 粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用(RPC)，通常消息量比较大，但是服务之间的交互频度较低。
6) 服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
7) 重用能力。服务应该是可以重用的。
8) 互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，例如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS-Policy用于定义可配置的互操作语义，来描述特定服务的期望、控制其行为。
在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。
上面的一些原则可能有点抽象，在文章的后面一个例子中会设计一个小的项目，会对这些原则多一些讲解。
今天就讲述到这里吧，没有什么很新的东西，都是为了给后文做准备的，下一篇主要讲述在SOA常常使用的设计模式和架构模式。
