企业服务总线ESB之概述

为了解决业务复杂度和业务变化导致的软件危机，软件方法沿着结构化、面向对象、构件技术和面向服务一路变革，软件开发的正确性、可重用性逐步得到提高。尤其是符合SOA架构风格后，软件的业务敏捷能力得到了大幅提升，软件技术也越来越接近业务本质。

SOA是一种架构风格。它的核心思想是通过服务（业务单元）的提取和灵活组合，充分整合企业的资源，适应业务的快速变化，以提高企业竞争力。

SOA架构是面向服务的技术体系，任何技术体系都有它的优势和局限性，他们的出现都是为了解决特定的应用和业务问题，所以SOA技术也不是包治百病的灵丹妙药。为了说明SOA能解决什么问题，需要解释一下什么是“服务”。软件的发展历程自始至终贯穿着“复用性”这样一根主线，提高软件的复用性意味着更少的投资带来更大的回报，从“面向过程”到“面向对象”再到“面向服务”都是为了软件的“复用性”。在这个发展过程中，随着软件不断地复杂，系统工程逐渐占据了主导地位，从简单的桌面应用发展到动辄数百上千个应用组成的复杂应用生态，为降低系统复杂度就要求复用的粒度不断的变大。

“服务”是一种可以相对独立运行的，对外提供稳定接口协议的封闭系统。相对于对象来说，服务是大颗粒度的，不可修改的（对象可以通过派生的方式来重构，而服务则只能被引用）。服务就像我们使用的冰箱、电视，本身就可以独立的运作；而对象或组件则像是汽车中的方向盘和档把，只有装在汽车上才有用，拆下来就毫无用处。联系服务之间的协议是报文，联系组件之间协议就是接口（API），它们之间的耦合度较之服务之间要高很多，同时效率也要高很多。SOA就是通过对服务进行组合，从而实现更高粒度的“系统”。SOA并不关心“服务”或者说“原子服务”本身如何实现，你可以用组件和对象来构造你的原子服务，也可以用面向过程的方法来实现，甚至你可以用汇编和硬件来实现服务。所以SOA并不能取代传统的开发手段，正相反传统的开发手段为SOA提供了丰富的资源。

在传统的开发方式中，存量系统是巨大负担，当采用J2EE的时候，会为大量的C/C++的存量代码感到头疼。但SOA却认为存量系统是财富，因为SOA并不关心服务是怎么实现的，相反地存量系统是经过长期稳定运行的可信赖的系统。

SOA不能做什么？从上面对服务的描述看，似乎可以把服务认为是一个巨大的组件或对象，但遗憾的是SOA体系有一个无法用组件的方式解决的问题，那就是交易一致性的问题。就好像我要做一道菜，先将鱼收拾干净放好佐料，然后用微波炉清蒸却发现没有电，这个时候我不可能把鱼还原等待有电了再重新这个过程一样。服务组合过程中的失败是无法rollback的，所以SOA只能采用补救手段“冲正”来解决这个问题，通俗讲就是反交易。当然，这也带来了麻烦，为了保证交易一致性，所有的冲正都可能需要人工的干预。所以，当你享受SOA带来的便捷的时候。你同样要忍受他带来的麻烦，好在便捷带来的好处远大于麻烦所增加的成本。

目前SOA的相关技术的发展已经形成信息化技术发展的一股浪潮，基于SOA的应用集成，成为当前企业IT基础架构发展的趋势。 基于这个前提，一种面向SOA基于数据、应用整合和信息共享的的集成中间件——ESB（Enterprise Service Bus，企业服务总线）慢慢的浮出水面。ESB具有集成特性和面向服务特性为一体的基础架构，以一种可以高度分布式部署的部署模型，“统一消息”的数据模型，高度可扩展、包含开放端点的体系，实现一个对各种企业服务“来者不拒”的智能化的集成和管理的中介，实现被集成的各个企业应用之间的信息共享。在Gartner的报告中，ESB被誉为SOA的“心脏”。