SOA的竞争前沿—ESB技术发展与应用趋势
Forrester研究公司将ESB(企业服务总线)技术描写成“通过起到中间件的中间层作用而实现面向服务架构(SOA)的软件基础设施，通过这样的中间件，就能广泛利用一套可重复使用的商业服务。”最近，ESB不仅需要支持异构环境中的服务、消息，以及基于事件的交互，还被认为具有适当的服务级别和可管理性。
在近一段时期，多家软件厂商都加大了对ESB产品的投入力度，并声称自己的SOA解决方案因此而更加完善，在SOA的赛跑中，ESB是竞争的前沿。
ESB让SOA落地
以Cape Clear、Sonic、IONA为代表的ESB领域专门厂商的出击，以增量式部署SOA为口号，强调以一种低廉的、基于标准的Web服务编排工具，并在此之上构建健壮的SOA。而SOA平台厂商纷纷反攻，正在向原有的套件产品中添加ESB和IT治理功能。甲骨文公司去年还只是把ESB产品内嵌在其业务流程管理产品中，今年已经推出了独立的ESB产品。BEA推出了 AquaLogic Service Bus、BEA AquaLogic Data Services Platform来加强ESB的产品线。IBM在原有WBI Message Broker、WAS 6 SIBus这些集成产品之外，又推出了独立的WebSphere ESB产品。而传统的EAI厂商Tibco和WebMethods也宣布了各自的ESB产品。
众厂商之所以都看准了ESB这块蛋糕，还得益于SOA理念与现实应用环境的差距。
SOA的风潮在软件行业内铺天盖地，连一些硬件厂商都忍不住参与其中，如果解决方案不提SOA就好像落了伍。但在实际应用中，SOA的实施依然不怎么起劲。因为对许多用户来说，SOA目前还是空中楼阁。大谈按照SOA的理念重建应用系统，这种理想状况相信每个人都不会反对，但现实中这样的事情太少，企业的CIO大多面临一件事，就是处理好目前应用系统的运行—集成就自然而然成为最容易切入的话题，由集成开始而赋予应用系统以SOA的灵魂，才确有其现实意义。ESB的冒头也就由此产生，它与EAI(企业应用集成)密不可分，同样是集成，ESB所提倡的集成与EAI的集成既有相同点，也有不同之处。“ESB的意义在于让SOA有了一个可实现的基础设施。”IONA公司大中国区高级架构师陆飞舟这样认为。他说:“ESB与EAI的主要目的是相同的，但是ESB更具开放性，尤其是对Web服务的支持，使得它成为实现SOA的基础设施。”
BEA公司中国区技术经理刘汩春认为:“SOA的‘服务’不仅仅是可重用，而且必须是可组装编排; 可快速注册发布; 质量可监控;生命周期可管理的。这样SOA才能在整个IT范围内实现服务治理和优化，从而直接推动业务的优化。而从简单的服务重用框架到SOA演进的过程中，ESB就是其中最重要的催化剂之一。”
作为国内中间件领域的后起之秀，中和威公司在2005年发布了其最新的ESB产品，该公司的总经理王志伟说:“SOA是一种架构上的创新，但其中的技术并没有创新，ESB明确了中间件的细分层次。”
无论SOA的理念有多么吸引人，终究不能纸上谈兵，ESB的成熟让SOA有了一个可以落地的依托。
竖井之惑
尽管软件厂商对ESB表现出很强的关注，并投入了大量的力量，在对ESB的作用并非只有一种声音。有一些人将ESB视为过时的EAI—感到它们藐视SOA的开放本质。在今年InfoWorld的一期报道中，介绍了Burton Group分析师Anne Thomas Manes的观点。她说:“EAI与SOA完全不同。EAI是为了在业务流程竖井上架一座桥梁，而SOA是为了推倒这些竖井。”她对使用ESB配置服务或将细粒度的服务编排为可广泛访问的粗颗粒的服务没有疑问。但她十分不满地批评总线作为连接所有服务网关的概念，尤其当转换到ESB消息传输和从ESB消息传输转换造成额外的开销时。一种替代ESB方式的选择是使用XML专用设备(也即所谓的网关)来传送消息、处理转换和映射，以及代理服务，使它们可以被有效地管理和保护。
记者就这一对ESB的质疑询问了几个厂家的专家。甲骨文公司大中华区SOA技术推广经理周有衡说:“如果在纯粹的SOA世界里，每一个应用都通过BPM(业务流程管理)编排来实现，流程之间也需要传输，系统内也存在着数据交换的需要，中间状态也需要保存，如果系统内有交互的需要，就应该有总线，只不过这个总线可以是网络的，而不是单一的,在现实的应用环境中,总线更是不可少的。”
陆飞舟认为:即使企业完全按照SOA的理念划分模块，但以后出现了新业务也会产生连接与交换的问题，而且企业外部的系统如果没有实现SOA，那么跨企业的系统之间仍然需要总线来连接。
Burton Group分析师Anne Thomas Manes的看法其实是把ESB与EAI的技术机制混为一谈。东方通公司首席软件架构师、SOA-RA-TF主席朱律玮告诉记者:“EAI最早的技术机制是点对点的集成，而后来更成熟和被业界所接受的是Hub-Broker机制，即EAI 软件创建了一个交换中心，用于转换不同应用程序间的数据和消息。EAI 交换中心使用这些适配程序将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外部适配程序都可以理解的通用格式，并将其称为规范格式。”
在Hub-Broker机制之下的中心总线确实有可能成为系统的瓶颈，并造成额外的系统开销，或者用户必须购买更强大的硬件设备来保证总线的效率。但在ESB的天空下，EAI的Hub-Broker机制已经烟消云散，代之以更灵活、轻便的结构。
朱律玮说:“ESB的总线方式可以是多样的。例如，总线可以是一个网络，而不是一个中心Hub，甚至还可以直接通过点对点的方式。多样的方式是为了减少总线的压力，具体的形式可以很灵活。”
刘汩春的看法更为直接，他说:“信息系统中竖井的存在是必然的，因为企业中本来就有着不同的部门，每个部门有不同的业务系统，竖井不一定是贬义的，竖井太多才会有问题，只要企业内和企业外有跨系统的应用存在，总线就有其生命力所在。”
超越EAI
ESB在开放性上的进步，使其在EAI的基础上又进一步，在秉承EAI集成的理念之上，ESB能够做到面向SOA的集成。
王志伟说:“在SOA之下，ESB具有了透明化与标准化的特点。例如，今天你用了一家厂商的ESB产品，如果以后你觉得不好，还可以用其他厂商的ESB产品代替，而不会影响ESB上层应用和下层的数据库和操作系统。”
刘汩春说:“如果具体的把ESB产品和传统EAI里面的消息总线类产品做个比较，两者差异就很大了，主要有三方面。第一，ESB以SOA面向业务的哲学为基础，所以它主要是通过配置来建立，而不是通过编程建立;第二，ESB必须有能力在不同的协议之间建立互通机制，包括传统的消息机制和Web服务接口;第三，除了消息(服务)代理方式外，ESB还必须为SOA服务治理提供服务的生命周期管理，而非简单的过滤、转发、路由。”
陆飞舟说:“ESB 采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时，集中式的交换中心才有意义。ESB(如 IONA Artix)可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。交换中心与大型主机一样，仍然可以用于某些需要它的体系结构中，但它们只是开发人员的一项选择，而不是供应商指定的要求。”
陆飞舟说:“ESB采用了Web服务这样的开放标准，而EAI采用的是私有化集成方式，许多接口都是某厂商自己的技术，而且往往许多集成并不透明。”
BEA公司的刘汩春认为:“ESB除了运营支撑系统作为服务提供者和消费者的中介提供服务交互、代理和路由功能外，还必须提供可扩展的服务编排、目录、元数据管理、生命周期管理、服务质量和级别控制等功能。通过这些功能，ESB帮助屏蔽各种服务生产者的差异，集中管理所有的服务消费行为。从而避免服务的大量蔓延，简化用户SOA环境的复杂性。”
进化中的技术与产品从广义的角度而言，ESB最主要的技术与Web服务密不可分，如WSDL(Web服务描述语言)、UDDI(统一发现、描述和集成)和SOAP(简单对象访问协议)，这方面的技术目前处于稳定的发展阶段，而有关WS*的发展正处于一个整合和渗透不稳定过程中。此外，还有一些相关的技术正在活跃起来，比如流程方面BPEL(业务流程执行语言); 安全方面SAML(安全断言标记语言)、XML处理的XQuery;服务组件模型SCA/SDO(服务组件架构/服务数据对象)与JBI(Java Business Integration)等。
朱律玮告诉记者:“目前大部分的ESB技术规范还处于发展之中。例如服务的查找，在行业内是基本可行的，但在互联网上，由于语义的差异，服务的查找还很困难，WSDL规范了技术语义的描述，但关于商务语义的描述还没有正式的规范出台。目前比较火的SCA/SDO的版本还是0.9，没有正式发布。”
刘汩春说:“ESB目前正处于快速发展的时期，随着ESB逐渐在实际项目中深入应用，用户对其提出更多的要求。比如，服务生命周期管理，就是指从服务发布、注册、使用、推广、效益统计、升级等;服务质量控制和服务级别保证;服务目录和元数据管理;异构适应性:跨越具有不同所有权的多种网络、多个协议以及多个管理域的真正意义上的总线。”
刘汩春认为，ESB还必须解决用户对传统EAI的主要诟病，就是其客户化开发工作量问题。ESB必须提供给客户越来越多的在线配置功能，而非开发框架来适应业务变化，所以其工具的优化是促进应用的一个重要因素，也是一个发展趋势。
目前，从厂商产品的划分来看，专门以ESB为主要产品线的中间件厂商的ESB产品覆盖面较广，他们一般认为自己的ESB产品可以帮助用户实现所有与SOA有关的工作，其中也包括了BPM。有些厂商还把门户功能也加入其中。而原来提供SOA平台产品的软件厂商则认为ESB是SOA中的一部分，他们的ESB产品是其整个SOA平台软件中的一块，通常会把BPM作为另一个单独的产品，例如BEA、甲骨文、IBM、东方通等公司。
王志伟谈到:“SOA影响力的扩大，让目前的中间件产品有了更细分的市场，最明显的就是产生业务流程管理和总线两个独立的市场，而在以前这两个部分都统称中间件。”
无论是IBM，还是BEA、甲骨文等公司都在套件产品的同时，推出了单独的BPM产品和ESB产品，对于用户服务而言就有了更多的选择，因为这些产品可以与其他厂商的中间件产品相互搭配使用，中间件产品原来的功能也是集成的，ESB的成熟对原有套件型中间件产品市场产生了不小的冲击。
王志伟说: “SOA带来了ESB与BPM等产品市场的细分，是一个重新洗牌的机会，但对于国内的中间件厂商而言，更需要完善主要产品的功能，还不可能与国外的平台厂商全面竞争，重点突破是目前能做的事。”
朱律玮谈到:“东方通的ESB产品线不会追求大而全，实用是第一位的，对于里面的关键技术都做到最好，例如连接服务和流程服务是我们的重点，其他一些产品可能会寻找合作伙伴或开源产品。”
ESB的应用
由于目前厂商对ESB产品有不同的划分，导致ESB的应用范围也产生了不同，综合主要ESB的产品应用，可以概括为应用在消息层面的转换、数据集成、以及流程的集成和管理。从应用领域而言，ESB与EAI没有大的区别，但由于ESB是基于开放的Web服务而来，在通向SOA的道路上，ESB可以当仁不让地挑起大旗。例如政府部门之间的跨系统互联，企业之间的跨系统电子商务应用。
周有衡说:“目前国内的用户还大多更关心例如数据整合、门户整合、应用集成这类的集成项目，从这些项目开始，SOA才得以导入。”
| 部分ESB产品列表 | ||
| 厂商名称 | ESB主要产品 | 关键特性 |
| BEA | AquaLogic Service Bus2.0 | 支持多种消息格式和传输协议，消除了消息之间的差距，发送方和接收方在不替换现有基础架构的 情况下，实现服务之间的快速集成和部署。可配置监控能力提供服务交互标准、消息跟踪事件和消息记录，并根据可配置的SLA设置界限和警告（不需要购买和集 成其他管理产品），支持有效的日常SOA运行，有在线建模能力。 |
| 东方通 | TongIntegrator3.0 | 有一个内在的伸缩性设计，保证了在系统规模扩大的情况下，不牺牲效率。这保证了能够迅速和容 易地连接新系统而不影响吞吐量。使用简单，每个TongIntegrator的适配器都通过一个简单的配置文件来定义。因为TongIntegrator 提供了一套标准组件，构建一个适配器，甚至可以不用写任何程序代码。 |
| IBM | WebSphere ESB | 提供了基于SCA的开发模式和完备的开发工具，并且提供了预先定义的元中介 (Mediation Bean)。这样用户通过工具WID (WebSphere Integration Developer)，可以采用拖拽/配置的方式简单地开发中介信息流，实现ESB不再是复杂的任务。 |
| IONA | Artix4.0 | 广泛的操作系统平台支持和编程语言支持，多协议集成；基于ART的高性能内核Artix底层 采用C++实现，不依赖于Java虚拟机，因此更具性能优势。Artix内核内存占用率低，更能充分利用操作系统资源，特别适合于大用户量、大并发量的企 业级应用。而ART的插件式结构也是用户能充分优化运行时环境，选用不同的插件集适用于不同的集成需求。 |
| 中和威 | InterESB | InterESB将多种通信模式融为一体，其中包括目标通信模式、点对点通信模式、发布/订 阅通信模式、扩展的发布/订阅集群模式。InterESB将上述多种通信方式有机封装成一个整体，并通过多种标准接口方式对外进行发布，从而使得基于 InterESB构建的企业应用能够以透明、一致、高效的方式应用不同的底层通信机制。与CORBA、J2EE技术实现良好结合。 |
实现SOA有两种途径，一种是在现有应用系统的基础上将需要复用的的模块进行SOA封装，另一种是将所有的应用系统按SOA重新设计和开发。前一种SOA之路是平滑的渐进之路，更容易被多数的企业用户所接受，毕竟，许多早期开发的应用系统正在承担着关键业务运行的重任，容不得半点闪失。而后一种SOA之路则是彻底地“动大手术”，肯定会在短期内带来巨大的阵痛，做好了可以脱胎换骨，做不好可能伤筋动骨。
站在SOA的岔路口，也许用户会感到有些为难。“目标是光明的，道路是曲折的，”这句话最能反映SOA实施策略的选择。信息化不是革命，而是促进业务发展(至少在大部分情况下笔者这样认为)，从这个角度而言，选择SOA的渐进之路是可以掌控的，但如果是一个新企业上全新的应用系统，那么不妨来个彻底的SOA。
ESB的兴起让SOA的渐进之路可以走得更开放和平稳，而ESB也代表了中间件产品本身的进化方向，中间件已经由广义的产品范畴向着细分的领域深入——应用服务器、ESB、BPM的分界逐渐清晰。尽管每个领域都在不断发展，但每个领域之间的关系变得更加透明、标准化。对于用户服务而言，分步实现SOA不是一句空话，因为在产品上已经有了可以实现的基础，用户可以根据自己的应用系统环境，由小到大、由局部到整体地去实施。那么，站在SOA的岔路口就不必心慌了。
案例一
北京移动
做为企业级的ESB，Artix 已成功地在北京移动部署并稳定运行了两年。由Artix组成的服务集群实现了40多个基于Web服务接口，通过Web 服务使不同的外部系统和核心运营支撑系统相连接，为北京移动的各种外围业务(CRM、门户、 IVR)等提供了7×24的接口服务。在开发过程中，Artix的Eclipse集成开发环境为开发和部署基于多种协议的路由应用提供极大的便利，所有开发和配置均通过Eclipse完成，实现跨平台的部署。由于Artix高性能、低资源消耗的优良特性，大大节省了硬件资源，为用户带来了巨大的投资回报。
案例二
AHL金融公司
Accredited Home Lenders(AHL)是一家美国的抵押银行公司，资产总额超过59亿美元，在全美范围内为家庭客户提供融资、证券、贷款等金融服务。
AHL当前正面临抵押代理人渠道的快速增长，因此需要改善其客户体验，同时改善其赢利能力，增加整体生产效率，保证数据的准确性，以便获得竞争优势。但当前AHL基于纸质的传统贷款流程过于繁重，且利润率偏低，增长缓慢，大量的业务管理问题需要解决。
BEA AquaLogic Service Bus(ALSB)作为一个能提供标准化中介的解决方案，完成了多系统间的协议连接、基于内容的路由、消息传递和服务的监控管理。同时可以支持多种消息类型，并完成服务和消息的安全控制。而所有这些功能在2003年AHL开始实时Web服务管理项目时，还都没有存在。新的基于ALSB的Web服务管理解决方案很好地解决了以上问题。
基于服务的对象增加了可重用性，降低了总体拥有成本。利用AquaLogic Data Services Platform和ALSB可以在运行时完成各种复杂的过滤功能，利用XQuery完成数据格式的转换，极大地提高了对Web服务的整体管理能力。