软件架构设计之七：软件架构设计

一、本章要点

1）信息系统综合知识。包括软件架构的概念、软件架构的风格、特定领域软件架构、基于架构的软件开发方法、软件架构评估、软件产品线；设计模式的概念、设计模式的组成、模式和软件架构、设计模式分类、设计模式的实现。

2）系统架构设计案例分析。包括软件架构技术、XML技术、基于架构的软件开发过程、架构模型（风格）、特定领域软件架构、基于架构的软件开发方法、架构评估、软件产品线、系统演化、设计模式。

3）系统架构设计论文。

 

二、软件架构概述

1）软件架构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。

2）软件架构是软件设计过程中的一个层次，处理算法与数据结构之上的关于整体系统结构设计和描述方面的一些问题。

3）架构问题包括：总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配特定功能、设计元素的组织、规模和性能、在各设计方案间进行选择等。

4）设计好软件架构是保证软件质量的根本措施，具有以下作用：

  （1）软件架构是项目干系人进行交流的手段。

  （2）软件架构是早期设计决策的体现。

  （3）软件架构是可传递和可重用的模型。

 

三、软件架构建模

1）首要问题是如何表示软件架构，即如何对软件架构建模，可将软件架构的模型分为5种：

  （1）结构模型。以架构的构件、连接器和其他概念来刻画结构，并力图通过结构来反映系统的配置、约束、隐含的假设条件、风格和性质等。核心是架构描述语言。

  （2）框架模型。侧重于描述整体的结构，主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

  （3）动态模型。对结构或框架模型的补充，研究系统“大颗粒”的行为性质，如系统的重新配置或演化。动态可以值系统总体结构的配置、建立或拆除通信信道或计算的过程。

  （4）过程模型。过程模型研究构造系统的步骤和过程，因而结构是遵循某些过程脚本的结果。

  （5）功能模型。该模型认为架构是由一组功能构件按层次组成，下层向上层提供服务。它可看做是一种特殊的框架模型。

2）Kruchten提出的"4+1"视图模型。

  （1）逻辑视图。主要支持系统的功能需求，即系统提供给最终用户的服务。在面向对象技术中，可以用对象模型来代表逻辑视图。

  （2）开发视图。也称为模块视图，主要侧重于软件模块的组织和管理。

  （3）进程视图。侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。

  （4）物理视图。主要考虑如何把软件映射到硬件上，通常要考虑解决系统拓扑结构、系统安装和通信等问题。

  （5）场景。可看作是那些重要系统活动的抽象，它使4个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。

3）逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

 

四、软件架构风格

1）软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。

2）软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomatic paradigm）。

3）软件架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

4）通用架构风格分类如下：

  （1）数据流风格：批处理序列、管道/过滤器。

  （2）调用/返回风格：主程序/子程序、面向对象风格、层次结构。

  （3）独立构件风格：进程通信、事件系统。

  （4）虚拟机风格：解释器、基于规则的系统。

  （5）仓库风格：数据库系统、超文本系统、黑板系统。

1、经典软件架构风格

1）管道/过滤器，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

2）管道/过滤器风格优点如下：

  （1）使得构件具有良好的隐蔽性和高内聚、低耦合的特点。

  （2）允许设计者将整个系统的I/O行为看成是多个过滤器行为的简单合成。

  （3）支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。

  （4）系统维护简单，可扩展性好。新的过滤器可以添加到现有系统中来；旧的可以被改进过的过滤器替换掉。

  （5）允许对一些如吞吐量、死锁等属性的分析。

  （6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。

3）管道/过滤器风格的缺点：

  （1）通常导致进程成为批处理的结构。

  （2）不适合处理交互的应用。

  （3）在数据传输上没有通用的标准，每个过滤器都有解析和合成数据的工作，导致系统性能下降，增加了编写过滤器的复杂性。

4）面向对象风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。

5）面向对象的系统的优点：

  （1）对其他对象隐藏自身的表示，改变一个对象不影响其他对象。

  （2）设计者可将一些数据存取操作问题分解为一些交互的代理程序的集合。

6）面向对象的系统的缺点：

  （1）通过对象标识进行调用，如果对象标识改变了，就必须修改所有明确调用它的对象。

  （2）必须修改所有显示调用它的其他对象，并消除由此带来的副作用。如A使用B，C使用B，那么C对B的使用可能造成对A的影响。

7）基于事件的隐式调用思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。其他构件对此事件进行注册，事件触发导致这些构件中的过程的调用。

