关于ESB实施的几点建议.doc

关于ESB实施的几点建议 作者 马国耀 发布于 2011年3月2日 上午12时0分 前言 谈及企业服务总线（ESB），在有面向服务的架构（SOA）实施经验的开发者眼中一定不会陌生。这些年，人们一直在谈论它，以至有些人认为“实施SOA一定需要ESB”，或“只要将ESB架起来了，我们就SOA了”。这些说法有可取之处，也存在片面之嫌，由于业界对于ESB没有统一、标准的定义，所以一千个人眼中有一千个“ESB”也就成了情理中的事情了。然而，怎么才能将ESB用好？我们需要清楚地认识ESB在SOA中所扮演的角色，理解哪些工作是ESB的职责之内，哪些却不是。只有正确地认识了ESB的职能，并委以恰当的任务，才能将它用在刀刃上、发挥其巨大的能量。 本文是这样安排的： 第一部分，简单介绍ESB在SOA中所起的作用。 第二部分：介绍三种常见的ESB的误用。 第三部分，介绍三种推荐实施。 第四部分，对ESB产品发展方向的展望。 申明：文中的出现所有观点仅代表作者个人看法，不代表作者所供职公司的观点。 正确理解ESB在SOA中的作用 平心而论，ESB的确是SOA中一个非常重要的集成层组件（Integration Layer），不论是OpenGroup发布的SOA参考架构，还是几大主流SOA供应商（参考IBM通过参考架构实施SOA解决方案 ，Oracle与F5的SOA参考架构，Microsoft的BizTalk ESB Toolkit中对ESB的定义），都将ESB置于SOA架构的核心位置。 事实上，ESB在SOA中扮演着重要的角色，在技术层解决了SOA的整合问题，耦合了应用与应用之间的集成逻辑，使得SOA更灵活，更易于扩展，更敏捷。有了ESB，新建的服务消费者应用程序不需要关心服务的提供者在哪里，使用何种通讯协议，与其交互的数据是怎样的……，它只需向ESB发出请求，使用开放的、标准的通讯协议。相反，若某个可重用的价值较大的服务位于某一个遗留系统中，而由于种种原因，该遗留系统不能在短期内重写，此时ESB可以架起该服务与其使用者之间沟通的桥梁。当然，ESB的作用远不止这些，业内也有很多讨论，本文不再赘述。读者可在Google上有哪些信誉好的足球投注网站ESB Patterns获得相关资料。 然而，ESB并非“救世主”，它注定也不可能解决应用系统整合中出现的所有问题。道理很简单，计算机发展历史长从没有出现过一个产品/工具可以满足所有的应用需求，技术发展得很快，需求发展更快，所以技术永远跟不上需求。此外，ESB或ESB产品有其特定的适用范围，它是基础设施层的概念/产品，解决的是整合中的常见问题，比如服务连通、路由、消息丰富、服务的注册/查找/发布等服务的管理、服务监控和质量保证等。ESB不能解决的问题比其能解决的问题多很多。比如，让它去做人工流程的编排是不合适的，让它提供门户类产品那样的用户交互也是极其困难的……。 笔者支持过许多客户项目。在这些项目中，有的客户将ESB用的好，有的则勉强用上，用的功能很简单，有的则用ESB做一些原本不属于它该做的工作。在这里，笔者仅从个人的立场，分享自己这些年来积累的ESB实施经验。下面列出笔者常看到但不推荐的实施和笔者在实施ESB的过程中积累的一些较好的实践方式，供读者参考。同时欢迎批评指正。 不推荐实施 挟ESB以令外围应用 现象： ESB的架构师在ESB上设计一套标准的数据接口（通用的XML格式），规定使用统一的协议（如Web Service/HTTP）。所有的ESB服务消费者和接入ESB的服务必须符合该标准。其目的是为了简化ESB上的开发工作。这就是一种“挟天子以令诸侯”的做法，因为在实际情况中，可能领导规定了“所有的服务必须要经过ESB，即便是透传”。 分析： 国内的ESB实施者大多数是一些SI/ISV，出于成本/人力或其他个方面的原因，总会有一些架构师希望达成这样一个目标：我能否设计/实现一个一劳永逸的ESB中间平台，将来不论哪种服务都可以方便地接入到ESB上？ 这是一个很浪漫很理想的目标，但这个目标是不可能实现的。原因有二：其一，仲裁逻辑一般是非常具体的，具体的服务有具体的整合需求。譬如，一个服务提供者基于HTTP提供了一个Web服务WS1，而我们希望将这个服务通过ESB暴露给两个客户端ClientA，Client B；Client A使用XML/HTTP访问服务，而Client B却使用SOAP/JMS访问该服务，如图1所示。有过ESB实施经验的人都能看出里面的仲裁逻辑是非常具体的，我们要考虑的不仅仅是协议之间的差别，还需要考虑消息格式的差别。其二，如果有这样的设计/实现存在，ESB产商为何不把这个特性直接实现了呢？你也许会说产商不理解具体的业务，而具体的业务是复杂的，SI/ISV却了解这些复杂业务。而事实上，ESB解决的更多是