企业服务总线解决方案剖析

1、第 1 部分: 企业服务总线的基本概念珉 李, IBM 中国软件开发实验室 SOA设计中心 高级软件工程师, IBM简介：本文作为ESB系列文章的第一篇，介绍了面向服务的体系结构(service-oriented architecture，SOA)和企业服务总线(Enterprise Service Bus，ESB)的基本知识，ESB的技术沿革，以及ESB与SOA之间的关系。引言一切都在流动，没有什么是持久的。一切都在融化，没有什么是固定不变的 - 赫拉克利特(Heracleitus)大约在2003年中的时候，SOA的概念逐渐进入人们的视野，一时间众人乐此不疲的发表各自对SOA的见解。SOA已

2、经成为IT业，尤其是软件开发及系统集成领域从业者的热门话题。很多的权威机构也纷纷预测SOA的美妙前景，例如，Gartner 预言，到了 2008 年，至少 60% 的企业将使用 SOA 作为其IT架构。抛开喧嚣躁动以及随声附和，对于软件开发者而言，经过了一年多的概念灌输，伴随着不断增长的困惑，更多的人希望能静下心来看一看：究竟怎样的系统架构是符合SOA设计的，而又有哪些技术可以用来实现SOA呢？特别是企业服务总线(Enterprise Service Bus, ESB)， 看起来更是SOA中一个玄虚的概念，本系列文章将通过实际的案例分析来详细讲解在SOA系统中是怎样实施ESB的。本系列文章将直

3、接面向广大的软件开发人员， 首先以直观的方式介绍什么是ESB， 然后引入一个实际案例，以此为基础，详细介绍怎样一步一步实现ESB。现在我们谈论SOA和ESB的时候都不再是空中楼阁，IBM作为SOA的倡导者，已经提供了很好的产品来实现我们的设想。我们会在本系列中的第二、第三部分中分别介绍基于WebSphere 6 和IBM EAI产品的两种实现方式， 然后在第四部分中介绍在复杂的企业应用场景中总线(Bus)怎样互联， 怎样扩展。希望通过本系列文章，能让广大读者朋友快速掌握ESB的实际开发技巧。 关于SOA关于SOA的概念，你可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方

4、式。BEA有流体计算，微软有Indigo 和SOA-building， SAP有ESA。 每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角度，IBM对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如下要素: 一个体系架构，用开放的标准将软件资产(Asset)化为服务 提供标准的方法来表示软件资产及其交互 单独的软件

5、资产作为构造单元，被重复使用来开发其他应用 将关注点从细节实现转移到应用(application)组装 整合企业外部的应用（B2B）的方式 开发（现在）和整合（未来）的统一本文针对的读者是软件开发人员，站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性： 面向机器语言(Monolithic)的开发模式：需要根据不同平台的机器语言来开发代码。 面向过程(Procedure)的开发模式：独立于机器的程序语言(C, Pascal等)使开发过程变得简单了，用过程来代表一个抽象的代码集合，包装重

6、用现成的代码。 面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。 面向组件(Component)的模式：随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境中，代码级别的重用性差，可维护性差，效率低的弱点是不可逾越的，因此人们以架构运行环境(如.Net，J2ee等)来提供完善的支撑平台，从而把开发者解放出来，更专注于业务核心的开发。而这些业务功能(Business Function) 以组件的形式