8）基于事件的隐式调用系统的优点：

  （1）为软件重用提供强大支持，构件注册到系统事件中即可加入到现存系统。

  （2）为改进系统带来了方便，替换构件不会影响到其他构件的接口。

9）隐式调用系统的主要缺点：

  （1）构件放弃了对系统计算的控制。构件触发事件后，不能确定其他构件是否会响应，不能保证过程被调用的顺序。

  （2）数据交换问题。依靠共享的仓库进行交互时，全局性能和资源管理变成了问题。

  （3）既然过程的语义必须依赖于被处罚时间的上下文约束，那么关于正确性的推理存在问题。

10）分层系统组织成一个层次结构，每一层为上层服务，并作为下层的客户。

11）层次系统的优点：

  （1）支持基于抽象程度递增的系统设计，式设计者可以把一个复杂系统按递增的步骤进行分解。

  （2）支持功能增强，因为每一层至多和相邻的上下层交互，所以功能的改变最多影响相邻的上下层。

  （3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交互使用。

12）层次系统的缺点：

  （1）并不是每个系统都可以很容易地划分为分层的模式。

  （2）很难找到一个合适的、正确的层次抽象方法。

13）仓库系统及知识库，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据结构存储上执行。

14）控制原则的选取产生两个子类：若以输入流某类时间出发进程执行，则仓库是传统型数据库；若中央数据结构的当前状态触发进程执行，则仓库是黑板系统。

15）C2（Component-Connector）架构风格：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

16）C2的特点：

  （1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起。

  （2）所有构件之间的通信是通过连接件为中介的异步消息交换机制来实现的。

  （3）构件相对独立，构件之间依赖性较少。

2、客户端/服务器风格

1）二层C/S架构有三个组成部分：数据库服务器、客户应用程序和网络。

2）服务器负责数据管理，客户程序发送、请求和分析从服务器接收的数据，这是一种胖客户端、瘦服务器的软件架构。

3）二层C/S架构的优点：

  （1）系统的客户程序和服务器构件分别运行于不同计算机上，对硬件和软件变化显示出极大适应性和灵活性，易于系统扩充和缩小。

  （2）功能构件充分隔离，客户层序集中于数据显示和分析，数据库服务器开发集中于数据管理。

  （3）将应用处理任务分布到许多计算机上，节约大量成本。

4）二层C/S架构的缺点：

  （1）开发成本高。对客户端软硬件配置要求较高。

  （2）客户端程序设计复杂。

  （3）信息内容和形式单一，界面基本按数据库的字段解释。

  （4）用户界面风格不一。

  （5）软件移植困难。

  （6）软件维护和升级困难。

  （7）新技术不能轻易应用。

  （8）客户端计算机可直接访问数据库服务器，则其他程序也可设法访问，数据库安全性降低。

3、多层架构风格

1）三层C/S架构总增加了应用服务器，应用逻辑都在此服务器上。

2）三层C/S架构将应用功能分成表示层、功能层和数据层。

3）表示层是应用的用户接口，担负着用户与应用间的对话功能；功能层相当于应用的本体，将具体的业务处理逻辑编入程序中；数据层是DBMS，负责管理对数据库数据的读写。

4）三层C/S架构的优点：

  （1）允许合理划分三层结构的功能，使之在逻辑上保持相对独立性，从而提高系统和软件的可维护性和可扩展性。

  （2）允许更灵活有效地选用相应平台和硬件系统，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。

  （3）三层C/S架构中，应用的各层可并行开发，各层也可以选择各自最适合的开发语言。

  （4）允许充分利用功能层有效地隔离开表示层和数据层，为严格的安全管理奠定了基础。

5）浏览器/服务器（Browser/Server，B/S）风格是上述三层应用结构的一种实现方式。

6）与C/S架构相比，B/S架构有如下优点：

  （1）系统安装、修改和维护全在服务器端解决。

  （2）用户使用系统达到了零客户端的功能，且自动升级。

  （3）踢狗了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放基础。

7）与C/S相比，B/S架构有如下不足：

  （1）缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。

  （2）系统扩展能力差，安全性难以控制。

  （3）在数据查询等相应速度上，要远低于C/S架构。

  （4）数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

4、富因特网应用

RIA（Rich Internet Application，富因特网应用）

1）Flash/Flax

2）Java

3）BWindows

4）Ajax

5）Laszlo

6）XUL（XML User Interface Language）

7）Avalon

5、正交软件架构

1）正交软件架构由组织层和线索的构件构成。

