有趣的是，2002年的服务定向流程报告中提出了ESB SOA方法的核心原则，在这份报告中，我们指出集成不过是服务组合的副产品。而且六年以后我们依然捍卫自己的观点：集成是服务和业务之间的事，而不是IT将各种基础设施联系在了一起。相反，SOA额度核心技术问题就是建立并维护业务服务抽取，这样业务就可以通过组合这些服务建立灵活的流程。换句话说，SOA要求我们从“连接基础设施”方法转变为分布式计算方法再到“组合服务”方法。

　　毕竟，业务流程所有的以集成为核心的方法，我们可以称之为传统业务流程管理（BPM)，一直苦于技术的局限性。传统的BPM流程引擎不是平台的一部分，就是和平台有着密不可分的联系。结果是，尽管你可以通过组合服务来实施流程，但是这些服务必须在平台上运行，否则擎无法合理的控制并管理这些服务。另一方面，如果你在业务流程中采取服务定向方法，那么你就可以从底层运行时间环境抽取服务，这些服务可以在任何地方运行——本地运行或者远程运行，总线上或者总线外，在Java，.NET或者是主机环境下都可以运行。这种流程需要通过服务交换的信息，而不是依靠引擎布线或者示例其它目标来实现流程实例状态，这些都是非服务定向技术。

　　关键是：实施业务流程的SOA平台方法的局限性大于其优越性。除了要求额外中间件的规模以外，它还阻碍了跨平台流程。另外，实施的规模越大，其灵活性就越差。另一方面，无ESB方法更为复杂，该方法要求架构实施必须正确，包括适当的治理，以及中介物形式，以及建立和维护业务服务抽取的其它方面。这些措施中最难的就是SOA的无ESB方法我们要用一种不同的方式思考分散式计算。对于那些早就习惯了传统以集成为中心的环境的人来说，就好像不带降落伞跳飞机一样。这种风险性实际上是一种幻觉：是供应商压力和对新事物不熟悉二者的合力，现在是时侯奋力一搏采用架构驱动的无ESB SOA技术了。

　　ZapThink采取的措施

　　如果你听过我们的LZA课程或者你关注ZapFlashes已经有一段时间，你就会对SOA的无ESB方法产生兴趣——然而不幸的是，这种软件为先的选择似乎风险更小。毕竟，如果你采用无ESB方法失败了，就肯定是一败涂地了，但如果你从供应商那里买来大型的程序包，你的工作也会遇到麻烦，如果大型的分析公司（许多这项公司为供应商所雇佣）认为这个SOA平台具有可行性，那么还有什么必要打乱计划呢？

　　但是，现在经济形势有了很大的变化。不管你认为用于定标SOA实施的“中间件的中间件”在低迷的市场上有多么不景气。一旦你的老板和供应商的销售部主任一起切磋球艺，这一切就毫无意义了，现在要尽可能的节俭开支，勤俭是在现今市场的制胜法宝。ZapThink一直都在强调，你不需要购买太多的软件来实施SOA，现在是吸取教训的时候了。

　　现在预测市场的走向还为时太早，我们唯一能够确定的就是只有一部分机构能够在这场劫难中存活下来，而SOA可以保证为你节省成本，增大灵活性，而这两点也是在在危难之中求存的良方，但是仅仅有SOA措施并不能保证你可以成功。毕竟你得保证其能正确实施，如果你实施SOA，却不能实现预想的收益，或者你想去实施SOA但是在这个过程中失败了，这并不意味着SOA本身有问题。而是你的方法有问题。当我们看到那些采用SOA平台方法的企业要为自己的中间件购买中间件来定标自己的SOA措施时，这种方法肯定会阻碍他们实现SOA的大计。我们把赌注都压在了他们的竞争上——即那些在SOA中采用架构第一位策略的机构。