7、(DCOM， EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。 面向服务(SOA)的模式：当软件的使用范围扩展到更广阔的范围，往往会面对更加复杂的IT环境和更加灵活多变的需求。服务(Service)的概念出现了，人们将应用(Application)以业务服务(Business Service)的形式公布出来供别人使用，而完全不需要去考虑这些业务服务运行在哪一个架构体系上，因为所有的服务都讲着同样的语言。SOA考虑了业务发展的长期性，体现了变化就是永恒的思想。SOA的核心体现在企业应用或者业务功能上的重用和互操作，而不再把IT与业务对立起来，这可以被视为在IT驱动业

8、务的方向上迈出的重要一步。我们注意到，SOA同样也强调重用(Reuse)， 但是相对于传统的代码重用，对象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在于业务级的应用，即服务的重用，这与软件的发展规律是相一致的。在软件发展的过程中，软件重用的对象越来越接近我们的现实生活。通过部件的重用，软件的开发更具效率，并且开始试图用组件表达业务模式。但是，IT人员仍很难对业务人员解释清楚IT结构怎样映射到业务模型上。然而，IT架构与业务模型的弥合是不可避免的方向。现代企业的业务环境所面临的最大挑战就是变化，规则在变，需求在变，而对变化做出最快的反应，尽快地适应变化，成为企业占得先机，成功运作的关键

9、。很多企业的业务环境依赖于他们的IT架构，因此，IT部门往往直接承载了业务变化带来的压力。每一个具体的业务变化，都直接反应到对现有的IT平台的要求：要么企业IT架构本身对变化自适应，要么IT架构能够在短时间内根据新的业务规则做出调整。这就是SOA架构提出的根本原因，我们需要一种更加贴近业务的IT架构，能够直接描绘业务，对那些不懂IT技术的业务领域专家来说，业务服务却是他们最熟悉的，也就是说是SOA把软件重用的对象从IT人员上升到了业务人员。因此，我们可以说SOA与其它的模式相比，最大的进步在于它与业务的关联性，服务对应到实际业务。IT通过服务与业务发生了密切的关系，业务人员和IT人员都可以专注

10、于业务逻辑的实现，而共同的语言就是服务。但不是什么场合都适用SOA。通常来讲，SOA适用于较为复杂的IT架构，经常需要与外部复杂的IT环境交互，并且需要快速地应对频繁发生的业务变化。就像你不可能在控制洗衣机的芯片上使用EJB开发一样，如果你的IT环境规模很小，足以灵活地应对变化，不需要与其他的异构IT环境频繁交互，那么SOA带来的好处就不足以抵消它给你带来的系统复杂性。但是，即令如此，你也并没有被完全排除在SOA的大趋势之外。SOA是如此地倍受瞩目，我们可以预见到它的迅猛发展，因此即使你的内部IT架构本身并不是基于SOA的，你也还有机会参与到未来的SOA架构中去。例如，将你的某个业务以服务的形

11、式发布到某个外部SOA平台上供别人使用，作为第三方SOA平台的一个服务提供者(Service Provider)存在。在选择SOA的实施方案时，要记住，软件的具体实现技术诸如Web 服务与SOA是两回事，SOA是一个概念，方法学， 或者用一个更时髦的词：一种模型。而Web 服务呢？它是一种具体的实现技术，就像EJB一样。SOA Web服务。不过公平地讲，Web 服务倒确实是目前最适合实现SOA的技术之一，用Web 服务来封装业务服务是个不错的选择。因为Web服务是标准的，WS-I协议保证了来自不同厂商的Web服务即使运行在不同的平台上，底层的实现机理不同也可以顺利交互，这是以前的任何一种技术如

12、CORBA，EJB，或DCOM都不能做到的。而且，Web服务的定义与实现是分开描述的，即松散耦合，因此，可以很方便地替换服务的内在实现而不会对现有的系统造成任何冲击，这也极大地促进了IT架构的灵活性。对于SOA更进一步的了解，可以参考IBM developerWorks上其他SOA相关的文章(请参见参考资料)，我们的系列文章将主要讨论ESB，因此不再此过多地论述SOA了。为了使我们下面的论述更顺畅，请先牢记典型的SOA架构有哪些基本的要求：1. SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用；2. 服务间保持松散耦合，基于开放的标准， 服务的接口描述与具体实现无关；3. 灵活的架构

13、 -服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明； ESB让我们暂时回到网络技术不普及的时代，你怎样在两台机器之间传递文件？我还记得为了给实验室的每台机器安装Borland C+的环境，猜猜我动用了什么：一根串口线。不过，我仍然觉得庆幸，好在每台机器都运行同样的操作系统- DOS(很少有人还记得DOS中有Interlnk这样一个命令吧)， 用来通过串口线在两台机器间传递流文件。否则我将不得不用软盘来拷贝所有的安装文件。我那个时候的梦想就是，哪一天有这么一个叫做网络的东西能够把实验室里面所有机器都连接起来，而不用我在各机器之间跑来跑去。让我们回归主题，你现在已经基本明白了什么是SO

14、A。假定你已经按照SOA的思想提炼出了各种业务服务，公布出来，同样，你发现其他很多人也做了同样的事情。大家都很振奋，开始踊跃的尝试，我调用你的一个服务，你调我的一个服务。啊哈！大家都SOA了。且慢，那么这个SOA给你们带来了什么好处呢？Ok，现在我可以在J2EE环境里调用.Net的组件了，但是原来没有SOA的时候也可以做到的呀。只要两个节点之间互相认可对方的方式，即使不存在公开/统一的服务界面也可以实现点到点的互联。因此我们不得不承认，如果我们只有服务，而服务的请求者和服务的提供者之间仍然需要这种显式的点到点的调用，那么这就不是一个典型的SOA架构。请看图二，服务的参与双方都必须建立1对1 的

15、联系。这样一个结构与我十几年前的那种互联的方式何其相似！但是，还记得我们上面提到的SOA三个基本要素吗？显然第三点没有做到。因此，在SOA中，我们还需要这样一个中间层，能够帮助实现在SOA架构中不同服务之间的智能化管理。最容易想到的是这样一个HUB-Spoke结构，在SOA架构中的各服务之间设置一个类似于Hub的中间件，由它充当整个SOA架构的中央管理器的作用。请看图三，现在服务的请求者和提供者之间有了一个智能的中转站， 服务的请求者不再需要了解服务提供者的细节。不错！看上去是一个好的SOA结构。事实上，传统的EAI就是通过这样一种方式来试图解决企业内部的应用整合问题。EAI的目标是支持对现有

16、IT系统的重新利用，通过EAI技术能够将不同的软件和系统串联起来，延长这些应用系统的生命周期。传统的EAI，往往使用如CORBA和COM等的消息中间件进行分布式，跨平台的程序交互，修改企业资源规划以达到新的目标，使用中间件、XML等方法来进行数据分配。因此，实际上传统的EAI是部件级的重用。很不幸的是，基于部件的架构没有统一的标准，因此，各个厂商都有各自不同的EAI解决方案，你会看到各种各样的中间件平台。如果EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不同的中间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。因此，你所见过的大多数传统EAI解决方案都比较笨重。再回顾一下

17、我们上面介绍过的SOA的应用场景：复杂的企业级架构。如果我们选择Hub的模式来构建SOA基础架构，从纯粹逻辑的角度，可能会出现哪些问题呢？首先，整个SOA架构的性能，如果每个服务的请求都经过中央Hub的中转，那么Hub的负担会很重，速度会随着参与者的增多而愈来愈慢；其次，这样的系统会很脆弱，一旦Hub出错，整个SOA架构都会瘫痪；最后，这样的架构会破坏SOA的开放性原则，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。因此，这也不是理想的SOA架构。好了，现在该ESB登场了，请看我们的正解：它与前面的Hub结构有什么不同呢？首先，它比单一Hub的形式更开放，总线结构有无限扩展的可能；其次，

18、真正体现了SOA的理念， 一切皆为服务，服务在总线(BUS)中处于平等的地位。即使我们需要一些Hub，那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多。这就是ESB，我们需要给它一个明确的定义：ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于： 面向服务的架构 -分布式的应用由可重用的服务组成 面向消息的架构 - 应用之间通过ESB发送和接受消息 事件驱动的架构 - 应用之间异步地产生和接收消息很不幸，上面的定义看上去很拗口，我们暂且用一句较通俗的话来描述它：ESB就是在SOA架构中实现服务间智能化集成与管理的中介。而它与SOA的关系要相对好理解一些：ESB

19、是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。可以这样说，ESB是特定环境下(SOA架构中)实施EAI的方式： 首先，在ESB系统中，被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台，这样就极大简化了在集成异构性上的考虑，因为不管有怎样的应用底层实现，只要是SOA架构中的服务，它就一定是基于标准的。其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作为

20、基础架构的EAI系统，必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体

21、现。其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可以利用这种机制来实现，例如，

22、SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。 ESB的适用场景及要素首先，我们来看一看ESB有哪些基本的功能。既然ESB会以中介的身份出现，它就必须有两方面的考虑，首先它必须了解被它中介的两个端点：1)服务的请求者以及请求者对服务的要求，2)服务的提供者和它所提供服务的描述；其次，它必须具有某种机制能够完成中介的任务。我们把这两类考虑归纳为ESB的两个基本功能：面向服务的原数据(MetaData)管理功能 和中介(Mediation)功能。 作为SOA的重要构成部分，ESB承担的重

