本篇主要是为后文做铺垫，所以理论的东西相对而言比较的多一点！
服务层的概述
首先解释一下什么是上海企业网站制作”服务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) &nbs上海闵行企业网站设计与制作p;明确定义的接口。服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式(Schema)用于定义所交换的消息格式（即服务的公共数据）。
使用者依赖服务规约调用服务，所以服务定义必须长时间稳定，一旦公布，不能随意更改：服务的定义应尽可能明确．减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
4) 自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
5) 粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用(RPC)，通常消息量比较大，但是服务之间的交互频度较低。
6) 服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
7上海企业网站设计与制作) 重用能力。服务应该是可以重用的。
8) 互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如一个服务对安全性方面的要求；也可以是跟上海徐汇企业网站制作业务有关上海闵行企业网站制作的语义方面的内容，例如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS-Policy用于定义可配置的互操作语义，来描述特定服务的期望、控制其行为。
在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。
上面的一些原则可能有点抽象，在文章的后面一个例子中会设计一个小的项目，会对这些原则多一些讲解。
今天就讲述到这里吧，没有什么很新的东西，都是为了给后文做准备的，下一篇主要讲述在SOA常常使用的设计模式和架构模式。