一步步了解ESB （一）你是否真正理解ESB？

        谈及企业服务总线（ESB），在有面向服务的架构（SOA）实施经验的开发者眼中一定不会陌生。这些年，人们一直在谈论它，以至有些人认为“实施SOA一定需要ESB”，或“只要将ESB架起来了，我们就SOA了”。这些说法有可取之处，也存在片面之嫌，由于业界对于ESB没有统一、标准的定义，所以一千个人眼中有一千个“ESB”也就成了情理中的事情了。然而，怎么才能将ESB用好？我们需要清楚地认识ESB在SOA中所扮演的角色，理解哪些工作是ESB的职责之内?哪些却不是?

         只有正确地认识了ESB的职能，并委以恰当的任务，才能将它用在刀刃上、发挥其巨大的能量。

          从下面可以看出ESB在各个系统服务之间发挥的作用，看看你是否理解正确了。

 

            从上图可以看出，ESB是为各个系统的服务又管理各个系统的服务，它可以利用现有的服务组合新的系统，图上它把OA、CRM、ERP整合等，那么它是不是就是一个万能的中间平台，任何服务都可以接入到上面？

            这是一个很理想的目标，但这个目标是不可能实现的。

            原因有两点：其一，仲裁逻辑一般是非常具体的，具体的服务有具体的整合需求。我的理解是它们在某些更详细的小的方面也有很多不同，需要把所有的不同大的差异还是小的差异都屏蔽掉，是不容易做到的。我们要考虑的不仅仅是协议之间的差别，还需要考虑消息格式的差别。其二，如果有这样的设计/实现存在，ESB产商为何不把这个特性直接实现了呢？你也许会说产商不理解具体的业务，而具体的业务是复杂的，SI/ISV却了解这些复杂业务。而事实上，ESB解决的更多是技术层面的工作，业务层面的工作大多数不属于ESB的范畴，复杂的业务逻辑不是在业务系统中实现，就是在其它SOA组件中实现，如JBPM

 

          ESB vs JBPM

         通常我们这么一想，ESB可以各个服务都组合在一起了，如果服务粒度小可以重新组合业务那么不就是变成了JBPM了吗？

         二者有着本质的区别。

          其一：ESB是一个偏向技术层整合的组件，比如将“客户资料查询”服务与“日志”服务组装起来，得到的结果还是“客户资料查询”服务，只是在仲裁流中间插入了一个新的附加功能，即“日志”服务。BPM中的服务编排的含义很侧重于业务流转的概念。比如“项目立项审批流程”，该流程的实现可能需要来自几个相关系统中的服务的参与，它们可能是“立项申请”，接着是“一级职能经历审批”，然后是“部门经理审批”，“财务审批”等。这些服务流转起来形成的是一个完整的业务流程。

          其二：ESB上的服务组合是无状态的，ESB运行时会为每个请求建立一个实例来执行其仲裁逻辑，请求与请求之间没有时序关系，是互不相干的、各自独立的。相反，BPM上的服务编排这不一样，未完成的业务流程实例一直会存活在BPM运行时中，存活期可能为一天、一周、甚至1个月或更长；请求与请求之间可能存在着一定的关联性，比如对与一个项目（相同的项目ID）的立项审批流程，一级职能经理、部门经理和财务对流程发出的请求都是针对同一运行时实例的。

 

           利用ESB在两个系统之间传送大数据，如视频、大文档等，是否可以呢？

           虽然它可以实现这一功能，但这并非最佳实践。

           ESB作为企业级的服务联通、管理平台，需要穿透ESB的服务应该是企业内重用可能最大、价值最大的那些服务，应用程序对这类服务的访问应该非常频繁，因此同一时刻需要ESB支撑的业务可能非常繁重。所以，ESB产品的设计初衷是实现一个无状态、高吞吐的服务总线，为企业内重要的业务服务提供透明、标准、开放的接入能力。

 

           小结

           在SOA中ESB扮演者重要角色毋庸置疑，可以说是中心地位让SOA发挥了最大的价值，不过网络越来越发达正在向着云计算法相发展，ESB要想逐渐广泛也需要和云服务整合在一起，将会有更大的应用和发展空间。