23、任还包括怎样将企业架构中已存在的业务服务连接到总线上来，我们称之为适配器(Adapter)功能。尽管服务本身已经用公开的接口来描述，但具体的实现还是运行在不同的环境中，因此，ESB还应该提供对服务底层协议的支持，譬如应用协议J2ee，.Net， 通讯协议如Http，JMS等等。除此之外，还需要对具体应用中涉及到的服务加以管理，如性能，可靠性，安全性等等。ESB 提供了最基本的功能来保障SOA系统的运行，这些功能应该包含下列内容： 在总线范畴内对服务的注册命名及寻址管理功能 - 服务的Meta-data管理 面向服务的中介功能o 提供位置透明性的服务路由和定位服务o 多种消息传递型式(请求/响应

24、，单路请求，发布/订阅等等)o 支持广泛使用的传输协议(Http，JMS，MQ等等) 支持多种服务集成方式，比如 JCA、Web 服务、Messaging、Adaptor 对服务管理的支持，如服务调用的记录、测量和监控数据的提供很多时候，很难界定哪些功能是应该由SOA的基础架构(infrastructure)提供的，而哪些应该放在ESB的范畴内来解决。笔者认为，放大或突出ESB在SOA架构中的地位并不很恰当。比较合理的解释是：ESB应该构筑在完善的SOA架构上，做它应该做的事-服务集成。至于怎样集成，应该根据你的上下文环境，考虑有哪些SOA的基础设施可供你使用，然后再基于SOA的基础架构来实现