2）层由一组具有相同抽象级别的构件构成；线索是子系统的特例，有完成不同层次功能的构件组成，每一条线索完成整个系统中相对独立的一部分功能。

3）正交软件架构主要特征如下：

  （1）正交软件架构由完成不同功能的n（n>1）个线索（子系统）组成。

  （2）系统具有m（m>1）个不同抽象级别的层。

  （3）线索之间是互相独立的（正交的）。

  （4）系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）。

4）正交软件架构具有以下优点：

  （1）结构清晰，易于理解。（2）易修改，可维护性强。（3）可移植性强，重用粒度大。

6、基于层次消息总线的架构

1）层次消息总线（Hierarchy Message Bus，HMB）的架构风格基于层次消息总线、支持构件的分布和冰法，构件之间通过消息总线进行通信。

2）消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回。

3）各个构件挂接在消息总线上，向总线登记感兴趣的消息类型。消息是构件之间通信的唯一方式。

 

五、特定领域软件架构

   特定领域软件架构（Domain Specific Software Architecture， DSSA）是在一个特定应用领域中为一组应用提供组织架构参考的标准软件架构，其目标是支持在一个特定领域中多个应用的生成。

  DSSA中领域的含义：

  （1）垂直域。定义一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件架构。

  （2）水平域。定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用架构。

1、DSSA的基本活动

1）领域分析。主要目的是获得领域模型。领域模型描述领域中系统之间的共同的需求，所描述的需求为领域需求。

2）领域设计。主要目的是获得DSSA。DDSA描述在领域模型中表示需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统需求的一个高层次的设计。

3）领域实现。主要目的是依据领域模型及DSSA开发和组织可重用信息。

2、DSSA的建立过程

DSSA的建立过程是并发的、递归的、反复的，或者说它是螺旋的。

1）定义领域范围。主要输出是领域中的应用需要满足一系列用户的需求。

2）定义领域特定的元素。编译领域字典和领域术语的同义词词典。

3）定义领域特定的设计和实现需求约束。

4）定义领域模型和架构。

5）产生、搜集可重用的产品单元。

3、DSSA与架构风格的比较

1）两者的出发点不同，是互相正交的方法和学科分支：以问题域为出发点的DSSA和一解决域为出发点的软件架构风格。

2）DSSA只对某一个领域进行设计专家知识的提取、存储和组织，但可以同时使用多种架构风格；而在某个架构风格中进行架构设计专家知识的组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。

3）DSSA的特定领域参考架构通常选用一个或多个适合所研究领域的架构风格。不同参考架构之间的基础和概念有较少的共同点。

4）架构风格的定义和该风格应用的领域是正交的，提取的设计知识比用DSSA提取的设计专家知识的应用范围要广。

5）DSSA和架构风格是互为补充的两种技术。

六、架构设计与演化

一个好的软件架构应该可以创建或再创建功能、用户界面和问题域模型，演化原型以满足新的软件需求。不但软件系统以原型方式演化，架构本身也以原型方式演化。

1、设计和演化过程

基于架构的软件开发过程可以分为独立的两个阶段：

1）实验原型阶段。此阶段首要问题是要获得对系统支持的问题域的理解。

2）演化开发阶段。重点在最终产品的开发上。

2、实验原型阶段

1）第一个开发周期没有具体明确的目标，一个小组创建图形用户界面，另一个小组创建一个问题域模型。

2）第二个开发周期任务是设计和建立一个软件架构，此软件架构特征如下：

  （1）必须足够灵活，能包含现有元素且能包含新增功能。

  （2）必须提供一个相当稳定的结构，原型在此实验原型阶段进行演化。

  （3）必须支持一个高效的开发组织，允许所有开发人员并行地在原型的基础上进行开发。

3）第二个开发周期细分为5个小阶段：

  （1）标识构件：生成类图、对类进行分组、把类打包成构件。

  （2）提出软件架构模型。

  （3）把已标识的构件映射到软件架构中。

  （4）分析构件之间的相互作用。

  （5）产生软件架构。

3、演化开发阶段

8个步骤：

（1）需求变动归类（2）制订架构演化计划（3）修改、增加或删除构件（4）更新构件的相互作用（5）产生演化后的架构（6）迭代（3）~（5）（7）对以上步骤进行确认（8）对所做的标记进行处理

七、基于架构的软件开发

传统软件开发过程包括问题定义、需求分析、软件设计、软件实现及软件测试等，软件架构的建立应位于需求分析之后，概要设计之前。此模型存在开发效率不高，不能很友好地支持软件重用等缺点，基于架构的软件开发模型可以弥补这个缺点，它有如下几个子过程：

