作者：Jason Bloomberg　

如何把必要的企业服务总线（ESB）转化为面向服务的架构（SOA）一直存在着争论。Bobby在他的文章中也说道，仅仅建造一个总线的工程是不可取的。离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总线，同时也将变得毫无价值。 　　关于如何把必要的企业服务总线(ESB)转化为面向服务的架构(SOA)一直存在着争论。强调ESB对于SOA重要性的人有着自己的关注点，而质疑ESB作为SOA基础的观点也有着更深层次的考虑，同时是对前一种观点走向极端的一种有益的矫正。

　　ESB简化SOA应用

　　异构和变化是信息化系统建设永远要面对的两个难题，而SOA正是这两个难题迄今为止最好的解决方案。SOA最重要的理念就是“服务”，通过在服务之间灵活地实现组装，从而能快速地生成新的应用，如此以来，SOA帮助IT系统及时地应对业务的变化。另一方面，SOA的本质是开放，它面向整个internet网络的，连接各种使用不同协议的通信网络和各种不同架构的应用，因此必然要求解决不同环境的异构问题。

　　使用SOA架构来搭建IT系统是一个复杂的过程，而ESB的使用则简化了这一过程。业内对ESB的定义是:它是由中间件技术实现并支持SOA的一组基础架构，它支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。

　　消息的路由和数据的传递是ESB解决的两个关键问题，通过这些，ESB帮助SOA实现了服务之间的灵活组装，有效地应对了业务的变化。

　　而在服务组装的过程中，不得不应对不同环境下服务的异构问题。不同的服务，它所采用的技术、消息结构的格式，还有一些语义上的不匹配，都需要借助ESB的方式在它们中间做一个适配。ESB屏蔽了底层不同环境之间转换的复杂性，使得服务的技术和位置变得透明，这样技术人员可以把更多的精力放到业务的考虑上，而把这些底层的不适配问题交由ESB来解决。

　　ESB的采用帮助SOA轻松地应对了它所面对的两个难题，通过把这种复杂性转移到ESB上，大大简化了SOA的实施。“ESB的意义在于让SOA有了一个可实现的基础设施。”IONA公司大中国区高级架构师陆飞舟这样认为。

　　ESB不等于SOA

　　ESB在SOA中的重要作用已经得到了人们的共同认可，Forrester Research公司发表的一份报告指出，持续采用SOA能很好的体现ESB的思想，并且把ESB称为“SOA的主要切入点”。 SOA厂商更是纷纷推出自己的ESB产品，并不断地向用户宣扬ESB可以帮助他们简化SOA的难题，降低SOA实施的成本。

　　但是，人们对ESB的追捧正在使SOA的实施走向“迷途”。利用ESB来辅助SOA实施变成了以ESB为中心来构建SOA应用，手段变成了目的，技术篡夺业务成为了SOA的重心，这严重地背叛了SOA的本原特性。

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

　　ESB不等于SOA，它更不能替代SOA。以ESB来启动SOA应用，然后以ESB为中心来构建SOA系统是不可取的。

　　Burton Group的分析师Anne Thomas Manes说道:“ESB绝对不是组织启动SOA的起点，ESB提供的能力你一开始并不需要。因此，ESB应该在后期购买”。

　　Accenture首席技术官Don Rippert认为激活SOA的全部潜力需要通过四个阶段，而ESB则处于第三个阶段。而当前大多数的企业还只是处于第一个阶段，因此ESB实际上对于他们来说并不是迫切需要的。

　　Bobby在他的文章中也说道，仅仅建造一个总线的工程是不可取的。IT部门认为只要建造了一个总线，人们就会围绕着总线来构造SOA的应用了。但是问题在于，当人们开始构造SOA应用时，他们会发现那些已经建造好的ESB已经不能满足当前的需求了。

　　针对这种错误的倾向，他警告道“只有当你实际需要一样东西，才去实现它，决不要仅仅因为你预见到未来的需要。”这种哲学遵循的思想是“够用就好”，或者说只有需求出现时才去满足它，而不是预测将来会出现什么样的需求，然后预先就去实现它，因为这样做将造成巨大的浪费，甚至给将来设置阻碍。

