最近几年来，企业服务总线（ESB）在SOA基础架构工具这一领域中颇有用武之地，但也不无争议。可以称得上是“摸着石头过河”吧。现在它被用得越来越多，但是用户需要进一步学习怎样才能更好地使用它。

　　在复杂的集成项目中，如果发现性能变得慢起来，ESB常常成为被指责的对象。此外，如果配置不当，它可能无法实现SOA所承诺的更好的服务可重用性。

　　在SearchSOA.com用户挑战及优先级2011－2012年度读者调查中，在受访者提到的ESB开发挑战之中，复杂性问题首当其冲，77％的受访者认为它是一个挑战。紧随其后的是性能和维护问题，分别占65％和53％。

　　最近，在同Lee Ackerman讨论SoaML设计时，我们提到了ESB的性能问题。作为Emphasys集团首席技术官的Ackerman说，只有服务设计中的服务粒度制定的适当，才能以正确的方式构建正确的服务。就像EJB或其他组件类型那样，他说，如果你确保传输已经连接上，你就要付出代价。

　　“当你已经建立了一堆服务，并且将它们放到一个ESB上，如果它们的表现不佳，很可能你在设计时就已经出了差错，”Ackerman说道。他认为配置ESB的策略是我们查找故障所在领域的一个标志。

　　“如果你发现ESB内部的策略过于复杂，这提示你需要审查一下你所设计的服务，以确保这些服务是正确的，粒度恰当，以及他们都有正确的责任，”他说道。

　　这一与性能相关的建议也得到了Ataptris首席技术官Jeff Bradshaw的赞同。过于庞大的消息和应用逻辑也是问题，他补充道。

　　“有时候，如果每秒内会有数以千计的消息，当出现特别大的消息时，那么性能就慢下来了。”Bradshaw 说道。“然后这就变成了你采用的ESB的逻辑问题了。非常重要的一点是，要确保您将ESB用到了正确的用途上。”

　　“ESB应该是一个彻底的中介逻辑，从一个地方得到消息并送到另一个地方，并确保它采用了正确的格式。这才是中介逻辑，而不是其他什么东西，”Bradshaw说道。

　　慎重处理ESB和应用逻辑

　　“如果你将应用逻辑放到ESB中，在我看来，这是一种错误的模式，这也是ESB名声不佳的一个肇始之源。如果你想编写一个应用程序，那么你就应该使用一个应用程序服务器，”他说道。“不要把它放在ESB容器中。”

　　Bradshaw告诫开发团队，要记住，ESB从根本来说是一种集成工具。ESB是“中介逻辑，而不是应用逻辑，”他强调说。

　　我们都熟悉“工欲善其事，必先利其器”这个说法。这一格言也适合用在系统集成中。

　　“一些规模较大的咨询公司会尝试将ESB用做万能药，并把所有的逻辑放在ESB中，”Bradshaw说道。应用逻辑应当放在应用程序服务器中，这样“扩展性会更好，”他说道。

　　在深入到ESB的设计问题时，Bradshaw谈到了数据治理和XSLT，在进行XML转换时，XSLT是一个很受欢迎的选择。

　　“如今，市面上所有的ESB在XML转换时都会使用XSLT。问题是，你会发现，有些开发人员开始会将业务逻辑编码到这些XSLT中，”他说道。“这样会有一些潜在的问题。”

　　随着时间的推移，像这样的代码更容易出错，就像过去已经在SOA中发现的那样，这种问题是很难跟踪的，尤其是在有多个版本的时候。

　　这一问题会损害SOA和ESB在从业人员中的声誉。如果这种错误出现在常规的软件堆栈中，操作人员可以更容易地发现这一bug。

　　“而在SOA中时，这个故障往往是随机出现的。你将逻辑放在了实际中会随机运行的地方，那么就很难去跟踪，”Bradshaw说道。