25、你的ESB设计。在更高的层次，ESB还提供诸如服务代理，协议转换等等功能，我们称之为ESB的应用模式(ESB usage pattern)。作为SOA架构的服务集成功能提供者，我们可以总结出的一些比较常用的应用模式，例如：1）协议转换模型，用于当服务的请求者与服务提供者基于不同协议时的消息转换情形2）消息广播模式，用于事件驱动多个动作或者消息广播的情形3）服务匹配模式，用于需要动态选择服务提供者的情形，例如可以根据消息的内容，或负载情况，或服务级别约定(SLA)，来为服务请求者选择合适的服务。这里我们只列举了3个典型的模式，而这样的例子实在太多了，发挥你的创造性，你还会想出来更多的，这也是ES

26、B的魅力所在。但是，在ESB的设计上，注意不能喧宾夺主，ESB的功能在于帮助服务的集成，而不是参与业务逻辑。业务逻辑应该封装在业务服务中，或通过业务编排服务(Process Service)来组织。 实战关于ESB，目前还没有被一致接受的标准。我们可以通过选择成熟的EAI 中间件来实现服务的集成与互操作性。这样做的好处是你的开发过程会很顺畅，因为它已经足够稳定且有丰富的工具支持。通常这样的EAI产品在目前阶段都还不是基于开放的标准，例如IBM的WebSphere MQ5.3，作为IBM EAI实现ESB的消息平台，就不是开放的标准。如果一定要选择开放标准的ESB实现方式，Web 服务加上WS-

27、* 协议几乎是我们唯一的选择，但毕竟SOA、ESB仍处于起步的阶段，一方面我们还没有很成熟的产品支持所有的WS-*协议，另一方面这些WS-* 协议本身还处在频繁变化的阶段。因此当你选择ESB实施方案的时候，最好考虑平衡ESB实施、开发的工作量。这里你可能会有疑问，既然SOA架构追求开放性，为什么我们要容忍用私有的ESB产品如IBM WBI/MQ来构建SOA架构的集成环境？这是一个好问题。SOA始终是我们追求的大目标，开放是必然的趋势，这是毋庸置疑的。但是，请注意ESB的定义，至少到目前为止，还没有明确的要求它的实现一定是开放的，每一个软件供应商对它都可能有不同的理解和实现的策略。我们不用怀疑E

28、SB将来的开放之路，但至少在目前阶段，我们不能坐下来等待它的到来。 其实，ESB充当的是SOA中的中介角色，因此，即使将来ESB变化了，对服务的请求者和服务的提供者都不会造成很大的冲击，因为它本来就是对用户透明的。举个例子，J2EE，它的标准一直在变化中，但是大家通常都能接受它的变化，社会总是要进步的，IT也一样。你不可能因为J2EE 两年以后要出1.6就不再使用现在的1.4了。IBM目前可以用于ESB实施的产品也可以分为两大阵营：1. 以目前稳定的产品如WS MQ，WBI Message Broker，Tivoli等为代表的EAI解决方案。2. 以WAS6 SIBUS为代表的专用ESB平台。

