ESB其实只是技术

　　SOA项目不应从ESB开始

　　ESB在SOA中的重要作用，使得各个SOA厂商纷纷推出自己的ESB产品，并在具体的SOA实施中，利用ESB来作为切入点，并简化SOA的复杂性。

　　但是这种对ESB的重视正在使SOA的实施进入迷途。因为ESB只是技术手段，而SOA的目标则是业务价值。对技术手段的过分重视往往使人们忽略了SOA的最终目标，陷入在技术的泥潭当中不能自拔。同时ESB的简化掩盖了SOA的复杂性，使大家对SOA的实施过分盲目乐观，忽略了除了技术以外其他很多更重要的因素。

　　针对这种错误倾向，IBM WebSphere SOA与J2EE顾问Bobby Woolf最近写了一篇文章《以ESB为中心的架构是实施SOA错误的途径》来质疑这种把ESB当作SOA的实现基础的做法。Bobby Woolf在文章中提到，很多客户在开始建设SOA时要求先为他们建立一个ESB，他们抛弃了SOA的理念而只对ESB感兴趣。“这些客户在ESB和SOA之间划了一个等号，或者更准确地说建设SOA就必须建设ESB。”毛新生指出了这种错误的根源所在。

　　因此以ESB来启动一个SOA项目是有害的，它将陷入技术的怪圈中，而无法产生最大的业务价值。毛新生认为业务才应该是SOA开始的起点和最终的目标。“你首先要在业务上进行服务的分解，然后才把他们映射到技术实现中。”毛新生说。

　　SOA项目的实施必须从业务需求的分析开始，而不是从构建ESB来开始。倪晓兵对这种观点也表示支持，“SOA框架体系下的软件开发，应该是从业务流程分析开始的，用一些组件化的业务建模方法，对实际的业务场景进行分析。在这个基础上建立业务用例，并根据这些业务用例构造业务流程模型。”

　　倪晓兵同时强调:“ESB不过工具和技术而已，关键上集成业务如何做?业务逻辑如何编制?如何实施?金蝶不仅提供产品,还能提供一套实施方法论。针对简单集成业务，提供标准知识集，也就是工具包，SI马上就可以用，针对复杂业务，我们提供一套方法论，金蝶的六步实施法，可以加速实施过程”。

　　引入ESB的最佳时机

　　我们既然不能从ESB来开始一个SOA项目，那么应该在项目的什么时候引进这个重要的工具呢?Accenture首席技术官Don Rippert认为激活SOA的全部潜力需要通过四个阶段，依次是使用XML，以更标准的方式使用应用程序接口;捕获一些业务过程，并将它们转化成为Web服务;引入并全面使用企业服务总线;产生业务过程执行语言(BusinessProcess Execution Language，BPEL)，它可由业务过程建模工具完成。

　　在这四个阶段，ESB的采用则位于第三阶段中。同时他认为当前大多数的企业还只是处于第一个阶段，因此ESB实际上对于他们来说并不是迫切需要的。

　　Burton Group的分析师Anne Thomas Manes的观点与Rippert相似，他认为要采用ESB，必须首先实现启动SOA的基本组件，这些组件是一个或多个服务平台(如.NET，Java EE应用服务器等)，SOA管理解决方案，注册表，另外如果服务要被暴露在防火墙之外，那么需要XML网关。

　　她说:“如果缺少我推荐启动SOA的‘基本组件’，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。”并且她认为ESB应该在后期购买。

　　毛新生认为，做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。

　　需要注意的是，这并不是否认ESB的价值。ESB是好的，单纯的ESB项目是坏的。让架构围绕服务，而非总线。