技术开发 频道

走出ESB误区:揭开ESB的十个神话

    误区5:ESB与J2EE应用服务产品之间存在竞争

    ESB与J2EE app服务器是高度互补性质的。通过使用JMS、MDB、JCA或Web服务等标准接口连接到ESB,即使是在非J2EE环境下J2EE app服务器也可以与其它应用服务器很好地集成。

    大部分ESB用户同时也是应用服务器技术的用户。这些用户利用应用服务器和ESB作为他们的集成环境的最优组件--使用应用服务器寄存业务逻辑并以门户的形式提供网站服务,同时使用ESB来集成应用服务器与企业中的各种后端应用和数据源。

    误区6:只要使用Web service call即可把门户网站连接到后端系统上

    虽然理论上Web服务调用可以把门户连接到后端目标系统上,可是这种方式无法扩展到多个后端系统上。通过使用ESB,可以让门户服务器通过唯一的接口连接到总线,而总线则成为门户服务器可能调用到的所有后端系统上的各种连接属性、协议、安全和数据格式的媒介。

    使用了ESB作为门户服务器和可能与门户服务器产生交互的各种后端应用的中间层相当于为ESB用户提供了一个更为灵活、扩展性能更好的SOA,因此当项目更成功、根据业务需求需要发生变化时,他们也能自由地处理各种各样的集成作业。

    误区7:当BPEL获得广泛应用的时候ESB就会退出舞台

    ESB可以支持多种事件驱动的服务调用的编排方式。BPEL只是其中的一种。ESB还有基于路线的路由,可以为消息指定一系列的路由指令。消息因被服务调用而经过总线的时候,这些代表业务过程定义的路由指令始终是和消息绑定的。然后由远程ESB服务容器决定将消息发送到哪里。

    这个过程中没有集中的路由规则引擎,因此基于路线的路由也是ESB分布式的特性一大体现。像星型EAI代理所用的这种集中的消息路由规则引擎则可能会成为系统的瓶颈,并且如果这一部分出现故障将导致整个系统的瘫痪。仅仅使用消息路线、消息和过程定义其实就足够了,这样还能允许ESB的各个不同部分独立地进行工作。

    消息路线可以有效地处理那些包含有限步骤并且无需很长的处理时间即可结束的无状态随机过程。甘特称这种过程定义为"微流(microflows)"。根据基于内容的路由服务的使用情况,路线中可能会产生简单的分支。

    如果需要更复杂的过程定义,还可以在ESB中加入一个流程编排引擎作为补充服务。这个过程编排可以支持可能存在很长时间的状态过程。它还可以支持带分支的平行执行路径,并根据联接条件或转换条件支持消息流执行路径的融合。这样的过程可以支持BPEL和其它的过程定义语法,比如ebXML BPSS。还可以将成熟的过程编排与非状态的基于路线的路由结合,建立一个可以解决复杂的集成问题的SOA。

    误区8:ESB技术和其它技术一样正在经历一个典型的技术发展曲线:凭空产生,迅速发展,然后马上进入“幻灭”阶段。

    ESB这个概念是制造、电子商务、电信、金融服务和零售等多个产业的先导者共同努力产生的结果。其产生是由于需求,是以当时已经比较成功的分布式计算模型和EAI技术为基础建立的新方式。这些IT先导者的最终结果是一致的:"我们的分布式消息基础结构是成功的,所以我们希望能以此为基础建立一个用于集成的基于标准的事件驱动的SOA。我们希望它能包含Web服务、XML数据转换、基于内容的路由和面向分布式过程的服务调用模型。"因此,ESB中所体现的这些概念都是成熟的,是有健全的基础的。也正因为如此,ESB技术正在发挥着它应有的作用。现在已经有数百条ESB在各行业服役,比如供应链、物流自动化、金融服务中的全球直通处理、电信的实时服务、以及零售业的远程店面管理。

    误区9:ESB只是一个推动器,但它并没有提供成熟的工具,比如设计业务流用的图形编辑器。

    现在有一种新的IDE(或Gartner集团所称的ISE)可以让你设计、配置、测试、调试你在建立应用ESB的SOA时开发的集成服务。其使用的是图形界面,集成设计师可以用UML表示法来描述过程定义。你还可以使用ISE图形化地创建不同数据之间的转换方式并建立和调试XSLT模式表。

    误区10:可以使用EJB容器实现ESB容器

    ESB结构中的一个关键组成部分就是一个高度分布式的、轻量级的服务容器。这个服务容器能以事件驱动服务的形式寄存集成组件,比如一个在XML消息中添加XPath表达式来决定路由的基于内容的路由服务。它还能寄存定制的服务或用于接入打包的应用的专门适配器。

    这和它们的远房亲戚应用服务器容器及集成代理可不一样,ESB服务容器可以让你随时在任何地方有选择性地按需部署集成服务,不多也不会少。而另一方面即使只需要添加一点集成功能都需要在所有地方安装完整的应用服务器堆栈。这样就产生了所谓的"到处都是应用服务器"的问题。同时还会产生数目不小的许可证、安装、和随后相关的各种费用。

    而ESB的精髓在于"配置取代编码"。如果是以应用服务器为主的集成方式,你通常要编写代码来描述服务之间的依存关系。EJB模型使用的是client/server的集成模式,服务之间的接口是紧耦合的关系,而这些都要写进代码并编译到类文件中,这样,每次需要改动的时候都要对这些文件进行修改和重新部署。

    在ESB中,服务是以与输入和输出通道有关的信息进行配置的。这些通道发送和接收基于内容的请求和响应模式以及单向事件通知,然后通过其它的调用框架进行处理,而不是服务本身。

    可以对ESB服务进行配置和部署,这只需要从配置仓库里读取XSL模式表、XPath表达式、脚本和参数等信息。一旦部署完成,其性能便是高度灵活的。

    总结

    总的来说,对ESB的理解包含以下方面:

    · ESB是建立企业SOA集成环境的主干总线。

    · WS-*标准的发展将使ESB的交互性能更为完善。今天采用ESB可以让你做好应付未来的准备,并且当WS-*标准具有真正的商业价值的时候你也能做出适当的调整。

    · ESB并不仅仅是一个抽象的模式。它属于产品的范畴,有清晰的定义,也有许多供应商可以选择。

    · ESB与应用服务器的互补性很强。

    · ESB提供了灵活的连接器和可扩展的设施,有利于将门户服务器集成到后端系统。

    · ESB为协调服务之间的交互提供了许多选择。

    · ESB技术是以实际为基础的,并已在许多行业得到应用。

    · ESB可以提供更高层次上的可视化工具在ISE环境下进行服务集成。

    · ESB提供了一个轻量级、可配置、高度分布式的服务容器环境。

0
相关文章