29、现有的EAI解决方案，可能涉及如下的IBM软件产品： WebSphere BI Message Broker用于提供ESB的message 中介功能(Mediation) WebSphere MQ / JMS 用于消息传输服务 WebSphere Process Choreographer 用于实现服务流程 WebSphere Adaptor用于连接遗留系统 Web Service Gateway用于实现Web服务 Proxy，屏蔽企业内部/外部Web服务的实现细节WAS6 中提供了崭新的消息服务平台WPM(WebSphere platform messaging)，并基于这一平台提供了ESB

30、的一个具体实现- SIBus(Service Integration Bus) 它可以支持同步和异步的消息通信。总线(Bus)通过互联的消息引擎管理消息源。同时支持基于Web服务和JMS，MQ格式的消息交互。你可以从WAS6身上看到IBM战略的变化，SIBus只是IBM加大对于SOA支持的一步，你还会很快看到更多的变化，例如独立的ESB产品，ESB的开发工具等等。但是，你完全不必担心，这些变化都会保持兼容性，现在SOA的投入，无论是以哪一种方式，都会在IBM的SOA整体考虑之中。上述的两种方案并不是对立的，你可以选择基于成熟产品实现ESB，也可以尝试一下IBM的最新技术。这两种方案甚至可以互联

31、，见图八。我们将在系列的第四部分讲解这一较为复杂的场景。在本系列文章接下来的三部分中，我们将继续详细描述ESB的具体实现步骤。 结束语本文向您介绍了SOA以及ESB 的基本知识，确定了一些 ESB 实现中最常见的基本功能，论述了ESB产生的必要性，以及ESB在SOA中的地位。 第 2 部分: 利用 WebSphere 6 中的 SIBus 实现 ESB志荣 周(), IBM 中国软件开发实验室 SOA设计中心 软件工程师简介：ESB作为SOA的基础设施，在构建SOA的过程中起着举足轻重的作用，本文是ESB系列文章中的第二篇。在第一篇文章中，我们对ESB的基础知识

32、进行了详细的介绍，本文将着重对IBM最新的应用服务器WebSphere 6中对ESB的支持进行实例化的介绍，希望通过具体的例子让读者更快，更方便的利用WebSphere 6的提供的基础设施向SOA(Service Oriented Architecture)进行迁移。引言ESB作为SOA的基础设施，在构建SOA的过程中起着举足轻重的作用，本文是ESB系列文章中的第二篇。在第一篇文章中，作者对ESB的基础知识进行了详细的介绍，本文将着重对IBM最新的应用服务器WebSphere 6中对ESB的支持进行实例化的介绍，希望通过具体的例子让读者更快，更方便的利用WebSphere 6的提供的基础设施向

33、SOA(Service Oriented Architecture)进行迁移。为了使本文更具有普遍性，在本文的样例中，作者模拟了一般可能出现的场景并给出了具体的讨论和实现。通过本文，读者最终可以自己利用WebSphere 6的SIBus实现ESB, 而本文所有的源代码和脚本将会提供给读者作为详细的参考。同时，本文中涉及的许多概念和基本操作流程本文所列的参考资料中都有详细介绍，本文就不再详细解释了。 1. 应用样例简介本样例是一个简化了的零部件价格查询模块，通常，一个制造企业所需要的零配件可能来自各个厂商，也有可能是自己制造的，同时，它所制造的零件也可能被它的内部用户或者外部用户来查询。由于零件

34、的价格变化比较频繁，所以这些价格的查询需要是即时的价格。下面是这个样例的Use case图： 2. 利用WebSphere 6中的SIBus实现ESB在本样例中，零部件的供应厂商的变化是频繁的，各个厂商的报价系统有可能是多种多样的，而且本模块还需要为企业内，企业外的客户进行服务，如何构造一个灵活的，可扩展的体系结构来适应复杂变化的环境已达到随需应变的需求？SOA是解决这个问题的好方法！首先，我们需要用WSDL来定义零部件价格查询的服务，这个WSDL文件相当于一个契约(Contract)，它定义了这个服务的具体交互方式，所有的服务请求者和服务提供者都遵循这个契约，但是具体服务的实现方式，交互协议

