我们不该仅片面地看待ESB本身

    BEA公司中国区技术经理刘汩春说:“SOA的‘服务’不仅仅是可重用，而且必须是可组装编排;可快速注册发布; 质量可监控;生命周期可管理的。这样SOA才能在整个IT范围内实现服务治理和优化，从而直接推动业务的优化。” 

    倪晓兵介绍，金蝶中间件推出的Apusic ESB不仅包含了数据连通的功能，还涵盖了智能网络、服务仓库、业务重组和管理工具。 

    首先，分布式部署和集中控制是ESB的典型特征。ESB服务器在物理上可能相隔很远，但是通过集中管理，这些服务器组成了一个ESB网络，在逻辑上形成完整的企业服务总线。 

    在Apusic ESB的智能网络中，不要求网络中的各个服务器都必须明确地和其他所有的服务器建立连接关系，只要一个节点不是孤立节点，那么这个节点就可以和Apusic ESB网络中的任意非孤立节点通信。并且，在通信过程中的路径选择上，Apusic ESB 网络会根据网络连接状况的实际情况，作出智能调整，自动选择最优路径。 

    其次服务的注册、发布和编排也是SOA实现服务重用性的基础。在Apusic ESB的服务仓库中，任何符合标准的服务都可以在其中注册，从而被其他服务调用。而消费服务也无需知道被调用服务的具体特征，只需要发送相应地请求即可找到相应的服务，并进行绑定和数据的传输。 

    同时为了满足具体的业务需求，不同的服务需要被组装在一起形成新的应用系统。Apusic ESB引入了工作流流程的概念，引入自主实现且基于业界标准的，具有条件分支和合并并行流转功能的BPEL4WS流程引擎，从而实现综合的、复杂的业务逻辑编排。这个流程引擎支持子流程、条件脚本、路由节点等功能。通过灵活的流程定义，按照即时的业务需求，将单个离散服务有机的组合起来，达到服务重组的目的，完成集成的业务需求。 

    此外，Apusic ESB在引擎级别将BPEL规范的细节进行了包装，对用户来说，只需要关心流程中的一个服务即可，无须再去关心BPEL的具体技术细节。 

    最后，所有的调用、转换都必须有一个良好的管理工具来帮助实施，并进行监控。Apusic ESB则提供了一体化的管理工具，通过这些工具，您可以非常方便的对Apusic ESB进行集中式管理、可视化的流程设计，以及运行期的实时监控等功能。 

    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马上就可以用，针对复杂业务，我们提供一套方法论，金蝶的六步实施法，可以加速实施过程”。 

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!