抢夺ESB制高点

从横向来看，企业内不同的应用系统需要互通与协同。从纵向来看，企业内不同时期引入的应用系统也需要互通与协同。因此，EAI(Enterprise Application Integration，企业应用集成）就成为永不退烧的热点话题。

不过，IT市场总是需要新的概念来推动。用户都使用EAI，怎么能够体现出市场和技术的进步呢？于是，随着时间的推移，企业不仅可以看到EAI，也看到了SOA(Service Oriented Archetecture，面向服务架构)，最近更是被ESB(Enterprise Service Bus，企业服务总线)所吸引。

面对技术进步的狂潮，企业用户究竟应该采取什么立场，才能够稳稳地占据市场的制高点？

概念争执 模糊市场界定

ESB市场的所有玩家都一致认为，这是一种EAI的新技术，可以帮助企业快速简便地实现SOA。然而，对于如何定义ESB，这些厂商存在非常大的歧见。

有的厂商认为，ESB是一种可以明确定义的产品，而另外有些厂商则认为ESB只是一种概念，只能融合在产品之中，却无法独立构成一种产品。在这些不同的阵营中，既有IBM、微软、BEA等大家熟悉的软件厂商，也有Sonic、Cape Clear这样的新创公司，还有Tipico、webMethods这类已经在专业EAI领域站稳脚跟的厂商。

概念真的那么重要吗？当然！只有对市场作出清晰的界定，才能有效地引导和推动需求。

有分析家指出，目前对ESB的定义有很多种，这就给厂商的市场运作带来不便。如果用户都不认为ESB是一种产品，又如何销售和购买呢？

基本上，ESB可以提供一种低成本的应用集成方案，它以Web服务标准为基础，为SOA提供了一种不错的实现方法。SOA则被认为是一种松耦合、易改变、以Web服务等标准为基础的IT架构。

事实上，已经有一些用户应用了ESB产品，把传统遗留系统与数据库集成进入了SOA架构之中。这些用户以自身的经验告诉人们，采用ESB产品的确使得应用集成更加容易了，ESB产品在不同应用之间实现了顺畅的沟通，并且通过部件重用降低了系统复杂度和成本，提高了系统可靠性。

透视ESB战场的硝烟

依据对ESB定义的不同，基本上可以把相关的厂商分为三类。

第一类厂商把ESB产品视为EAI和SOA的必由之路，他们基本上都属于新创公司;

第二类厂商把ESB视为SOA的锦上添花，他们大多数都在EAI领域站稳了脚跟;

第三类厂商则不认为ESB可以构成独立的产品，这类厂商基本上都拥有非常丰富完善的软件产品线。

可见，对于ESB采取什么态度，其实都是各厂商根据自身的市场地位和发展阶段而作出的姿态。

Sonic Software被认为是ESB概念的创造者，Cape Clear也是积极倡导这个概念的先锋，他们都推出了具体的ESB产品。BEA也加入了这个阵营，支持ESB作为一种产品而存在，并且推出了自己的产品，代号为Quicksilver。

Sonic公司副总裁兼CTO Dave Chappell指出:“作为一种产品，ESB可以简化应用集成工作，并且为SOA中业务部件的重复使用增加了灵活性。”

Cape Clear公司CEO Annrai O’Toole则透露，“目前市场对于ESB产品的需求十分旺盛，我们的业绩在今年内将会成长一倍。显然，ESB是新一代的中间件平台。”

这些以ESB为核心产品的新创公司对ESB进行了明确的定义―为SOA之中服务模块之间的通信、仲裁和控制提供平台，从而为业务部件的灵活应用提供方便。他们认为，ESB的概念是清晰的，因而市场也是清晰可见的。这些厂商也强烈指出，那些老牌中间件厂商利用ESB来混淆视听，试图为自己老旧的产品加上ESB的光环。

爱尔兰著名的软件公司IONA也推出了自己的ESB产品Artix ESB，并且于不久前推出了开放源代码的版本Celtix。他们认为，ESB采用了基于Web服务系统集成技术，而且支持Java Message Service和EDI通信等其他技术，可以替代较昂贵的传统EAI方法。从技术实现上来看，IONA更注重新老技术的融合。他们把ESB看作是对传统EAI的增强，而不是一个必需品。

BEA很快就加入了ESB产品的行列，并且指出ESB是SOA架构的核心，为服务部件之间的动态仲裁提供了整合层。BEA的ESB产品在Web服务的使用者和提供者之间建立联系，提供路由、传递和交互管理功能。与传统EAI方法相比，软件开发的编成量大大减少。BEA同样认为，ESB并不是SOA的必需品，但是可以让SOA的实现更加容易。

以webMethods和IBM 为代表的传统厂商则认为ESB只是一种中间件技术,单是不存在独立的ESB产品。

IBM认为，ESB只是一个概念术语，有些厂商声称可以销售ESB产品，并把它与Web服务划上等号，这是对“总线”的狭义理解。只要睁开眼睛看看，就会发现，有无数的应用系统根本与Web服务沾不上边。企业不可能将传统大型主机上面的应用置之不顾。因此，IBM将会把ESB当作是一种新的功能吸收到WebSphere MQ软件之中。

WebMethods明确指出，ESB仅仅是一种能力，一种功能，根本不应该作为独立的产品而存在。这家公司宣称已经把ESB融入自己产品ESP（Enterprise Services Platform，企业服务平台）之中，其中包括通信、数据转换和路由、服务水平监控等一系列技术。

显然，在合作伙伴企业之间实现应用集成的时候，仅有ESB是不够的。ESB显然不能支持传统的EDI集成方法。

来自微软的挑战

提起基础架构软件的竞争，如果忽略了微软，就难免有“一叶障目”之嫌。在ESB方面，微软的Indigo正在紧锣密鼓。不久前通过Weblog有一场论战，给人不少启发。

事情的起因是这样的―

Sonic公司副总裁兼CTO Dave Chappel刚刚出版了一本关于ESB的书,而微软公司的一位软件经理Richard Turner认为,书中以Java为基础来介绍ESB,而Java是一种封闭、专有的技术,将会把用户锁定在特定的一家厂商之上。Richard Turner同时指出，微软的ESB产品Indigo才是一个开放的系统。他说:“在微软的世界里，Microsoft BizTalk Server 2004与.NET框架几乎可以提供ESB所需的全部特性，而且提供了与客户系统进行组合的能力。”Richard更加充满激情地说，“如今，通过Web服务的合作机构，微软与许多合作伙伴、甚至竞争者一起联合起来，共同推广这种技术，整个IT产业终于有可能形成真正可互操作、开放、兼容的线级协议，建立安全、可靠的分布式系统。在IT历史上，我们第一次看到所有的主要厂商坐在一起，共同支持一个线级协议。”

然而，Richard Turner的文章一经发表，立刻引起了广泛的争议。

Java真的是只属于一家厂商的封闭技术吗？

如今大多数的ESB产品都是以Java为基础吗？

微软的ESB产品真是那么开放吗？

……

人们纷纷提出各种各样的质疑。

在众多讨论中，Burton Group分析师Anne Thomas Manes的意见受到广泛的赞同。她首先举例指出，IONA的ESB产品Artix的基础就十分广泛，包括C++、Java、COBOL、PL/I和.NET。所以，并非所有的ESB产品都是绑定在Java之上。

引发争论的Dave Chappell首先表示，不要渲染Java和.NET的对立。他指出，ESB当然不会把自己绑死在一种技术上，这与其核心理念完全背道而驰。

ESB以一种哲学为基础，这就是SOA应该是通过配置来建立，而不是通过编程建立。而且，ESB必须有能力在不同的协议之间建立互通机制。

事实上，这是一个多样化并存的世界，也是优胜劣汰、适者生存的世界。挑战与争斗并不奇怪，只是我们都不得不认清形势，找准自己的立场。

用户将何去何从？

不难看出，在ESB的战团中，每个厂商都在根据自己的现状和目标来表明自己的观点。

新创的ESB厂商希望以这个新的概念为起点，最终把所有的EAI问题都纳入这个体系之中，而传统的软件厂商则希望把ESB这个新概念纳入自己原有的产品和技术架构之中，利用这个新概念来推广自己的传统产品。

用户自然也希望能够利用ESB为自己部署更为合适的IT平台。

在这个世界上，绝对的公正、中立是不存的，也没有必要去追求。每个企业用户同样都应该站在自己的立场上，根据自己的现状和需求来做出决定。用户可以从两个极端去思考，然后为自己找到最适当的定位。

一个极端是经过长期积累、拥有较多遗留系统的企业用户。他们应当选择那些注意技术继承性的ESB厂商作为自己的提供商;

另一个极端是那些新创的企业用户。对于他们来说，则不必顾忌技术继承问题，而应当侧重于当前和今后的应用集成问题，选择较具技术创新色彩的IT提供商，这样不仅可以在较短时期内获得新技术的支持，而且可以相对降低系统成本。不难想象，功能相近的软件，从IBM公司购买和从新创公司购买，其中的价格差异有多大。