35、并不需要紧耦合在WSDL中，而且作为SOA的目标之一，使用者是无需知道服务者的端点地址和绑定方式的。接着，我们需要把这个服务架构在ESB上。在SOA中，ESB是不可缺少的，核心的基础设施，因为服务将最终在其上进行整合。WebSphere 6中全新的Service Integration Bus(SIBus)组件是实现ESB概念良好的选择，它的提出是为了更明确的为服务集成，服务整合提供支持，关于SIBus中的一些基本概念和它的配置、管理，用户可以从WAS6 Info Center得到帮助，本文将注重如何利用SIBus来实现ESB的基本功能。首先我们来看看在SIBus上，我们怎么架构这个应用，为了

36、使读者有个整体的把握，我们先来看看整体的架构图：下面就让我们来看看SIBus为实现ESB都做了哪些基础工作，每个基础工作又都为我们的样例应用提供了怎样的支持： 整合内部和外部服务从这个框架中，我们可以看到，不管是外部服务还是内部服务，我们都把它们抽象成与端点地址和绑定方式无关的，统一的一个入口点: 服务目标(Service Destination)，由它来在SIBus中代表零件查询这个服务。各个具体的服务提供者在SIBus中抽象成端口目标(Port Destination)，由它来代表一个具体的绑定方式和服务访问点。SIBus为端口目标提供了多种绑定方式的支持，从而使它可以以HTTP(S),

37、(Secure)JMS的方式的传输Web Service请求，对WS-Security和JAX-RPC Handler的配置都可以在端口目标级别进行，以适应各个服务提供者不同的要求。这样一个整合的过程在SIBus中是通过新建一个出站服务的方式来完成(Outbound)。 对外发布内部的服务对外部用户，我们把对服务目标的访问通过绑定在某个End Point Listener上来间接的提供，这样一个过程在SIBus中是通过新建一个入站服务的方式来完成(Inbound)。这样做的好处是统一了外部用户的访问点，方便了我们的管理，更好的安全性和更方便的性能调优。当外部用户需要访问某个入站服务的时候，他可

38、以通过入站服务发布的WSDL来获得具体的访问地址和绑定方式。 企业内部对内部服务直接的访问对于企业内部的用户，我们让他们通过API Attach的方式来访问我们抽象出的出站服务。这种API Attach的方式使企业内部客户可以通过标准JSR 109规定的方法来直接访问出站服务所对应的服务目标，SIBus为此提供了专有的绑定，这种方式比通过End Point Listeners的方式有着更高的效率，从而更适合内部用户使用。 消息灵活的中介 SIBus提供了消息中介的基础框架和编程模型，用户可以在SIBus上定制各种消息处理机制，SIBus为消息中介提供足够的信息让它来进行各种有效的工作。在本文的

39、样例中，我们使用了消息中介来解决了下面两个问题：o 外部的服务并不一定完全和内部的需求所匹配。在本样例中，我们的外部服务所暴露的接口方法名字和我们内部服务不一样，为了解决这个问题，我们开发了相应的消息中介并将这个消息中介绑定在相应的端口目标上来实现消息格式的转换。o 服务选择的问题，在本文样例中，我们有多个服务提供者存在，服务目标代表着其身后许多的端口目标及其相关的服务，我们仍然通过开放相应的消息中介来帮助我们实现我们需要的选择逻辑。 对ESB高级特性的支持SIBus还为ESB提供了和J2EE紧密融合的安全机制，事务的传输机制，消息的QoS服务，还有和MQ消息系统的直接互连，虽然这些在本文样例

40、中没有涉及，但在后面的文章中，我们将专门介绍这些高级特性。 3. 在SIBus上实现样例应用为了实现本文的样例，我们需要定义好零部件查询服务WSDL，然后实现内部服务，开发需要的消息中介，发布这个应用，接着需要对内外部服务进行整合，最后把整合后的服务发布出去。为了本文样例的演示，还需要开发模拟的外部服务，模拟的内部客户和外部客户来使整个流程运转起来，下面我们就详细介绍各个部分的实现方法和关键点：1实现内部服务首先，对内部服务，我们按照JSR 109的方式定义为Web Service。JSR 109规范定义的服务有两种基本方式，在Web Module中的Java Bean的方式和在EJB Mod

41、ule中的EJB方式，本文的样例中对外部服务采用了第一种方式来实现，对内部服务采用了第二种方式来实现，这为的是给读者提供全面的参考，同时也更符合实际的场景。内部服务的具体实现可以参考样例中InsideService_JAR模块。这里需要指出的是当使用Java2WSDL来产生ejb绑定的WSDL的时候，WebSphere 6引入了新的EJB的绑定方式，这为的是省去SOAP方式的序列化和反序列化的过程，直接通过RMI-IIOP来进行更高效的通信，下面就是内部服务WSDL中绑定部分的定义： 请注意这里的EJB绑定方式和它的端点地址的表达方式，这种绑定和WSIF的EJB绑定是不一样的，WSIF在Web

