技术开发 频道

ESB的前世今生

【IT168 技术文章】

    序言

    你可能是一家集团企业的CIO,为了维持企业业务正常运转,你已经部署了几个,十几个,甚至是几十个不同的IT系统。这些IT系统在运行初期,为提升企业的执行效率发挥了很大的作用,但随着业务内容的不断深入,你发觉这些业务系统之间是离散的,是孤立的,你希望将这些系统进行整合。更进一步的,你盼望有一种神奇的魔力,不仅能够有效整合遗留系统,新建的IT系统也能够在这种魔力下获得一体化的支持,而你所掌管的IT系统能真正做到随需应变,按需扩充。

    你也可能是一家IT公司的CTO,你所带领的团队正在开发一种新的IT应用,你渴望用SOA理念来指导这个新应用的架构设计,但你又不知如何才能使SOA落地;你被灌输了太多的SCA、SDO、BPEL等等的标准与规范,但你却不知道这些标准与规范又该如何运用到具体的项目;你也同样希望有一种神奇的魔力,能够让你的团队多年积累下来的业务逻辑形成跨基础架构、跨技术平台的真正可重用的组件库,而这些组件库在流程编排下形成具体的功能模块,解决具体的业务场景。

    那么,你找到问题的解决方案了吗?我有个主意,它叫ESB,它能让你的SOA真正落地。
   
    真是这样的吗?别急,先让我们来了解一下ESB的前世今生......

    企业集成软件的发展史

    在企业信息化进程的最初,一个应用软件的使用范围可能仅限于某一个部门或某一种业务,由此而导致的情况是:一个大型的企业可能存在多个大小不一且支撑技术不同的应用软件系统,这些系统可能基于不同的编程语言,运行在不同的硬件上,有着不同的系统平台。但随着企业的壮大,业务的发展,部门和部门之间的关键路径和业务接口逐渐增多,各个应用软件之间的信息交互也越发频繁,同时,企业与上下游合作伙伴之间,数据共享、流程整合的需求也不断催生,在这样的背景下,企业应用集成软件应运而生。至今为止,企业集成软件的发展,可以分为三个阶段:

    基于标准协议的代码定制

    这是最初出现的集成软件。一个业务系统和另一个业务系统直接通话,业务接口采取定制代码的方式,通过一些标准的协议,例如Http、Ftp等,紧密的集成在一起。这种集成方式的缺陷不言而喻:缺乏可靠的数据传输保障;系统毫无弹性可言;数据交换时双方必须同时在线;部署模型是非常复杂混乱的网状结构等等。

    


    基于消息的代码定制

    基于消息的异步编程模型,则为企业集成提供了一种新颖的解决方案。传统的消息中间件,能够有效解决数据传输的可靠性、稳定性与安全性,并且,消息提供的异步编程模型,避免了集成双方必须同时在线的问题,于是,人们在原先方式中的数据载体由通过标准协议,换成基于消息,大大提高了数据的可靠性,以及部署上的分布性。但是缺点还是同样明显:路由逻辑和业务逻辑没有分离,系统基本没有扩展性,部署上还是网状结构等等。

0
相关文章