各个地方的IT开发人员通常都面临这样一个问题：一年下来，不同部门开发的应用搬到网站门户这样的通用系统上后，根本无法很好地协同运行。

2007年初，Leapfrog Enterprise就遇到了这样的困境：当时这家玩具公司需要稳定一致地为供应商和顾客提供各种应用，希望更充分地利用基于互联网的商业交易。Leapfrog Enterprise公司的系统基础设施主管Eugene Ciurana说，公司在今年3月决定需要一种新的方式来开发应用，于是启动了SOA项目，最初的努力如今收到了成效。他说：“我们希望为Web基础设施和系统奠定基础，于是我们从新的起点开始。”

Leapfrog有着典型SOA项目通常会有的许多目标：更多地重复使用代码、缩短开发时间以及方便整合。但是这家公司不想让SOA对开发工具和整合平台而言只是“换汤不换药”。相反，Leapfrog希望自己的开发人员能从遵循某个平台的最佳实践概念中解放出来，以便致力于应用的功能、使用最适合每项任务的一系列广泛的开发技术——Leapfrog的开发人员现在使用诸多开发技术，包括Java 5与Java 6、微软的C#以及附带各种第三方库的Web服务。

举例说，Ciurana不想迫使开发人员都使用相同的传输机制。按照他的说法，如何传输并不重要。他决定使用开源的Mule ESB作为消息传输骨干，靠它来处理诸多传输接口。这样一来，开发人员可以尽量少去关注服务的实现，而是把精力集中所要实现的功能上。结果就是，开发人员往往使用HTTP作为传输机制，不过也有人使用代表性状态传输（Representational State Transfer，REST）和简单对象访问协议（SOAP）。只要效果最好，或者开发人员觉得用起来最方便，什么传输机制都行。有了Mule ESB的方案，开发人员他们用不着担心在特定的SOAP堆栈中有什么或者使用什么集成开发环境（IDE）。Ciurana之前在沃尔玛网站的时候就用过Mule，所以他确信这是Leapfrog的“新起点”项目需要的基础。

Ciurana 指出，Leapfrog之所以能采用这种方法，是因为把重点放在了整合应用上。大部分整合是在应用层面进行的，即应用与应用进行联系。所以应用只要进行输入及输出。开发人员把服务作为普通的Java对象（Plain Old Java Object，POJO）来编写，让Mule ESB把POJO“传送”到消息传输网络，从而在ESB里面完成各种转换。如果你使用SOAP和REST，往往通常会考虑如何连接外界。但要是使用POJO，就用不着这么做。

Ciurana还喜欢Mule ESB的简单，因为只需要管理消息传输。所有商业的SOA厂商都希望把一整套产品卖给用户企业。不过这只不过从一种专有的SOA系统换成另一种专有的系统。由于使用Mule ESB，Leapfrog必须组合SOA堆栈的各层，但Ciurana乐于付出这样的代价，以换取使用上的灵活性。

Leapfrog使用两个ESB，一个ESB用于管理企业资源规划（ERP）、活动目录和数据仓库等内部系统之间的数据流以及应用相互联系；另一个ESB用于面向客户、基于Web的应用，譬如提供给消费者的客户账户自我管理应用和在线游戏。这不但为安全管理和访问管理带来了自然的界限，还提供了为对方充当后备的功能：一旦需要，其中一个ESB就能接过另一个ESB的工作。

Ciurana指出，Leapfrog确实不得不创建通用的服务命名模式，以便服务在每个ESB上都能运行。要求极其准确的名称可以让所有服务井然有序。为了获得ESB方面的自由，这是很小的代价。
美国联合航空公司结合SOA与事件驱动架构
尽管SOA概念很合理：把业务流程分解成各个构成元素，然后开发独立的软件服务，让你在需要时对组件进行配合搭配，从而满足各种业务要求，但是它假设：你在处理的是不相关联的事务处理功能。SOA的这个基本前提要求：业务功能应当是几乎能够以不受限制的方式来组合。