面向ESB的体系结构：一种错误的采用SOA的方式

　　导读：仅仅构建ESB没有实际意义，因为在这种情况下IT构建ESB，然后希望某个SOA将出现并使用这个ESB。这种面向ESB的体系结构缺少SOA的好处。它并不能带来业务价值。

　　引言

　　我们会经常遇到越来越多的客户要求完成根本不使用SOA的项目，而仅仅在其中实现企业服务总线(EnterpriseServiceBus，ESB)体系结构。此类面向ESB的体系结构并不困难，但是其成功与否却难下定论。要求进行此类项目的客户并不了解这一点：面向ESB的体系结构并不带来业务价值。基于面向ESB的体系结构的项目需要成为基于SOA的项目，才能帮助确保成功地提供业务价值。

　　仅使用ESB体系结构

　　SOA基于业务需求。SOA可保持IT与业务的一致性，使IT系统按照业务系统的方式工作，帮助确保IT产生业务价值。有关更多细节，请参见IBM白皮书“IBMSOAFoundation:Anarchitecturalintroductionandoverview”

　　SOA的主要目标是在业务领域与IT领域之间保持一致，从而同时提高二者的效率。

　　使用IBM产品和服务构建IT系统的IT部门可能对其业务需求了解并不够。对于习惯于精确计划系统将如何工作的工程师，业务工作的方式可能会让人觉得没有计划，是随机的。说明内容看起来不一致，不可行，业务用户的需求似乎不现实，而且总在变。业务需求成了“都市神话”，似乎存在于组织中，但仔细分析却又找不到。

　　从这个角度而言，将IT与业务保持一致是不现实的。业务部门似乎不知道自己需要什么。其流程对自动化构成了挑战。实现流程自动化的工作没有效果，而且站不住脚。

　　工程师所了解的是技术。技术并不需要想像的需求列表，仅仅需要代码而已。代码不会抱怨不好用，编译器也不会每天改变自己的需求。代码要么运行，要么不运行。如果今天代码在运行，那么明天它也会运行。

　　技术对于工程师来说更容易掌握，也让他们觉得比较满意。这也碰巧成为了大多数企业软件公司销售的主要内容。ESB是技术，用于连接到其他技术。

　　SOA非常复杂，而与此不同，ESB理解起来较为容易。ESB并不需要任何这样的业务需求，仅仅需要技术需求。ESB非常精确，以各项标准为基础：数据格式、连接协议、XML、IP、HTTP、SOAP、JMS、JAX-RPC、JAX-WS等等。SOA可能会永远都处在分析停滞状态，而构建ESB可以实际完成一些看得见的工作。

　　这经常被称为连接一切的项目。客户有很多部分——应用程序、计算机系统、数据中心、部门、子公司、外派机构、合作伙伴和客户——这些部分彼此并不通信。各个部分对其他部分所进行的工作毫不知情。一个部分拥有另一个部分需要的数据，因此这两个部分需要协同工作。只有所有的部分连接到一起，才能够都正常工作。与尝试了解业务需求的无效果相比，连接一切是一个能够解决的问题，因为其解决方案是技术。如果将IT部门比作锤子，则ESB就是SOA的钉子。

　　他们的想法经常是，“我们不知道还需要别的什么，因此目前我们将仅仅构建ESB。”但这与“您开始编写代码，我们将了解他们需要什么”方法有什么实际的区别么?

　　ESB“梦话之地”介绍

　　读者经常通过单个属于来对连接一切的想法进行总结：企业服务总线(ESB)。那么，他们在说需要ESB的时候到底是希望什么呢?他们的ESB指的是什么呢?是否真的有必要将其称为ESB?

　　客户经常喜欢将ESB中的第一个词替换掉。他们不使用企业，而使用其它的组织单位，如公司、部门或政府。有时候还会使用其用途进行描述，如采购或工资单。或者描述其将传递的内容，如产品或订单。即使客户所需的是公司产品采购服务总线，也不要被服务总线之前的词语所迷惑。这些客户需要的是ESB。他们有时候甚至会这样描述需求“一个ESB，但……”。

　　客户的重点实际上在最后一部分：总线。在包括总线的技术拓扑中，所有对象都连接到总线，因此，也使用总线连接到所有其他对象。总线是各个部分间通信的主干道。应用程序间的通信(甚至网络上计算机之间的通信)通常都使用消息(即一系列不同的信息数据包)完成。EnterpriseIntegrationPatterns一书对此进行了很好的概述，其中将此类连接称为消息总线。

　　客户机经常不会太多考虑ESB的服务部分。xSB(x可以为企业或别的什么)用于调用服务，否则就只是消息总线。服务调用指一个应用程序告知另一个应用程序进行什么工作，而后者将完成此工作，而且通常会发送回响应，以报告结果。

　　因此，如果客户希望构建的是xSB，那服务是什么?IT人员可能会说，“服务可以是所需要的任何形式的东西”。这是最明确地指出，该项目实际上仍然是一个技术性的解决方案。暗示服务不相关，就是在说使用总线的应用程序不相关，应用程序如何使用总线不相关，而且应用程序集成需求(算不上业务需求)不相关。xSB将用于任何目的。针对SOA进行了体系结构设计的ESB最初可能会忽略很多这样的服务需求，因为服务会在充实SOA的过程中变得明显起来。但没有SOA的ESB没有服务，因此只是总线而已。