　　“ESB就是道路，试想城市规划时是不是先把所有的道路都修好，然后再去修建筑呢?”毛新生这样形象地做了一个比喻。

　　正确认识SOA的真谛

　　以ESB为中心来构建SOA系统，这种错误的根源就是完全从技术角度考虑，而忘记了SOA的核心是业务价值，而ESB只是一个技术问题。

　　“Bobby Woolf的这篇文章就是批判唯技术而技术的错误路线，这是一个不太好的建设企业IT的倾向。”毛新生这样解释Bobby那篇文章的真正目的。

　　离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总线，同时也将变得毫无价值。Bobby做了一个比喻:路是没有任何价值的，除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA，ESB就像一个没人使用的道路。

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

　　在认识到SOA的业务本性后，我们将重新回归ESB在SOA实施过程中的正确位置，而不是一切以ESB为中心。当然这种矫正并不是否认ESB的价值。ESB是好的，单纯的ESB项目是坏的。让架构围绕服务，而非总线。

　　编者按:作为一项颠覆性的变革技术，SOA项目的实施耗资巨大，如何降低实施成本就成为企业最关心的话题。

　　作为一家专注于SOA的咨询公司，Zapthink于9月份推出了一份《Justifying&Funding your soa project》的白皮书，详细地回答了SOA实施过程中的成本控制问题。本栏目将分三期推出这份白皮书的翻译稿，以期对SOA在中国的推广提供一些有益的借鉴。

　　合理实施SOA项目，降低成本

　　许多企业都很抵制创建SOA架构的商业案例——不是因为SOA不能为企业提供巨大的利益，而是因为它们不能合适的来定义商业问题，否则SOA将会很好的发挥出其优势的。

　　在实施SOA时，很多架构师问的第一个问题是:“我知道SOA是未来的发展趋势，但是我如何把它推销给我的商业客户呢?”而这个问题本身就是错误的。因此，架构师在试图说服商业客户时，总是困难重重。而正确的问题应该如下所述:“这是个纯粹的业务问题，我应该从业务角度来考虑，而不是继续从技术角度。”

　　对架构师来说，有两个至关重要的方面需要学习。首先，为了找到解决的方法，你必须首先提出商业的问题。如果你提出的问题未能抓住他们的“痛楚”，或者你并不明白关键点是什么，那么他们将不会为此投资。其次，IT部门的解决方式倾向于根据特定的问题来解决商业的问题。正如一句谚语所说的，如果所有的问题是钉子，那么需要一把铁锤就够了。但是，在商业的这个世界里，有许多种不同的问题引起商业的“痛楚”，为此，对架构师来说，在他们的工具箱里应该有多种工具。

　　SOA给公司带来的最直接的利益就是降低集成费用，而公司最看重的也正是这一点。SOA所创造的价值是否能够弥补它的实施成本，这是推动SOA实施的关键的第一步。一旦你成功的证明了这一点，SOA的继续实施和以此赚取利润就会变得更加容易。

　　利用Web Service

　　虽然对于SOA的实施来说，Web Service既非必要也不充分。但是利用Web Service的开放标准有助于降低集成的成本，而这将大大推动SOA的发展。按照那些标准来构建Web Service是很重要的，这既能快速地获取回报，又能为SOA打下良好的基础。否则，构建的Web Service往往是不兼容的，甚至是无用的。

　　Web Service可以实现对多种平台的兼容性，它提供了一组描述和传输信息的标准协议。Web Service允许用户有权使用多重内部系统上的信息，这样能够满足企业实现内部集成的需要。Web Service通过从私有的、点对点的连接转向基于标准的连接，这种集成能够减轻数据交流的压力，并且这种标准连接还具有平衡转换的能力。

　　对还没有考虑使用SOA的企业来说，Web Service最重要的商业应用那就是提高集成。此时，一些企业希望通过合理的计划，可观、易得的解决方式来降低集成费用。但是，商业的真正价值是来源于 Web Service所具有的长期的潜力。随着多种构成Web Service模式的依次出现，企业学会了如何利用SOA的优势。通过简单集成，Web Service技术将会为企业继续节省费用。

　　降低昂贵中间件的依赖性