1）架构需求：需求获取、标识构件和需求评审。

2）架构设计：提出软件架构模型、把已标识的构件映射到软件架构中、分析构件之间的相互作用、产生软件架构及设计评审。可迭代。

3）架构文档化：输出架构需求规格说明和测试架构需求的质量设计说明书。

4）架构复审。架构设计、文档化和复审是一个迭代过程。

5）架构实现。

6）架构演化。

八、软件架构评估

在架构评估过程中，评估人员所关注的是系统的质量属性。敏感点和权衡点是关键的架构决策。

敏感点是一个或多个构件（和/或构件之间的关系）的特性。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

1、主要的评估方式

1）基于调查问卷或检查表的评估方式。

2）基于场景的评估方式。主要应用在架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。采用刺激、环境和响应来描述。刺激时场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激作出反应的。

3）基于度量的评估方式。度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数和构件个数。首先，建立质量属性和度量之间的映射原则；然后，从软件架构文档中获取度量信息；最后，根据映射原则分析推导出系统的某些质量属性。

4）比较如下：

2、ATAM评估方式

1）步骤：

  （1）描述ATAM方法（2）描述业务动机（3）描述架构（4）确定架构方法（5）生成质量属性效用树（6）分析架构方法（7）讨论和对场景分级（8）分析架构方法，测试步骤（9）描述评估结果

2）第一个阶段以架构为中心，重点是获取架构信息并进行分析；第二个阶段以项目干系人为中心，重点是获取项目干系人的观点，验证第一个阶段的结果。

3、SAAM评估方式

1）步骤：

  （1）形成场景（2）描述架构（3）对场景进行分类和确定优先级（4）对间接场景的单个评估（5）评估场景的相互作用（6）形成总体评估

九、软件产品线

1）软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。

2）软件产品线主要由两部分组成：核心资源和产品集合。

3）软件产品线开发有4个基本技术特点，即过程驱动、特定领域、技术支持和架构为中心。

1、产品线的过程模型

1）双生命周期模型

来自STARS，分成两个重叠的生命周期：领域工程和应用工程。

领域工程主要任务：

  （1）领域分析，利用现有系统的设计、架构和需求建立领域模型。

  （2）领域设计，用领域模型确定领域/产品线的共性和可变性，为产品线设计架构。

  （3）领域实现，基于领域架构开发领域可重用资源（构件、文档、代码生成器）。

应用工程在领域工程结果基础上构造新产品：

  （1）需求分析，划分领域公共需求和独特需求，得出系统说明书。

  （2）系统设计，在领域架构基础上，结合系统独特需求设计应用的软件架构。

  （3）系统实现，按应用架构，用领域可重用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构件新的系统。

领域工程从应用工程中获得反馈或结合新产品的需求进入又一次周期性发展，称此为产品线的演化。

2）SEI模型

基本活动分为三部分，分别是核心资源开发（即领域工程）、产品开发（即应用工程）和管理。

主要特点：

  （1）循环重复是产品线开发过程的特征，也是核心资源开发、产品线开发以及核心资源和产品之间协作的特征。

  （2）核心资源开发和产品开发没有先后之分。

  （3）管理活动协调整个产品线开发过程的各个活动，对产品线的成败负责。

  （4）核心资源开发和产品开发是两个互动的过程，三个活动和整个产品线开发之间也是双向互动的。

3）三生命周期模型

为有多个产品线的大型企业增加企业工程流程，以便在企业范围内对所有资源的创建、设计和重用提供合理规划。

2、产品线的组织结构

1）软件产品线开发过程分为领域工程和应用工程，相应的软件开发组织结构也应该有两个基本组成部分，即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。

2）组织模型：开发部门、商务部门、领域工程部门和层次领域工程部门。

3）动态的组织结构，根据产品线的建立方式和发展阶段、成熟程度的变化，有一种组织结构向另一种组织结构演变。

3、产品线的建立方式

划分依据：用演化方式还是革命方式引入产品线开发过程；基于现有产品还是开发全新的产品线。

四种方式的基本特征如下：

十、设计模式

1）模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。

2）四个基本成分是：模式名称、问题、解决方案和效果。

1、模式和软件架构

判断模式成功的准则是在多大程度上达到了软件工程的目标。

1）模式作为架构构造块，用已定义属性进行特定的软件架构的构造。

2）构造异构架构，单个模式不能完成一个完整的软件架构的详细构造，模式系统统一描述模式，对它们分类，说明它们之间的交互。模式目录则相反，不描述交互关系。

