Leapfrog愿意考虑开源的SOA方案

    各个地方的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方面的自由，这是很小的代价。