（计算机软件与理论专业论文）企业服务总线应用模式研究与实现.pdf

摘要 摘要 为了应对日益激烈的商业竞争，企业需要在应用环境中使用更加高 效的技术来整合己有的信息化资产和灵活地融合新的服务。面向服务体 系结构的编程模型和方法学，以及集成企业服务的总线基础架构是解决 这一难题的一个方向。 论文围绕面向服务软件的方法学和企业服务总线的应用模式展 开讨论。首先回顾了编程模型和体系结构发展的背景，概述了服务总线 的概念和功能，重点论述了在现有文献的基础上，经过大量实践总结和 扩展了三种常用的服务总线应用模式，对其逻辑结构进行定义，并实现 了支持该模式的中间件框架。在中间件框架中可以灵活的进行功能的设 置和扩展，模式中间件框架的实现可以帮助企业更加方便灵活的应用服 务总线。通过分析该中间件在一个商业项目的应用，本文还对模式中间 件的应用效果和实现过程中积累的经验进行了总结。模式的逻辑定义、 模式中间件的实现以及商业项目中的实践，为服务总线的推广和服务总 线的后续研究奠定了基础。 关键词：企业服务总线应用模式总线模式网关模式扩展模式 企业服务总线脚用模a l i j 究t j 实j 见 t h er e s e a r c ha n di m p l e m e n t a t i o no fr u m t i m ep a t t e r n s o fe n t e r p r i s es e r v i c eb u s l i uc h a o j u n ，d i r e c t e db yl ij i n g a b s t r a c t f a c i n gt h e h e a t e db u s i n e s sc o m p e t i t i o n ，e n t e r p r i s e ss h o u l df i n dam o r e e f f i c i e n tw a yt ou s et h el e g a c y1 ta s s e t s ，a n dm a k et h ei tf o u n d a t i o nm o r e a g i l et of a c et h ec h a n g e a b l er e q u i r e m e n t so ft h em a r k e t t h i sw i l lm a k ea h i g h e rr e q u i r e m e n tf o r t h ei n f o r m a t i o ni n f r a s t r u c t u r e i nt h e e n t e r p r i s e ， t o t a l l yi nt w oa s p e c t s ：l e v e r a g et h ea s s e t sm o r ee f f i c i e n t l ya n di n t e g r a t en e w t e c h n o l o g yu pt od a t e 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 ) a n de n t e r p r i s e s e r v i c eb u s ( e s b ) a r et h ew a y st om e e tt h e s eg o a l s t h i sd i s s e r t a t i o nw i l ld i s c u s st h ee s s e n t i a li d e a so fs 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 ea n dt h e d e s i g np a t t e r n s o fe n t e r p r i s es e r v i c eb u s t h e h i s t o r i c a l b a c k g r o u n do fs o ap r o g r a m m i n gm o d e la n dt h ed e f i n i t i o no f e s bw i l lb ep i c t u r e df i r s t t h e nw ew i l ld i s c u s st h r e er u n t i m ep a t t e r n so f e s b ，w h i c hi sa b s t r a c t l yc o n c l u d e df r o mp r a c t i c ea n db a s e do f fs o m eo ft h e p r e v i o u sr e s e a r c hw o r k s t h er u m t i m ep a t t e r n s a r ed e f i n e di n l o g i c a l m o d u l e s ，i n c l u d i n gn a m e s ，t h er e l a t i o n sb e t w e e nm o d u l e sa n dt h ef u n c t i o n s o ft h e m t h r e em i d w a r ef r a m e w o r k s ，w h i c hw i l ls u p p o r tt h ef u n c t i o n so f t h ep a t t e r n s ，w i l lb ei m p l e m e n t e da f t e rt h ed e f i n i t i o n i nt h ef r a m e w o r k ，w e c a ne a s i l y c o n f i g u r ea n de x t e n dt h ef u n c t i o n so fp a t t e r nm i d w a r e s t h e f r a m e w o r ka l s oc a nh e l pt h ee n t e r p r i s ei m p l e m e n te s bi nt h e i ra p p l i c a t i o n e n v i r o n m e n tw i t h o u tm u c hd i f f i c u l t y t h e nt h ep a t t e r nd e s i g n sa n dt h e m i d w a r ef r a m e w o r kw i l lb ee n g a g e di nar e a l p r o j e c t ，t a xe x p e r i m e n t a l p r o j e e l i nw h i c hs o m ev a l u a b l ee x p e r i e n c ew i l lb ec o n c l u d e d f o ra l lt h e s e w o r k si n t h i sp a p e r , i n c l u d i n gt h el o g i c a ld e f i n i t i o no fe s br u n - t i m e p a t t e r n s ，t h ei m p l e m e n t a t i o no fr u n - t i m ep a t t e r nm i d w a r ef r a m e w o r k sa n d t h ep r a c t i c ei nab u s i n e s sp r o j c o t ，w i l ld os o m eh e l pt ot h ep o p u l a r i z a t i o no f ； a b s ir a c e s bi nt h ee n t e r p r i s ee n v i r o n m e n t ，a n da l s ow i l lb et h eg r o u n d w o r kf o rt h e f u t u r er e s e a r c h k e yw o r d s ：e n t e r p r i s es e r v i c eb u s ，r u n - t i m ep a t t e r n s ，s e r v i c e b u sp a t t e r n ， s e r v i c e g a t e w a yp a t t e r n ，s e r v i c e c o n n e c t i o np a t t e r n 第一章绪论 第一章绪论 1 1 研究背景 当今企业的从商业和技术两个方面对编程模型和系统架构设汁方式 提出了新的需求。 从商业的角度讲，在全球市场一体化的今天，企业而l 临着前所未有 的广泛的竞争，只有能在最短的时间内响应市场需求的企业能在市场竞 争中生存下来。这种压力迫使企业不断地提高自身业务的灵活性，以面 对复杂多变得现实情况。同时还需要企业节省成本，在根据市场需求开 拓新业务时能最大限度的利用已有的技术资产。新构建的业务平台最好 也能利用开放的标准，以便在最大的范围内整合和利用资源。另外，开 放的标准还能帮助企业业务系统在整个生命周期中能高效的维护和快速 的升级，响应外界需求的变化。 另一方面，从技术的角度讲，企业需要其技术部门能够实现利润最 大化，即相对最少的投入而给企业带来最大的商业效益。这样的要求迫 使企业的技术部门从两方面节省开支寻找收益：首先，从企业内部，技 术支持架构需要消除部门之问的数据隔膜，让信息能在部门之间顺畅的 流动。以此带来企业的资源在企业内部高效的配置，使企业的潜力能得 到最大的发挥，并且为企业的良性发展提供一个坚实的基础：其次，从 企业的外部，为了应对外部环境的变化，企业需要实现灵活开放的业务 模型，与外部企业伙伴进行高效的合作。这就需要企业的技术部门能设 计出一个能跨平台整合的业务系统，以一种标准的方式与企业伙伴的业 务系统实现对接。 企业的需求推动了编程模型和业务架构思想的发展，最终导致了面 向服务体系结构( s e r v i c eo r i e n t e da r c h i t e c t u r e ，s o a ) 和以及企业服 务总线( e n t e r p r i s es e r v i c eb u s ，e s b ) 架构的产生。企业服务总线的 目标是要实现面向服务的业务功能整合。e s b 作为服务集成的中间件， 在企业应用范围内为实现面向服务的体系结构和面向服务的整合方式提 供了一种现实可行的基础架构。 企业服务总线脚用模式研究! j 实现 e s b 是一个架构设计的理念，在不同的企业环境中，利用不同的产品 组件，设计实现出来的服务总线可能大不相同，即使在相同的环境和需 求下，也有很多的实现方案可供权衡和选择。因此，对于抽象的e s b 概 念，我们希望从模式的角度入手，通过模式的抽象和实践验证的方式， 总结e s b 的功能和应用特点，为e s b 的复用和推广积累一些经验和理论， 希望能对企业级应用的服务整合和迁移进行一些有用的探索。 1 2 论文的工作 根据企业服务总线架构设计，以及模式抽象和实践的需要，论文的 工作围绕下面几方面展开： 1 2 1 模式的定义 本文根据服务总线在实际应用中的功能需求和实现这些需求所需要 的最小功能组件集合，对每一个中间件框架实现中的功能组件进行角色 抽象，定义出模式的逻辑结构。每一个应用模式定义主要由模式的名称， 模式中的主要逻辑节点，这些逻辑节点在模式中所扮演的角色，以及模 式的适用范围和实用效果四部分组成。 1 2 2 实现模式中间件 在模式抽象定义的基础上，使用成熟的中间件组件作为模式中的组 成节点，对这些组件进行更高层次的封装，实现支持该模式逻辑结构的 中间件框架，简称其为模式中间件。在一个抽象出来的具有代表性的应 用场景中分析描述模式中间件所需要实现的功能，并从实现中分析模式 的适用场景和实现效率。实现的模式中间件和从实现过程中总结的实践 经验，为实际项目中的服务总线模式应用做了相应的技术准备。 1 2 3 应用模式在实际项目中的应用 在一个实际的税务系统示范项目中使用服务总线的模式中间件。在 该税务系统为一个面向服务架构以及服务总线集成技术的进行试点，应 第一章绪论 用到了服务总线模式中间件以及其实现过程中使用设计思想和技术。本 文描述了项目的服务模型提取，服务建模，服务总线设计和服务总线的 构建。最后本文还对服务总线解决方案的优劣做给出了评价。 1 3 论文结构 论文的后续内容主要分为三个部分： 第一部分作为论文工作的知识背景介绍，对面向服务的体系结构和 服务总线的概念进行了概要的描述，其中包括了编程模型的发展历史， 面向服务的开发方式和编程模型，以及服务总线的架构、功能总结和适 用环境等。这一个部分包括第二和第三两个章节。 第二部分主要描述了服务总线模式抽象定义和模式中间件的实现过 程，这部分内容包括了第四和第五两个章节。 第三部分具体介绍的是项目实践，这部分的内容包括第六章。 本文的最后对工作进行了总结，并对后续的内容进行展望。 企业服务总线心用模代研究1 j 实现 第二章面向服务体系结构 关于面向服务体系结构( s o a ) 的概念，很多的文章从不同的角度 对它进行了描述，不同的软件提供商也对它进行了不同的定义。比如， b e a 有流体计算，微软有i n d i g o 和s o 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 就 是基于标准的业务应用服务。从概念的角度，i b m 对s o a 的定义较为 全面的，即s o a 是一种构造分布式系统的方法，它将业务应用功能以服 务的形式提供给最终用户应用或其他服务。 本章将对面向服务体系结构的产生背景，概念定义，以及面向服务 的丌发方式和编程模型进行描述。首先回顾一下技术演化的路程和商业 需求的发展，理解面向胀务体系结构出现的历史背景。 2 1 编程模型的发展 在企业中，l t 经理一直面临着削减成本和最大限度地利用现有技术 的难题。与此同时，他们还必须不断地努力，以期更好地服务客户，更 快地响应企业战略重点，从而赢得更大的竞争力。 在所有这些压力之下，他们面临两个基本的主题：异构和发展。异 构是第一个主题。现在，大多数企业都有各种各样的系统、应用程序以 及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简 直就像一场噩梦。但是企业也不能单单使用一家厂商的产品，因为改变 遗留的应用程序套件和支持基础设施是如此之难。 发展是第二个主题。全球化和电子商务加快了改变的步伐。全球化 带来了激烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手 的优势。在竞争产品和可以从i n t e r n e t 上获得的大量产品信息的推动 下，客户要求更快速地进行改变。因而，在改进产品和服务方面展开的 竞争进一步加剧了。 为了满足客户提出的越来越多的新要求，技术方面的改进也在不断 第二章_ 血向服务体系结构 地加快。企业必须快速地适应这种改变，否则就难以生存，更别提在这 个动荡不安竞争激烈的环境中取得成功，而i t 基础设施必须支持企业提 高适应能力。 因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的 垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构， 向新的生态系统业务范例发展。重点是扩展供应链，支持客户和合作伙 伴访问业务服务。 企业的i t 经理时时刻刻面临着这样的问题：如何使企业内部的i t 环境更灵活且更快地响应不断改变的业务需求? 如何使这些异构系统和 应用程序尽可能无缝地进行通信? 如何达到企业目标而不使企业走向破 产的深渊? l t 体系结构的发展是随着企业的这种发展而进行的，从面向机器与 过程结构，到c s 结构，再到三层结构，以及后来的分布式对象，组件， 最终发展到面向服务的体系结构( s o a ) 。现在，许多i t 经理和专业人 员都同样相信，这已经真的快找到了一种理想的结构一一面向服务的体 系结构和一种理想的基础模型一一服务总线模型。 为了减少异构性、互操作性和不断改变的要求的问题，这样的体系 结构应该提供平台来构建具有下列特征的应用程序服务： 松散耦合 位置透明 协议独立 基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通 信的特定服务，因为底层基础设施，或者我们后面将会重点介绍的服务 总线，将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能 多的技术。特别地，来自不同的实现技术( 如j 2 e e 或n e t ) 的技术 规范不应该影响s o a 用户。如果已经存在一个服务实现，我们就还应 该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更 好的服务质量。 自从“软件危机”促进软件工程的开创以来，l t 界一直在努力寻求解 企业服务总线心用模式研究j 实现 决上述问题的方案。在过去几年里，下面将要简要概述的核心技术进展 使我们走到了今天。简要回顾一下这些核心技术，同时重点关注这些技 术如何帮助企业解决了i t 问题，有助于更加深刻的理解面向服务体系结 构出现的历史必然性。 2 1 1 面向机器与过程的语言 最早程序开发是通过面向机器语言f m o n o l i t h i c ) 的开发模式来实现 的。能为计算机直接接收和识别的由0 和1 组成的指令代码，这种指令称 为机器指令，机器指令的集合称为机器语言，用机器语言编写的程序称 为手编程序，手编程序能在计算机上直接执行，所以又称为目的程序。 使用机器语言编写程序，计算机能够直接识别，运行速度快，占用内存 少，但难编，难读，难修改；而且机器语言因机种的不同而有所不同， 用机器语言编写的程序不具有通用性，需要根据不同平台的机器语言来 开发代码。这个阶段的开发工作基本不具有重用性，更谈不上模式的应 用。 机器语言之后出现了高级语言，随之而来的是面向过程( p r o c e d u r e ) 的丌发模式。独立于机器的程序语言( c ，p a s c a l 等) 使开发的过程变得简 单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。这个 阶段有了代码级的重用，但因为代码和具体的环境有极大的耦合性，因 此重用的范围有限，也不存在更高层次的模式抽象。 这两种开发模式统制了早期的软件开发。面向机器语言的开发模式 基本不具有重用性，一次实现的代码局限于个特定的应用和环境。面 向过程的开发模式比面向机器语言的开发模式有一定的进步，独立于机 器的语言和过程的封装为重用带来了一定的便利。但这个阶段的重用依 然停留在比较低级的阶段，很多时候只是一些简单的功能代码的重用。 2 1 2 面向对象的分析和设计 面向对象的分析和设计的本质可以描述为“从对象( 物体、概念或实 体) 的角度考虑问题域和逻辑解决方案”【1 】。或者可以将这些对象定义 笫二章面向服务体系结构 为“特点在于具有许多操作和状态( 记忆这些操作的影响) 的物体”【2 】。 在面向对象的分析中，对象一般都是用现实中的问题域来标识和描 述的。在面向对象的设计中，将现实的问题转变成逻辑软件对象，而这 些对象最终将用丽向对象的编程语言进行实现。 通过而向对象的分析和设计，可以封装对象( 或对象组) 的某些方 面，以简化复杂业务场景的分析。为了降低复杂性，也可以抽象对象的 某些特征，这样一个过程可以达到只捕获问题的重要或本质方面的目的。 在面向对象的开发过程，开发的模型被抽象到一个比较高的层次， 以问题域作为编程的最小单元，将问题的特征模型映射到代码模型中， 这样复用的层次也得到了大大的提高。在这个阶段，对象的静态模型类 以继承重载等方式被重用，编程模型丌始出现经典的复用模式，但这个 阶段的复用依然没有脱离代码级别。 2 1 3 面向组件的开发方式 随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境 中，仅仅停留在代码级别的重用会导致重用性差，可维护性差，效率低 等不能忍受的弱点。同时这些弱点难以逾越的。因此人们以架构运行环 境( 如n e t ，j 2 e e 等) 来为开发者提供完善的支撑平台，从而把开发者解放 出来，更专注于业务核心的开发。而这些业务功能( b u s i n e s sf u n c t i o n ) 以组件的形式( d c o m ， e j b 等1 发布运行在架构运行环境中。软件开发 的重用模式也上升到业务组件的级别。 基于组件的设计并不是一种新技术。它是从对象范例中自然发展而 来的。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重 用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用 来使重用广泛应用于实践之中。在应用程序开发和系统集成中，粗粒度 组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的 对象来提供定义良好的功能。通过这种方式，还可以将打包的解决方案 套件封装成这样的“组件”。 一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系 企业服务总线心用模式研究j 实现 结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。 可咀将组件看作是打包、管理和公丌服务的机制。 在组件的丌发模型这一级别，复用已经脱离代码，实现了基于业务 逻辑架构设计重用。 2 1 4 基于接口的设计 在组件的丌发中，需要进行接口设计，这样软件实体就可以实现和公 开其定义的关键部分而不用暴露其内部信息。因此，在基于组件和面向 服务的系统中，“接口”的概念对于成功的设计非常关键。下面是一些与 这种信息接口有关的重要定义： 接1 3 ：定义一组公共方法签名，它按照逻辑分组但是没有提供实 现。接口定义服务的请求者和提供者之间的契约。接口的任何实 现都必须提供所有的方法。 已发布接口：一种可唯一识别和可访问的接口，客户端可以通过 注册中心来发现它。 公共接口：一种可访问的接口，可供客户端使用，但是它没有发 布，因而需要关于客户端部分的静态知识。 双接口：通常是成对开发的接口，这样，一个接口就依赖于另一 个接口：例如，客户端必须实现一个接口来调用请求者，因为该 客户端接口提供了某些回调机制。 2 2 面向服务体系结构 编程模型的发展随着技术和市场两方面的推动，最终发展到了面向 服务的体系结构。下面将从服务的定义，面向服务的模型，编程方式和 面向服务体系结构中各种组成角色之阃的交互关系等方面来对面向服务 的体系结构进行探讨。 2 2 1 服务的定义 在面向服务的体系结构( s e r v i c eo r i e n t e d a r c h i t e c t u r e ，s o a ) 中，服 第二章面向服务体系结构 务( s e r v i c e ) 是封装成用于业务流程的可重用组件的应用程序函数。它 提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转 变【4 】。对于服务的调用者来说，用于实现特定服务的流程并不重要，只 要它能响应调用者的命令并为你的请求提供高质量的服务就可以了。 通过定义的通信协议，可以调用服务来强调互操作性和位簧透明性。 一个服务表现为一个软件组件，因为从服务请求者的角度来看，它看起 来就像是一个自包含的函数【4 】。然而实际上，服务的实现可能包括在一 个企业内部的不同计算机上或者许多业务合作伙伴拥有的计算机上执行 的很多步骤。就封装的软件而言，服务可能是一个组件，也可能不是一 个组件。如同类对象一样，对于请求者应用程序，服务可以看作是一个 整体。 具体到w e b 服务，则是以使用s o a p 消息作为调用的基础，使用像 h t t p 或者j m s 这样的标准协议来传输，通过w s d l 文件来描述的服 务形式。使用w e b 服务的最佳实践方式就是通过标准的协议栈与外部 的业务伙伴通信。 2 2 2 面向服务体系结构的模型 在“c o m p o n e n t b a s e dd e v e l o p m e n tf o re n t e r p r i s es y s t e m s ”中涉及了服 务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代 码单元。它的服务只能通过一致的已发布接口( 它包括交互标准) 进行 访问。组件必须能够连接到其他组件( 通过通信接口) 以构成一个更大 的组件”【3 】。服务通常实现为粗粒度的可发现软件实体，它作为单个实 例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服 务交互。下面展示了重要的面向服务术语： 服务：逻辑实体，由一个或多个己发布接口定义的契约。 服务提供者：实现服务规范软件实体。 服务使用者( 或请求者) ：调用服务提供者的软件实体。传统上， 它称为“客户端”。服务使用者可以是终端用户应用程序或另一个 服务。 9 企业服务总线应用摸式研究与实现 服务定位器：一种特殊类型的服务提供者，它作为一个注册中心， 允许查找服务提供者接口和服务位置。 服务代理：一种特殊类型的服务提供者，它可以将服务请求传送 到一个或多个其他的服务提供者。 面向服务的体系结构提供了一种方法，通过这种方法，可以构建分 布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服 务。其组成元素可以分成功能元素和服务质量元素。图2 - 1 展示了体系 结构堆栈以及在一个面向服务的体系结构中可能出现的角色元素。 g u a 班ve s e r v i c e b u s i n c , s sp r o c f s s s e f i c o 荔 王 南j 旺 s e r v i c ed e s c l i p c i o n s 口 5 己 兰 j s e r a c 目c o m m u n i c a t i c n p r o t o c o l t r a n 5 p o d 图2 1 面向服务的体系结构堆栈 体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面， 而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下： 功能性方面包括： 传输是一种机制，用于将来自服务使用者的服务请求传送给服 务提供者，并且将来自服务提供者的响应传送给服务使用者。 服务通信协议是一种经过协商的机制，通过这种机制，服务提 供者和服务使用者可以就将要请求的内容和将要返回的内容 进行沟通。 服务描述是一种经过协商的模式，用于描述服务是什么、应该 1 0 第二章向向胀务体系结构 如何调用服务以及成功地调用服务需要什么数据。 服务描述实际可供使用的服务。 业务流程是一个服务的集合，可以按照特定的顺序并使用一组 特定的规则进行调用，以满足业务要求。注意，可以将业务流 程本身看作是服务，这样就产生了业务流程可以由不同粒度的 服务组成的观念。 服务注册中心是一个服务和数据描述的存储库，服务提供者可 以通过服务注册中心发布它们的服务，而服务使用者可以通过 服务注册中心发现或查找可用的服务。服务注册中心可以给需 要集中式存储库的服务提供其他的功能。 服务质量方面包括： 策略是一组条件和规则，在这些条件和规则之下，服务提供者 可以使服务可用于使用者。策略既有功能性方面，也有与服务 质量有关的方而：因此，我们在功能和服务质量两个区中都有 策略功能。 安全性是规则集，可以应用于调用服务的服务使用者的身份验 证、授权和访问控制。 传输是属性集，可以应用于一组服务，以提供一致的结果。例 如，如果要使用一组服务来完成一项业务功能，则所有的服务 必须都完成，或者没有一个完成。 管理是属性集，可以应用于管理提供的服务或使用的服务。 2 2 3 面向服务的编程模型 面向服务的编程模型具有几个主要特性【5 】，下面将一一阐述。 服务数据对象( s d o ) 是s o a 中的一个基础概念，它提供了简化的 抽象，使程序员可以更多的集中在业务逻辑上。s d o 还提供了统一的消 息表示来与服务交互，淘汰了用于数据表示的复杂技术迷宫，仅仅访问 单个统一模型。s d o 大大提高了开发人员的生产力，并且将编程人员从 如何访问特定后端数据源、应用程序和服务的技术细节中解脱出来。 企业蹦务总线臆川模式研究与实现 s o a 编程模型同样需要统一的范型来创建和访问业务逻辑。服务隐 藏了实现技术之间的差别，并应该建立在比现有编程结构( 比如e j b ) 更高级别的抽象上，这样更加的易于使用。服务可以通过组装到模块( 这 些模块可以组成解决方案) 中的组件来实现。通过组件公丌的服务可以 使用可定位的接口来调用。可以使用w e b 服务描述语言( w s d l ) 、j a v a 或其他语言来描述接口。这个实现类型可以有对所需服务的待定引用， 在将组件结合在一起执行之前，这些服务是满足需求的。 s o a 编程模型还引入了良好定义的组件类型，对程序员开发和部署 到解决方案中的常用构件建模。比如”无格式旧j a v a 对象”、业务流程 执行语言( b p e l ) 流程、结构化查询语言( s q l ) 服务、a d a p t i v eb u s i n e s s o b j e c t s 、通过j a v a 连接器体系结构( j 2 c ) 资源适配器访问的c i c s 程序、使用s a p 业务应用程序编程接口的应用程序、j a v a2e n t e r p r i s e e d i t i o n ( j 2 e e ) 无状态会话b e a n 和m q s e r i e s 应用程序等等。 在面向服务编程模型中，企业服务总线是多协议结构的一个关键角 色，将服务组件编成无缝的交互，通过在消息路径中加入被称为中介的 特别组件，来代理服务间的交互，而不用更改现有的端点，从而允许在 核心级别上处理企业关注的内容一比如审核、日志、路由、不匹配接 口的适配、等价组件的增量替换、安全等。 总的来说，s o a 编程模型将开发和部署活动分割为不同的阶段，这 些阶段可以发生在不同的时间，并且可以通过不同的个人使用不同的技 能来实现。这就产生了关系的分离，使软件组件可以被重用。它也将软 件体验划分为单独用户的业务角色、技能和任务。最终，它使软件生命 周期可以适应按需企业的需要，因为它们通过针对业务灵活性重新设计 l t 流程来寻求更高的有效性【6 】。 2 2 4 面向服务体系结构中协作关系 图2 2 展示了s o a 的基本模型及其中主要角色之间的协作。这些协 作遵循“查找、绑定和调用”范例，其中，服务使用者执行动态服务定位， 方法是查询服务注册中心来查找与其标准匹配的服务。在服务存在的情 第二章面向胜务体系结构 况下，注册中心会给使用者提供接口契约和服务的端点地址。图中展示 了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体【5 】。 图2 2 面向服务的体系结构中的协作 面向服务的体系结构中的角色包括： 服务使用者：服务使用者是一个应用程序、一个软件模块或需 要一个服务的另一个服务。它发起对注册中心中的服务的查 询，通过传输绑定服务，并且执行服务功能。服务使用者根据 接口契约来执行服务。 服务提供者：服务提供者是一个可通过网络寻址的实体，它接 受和执行来自使用者的请求。它将自己的服务和接口契约发布 到服务注册中心，以便服务使用者可以发现和访问该服务。 服务注册中心：服务注册中心是服务发现的支持者。它包含一 个可用服务的存储库，并允许感兴趣的服务使用者查找服务提 供者接口。 面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注 册中心这三种角色中的某一种( 或多种) 。面向服务的体系结构中的操作 包括： 发布：为了使服务可访问，需要发布服务描述以使服务使用者 可以发现和调用它。 发现：服务请求者定位服务，方法是查询服务注册中心来找到 企业服务总线应用模式研究j 实巩 满足其标准的服务。 绑定和调用：在检索完服务描述之后，服务使用者继续根掘服 务描述中的信息来调用服务。 面向服务的体系结构中的构件包括： 服务：可以通过已发布接口使用服务，并且允许服务使用者调 用服务。 服务描述：服务描述指定服务使用者与服务提供者交互的方 式。它指定来自服务的请求和响应的格式。服务描述可以指定 一组前提条件、后置条件和或服务质量( o o s ) 级别。 除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构 还具有以下特征： 服务是自包含和模块化的。 服务支持互操作性。 服务是松散耦合的。 服务是位置透明的。 服务是由组件组成的组合模块。 这些特征也是满足电子商务按需操作环境的要求的主要特征。因此在 电子商务的按需操作环境中，服务常常作为一个主要的关键词出现，以 至于有人将按需操作环境就等价与w e b 服务。应该特别将调的是，这是 两个不同层次的概念。服务只是作为一个实现层次的技术概念，而面向 服务架构的按需操作环境是一个表现了更高抽象层次的设计概念。 2 3 小结 面向服务的体系结构并不是一个新的概念。面向服务的体系结构所 涉及的技术至少包括c o r b a 、d c o m 和j 2 e e 。面向服务的体系结构 的早期采用者还曾成功地基于消息传递系统( 如i b mw e b s p h e r em q ) 创建过他们自己的面向服务企业体系结构。晟近，s o a 的活动舞台已经 扩展到包括w o r l dw i d ew e b ( w w w ) 和w e b 服务。 最后给s o a 进行一个总结作为本章的结束。典型的s o a 架构简单 第二章面向服务体系结构 的说应该具备以下基本的要求： s o a 在相对较粗的粒度上对应用服务或业务模块进行封装与重 用； 服务间保持松散耦合，基于开放的标准，服务的接口描述与具体 实现无关： 灵活的架构，服务的实现细节，服务的位置乃至服务请求的底层 协议都应该透明： 下面的章节中我们将会把重点放在对企业服务总线( e n t e r p r i s e s e r v i c eb u s ，e s b ) 的论述上。这一章中s o a 的概念和s o a 所应具备的 基本要求，是e s b 产生的基础和存在的根基。简单的说，服务总线架构 只是s o a 思想在企业应用集成范围内一个特殊的中间件框架实现方式 而己。 企业服井总线应用模代1 i j f 究与实现 第三章企业服务总线概述 企业服务总线作为s o a 在企业应用环境下实现的基础架构，为企业 提供了一整套抽象企业业务逻辑，包装和整合业务服务的方法和基础功 能。在本章巾将首先从传统s o a 架构的局限性入手，对企业服务总线在 企业环境中的定义，功能的描述以及服务总线适用的范围进行逐一的描 述。 3 1 传统s o a 架构的局限 在企业的环境中，两个节点之问只要通过互相认可对方的方式，即 使不存在公开统一的服务界面也可以实现点到点的互联。因此如果只有 服务，而服务的请求者和服务的提供者之问仍然需要这种显式的点到点 的调用，那么不能算一个典型的s o a 架构。请看图3 - 1 ，如果服务的参 与双方都必须建立1 对1 的联系，那么这样一个结构与以前的简单互联 的方式没有什么不同。参照2 3 中提出的三点实现s o a 架构应该具有的 基本要求，这种简单的方式没能做到基本要求中的第三点。 图3 - 1 简单的点对点调用方式 因此在s o a 中，必须要有这样一个中问层，能够帮助实现在s o a 架构中不同服务之间的智能化管理。一般的中间层就是一个h u b 结构的 节点。在s o a 架构中的各服务之间设置一个类似于h u b 的中间件，由 它充当整个s o a 架构的中央管理器的作用( 图3 2 ) 。在服务的请求者 和提供者之间设置一个智能的中转站，服务的请求者不再需要了解服务 1 6 第三章企业服务总线溉述 提供者的细节。传统的企业应用 合( 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 ， e a i ) 即是通过这样一种方式来试图解决企业内部的应用整合问题。 图3 - 2 通过h u b 进行互联的方式。 e a i 的目标是支持对现有i t 系统的重新利用，通过e a i 技术能够将 不同的软件和系统串联起来，延长这些应用系统的生命周期。传统的 e a i ，往往使用如c o r b a 和c o m 等的消息中问件进行分布式，跨平台 的程序交互，修改企业资源规划以达到新的目标，使用中间件、x m l 等 方法来进行数据分配。因此，实际上传统的e a l 是部件级的重用。但是， 基于部件的架构没有统一的标准，因此各个厂商都有各自不同的e a i 解 决方案，这也构建了各种各样的中间件框架。如果e a i 碰到了异构的l t 环境，就必须分别考虑怎样解决各个不同的中间件之间异构的问题，来 实现合理的互联方式，这时不得不考虑各种复杂的可能性。因此，大多 数传统e a i 解决方案都比较笨重。 般的s o a 应用场景为复杂的企业级架构，如果选择简单h u b 互联 的模式来构建s o a 基础架构，从逻辑的角度则可能出现以下问题：首先， 如果每个服务的请求都经过中央h u b 的中转，那么h u b 的负担会很重， 整个s o a 架构的性能会随着参与者的增多而愈来愈慢；其次，这样的系 统会很脆弱，一旦h u b 出错，整个s o a 架构都会瘫痪；最后，这样的 架构会破坏s o a 的开放性原则，参与者运行在一个相对封闭的环境中， 扩展起来十分麻烦。因此，这并不是理想的s o a 架构。 设计的s o a 的架构要满足负载均衡，强健以及足够开放的要求，需 要有一个更加智能化的，更加开放的标准基础架构来代替h u b 的位置， 1 7 企业服务总线心用模式研究j 实现 企业服务总线正是按照这些要求设计出来的架构模型。 3 2 企业服务总线架构 企业服务总线的架构( 图3 3 ) ，它与前面的h u b 结构存在以下的不 同：首先，它比单一h u b 的形式更丌放，总线结构有无限扩展的可能； 其次，在总线中服务是最小的功能单元，所有的服务处于平等的地位。 即使在构建的过程中需要一些h u b ，那么它们也是以某种服务的形式部 署在总线上，相比上面的结构要灵活的多。 对于企业服务总线( e n t e r p r i s es e r v i c eb u s ，e s b ) ，我们需要给它一个 明确的定义：e s b 是一种在松散耦合的服务和应用之间标准的集成方式。 它可以作用于： 面向服务的架构分布式的应用由可重用的服务组成 面向消息的架构应用之问通过e s b 发送和接受消息 事件驱动的架构应用之间异步地产生和接收消息 图3 3 企业服务总线 上面的定义可以用一句简单具体的话来描述：e s b 就是在s o a 架构 中实现服务间智能化集成与管理的中介。它与s o a 的关系是：e s b 是 逻辑上与s o a 所遵循的基本原则保持一致的服务集成基础架构，它提 供了服务管理的方法和在分布式异构环境中进行服务交互的功能【7 】。 另一方面，e s b 为s o a 实现提供了灵活且易于管理的模型。对于一 个服务集成的应用，清晰的定义服务的各个端点之后，将总线透明地插 入到端点之间，可以提高服务质量，可以促进请求者和提供者间的交互 第三章企业服务总线慨述 ( 而不受协议、交互模式或服务功能不匹配的影响) ，还可以支持监视 和管理。 可以这样说，e s b 以s o a 的方法学实施e a ! 的方式： 首先，在e s b 系统中，被集成的对象被明确定义为服务，而不是传 统e a l 中各种各样的中间件框架，这样就极大简化了在集成异构性上的 考虑，因为不管有怎样的应用底层实现，只要是s o a 架构中的服务，它 就一定是基于标准的。 其次，e s b 明确强调消息( m e s s a g e ) 处理在集成过程中的作用，这里 的消息指的是应用环境中被集成对象之间的沟通。传统的e a i 实施中碰 到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作 为基础架构的e a ! 系统，必须能够对系统范畴内的任何一种消息进行解 析。传统的e a i 系统中的消息处理大多是被动的，消息的处理需要各自 中问件的私有方式支持，例如a p i 的方式。因此尽管消息处理本身很重 要，但消息的直接处理不会是传统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 的概念不仅仅是提供消息交互的通 道，更重要的是提供服务的智能化集成基础架构【7 】。 最后，事件驱动成为e s b 的重要特征。通常服务之间传递的消息有 两种形式，一种是调用( c ar 1 ) ，即请求回应方式，这是常见的同步模式： 还有一种被称之为单路消息( o n e w a y ) 方式，它的目的往往是触发异步的 事件，发送者不需要马上得到回复。考虑到有些应用服务是长时问运行 的，因此，这种异步服务之间的消息交互也是e s b 必须支持的。除此之 外，e s b 的很多功能都可以利用这种机制来实现。例如，s o a 中服务的 1 9 企业服务总线戍用模式研究1 j 安现 性能监控等基础架构功能，需要通过e s b 来提供数据，当服务的请求通 过e s b 中转的时候，e s b 很容易通过事件驱动机制向s o a 的基础架构 服务传递信息。 3 3 企业服务总线的功能 现有文献中对e s b