SOA环境中如何正确实现ESB？

在SOA内实现ESB的正确方式是什么？

自从2002年开始使用企业服务总线或者ESB这个术语，ESB就一直是一项有争议的技术。实际上争论的焦点主要在于它不是一项技术，而是一种架构方法。

SOA是2000年初的热门话题，厂商希望将其资本化。ESB产品成为最接近SOA的技术，导致一些人认为必须采用ESB，才能拥有SOA（当然不是），或者购买一个ESB，就会奇迹般地拥有SOA（当然也不是）。

甚至更糟糕的，没有两个ESB是类似的。一些ESB从零开始，一些是现有集成（EAI）套件的新名称，还有一些将其作为一种网络设备交付，另一些则是将其定位为下一代应用服务器。也难怪我们还会问如何恰当地使用它们了。

尽管其他人可能有不同的观点，但是我建议ESB最佳使用是中介(Mediation)和强制操作策略。可以将其看作是服务消费者和服务提供者之间的智能代理服务器或者是路由器，类似用户浏览器和提供了内容Web服务器之间负载均衡器。中介并不包含业务逻辑，而是强制让操作策略和服务交互相关联。

这个中介包括路由选择、安全、流量定形（节流）、监控、衡量采集以及一些与版本控制相关的基本变换。它不包括编制或者是与服务相关的业务逻辑的托管，尽管市场上有些ESB是这样做的。

作者介绍：
Todd Bisk是一家财富500强企业的企业架构师。他的博客主要关于BPM、EA和SOA，此外他还是来自用开源项目快速建站实践丛书中的SOA治理的作者。他在Twitter上的的地址为@toddbiske。

这背后的原因主要是保持关注分离。业务逻辑和业务编制是涵盖开发团队的任务。对于开发者来说，要用工具对它们进行编译，无论是IDE还是BPMN建模工具，然后将其部署到应用服务器、Web服务器或者是流程执行引擎上。执行策略是一项运营工作。

你的开发者是否配置防火墙或者设置负载均衡池？可能没有。他们从开发团队中获取所需的策略信息，但是配置是运营团队执行的。选择ESB厂商的时候，要将这个问题考虑进去，因为有一些外在的内容要求用Eclipse来配置它们，这对于运营团队来说很显然是非典型的情况。

如果你将ESB看作是开发者的工具，ESB和应用服务器对比哪个更合适？谁来选择？通常这个问题很复杂。

如果在执行策略和中介上，你同意我的观点，这就是运用团队的配置活动，而不是开发活动，下一个问题你可能要问“那我还需要它吗？”的确防火墙和负载均衡器可以处理很多，但是很显然它是TCP/IP或者HTTP头层的，没有任何信息可能包括检查。

如果你需要更深层地进入消息架构中，无论是SOAP头或者XML或者JSON负载，一些ESB技术可能更适合，尤其是如果一些消息的基本变换需要支持所包含消息和接口的不同版本（要小心这种情况，可能快速地将转换策略转化得像源代码一样复杂。）。

另一个问题是，你是否需要一些不常见的强制策略领域，像流量节流。内部使用的话，可能就有些过了。外部客户端的话，对于服务消费者如何编写服务没有任何可视性，可能就更为重要。这就引入了域的概念。你需要根据具体策略的域目标考虑你的服务消费者所运行的环境以及你的服务提供者运行在哪里。哪里需要进行跨域的交互，哪里可能就需要一个ESB。

一个比较简单的例子就是内部防火墙和外部防火墙的对比。当跨越边界的时候，中介站出来指出执行策略就显得有意义了。公司内部，你可能在不同地理环境中的数据中心调用的时候，就会做同样的选择，或者是在ERP环境（必须遵循厂商软件标准）和自定制代码环境（更为灵活）之间。

这些域是什么，哪一个边界重要由组织自己确定，这一点很多样，但是如果你能够识别出这些域，对于在合适的地方放置ESB以及避免潜在的执行策略瓶颈很有帮助。转移这些执行点，以便他们只能够看到流量正是这些策略的目标。

总而言之，如果使用得当，ESB在你的环境中就会是很有价值的角色。确保你理解了将ESB作为运营人员的工具还是开发者的工具，确保你实际上的确需要ESB所提供的强大功能。