　　多年前，面对高昂的IT系统建设和不断追加的成本，就有人倡导，企业必须继续缩减 IT的费用和降低总的花费。现在企业IT建设的目标依然是:这种花费必须一年比一年降低。这对企业来说是一个挑战，它们不但必须维持现有的IT系统，而且要实施新的技术和方法，比如SOA的出现。但是，如果企业所做的能够一年比一年降低花费，那么他们如何才能继续创新?幸运的是，SOA提出了看似矛盾但又有趣的论点:虽然架构SOA需要花费，但是它却使其它IT花费降低到一个很大的程度。

　　在企业里，集成全异的系统可能花费整个工程预算的大部分。点对点的集成，实际上是将两个系统硬性的配置在一起。在一个多重系统里，这会带来企业额外总花费。因此，整体集成的典型架构是依靠总线或轴辐式拓扑的方式，每个系统插进一个公用的下部基础构造中，并由总线为每个系统之间的交流进行必要的信息处理。

　　但是上述集成方法，需要长时间的执行，并且不能灵便的传递。除此之外，这种方式的实施费用远远超过了软件本身的费用，因为它们是私有、复杂的，即使创建一个下部构造，但是这样也未能灵活地、适应地传递信息。很显然，企业迫切地需要一个更灵便、有效且费用低的集成方案。

　　SOA的出现使得降低或消除紧密连接的中间件成为可能，或者说，至少在中间件上的依赖和它的相关的维护费用方面是一种降低。我们看到，大多数公司每年架构的花费明显的少于在解决笨拙中间件方面的费用。随着企业解决集成架构的能力不断提高，在使用私有的、大容量的、不灵巧的中间件方面将会变得越来越少。

　　对中间件，企业也不可能完全抛弃。但是SOA能够提炼出中间件的性能，使得企业使用一种“非入侵”的方式，将老的中间件和新的下部构造合并成为可能。

　　从现有系统中榨取更多

　　虽然企业通过降低中间件的费用能够获得利润，但是在IT环境中，比较老的系统和应用程序仍然提供基本的商业价值，它们称为遗留系统。对多数企业来说，遗留系统自我矛盾的地方是:这些系统太老了，而不能确定是否能够改进，但是它们又太重要了而不能去除。因此，企业感到它们必须继续维持遗留系统的投资，尽管它们的回报可能随着时间在降低。

　　实际上，这种遗留系统并不是引起惊慌的原因，更重要的是这些系统上存在着巨大的商业价值——重要的数据和业务流程。如果此系统对于企业来说是不可或缺的，此时企业就必须考虑如何在新的架构下保留这些应用系统。当然了，这些问题在每个企业当中都存在，否则IT人员就不会面对技术进步苦恼不已。

　　去除遗留系统是一个高危险且成本巨大的工作。事实上，简单的维护已有的遗留系统，比起用新的应用系统替代它们，其危险性是比较低的。企业更愿意花钱来扩展它们的遗留系统，将这些遗留系统整合进SOA架构中，同时确保他们的可靠性。

　　在很多情况下，遗留系统引起重大的问题影响业务的执行，因为这些应用软件不再满足已经变化的业务需求，或者是太复杂而不易改变。一些企业也发现，某些遗留系统现有的功能，必须有新的系统来代替实现。在这种情况下，企业更愿意去探索一种能够使遗留系统移植并且“退役”的策略。

　　另一种情况是，企业保持遗留系统的应用程序，从它们身上榨取尽可能多的价值，这需要SOA 的帮助，它可以从很多方面来提炼价值。SOA的可适性能简化遗留系统移植、重用、重生等过程。关于基于SOA的遗留系统的移植、重用、重生之间的关系如图1所示。

　　一个遗留系统完全是多余的，这种情况一般很少见;在它即将“退役”的时间里，它仍然能够提供一些有价值的服务。在这种情况下，用一种无缝结合的方式将其由性能消耗转到替代系统变得尤为重要。但是，大多企业认为它们实际上不需要替换遗留系统，它们关心的是遗留系统的可用性，或者说，这些原有的系统是否能够满足新的业务需求。

　　事实上，在很多情况下，这种完全替代现有系统的方法是不合实际的，也是不可能完成的。因此通过改进，在现有系统上榨取更多的价值可能是一个更好的方法，并且也可以避免承担系统改变的高风险性。