42、Sphere 6中已经不再被建议使用。读者可以参考Info Center获得Multi-protocol JAX-RPC详细的信息和Java2WSDL的具体语法。2实现外部服务对外部服务，我们用一个Web模块来模拟，它是一个按照JSR 109方式定义在Web Module中的以Java Bean方式实现的Web Service，具体实现可以参考样例中的OutsideService_WAR模块。需要注意的是：外部服务WSDL接口定义的方法和内部服务是不一样的，外部服务WSDL定义的服务方法是：getPartPriceOfOutService，内部服务WSDL定义的方法是: getPartPric

43、e。3实现对消息的路由和格式转换SIBus的消息中介框架是我们实现消息路由和格式转换的基础，开发者可以利用Rational Application Developer来开发，部署各种消息中介。我们这里将简要的介绍一下实现的关键，具体细节请参考Mediation_JAR模块中的QueryDispatcher类和Adaptor类： 消息的路由：在本文样例中，我们将根据零件的编号的前缀来决定它属于哪个零部件厂商，从而把价格查询请求转发到该零部件厂商的服务所对应的端口目标上。具体的选择规则我们是通过配置目标上下文属性的方式来提供给消息中介的，详细情况可以请参考4.3中的说明。那么选择好了目的地后，怎么

44、路由消息到那个目的地，而不是原来缺省的地址呢？我们来看看SIBus是怎样处理消息的分发的：在SIBus中，消息的路径是直接放在消息中的，路径分为前进路径和返回路径，每个路径都是一个SIBus上目标地址(Destination)的列表，消息传送引擎所做的工作就是从前进路径列表中取出第一个地址，然后把消息转发到这个地址所对应的目标。所以如果想更改消息的前进路径，我们只需把路径列表取出来，然后更改这个列表就可以了。下面的代码演示了如何把把消息转发到已选出的端口目标portDestination上。List frp = msg.getForwardRoutingPath();/取得前进路径列表SIDe

45、stinationAddress destination = /根据portDestination生成SIBus的目标地址类SIDestinationAddressFactory.getInstance().createSIDestinationAddress(portDestination,false);frp.add(0, destination);/把目标地址插在第一个位置msg.setForwardRoutingPath(frp); /把前进路径放回消息体 消息的格式转换：在本文样例中，外部零件厂商的服务接口和内部零件厂商的接口并不一样，所以我们需要在对外部服务请求发出去之前进行一定的