　　只构建总线的项目可以视为IT梦话之地项目。就像KevinCostner在“梦话之地”(FieldofDreams)这部棒球运动电影中的角色一样，IT部门所持有的态度是，“如果您建了，他们就会来。”如果构建了总线，人们就会围绕总线构建SOA应用程序。“梦话之地”的问题在于，与好莱坞的世界不一样，在业务世界中并不能保证服务将会出现。如果人们构建SOA应用程序，可能不会像您所构建的应用程序那样，因此可能必须进行大量的重新构建工作后才能使用。即使最后投入了使用而且效果非常好，得到回报的延迟也非常大，而这可能会让IT部门在等待“电影”最后的美满结局的过程中感到十分难熬。

　　了解面向ESB的体系结构的局限性

　　ESB有什么问题呢?还记得在电影的中间Annie想和Ray离婚的部分吗?(就是整个第二幕的内容，此时每个人都认为Ray是个傻瓜。)您的项目也将经过这样一个时间段，项目赞助人可能并不希望他的员工离自己而去!

　　问题是：ESB本身不产生任何业务价值。ESB是实现目的的手段，而不是目的本身。ESB就像SOA的电线或水管。水管并不产生价值，带有能放出水的水龙头的水池能带来价值。电线不会产生价值;但电灯(特别是连接到开关的电灯)具有价值。除非一条路能够让您从一个位置达到另一个位置，否则这条路就没有价值。没有SOA的ESB就像一条起点和终点没有意义的路。人们可能会最终希望去这些地方，但此前这条路所带来的全是成本，没有好处。

　　面向ESB的体系结构有个固有的缺点，即它所构建的是没有人要使用的连接。除非系统彼此连接并协同工作，否则业务并不会带来任何其他价值。在此之前，ESB只是没有好处的开销而已。IT部门可能会因为搭建了某些实际的东西而感觉不错，但业务部门决不会有任何好的感觉，业务部门依然无法完成那些在没有ESB时候就无法完成的工作。ESB成了IT部门可有可无的东西，也成了已部署的应用程序拓扑中的累赘。

　　不要遵循IT“梦话之地”方法所奉行的“如果您建了，他们就会来”，极限编程(ExtremeProgramming，XP)中的一句话可能更为恰当：“您将不需要它。”这句话代表了一个非常实用的原则：

　　在真正需要的时候实现所需的内容，而不要在预计会使用时进行实现。

　　这个原则(直到需要时才构建)与IT“梦话之地”方法奉行的原则相反。不要因为希望有人将会使用而进行相关的构建工作，而是要在知道有人真正需要时才进行构建。这样就可以确保能构建他们真正所想要的东西，而不是您认为他们可能会最终需要的东西。这样只有在您真正想获得这个构建带来的好处时才进行构建，直到这个时候您才需要付出相应的成本。此原则是一个很好的业务哲学，也适用于IT部门和业务的其他部分。

　　使用SOA

　　现在来回顾一下前面的内容，下面列出了一些任何软件开发过程都适用的原则：

　　·直到需要时才构建。

　　·构建可带来业务价值的东西。

　　·使IT与业务保持一致。

　　不要采用面向ESB的体系结构，而要采用SOA，将ESB作为SOA的一部分构建。也就是说，按照IBMSOAFoundation:Anarchitecturalintroductionandoverview所述的关于进行SOA开发，创建和集成采用SOAFoundation体系结构的应用程序。

　　通过此方法，可以将ESB作为SOA的一部分进行开发。您将根据业务需求发现服务。每个服务不仅需要提供者和使用者，还需要ESB中的通道来连接这两者。该通道就像提供者一样实现服务接口(但实际充当代理)，包括支持服务的远程调用(如进程内通信)的服务请求和响应的消息格式。使用者和提供者的服务接口、消息格式、范围和服务质量的区别可以通过中介予以解决和消除。所有这些都是ESB设计的核心，而且在不知道ESB调用的服务的情况下根本不能进行其中的任何工作。了解这些服务，还需要了解SOA中将使用ESB的服务。

　　从这点而言，连接应用程序是较为容易完成的部分。将其业务功能连接起来将是更大的挑战。这不能通过仅构建ESB来实现。

　　结束语

　　客户经常仅仅构建ESB，因为这涉及到没有杂乱的业务需求的技术挑战。仅仅构建ESB没有实际意义，因为在这种情况下IT构建ESB，然后希望某个SOA将出现并使用这个ESB。这种面向ESB的体系结构缺少SOA的好处。它并不能带来业务价值。事实上，它会在没有直接好处的情况下产生成本。而且这样并没有保持IT与业务的一致性。面向ESB的体系结构的更好的替代品是SOA。不要仅仅构建ESB，而要将其作为SOA(最好符合IBM建议的SOAFoudation体系结构)的一部分构建。