（计算机应用技术专业论文）基于企业服务总线的以服务为中心的集成的研究与应用.pdf

摘要 本文从微观和宏观角度分析了e a i ( e n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ，企业 应用集成) 的推动因素，以及集成解决方案的发展沿草，并阐述了s o i ( s e r v i c e o r i e n t e di n t e g r a t i o n ，以服务为中心的集成) 这一新的集成架构是如何 优越于之前的集成技术。 整篇文章以c r m ( c u s t o m e rr e l a t i o n s h i pm a n a g e m e n t ，客户关系管理系统) e r p ( e n t e r p r i s er e s o u r c ep l a n n i n g ，企业资源规划系统) 业务整合项目的开发过 程为基础，阐述了如何利用e s b ( e n t e r p r i s es e r v i c eb u s ，企业服务总线) 来实 施以服务为中心的集成。本文所做的工作主要有以下几点： 1 详细分析了s o l 的开发过程，具体实施方法及所用到的关键技术 2 采用面向对象的方法对c r m e r p 业务整合项目进行了需求分析，设计 和实现工作：具体阐述了如何利用企业服务总线这一基础设施来实现 s o i 的整个过程，并在其中研究了企业服务总线的工作机制 3 对c r m e r p 业务整合项目做了如下的经验总结：给出了一个通用而简 洁的s o i 架构模板，并对架构模板的各层进行了详细描述；企业集成中 应尽早引入统一的权限管理；讨论了如何确定业务服务的粒度；企业实 施s o i 时可以e s b 为突破口；如何合理利用开源项目来支持企业集成。 关键词：服务集成企业服务总线 r e s e a r c ha n d a p p l i c a t i o no f s o ib a s e do ne s b a b s t r a c t t h i sp a p e ra n a l y z e st h ep u s h i n gf a c t o r so fe a if r o mm i c r oa n dm a c r oa t t i t u d e s ， a n dt h ed e v e l o p i n gp r o c e s so f e a i ( e n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ) s o l u t i o n t h e n e x p l a i n sw h ys o l ( s e r v i c e - o r i e n t e di n t e g r a t i o n ) ，t h i sn e w e a ia r c h i t e c t u r e ，i sb e t t e r t h a nt h ei n t e g r a t i o nt e c h n i q u e sb e f o r e b a s e do nt h ec r m ( c u s t o m e rr e l a t i o n s h i pm a n a g e m e n t ) e r p ( e n t e r p r i s e r e s o u r c ep l a n ) b u s i n e s si n t e g r a t i o np r o j e c t ，t h ew h o l ep a p e rd i s c u s s e sh o wt ou s e e s b ( e n t e r p r i s es e r v i c eb u s ) t oi m p l e m e n ts o i t h em a i nc o n t e n t so ft h i sp a p e r i n c l u d e s ： 1 a n a l y z i n gt h ed e v e l o p i n gp r o c e s so fs o l ，i m p l e m e n t a t i o nm e t h o d sa n dc r i t i c a l t e c h n i q u e su s e d 2 u s i n go b j e c t - o r i e n t e dm e t h o d t od or e q u i r e m e n ta n a l y s i s ，d e s i g n i n ga n d i m p l e m e n t a t i o no fc r m e r pb u s i n e s si n t e g r a t i o np r o j e c t d e s c r i b i n gh o w t o i m p l e m e n ts o lb yu s i n gt h ee s bi n f r a s t r u c t u r e i nd e t a i l ，a n dr e s e a r c h i n gt h e w o r k i n gm e c h a n i s mo f e s b 3 s u m m a r i z i n gt h ec r m e r pb u s i n e s si n t e g r a t i o np r o j e c t ，e x p e r i e n c e s a r e c o n c l u d e db e l o w ：p r o v i d i n gau n i v e r s a la n dt i g h ts o ia r c h i t e c t u r et e m p l a t e ，a n d i n t r o d u c i n ge a c hl a y e rt h o r o u g h l y ；u n i f o r mr i g h tm a n a g e m e n ts h o u l db ei m p o r t e d i n t oe a ia se a r l ya sp o s s i b l e ；h o wt od e c i d et h eg r a n u l a r i t yo fb u s i n e s ss e r v i c e ； u s i n ge s b a st h eb r e a kp o i n tt oi m p l e m e n ts o l ；h o wt om a k eb e s tu s eo fo p e n s o u r c ep r o j e c t sf o re a i k e yw o r d ：w e bs e r v i c e ，i n t e g r a t i o n ，e n t e r p r i s es e r v i c eb u s i i 西北大学学位论文知识产权声明书 本人完全了解学校有关保护知识产权的规定，即：研究生在校攻 读学位期间论文工作的知识产权单位属于西北大学。学校有权保留并 向国家有关部门或机构送交论文的复印件和电子版。本人允许论文被 查阅和借阅。学校可以将本学位论文的全部或部分内容编入有关数据 库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学 位论文。同时，本人保证，毕业后结合学位论文研究课题再撰写的文 章一律注明作者单位为西北大学。 保密论文待解密后适用本声明。 ， 学位论文作者签名：捌指导教师签名： 墨生 坼月f g 目6 1 年月昭日 西北大学学位论文独创性声明 本人声明：所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，本论文不包含其他入已经发表或撰写过的研究成果，也不包含 为获得西北大学或其它教育机构的学位或证二炜而使用过的材料。与我 一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的 说明并表示谢意。 学位论文作者签名 ， 问每6rf ab 第一章绪论 1 1 课题研究背景与意义 “如果有人跟你说企业应用集成是件很轻松的事，这人要么是聪明得出奇， 要么是傻得出奇，要么就是出于商业原因希望让你相信他即将兜售的某种东西。” 对于企业集成从来没有简单的答案【l 】 下面从微观和宏观角度来分析企业集成的推动因素。 从微观上来看，推动e a i ( 企业应用集成) 的因素，来自商务和技术两个方 面。从商务的角度，今天企业要在全球化的经济环境中求生存和发展，就必须努 力适应越来越强的竞争和越来越快的变化，这意味着一个企业的业务模型要变得 灵活以快速应变，也就是随需应变。在一个企业的业务模型变得灵活的转型过程 中，需要将业务流程不断地自动化，然后跨部门横向集成它们，并且管理和优化 它们，这意味着支撑这些流程的技术基础。即r r 应用和数据资源等，需要在企 业范围内集成。所以，业务灵活应变的能力是s o i 的驱动因素之一f 2 】。 在技术方面，i t 部门面临着业务部门越来越高的期望值，就是用更少的钱 做更多的事情，但要做得更快、更好，这迫使i t 部门考虑如何最大程度地重用 已有应用的功能和数据资源，来支持新应用的开发。但这种重用面临着如何将高 度异构、分布的各个应用集成起来的难题，s o i 是目前最有效的解决之道。总之， 这种通过重用粗粒度服务而不是在底层编程来开发新应用以满足业务新需求的 方法，使得i t 组织能够以更少的投入、更快的速度、更好的质量来开发应用。 综上所述，可以灵活应变的重用方式，是s o i 的另一个驱动因素。 从宏观上来看，在实施信息化推动工业化国策的今天，以服务为中心的 集成更有其明确的现实意义 9 1 。 1 2 国内外研究现状 大约在2 0 0 3 年中的时候，s o a ( s e r v i c e o r i e n t e da r c h i t e c t u r e ，面向服务的 架构) 的概念逐渐进入人们的视野。目前，s o a 集中在对服务组合、服务协同 和服务管理方面的研究。其中。服务组合己探讨了包括基于类型、q o s 、有向图、 l p e w i n e t 等多种服务组合方法；在服务协同方面，也出现了相应的标准，如b p e l ( b u s i n e s sp r o c e s se x e c u t i o nl a n g u a g e ，业务流程执行语言) ，b p e i a w s ， w s c o o r d i n a t i o n 等；服务管理包括通过包装遗留系统为w e b 服务的方法来协调 管理集成系统和管理w e b 服务两方面，s o i 即为服务管理的一个重要方面。其 中，管理w e b 服务还包括对基础层管理、应用层管理和业务层管理的研究。在 对s o a 集成方法的研究中，目前，服务协同主要是依据业务流程的方法而建立， 具有单调性，还需要扩张多种协同方法，并且服务组合和服务协同的方法常常交 叉覆盖。在管理方法方面，还没有相应的标准出现。在s o a 方面，还有广泛的 研究空间和待解决的问题，如在服务建立协同之后，如何保障服务的可靠性，换 句话说，采用哪些机制能够保障服务的可靠性；随外界环境的变化，组合服务又 如何进化唧。 1 3 主要研究内容及创新点 1 详细分析了s o i 的开发过程，具体实施方法及所用到的关键技术 2 采用面向对象的方法对c r m e r p 业务整合项目进行了需求分析，设计和实 现工作；具体阐述了如何利用企业服务总线这一基础设施来实现s o i 的整个 过程，并在其中研究了企业服务总线的工作机制 3 对c r m e r p 业务整合项目做了如下的经验总结：给出了一个通用而简洁的 s o i 架构模板，并对架构模板的各层进行了详细描述；企业集成中应尽早引 入统一的权限管理；讨论了如何确定业务服务的粒度；企业实施s o i 时可以 e s b 为突破口；如何合理利用开源项目来支持企业集成。 1 4 论文结构安排 本论文如下部分是这样安排的： 第二章介绍了和本论文相关的一些关键技术，如s o l ，e s b ，j b l ( j a v ab u s i n e s s i n t e g r a t i o n ，j a v a 业务集成) 等： 第三、四、五章详细阐述了c r m e r p 业务整合项目的需求及其对应的用例 图、设计原则及设计过程的核心部分及其实现： 2 第六章总结了本论文所做的工作，指出进一步的研究方向 1 5 本章小结 本章首先从微观和宏观的角度分析了s o i 这个课题研究的背景和意义，然 后阐述了课题的国内外发展现状以及本文的主要研究内容及创新点，最后介绍了 整个论文的结构安排。 3 第二章关键技术 2 1 以服务为中心的集成 “以服务为中心的集成”是英文词语”s e r v i c e o r i e n t e di n t e g r a t i o n “的中文翻 译，简称s o i 。它可以定义为：在s o a ( s e r v i c e o r i e n t e d a r c h i t e c t u r e ，以服务 为中心的体系架构) 中，通过服务的交互来集成各企业的r r 资源，如分布的应 用或者数据，帮助企业i t 部门将已有但老旧而不灵活的系统集成起来，释放其 中功能或数据为可重用的服务与业务流程。 通常，完整的s o l 解决方案包括如下要素： 代表应用的功能和数据资源的服务； 提供连接服务的基础设施即企业服务总线( e s b ) ，连接已有应用的连接 器( c o n n e c t o r ) 和适配器( a d a p t e r ) ； 元数据及其管理如服务描述和服务注册管理( s e r v i c er e g i s t r y ) 等； 将服务组合成业务流程的引擎如b p e l 4 w s 引擎； 业务流程管理和业务绩效管理的部分： 一个基于标准的编程模型以及支持它的建模、开发和组装、测试、部署 和管理的端到端工具环境； 2 1 1 集成解决方案的发展沿革 企业应用集成的方法各种各样，初级一点的借助于简单的机制如应用编程接 口，管道、共享目录和文件，或者某些传输协议如f t p 来交换数据和互操作： 高级一点的则使用各种消息中间件来提供消息的传输、转换、合并、路由和分发、 事件的发布和订阅等；分布式计算技术，如c o r b a ，c o m 等，也有较广的使 用。 在初期实践中，应用之间的连接拓扑大多数情况下是点对点的，硬编码的， 所使用的协议是非标准的，功能的提供者和使用者之间是紧耦合的，功能的粒度 通常较细，数据的表示也不统一随着集成复杂度的增长，和实践经验的总结， 开始出现一些从好的实践中总结出来的集成模式，如消息中枢( m e s s a g e 4 b a c k b o n e ) 、信息总线、应用集成中心( a p p l i c a t i o ni n t e g r a t i o nh u b ) ，这些模式 从不同的角度以不同的方式来管理集成的复杂性，但都或多或少地尝试提供一个 集成基础设旌来简化应用之间日趋复杂的连接拓扑，提供异构数据和功能访问方 式之间的转换，甚至提供一致的数据和功能表示与访问方式通过元数据和应用 相关的领域知识，这些集成基础实施提供了很多中介和转换的机制与模式来实现 高级的功能，如路由、动态选择等能力 随着互联网络技术的发展、普及和应用，相关技术和标准，如x m l 和w e b s e r v i c e ，被广为接受，这给应用集成带来了新的发展。企业应用架构的风格开始 朝着以服务为中心的方向发展，而企业应用集成也转向以服务为中心的集成，服 务的描述和访问基于开放一致的标准( 如w s d l ) ，连接应用的基础设施继承了 过去发展的成果，并通过支持开放标准，来提供通用的连接服务，包括基本的服 务如消息传输、转换，事件的发布和订阅，服务的中介( 选择，路由) ，和高级 的服务如安全、事务、服务质量，以及可管理性，来使得服务在一个标准、开放、 可靠、安全、可管理、满足服务质量要求的环境下，以松散耦合的方式相互交户， 根据需求动态地进行企业应用集成，达成非常高程度的灵活应变能力和重用能 力s o i 是对现有集成技术与实践的总结和标准化。 s o l 继承和发展了传统的e a i ，比较而言，s o i 的好处在于： 定义良好而又基于标准的接口服务的描述易于理解，而且标准一致 实现技术和位置的透明提供服务功能的应用，它的位置以及所使用的实 现技术被接口所屏蔽，事实上，不需要一个固定的服务提供者 灵活性一只要服务的接口不变，服务的提供者和服务的使用者都可以变化 而不影响彼此，从而将变化带来的影响减少到了最少 重用能力 渐进式集成在s o l 中，通过将若干已有系统的相关功能转化为服务来进 行集成。随着这些项目的进行，可重用的服务越来越多，最终，新的集成需求将 绝大多数可以通过已有的服务来完成。所以，我们可以从当前重要的集成需求开 始来封装已有系统的功能和开发必要的新服务，以渐进的方式逐步地扩展到整个 企业范围内的集成。更重要的是，由于服务的灵活性，即使已有系统迁移到新的 技术平台，甚至是被替代，都不会影响到依赖于这个应用所提供功能的那些应用， 从而保证了集成对变化的适应能力，使得业务灵活性有一个坚实的基础。这也意 味着从传统规模大、投入大、周期长、见效慢、风险高、专有技术，转向小步快 跑、见效迅速、风险低、基于标准的集成方式这对于如今面对业务需求快速变 化的1 1 r 机构来说，s o i 在投入和工程方面的好处，是非常吸引人的 2 1 2 关于s o a 目前，关于由s o a 和它的w e b 服务实现所表现的时机有许多传言一有一 些是有事实根据的，但是一些却没有什么事实依据。分析家已经预言，博学者已 经声称，教授已经讲演，公司已经匆忙地卖他们的产品，作为s o a 产品一经 常失去s o a 不是一个产品的要点。它是业务和玎之间的桥梁，通过一系列使 用一些设计原则、模式和技术的依赖于业务的r r 服务来实现 3 1 z d n e t 最近报道说，“g a r t n e r 预言到了2 0 0 8 年，至少6 0 0 , 6 的企业将使 用s o a 作为创建任务苛刻的应用程序和过程的指导原则” 开发和实现s o a 有很大的需求。因此如果s o a 不仅仅和产品和帮助实现 它的标准相关( 比如通过w e b 服务) ，那么为了实现s o a 你还需要什么附加 的元素吗? 然而，你还需要重视一些额外的重要的需要考虑的事项首先，目前的 o o a d 方法没有定位s o a 三个重要的元素：服务，流，和实现服务的组件。 你同样需要可以明确定位鉴别、制定和实现服务所需的技术和过程，它们的流程 和组合，以及实现和确保所需服务质量的企业级组件 第二，需要进行范例的替换，以便更好的区分s o a 的两个关键角色之间的 截然不同的需求：服务提供者和服务消费者。第三，假设为一个企业或者业务线 构建的应用程序，现在必须被提升到一个供应链中使用，并且公开给合作伙伴， 这些合作伙伴可能组合、联合和封装应用程序到一个新的应用程序中。这是服务 生态系统或者服务价值网的概念。 这是仅从“分布式对象”的一个微小的进步。它是关于通过网络作用创造的 价值：例如，当合作伙伴利用了a m a z o n c o r n 与g o o g l e 搜索的联合，并且与 e b a y 服务结合在一起，来构建他们自己的混合解决方案。或者当旅行社深入到 6 机票预订系统，并且与汽车租赁公司以及宾馆相互协调，更新他们的记录并且将 旅行计划发送到你的电子档案中无论什么样的应用程序，你如果想成功地创建 s o a ，需要的都不仅仅是好的工具和标准你需要一些规范的步骤来支持你的 s o a 生命周期；用来分析、设计、实现服务、流程和组件的技术 关于s o a 的概念，你可以找到很多的文章从不同的角度来描述它，不同的 软件提供商也有不同的定义方式。b e a 有流体计算，微软有i n d i g o 和 8 0 a - b u i l d i n g ，s a p 有e s a 每个人都可以从不同的视角来理解s o a ，从程 序员的角度，s o a 是一种全新的开发技术，新的组件模型，比如说w e bs e r v i c e ； 从架构设计师的角度，s o a 就是一种新的设计模式，方法学；从业务分析人员 的角度，s o a 就是基于标准的业务应用服务从概念的角度，m m 对s o a 的定 义是最为全面的，既s o a 是一种构造分布式系统的方法，它将业务应用功能以 服务的形式提供给最终用户应用或其他服务。s o a 包括如下要素 4 1 ： 一个体系架构，用开放的标准将软件资产( a s s e t ) 化为服务 提供标准的方法来表示软件资产及其交互 单独的软件资产作为构造单元，被重复使用来开发其他应用 将关注点从细节实现转移到应g ( a p p l i c a t i o n ) 组装 整合企业外部的应用( b 2 b ) 的方式 开发( 现在) 和整合( 未来) 的统一 站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、 易维护性、易管理等多方面的更高要求。让我们通过回顾软件开发的演化过程来 看一看s o a 出现的必然性： 面向机器语言( m o n o l i t h i c ) 的开发模式：需要根据不同平台的机器语言来开 发代码。 面向过程( p r o c e d u r e ) 的开发模式：独立于机器的程序语言( c ，p a s c a l 等) 使开 发过程变得简单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。 面向对象( o b j e c t ) 的开发模式：用更接近现实的对象来表述一个相对完整的 事物。面向对象的语言( s m a l l t a l k ，j a v a 等) ，提供了更抽象的封装和重用模式。 面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自 然思维方式。 7 面向组件( c o m p o n e n t ) 的模式：随着软件开发规模的扩大，在涉及分布式、 异构等复杂特征的环境中，代码级别的重用性差，可维护性差，效率低的弱点是 不可逾越的，因此人们以架构运行环境( 如n e t ，j 2 e e 等) 来提供完善的支撑平台，。 从而把开发者解放出来，更专注于业务核心的开发而这些业务功能( b u s i n e s s f u n c t i o n ) 以组件的形式f o c o m ，e i b 等) 发布运行在架构运行环境中。软件开发 的重用模式也上升到业务组件的级别 面向服务( s o a ) 的模式；当软件的使用范围扩展到更广阔的范围，往往会面 对更加复杂的r r 环境和更加灵活多变的需求。服务( s e r v i c e ) 的概念出现了，人 们将应用( a p p l i c a t i o n ) 以业务服务( b u s i n e s ss e r v i c e ) 的形式公布出来供别人使用， 而完全不需要去考虑这些业务服务运行在哪一个架构体系上，因为所有的服务都 讲着同样的语言s o a 考虑了业务发展的长期性，体现了“变化就是永恒”的 思想。s o a 的核心体现在企业应用或者业务功能上的“重用”和“互操作”，而 不再把r r 与业务对立起来，这可以被视为在r r 驱动业务的方向上迈出的重要一 步 。， 我们注意到，s o a 同样也强调重用( r e u s e ) ， 但是相对于传统的代码重用， 对象重用，和部件重用，s o a 的重用粒度更粗。s o a 的重用在于业务级的应用， 即服务的重用，这与软件的发展规律是相一致的在软件发展的过程中，软件重 用的对象越来越接近我们的现实生活。通过部件的重用，软件的开发更具效率， 并且开始试图用组件表达业务模式但是，i t 人员仍很难对业务人员解释清楚 i t 结构怎样映射到业务模型上然而，r r 架构与业务模型的弥合是不可避免的 方向。现代企业的业务环境所面临的最大挑战就是变化，规则在变，需求在变， 而对变化做出最快的反应，尽快地适应变化，成为企业占得先机，成功运作的关 键。很多企业的业务环境依赖于他们的r r 架构，因此，i t 部门往往直接承载了 业务变化带来的压力。每一个具体的业务变化，都直接反应到对现有的r r 平台 的要求：要么企业1 1 r 架构本身对变化自适应，要么r r 架构能够在短时间内根据 新的业务规则做出调整这就是s o a 架构提出的根本原因，我们需要一种更加 贴近业务的r r 架构，能够直接描绘业务，对那些不懂r r 技术的业务领域专家来 说，业务服务却是他们最熟悉的，也就是说是s o a 把软件重用的对象从1 1 r 人员 上升到了业务人员。因此，我们可以说s o a 与其它的模式相比，最大的进步在 8 于它与业务的关联性，“服务”对应到实际业务。1 1 r 通过“服务”与业务发生了 密切的关系，业务人员和r r 人员都可以专注于业务逻辑的实现，而共同的语言 就是“服务” 但不是什么场合都适用s o a 通常来讲，s o a 适用于较为复杂的i t 架构， 经常需要与外部复杂的r r 环境交互，并且需要快速地应对频繁发生的业务变化。 就像你不可能在控制洗衣机的芯片上使用e j b 开发一样，如果你的i t 环境规模 很小，足以灵活地应对变化，不需要与其它的异构r r 环境频繁交互，那么s o a 带来的好处就不足以抵消它给你带来的系统复杂性但是，即令如此，你也并没 有被完全排除在s o a 的大趋势之外s o a 是如此地倍受瞩且，我们可以预见到 它的迅猛发展，因此即使你的内部r r 架构本身并不是基于s o a 的，你也还有机 会参与到未来的s o a 架构中去例如，将你的某个业务以服务的形式发布到某 个外部s o a 平台上供别人使用。作为第三方s o a 平台的一个服务提供者( s e r v i e 宅 p r o v i d e 0 存在。 在选择s o a 的实施方案时，要记住，软件的具体实现技术诸如w e b 服务与 s o a 是两回事，s o a 是一个概念，方法学，或者用一个更时髦的词：一种模型 而w e b 服务呢? 它是一种具体的实现技术，就像e j b 一样。s o a w e b 服务 不过公平地讲，w e b 服务倒确实是目前最适合实现s o a 的技术之一，用w e b 服 务来封装业务服务是个不错的选择。因为w e b 服务是标准的，w s i 协议保证了 来自不同厂商的w e b 服务即使运行在不同的平台上，底层的实现机理不同也可 以顺利交互，这是以前的任何一种技术如c o r b a ，e j b ，或d c o m 都不能做到 的。而且，w e b 服务的定义与实现是分开描述的，即松散耦合，因此，可以很方 便地替换服务的内在实现而不会对现有的系统造成任何冲击，这也极大地促进了 1 1 r 架构的灵活性。 s o a 架构有如下基本的要求： 1 s o a 在相对较租的粒度上对应用服务或业务模块进行封装与重用： 2 服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无 关； 3 灵活的架构服务的实现细节，服务的位置乃至服务请求的底层协议都应 该透明； 9 2 1 3s o a 的概念模型 这个概念基于一种架构样式，该样式在三个主要参与者之间定义了交互模 型：服务提供者，公布服务描述并且实现服务，服务消费者，它既可以使用统一 资源标记符( u r i ) 来直接使用服务描述，也可以在服务注册中心来查找服务描 述并且绑定和调用服务。服务代理提供和维护服务注册中心，然而现在并没有通 用公共注册中心。 图2 1 是一个显示了这些关系的元模型。 2 2 企业服务总线 匿三习 匕僦剑 图2 1s o a 架构样式的概念模型i 在s o a 中，我们还需要这样一个中间层，能够帮助实现在s o a 架构中不同 服务之间的智能化管理最容易想到的是这样一个h u b s p o k e 结构，在s o a 架 构中的各服务之间设置一个类似于h u b 的中间件，由它充当整个s o a 架构的中 央管理器的作用。请看图2 2 ，现在服务的请求者和提供者之间有了一个智能的 中转站，服务的请求者不再需要了解服务提供者的细节。事实上，传统的e a i 就是通过这样一种方式来试图解决企业内部的应用整合问题1 1 2 1 。 1 0 图2 2h u b - s p o k e 结构中间件1 4 l e a i 的目标是支持对现有r r 系统的重新利用，通过e a i 技术能够将不同的 软件和系统串联起来，延长这些应用系统的生命周期【1 3 】。传统的e a i ，往往使用 如c o r b a 和c o m 等消息中间件进行分布式，跨平台的程序交互，修改企业资 源规划以达到新的目标，使用中间件、x m l 等方法来进行数据分配。因此，实 际上传统的e a i 是部件级的重用。很不幸的是，基于部件的架构没有统一的标 准，因此，各个厂商都有各自不同的e a i 解决方案，你会看到各种各样的中间 件平台。如果e a i 碰到了异构的r r 环境，就必须分别考虑怎样在各个不同的中 间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。因此， 你所见过的大多数传统e a i 解决方案都比较笨重。 再回顾一下我们上面介绍过的s o a 的应用场景：复杂的企业级架构。如果 我们选择h u b 的模式来构建s o a 基础架构，从纯粹逻辑的角度，可能会出现哪 些问题呢? 首先，整个s o a 架构的性能，如果每个服务的请求都经过中央h u b 的中转，那么h u b 的负担会很重，速度会随着参与者的增多而愈来愈慢：其次， 这样的系统会很脆弱，一旦h u b 出错，整个s o a 架构都会瘫痪；最后，这样的 架构会破坏s o a 的开放性原则r 参与者运行在一个相对封闭的环境中，扩展起 来十分麻烦。因此，这也不是理想的s o a 架构【l4 】。 好了，现在该企业服务总线( e n t e r p r i s es e r v i c eb u s ，以下简称e s b ) 登场了， 请看我们的正解，如图2 3 所示： 图2 3 使用e s b 来实现s o a 架构【4 l 它与前面的h u b 结构有什么不同呢? 首先，它比单一h u b 的形式更开放， 总线结构有无限扩展的可能；其次，真正体现了s o a 的理念，一切皆为服务， 服务在总线u s ) 中处于平等的地位【1 5 1 即使我们需要一些h u b ，那么它们也是 以某种服务的形式部署在总线上，相比上面的结构要灵活的多。这就是e s b ，我 们需要给它一个明确的定义：e s b 是一种在松散耦合的服务和应用之间标准的集 成方式。它可以作用于： 面向服务的架构- 分布式的应用由可重用的服务组成 面向消息的架构一应用之间通过e s b 发送和接受消息 事件驱动的架构应用之间异步地产生和接收消息 很不幸，上面的定义看上去很拗口，我们暂且用一句较通俗的话来描述它： e s b 就是在s o a 架构中实现服务间智能化集成与管理的中介。而它与s o a 的关 系要相对好理解一些：e s b 是逻辑上与s o a 所遵循的基本原则保持一致的服务 集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的 功能。可以这样说，e s b 是特定环境下( s o a 架构中) 实施e a i 的方式：首先， 在e s b 系统中，被集成的对象被明确定义为服务，而不是传统e a i 中各种各样 的中间件平台，这样就极大简化了在集成异构性上的考虑，因为不管有怎样的应 用底层实现，只要是s o a 架构中的服务，它就一定是基于标准的。 其次，e s b 明确强调消息( m e s s a g e ) 处理在集成过程中的作用，这里的消息 指的是应用环境中被集成对象之间的沟通。以往传统的e a i 实施中碰到的最大 的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的e a i 系统，必须能够对系统范畴内的任何一种消息进行解析。传统的e a i 系统中的 消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如a p i 的方式【l “。因此尽管消息处理本身很重要，但消息的直接处理不会是传统e a i 系统的核心。e s b 系统由于集成对象统一到服务，消息在应用服务之间传递时格 式是标准的，直接面向消息的处理方式成为可能如果e s b 能够在底层支持现 有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通 过消息的标准格式定义来进行这样，在e s b 中，对消息的处理就会成为e s b 的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是e s b 中总 线( b u s ) 功能的体现。其实，总线的概念并不新鲜，传统的e a i 系统中，也曾经 提出过信息总线的概念，通过某种中间件平台，如c o r b a 来连接企业信息孤岛， 但是，e s b 的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化 集成基础架构。 最后，事件驱动成为e s b 的重要特征。通常服务之间传递的消息有两种形 式，一种是调用( c a l l ) ，即请求回应方式，这是常见的同步模式。还有一种我 们称之为单路消息( o n e - w a y ) ，它的目的往往是触发异步的事件，发送者不需要 马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间 的消息交互也是e s b 必须支持的。除此之外，e s b 的很多功能都可以利用这种 机制来实现，例如，s o a 中服务的性能监控等基础架构功能，需要通过e s b 来 提供数据，当服务的请求通过e s b 中转的时候，e s b 很容易通过事件驱动机制 向s o a 的基础架构服务传递信息。 企业服务总线是过去消息中间件的发展，e s b 采用了“总线”这样一种模 式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持 应用之间在消息、事件和服务的级别上动态地互联互通。e s b 对用户是透明的。 e s b 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求 者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总 结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力， 以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力， 包括对安全的支持、服务质量保证、可管理性和负载平衡等。e s b 所提供的基 于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标 准的方式来访问的服务；当请求者来请求一个服务时，e s b 中这种中介转化过 程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、 选择一个服务，消息的传递、路由和转换、协议的转换这种中介过程，是e s b 借助于服务注册管理以及问题域相关的知识( 如业务方面的一些规则等) 自动进 行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的 技术基础，使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方 在保持接口不变的情况下，各自可以独立地演变所以，e s b 采用总线结构模 式简化了应用之问的集成拓扑，通过源自实践的模式，提供了基于标准的通用连 接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互， 从而在不同层次上使得s o i 解决方案是一个松散耦合、灵活的架构需要注意 的是，e s b 是一种架构模式，不能简单地等同于特定的技术或者产品，但实现 e s b 确实需要各种产品在运行时和工具方面的支持 关于e s b ，目前还没有被一致接受的标准旧。我们可以通过选择成熟的e a i 中间件来实现服务的集成与互操作性这样做的好处是你的开发过程会很顺畅， 因为它已经足够稳定且有丰富的工具支持通常这样的e a i 产品在目前阶段都 还不是基于开放的标准，例如i b m 的w e b s p h e r e m q 5 3 ，作为m m e a i 实现e s b 的消息平台，就不是开放的标准。如果一定要选择开放标准的e s b 实现方式， w e b 服务加上w s 协议几乎是我们唯一的选择，但毕竟s o a 、e s b 仍处于起 步的阶段，一方面我们还没有很成熟的产品支持所有的w s 协议，另一方面这 些w s - 协议本身还处在频繁变化的阶段因此当你选择e s b 实施方案的时候， 最好考虑平衡e s b 实施、开发的工作量【1 8 l 。 2 3j a v a 业务集成 j b i ( j a v ab u s i n e s si n t e g r a t i o n ，j a v a 业务集成) 通过创建一个基于统一标准 的架构来解决e a i 和b 2 b 集成领域标准众多的问题。这个架构允许第三方构件 通过“插入”的方式连接进来( 如图2 4 所示) ，并允许这些构件以一种可预见 的，可靠的仲裁消息交换方式进行交互( 如图2 5 所示) ，而不管它们是由哪家 厂商提供的。当前版本( 1 0 ) 是2 0 0 5 年8 月通过的j s r ( j a v a j a v a 规范需求) 2 0 8 定案。商业和开源界都欢迎j b i 成为他们e s b 产品的集成标准。 图2 4 第三方构件通过“插入”的方式连接至j b i l 5 1 图2 5 仲裁消息交换：高层消息序列图【5 1 j b i 环境的架构 j b i 定义了基于插件方式的架构，以便服务能融入“j b i 运行时”环境。j b i 提供了详细的接口，使服务能与“j b i 运行时”环境交互。这些服务要为“j b i 运 行时”环境暴露接口，以便“j b i 运行时”环境为服务路由消息，也即j b i 定义 了一种环境，在这种环境下，插件组件使用一种直接基于w s d l 2 0 的服务模型 来进行交互。所以，“j b i 运行时”环境在部署在s o a 环境中的服务间扮演着 仲裁者的角色 1 9 】。 在同一m 中，“j b i 运行时”核心主要包括如下组件： 组件框架：组件框架把不同类型的组件部署到“j b i 运行时”。 归一化的消息路由器：归化的消息路由器利用标准机制实现服务间消息交 换。 管理框架：管理框架基于j m x 进行部署、管理以及监控“j b i 运行时”中 的组件。 图2 6 为j b i 高层架构的视图 图2 6 j b i 高层架构图哪 j b i 环境外面的是服务消费者跟提供者，它们代表了将被j b i 集成进来的外 部实体。这些外部实体可以使用各种不同的技术来跟j b i 环境里的b m d m g c o m p o n e n t s 来进行通信。而服务引擎是一个基本的标准化的容器，它用来容纳 基于引擎规范所定义的实体( 比如说w s d l 所定义的服务提供者和消费者) 组件模型一一组件框架( c o m p o n e n tf r a m e w o r k ) j b i 在“j b i 运行时”环境中定义了两种组件，如图2 7 所示： 服务引擎( s e ) 组件：该组件负责实现业务逻辑和其它服务。服务引擎组 件在其内部可使用多种技术和设计模式。服务引擎组件可提供数据传输和转换这 种简单的基础服务，也可实现像w s - b p e l 实例一样复杂的业务处理。 绑定( b c ) 组件：绑定组件主要为已部署服务提供传输级绑定。绑定组件 有多种类型： ( 1 ) 利用标准传输协议与外部系统进行远程通讯。 ( 2 ) 使已部署服务能在同一个m 内部相互调用。 1 6 ( 3 ) 服务间可使用标准的w s i ( w e b 服务协同工作组织) 规范通讯。 t w ot y p e so fd b ic o m p o n e n t s ： 一s o r v i c e e n g i n e s ：p r o v i d ea n dc o t i s u m eb u s i n e s sl o 磐ca n db a n s f o r m a t i o ns e r v i c e s 圆s i n d i gc o m p o n e n t s ：p r o v i d ec o n l e ( 蜘t os e r 话c e se x t e r n a lt oaj b ii n s t a l l a t i o n 图2 7 “j b i 运行时”环境中的两种组件嘲 f b i 的关键是分离服务引擎和绑定组件，以便业务逻辑不被下面的具体细节 所干扰。这种方式促进了体系的灵活性和可扩展性绑定组件和服务引擎组件在 j b i 内部都可以是服务提供者和或服务消费者。 绑定组件和服务引擎组件为“j b i 运行时”提供接口以便从“j b i 运行时” 接收消息。同样的，它们也利用j b i 提供的接口来和“j b i 运行时”通讯。 消息传输模型一一归一化的消息路由器( n o r m a l i z e dm e s s a g ee x c h a n g e ) j b i 利用消息传输模型分离服务提供者和服务消费者之间的耦合。消息传输 模型利用了w s d l 。w s d l 用于描述暴露的服务引擎组件和绑定组件的业务处 理。另外，w s d l 也用于定义抽象服务处理的传输级绑定。 j b i 架构中一个关键组件是n m r ( 归一化消息路由器，也译作“正规消息 路由器”) 。n m r 基于w s d l 提供了主要的消息传输中枢，n m r 为部署在“j b i 运行时”中的服务引擎组件和绑定组件间的消息传递提供松散耦合。服务需要有 聚合业务处理的接口，每个业务处理由零个或