46、消息格式转换，把消息转换成外部服务的格式才行，当然，这种转换必须在逻辑上是可行的才可以实现。我们先来看看SIBus中的消息格式：在SIBus中，各种消息格式将统一在SDO(Service Data Object)接口之上，我们只需通过SDO接口就可以对数据进行各种操作，包括格式转换，而无需使用各种不同形式的API，这无疑将大大减轻了开发者的负担。回到本例，我们需要对消息格式进行转换，具体的说就是需要变换操作的名称，从getPartPrice转到getPartPriceOfOutService，下面是本文样例中如何对消息格式进行变换的关键代码：if(getPartPrice.equals(ope

47、rationName) /对前进消息进行中介String serviceDestination=dest:ESB_SHOWOFF::PartsInfoService;String graphFormat=SOAP:+serviceDestination+,,PartsInfoService,PartsInfo;String requestValue=info.getDataObject(body).getString(itemID);DataGraph graphNew=SdoRepositoryCache.insta

48、nce().createDataGraph(serviceDestination);DataObject root=graphNew.createRootObject(graph.getRootObject().getType();info=null;info=root.createDataObject(info);info.setString(operationName, getPartPriceOfOutService);info.setString(messageName, getPartPriceOfOutServiceRequest);info.setString(messageTy

49、pe, input);DataObject body=info.createDataObject(body, /生成新的数据类型,getPartPriceOfOutServiceRequest);body.setString(itemID,requestValue);需要注意的是: 我们对前进的消息进行消息变换的时候，对返回的消息也要进行反向的消息变换才能使服务请求者得到所期望的结果。 我们需要一些WebSphere内部的接口（SdoRepositoryCache）来生成新格式的DataGraph，因为所有的数据类型都是在SIBus中的SdoReposit

50、ory定义的。 用户需要熟悉这些内部接口和SDO的API，不过，本文样例给出了很好的参考，基本解决了数据格式变换会碰到的问题。4整合内部、外部服务现在，内部服务，外部服务都有了，消息处理中介也有了。下面我们就要通过新建一个出站服务来把他们整合在一起。我们需要给出站服务提供一个完整WSDL定义，来表示可以通过出站服务的数据类型，对本文样例来说，它需要涵盖内部和外部所有数据类型的定义，具体定义可以参考InsideClient_WAR模块中的PartsInfo.wsdl。我们在这个WSDL中定义了三个可以使用的端口：PartsInfo，PartsInfo_SEIEjb和PartsInfo_SIB，也

51、就是有三个服务提供者可以选择，他们分别对应HTTP，wsejb和sib类型的绑定。同时，在新建出站服务的时候，我们可以同时把服务选择消息中介绑定到出站服务目标上，而消息转换的消息中介则需要在完成新建出站服务后手工绑定到外部服务所对应的端口目标上。我们可以通过管理控制台或者wsadmin命令行的方式配置出站服务，详细的脚本和参数请参考附件中的脚本ConfigSamples.jacl，最终配置结果在管理控制台中显示如下：5把SIBus上的服务发布到企业外最后一步，我们需要把企业内部的服务发布出去，让外部的客户能够访问到我们的服务。我们可以通过新建一个入站服务来把SIBus内部的服务目标通过HTTP

52、(S)或者(Secure)JMS Listener为外部用户提供统一的访问入口点。新建入站服务的时候，我们需要提供一个模板WSDL来定义这个入站服务可以接收的服务请求，在这个模板WSDL中，我们只需定义我们需要向外部提供服务的端口类型就可以了，绑定类型和端点地址都不需要提供，实际上这些都是由Endpoint Listeners来具体决定的，我们一般称这种WSDL为non-bound WSDL，具体内容请参考InsideClient_WAR模块中的PartsInfo_Templet.wsdl。配置入站服务的参数请参考附件中的脚本ConfigSamples.jacl，最终配置结果在管理控制台中显示

53、如下： 4. 本文样例的一些说明在本文的样例中，我们在一个企业应用（WAS6ESB.ear）中模拟了各种角色，下表总结了这个应用的各个部分的和它们所扮演的具体角色，具体的部署后的结构图可以参考前面的整体架构图：这个应用是基于Ant来构建的，读者也可以使用WebSphere Server Toolkit或者Rational Application Developer来辅助开发。打包文件中已经包含了Build好的结果，各种脚本在Scripts目录下，对具体脚本的功能请参考目录下的ReadMe.txt。在部署的过程中，以下几点是需要注意和说明的地方：1 WebSphere 6安装好后缺省是没有SIB

54、us环境的，所以首先要建好SIBus，配置好Endpoint Listeners，读者可以用管理控制台来实现，也可以用作者提供的脚本来自动配置（WasSetupSIBus.bat），不过读者需要更改一下脚本中相关的目录信息。建好SIBus后还需要重启一下才能使它生效，要不然应用会报找不到引擎的错误。2 安装企业应用WAS6ESB.ear的时候可以使用脚本InstallWAS6ESBApp.jacl来自动进行，出站，入站和消息中介的配置，读者可以使用脚本ConfigSamples.jacl来自动进行，用户也可以自己通过控制台来完成，使用控制台时需要的参数可以参考脚本中的相关信息。3 目标上的上下

55、文配置信息可以被灵活的利用来给消息中介提供帮助，本文样例中，我们就是通过在服务目标上加上上下文属性来决定服务的选择规则。我们加入了下列属性值：这里，我们用属性的名称来代表零件标号的前缀，属性的值代表外部服务所对应的端口目标的名字，DispatcherMediation根据这些上下文属性来选择服务。这样做的好处是当有新的服务提供者加入的时候，我们只要增加一个端口目标并在服务目标上下文属性中加上规则就可以了。不过，WebSphere 6中没有提供脚本配置目标上下文属性的方法，所以这些属性需要手工加入。4 SIBus为我们提供了灵活的运行时配置的支持，我们可以在应用部署以后动态更改端口目标中的端点地址和绑定空间，在本文样例中，我们就可以利用这个功能在新建完出站服务后更改各个端口目标的端点地址设