关于ESB常见认识误区

    随着政府、企业信息化这么多年的发展，信息化在许多单位已经实现了业务领域的全覆盖或基本覆盖，很多时候，再做信息化已经不再是像以前那样新上个业务应用，针对现有业务应用的集成整合，越来越成为一个大的趋势。应用间的集成整合，从技术手段上来讲，可以有多种选择，而基于SOA理念的集成整合则是目前广为大家所知、所接受的一种方式。ESB作为SOA参考架构模型中的核心组件，越来越多的在应用整合集成领域发挥大的作用。

    不可否认，ESB是个非常好的工具，内置各种接入组件和接入协议支持，能够方便的实现跟不同业务应用的接入，但ESB也不是万能的，在跟客户、同事交流过程中，发现有些认识上的误区。

    一、ESB能干的事情是其他工具或其他方法干不了的

    很多人一开始接触采用ESB做应用集成整合的思路时，通常会问，为什么要用ESB，有哪些ESB能干的事情是其他的工具或其他的方法不能干的。要理解这个问题其实很简单，ESB只是一个工具，也是一套程序，具备一定功能的程序。既然是程序，就是通过某种编程语言写代码实现的，只不过这一大堆代码可能设计良好，考虑到了很多种情况，经历了很多场景的检验，是比较成熟稳定的；时间和精力足够的前提下，相信有很多牛人或者牛公司可以从零开始实现一个ESB的全部功能。所以从这个意义上来讲，没有任何事情是ESB能干而其他工具或其他方法不能实现的。那为什么还用ESB，直接写代码多直接？理解这个问题也简单，因为ESB这堆代码是设计良好的、经历很多场景检验的、成熟稳定的，如果自己写，不能说就一定是不够设计良好、不够成熟稳定，但要达到这个目标至少需要一段比较长的时间，而时间恰恰在很多时候是个稀缺资源。

    二、只要是做应用集成整合，用ESB就是最好的选择

    这其实也是一个比较常见的误区，ESB适用的场景是：在多个（一般来说至少两个以上）应用之间做整合集成的情况，而且希望应用系统之间是松耦合的，因为后续系统间的接口有可能会发生变化。这种情况下就是ESB大显身手的时候，设想有10个系统，如果每个系统都有可能需要跟其他的系统有接口，你可以算一下一共得多少个接口，如果后续业务有一点点变化，你要改这些接口是不是有点欲哭无泪的感觉。而采用ESB则不然，所有应用间的集成交互都是通过工具可视化配置的，基本不需要写代码，修改起来也非常灵活。如果只有两个系统要实现数据交换，要交换的内容不是很多，而且是一成不变的（至少在可预计的将来，比如5-10年内不会变），通过写代码来实现也不失为一个可选项，毕竟采用ESB需要购买工具不是。

    三、ESB内置各种接入组件和接入协议，做应用集成整合不需要应用系统原厂商支持

    这个认识误区可能更具普遍性。很多人会问，你们的ESB不是可以跟各种数据库、各种协议都方便的接入吗，不是不用关心是采用什么开发语言吗，为什么还需要应用系统原厂商提供支持？首先，ESB确实可以实现跟各种数据库、各种协议方便接入，也确实不关心应用系统采用什么开发语言，但是ESB要实现对不同应用的接入，还需要这些应用系统提供接入的接口，举例来说，有A系统，ESB需要将A应用接入，把其中的某些数据提供给另外的应用使用，那这些数据ESB怎么获取到呢，总的来说无非两种方式，一种直接到数据库里取，另外一种是跟应用做接口，从接口取；如果是从数据库里取，是不是需要知道这个应用的相关表的结构和业务含义？是不是需要应用数据库对ESB放开读取权限？这些没有应用原厂商支持怎么做到？如果是跟应用做接口，那应用有没有现成的接口，如果没有是不是要开发一个接口，开发接口是不是也需要应用原厂商来做？这还只是从系统里取数据的情况，如果要往某系统里写入某些数据，是不是更需要原厂商提供接口（往应用里写数不推荐直接操作库表的方式）？所以，虽然ESB具备了开放强大的接入能力，在做应用集成时，离开了原厂商的支持，也是无法开展工作的，至少是很难开展工作。