3）模式和方法，模式的实现指南可视为一种微方法，提供步骤来解决软件开发中的具体再现问题。

4）模式的实现，并非仅有面向对象风格，几乎所有编程范例可在几乎所有编程语言中来实现模式。

2、设计模式目录

十一、可扩展标记语言

1）与HTML一样，XML从元语SGML（Standard Generalized Markup Language，标准通用标记语言）中派生出来。

2）主要作用：

  （1）实现不同数据的集成（2）使用于多种应用环境（3）客户端数据处理与计算（4）数据显示多样化（5）局部数据更新

3）相关技术：Schema、XSL和XLL（eXtensibel Link Language，可扩展连接语言）

十二、Web服务架构

Web Service是解决应用程序之间相互通信的一项技术。Web服务是描述一系列操作的接口，使用标准的、规范的XML描述接口。

1、Web服务模型

对于Web服务模型中的操作，包含以下三种：发布服务描述、查找服务描述、根据服务描述绑定或调用服务。

2、Web服务协议堆栈

1）SOAP（Simple Object Access Protocol，简单对象访问协议），基于XML，仅仅是一个对象通信协议，与应用平台无关。可理解为HTTP+XML+RPC。

2）WSDL包含了一套基于XML的语法，将Web服务描述为能够进行消息交换的服务访问点的集合，从而满足了这种需求。

3）UDDI（Universal Decription Discovery and Integration，统一描述、发现和集成）tigongleyizhongWeb服务的发布、查找和定位方法。

3、Web服务架构的优势

1）高度的通用性和易用性。

2）完全的平台、语言独立性。

3）高度的组装性和集成性。

4）容易部署和发布。

十三、面向服务的架构

1、SOA概念

面向服务的架构（Service-Oriented Architecture，SOA）并不仅是一种现成的技术，还是一种架构和组织IT基础结构及业务功能的方法，是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。

SOA是一种粗粒度、松耦合的服务架构，其服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型，有如下特征：

1）松散耦合

2）粗粒度服务

3）标准化接口

2、面向服务的分析与设计

1）从概念上讲，SOA有三个主要的抽象级别，分别是操作、服务和业务流程。

2）从建模的观点来看，SOA带来的主要挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。

3）OOAD（OOA和OOD）、企业架构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）分别从基础设计层、应用结构层和业务组织层三个层次上为SOAD提供了理论支撑。

  （1）底层设计层采用OOA和OOD的思想，主要目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的底层服务构件。

  （2）架构层采用EA的理论框架，以努力实现单独的解决方案之间架构的一致性。

  （3）业务组织层采用BPM规则，如UML，SOAD的流程建模必须与设计用例保持同步。

4）SOA是一种企业系统架构，它是从企业的业务需求开始的，比其他方法优势在于提供了业务的敏捷性。原则：业务驱动服务，服务驱动技术；业务敏捷是基本的业务需求。

3、Web服务实现SOA

1）底层传输层，HTTP、JMS和SMTP作为Web服务的消息传输协议。

2）服务通信协议层，定义服务之间进行消息传递所需的技术标准，如SOAP协议、REST协议。

3）服务描述层，统一描述服务的接口与消息交换方式，相关标准WSDL。

4）服务层，包装遗留系统，并通过发布WSDL接口描述被定位和调用。

5）业务流程层，支持服务发现，服务调用和点到点服务调用。相关标准WS-BPEL。

6）服务注册层，使服务提供者能通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息，相关标准UDDI。

十四、企业服务总线（Enterprise Service Bus，ESB）

由中间件技术实现并支持SOA的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。

1）使用ESB，可在不改变现有基础结构的情况下让几代技术实现互操作，在几乎不更改代码的情况下以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。并且，不同的应用程序可以同时使用同一服务，在应用程序或者数据发生变化时无须改动服务代码。

2）面向服务的企业应用集成机制：

  （1）ESB允许在多种形式下通过像HTTP/SOAP和JMS总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或接卖弄提供基础设施。

  （2）ESB提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息道不同的目的地。

  （3）ESB挺高安全和拥有者机制以保证消息和服务使用的认证、授权以及完整性。

  （4）ESB的服务质量也是可以区分企业集成技术平台优劣的关键标准之一。

3）ESB的优点

  （1）扩展的、基于标准的连接。

  （2）灵活的、服务导向的应用组合。

  （3）提高重用率，降低成本。

  （4）减少市场反应时间，提高生产率。