美国联合航空公司结合SOA与事件驱动架构
　　
    尽管SOA概念很合理：把业务流程分解成各个构成元素，然后开发独立的软件服务，让你在需要时对组件进行配合搭配，从而满足各种业务要求，但是它假设：你在处理的是不相关联的事务处理功能。SOA的这个基本前提要求：业务功能应当是几乎能够以不受限制的方式来组合。 

    但许多业务任务不是可以这样分解的，而是依赖特定的事件顺序。航空公司就是使用事件驱动流程的一个典例，所以它们部署了事件驱动架构（Event-Driven Architecture，EDA）来处理事件。美国联合航空公司的中间件工程经理Ramnath Cidambi说：“EDA完全面向流程，而SOA涉及的是不相关联的黑盒子（即未知因素）。”他指出，两者各有一席之地。毕竟，航空公司也有机票预订和座位安排等事务处理系统，而不是只有事件驱动系统，如飞机着陆后调度运送燃料的卡车，或者航班到达后更新航班信息牌等系统。 

    联合航空公司很早就投资EDA，七年来使用IBM公司的WebSphere作为消息传输总线。在过去的一年，这家公司启动了SOA项目，处理公司网站上使用的现代化Web服务。但是这两种环境大不一样，所以它们有可能并行存在。不过随着公司开始在内部运营方面添加事务处理服务，这种情况正在开始发生变化，譬如利用文本消息（使用Web服务）通知客户服务代表当天的时刻表，使用人力资源系统查看谁在值班、谁请了病假等等，从而安排人员负责各个机场的不同登机口。这使Web服务与事件驱动流程处于同一环境中，从而使这家航空公司除了网站项目外，还可以启动SOA项目。 

    联合航空公司的挑战在于，弄清楚如何设计服务架构，并把服务部署到拥有而且需要两套架构的公司环境。虽然这家公司的内部运营使用两套架构，但不能完全分开来对待。毕竟，航班取消（一个事件）也会影响到事务处理系统（如重新调度航班、更新基于Web的航班状态查询工具，或者发放代金券）。许多流程既包括事件部分，又包括事务处理部分：客户服务代表从事务处理系统得到当天的时刻表，而航班取消、天气造成的延误等因素会导致航班状态出现变化，原来的时刻表很快就会失效。事件驱动系统可以跟踪航班状态，调度事务处理系统随后通过定期查询航班状态（航班的显示屏使用同样的流程）来重新调度人员。 

    最大的挑战在于弄清楚消息传输系统。ESB并不使用Web服务标准之外的标准，所以如何处理事件驱动服务并不明朗，还会由于使用不同的产品和工具出现不一致。不过，吸引Cidambi的是使用ESB同时用于SOA和EDA，因为它们可以很好地处理消息传输、数据转换以及其他关键的数据路由任务。 

    如今，美国联合航空公司有两个ESB，一个用于EDA服务，另一个用于SOA服务。它使用IBM WebSphere集成代理器，作为面向发布和订阅的消息传输平台，用于事件驱动服务。需要时可传输事件，并且处理服务之间的任何转换――其实是充当EDA的ESB。至于传输方面，现有的J2EE应用完全面向消息传输，所以都使用Java消息服务（Java Message Service，JMS）而不是Web服务作为消息传输标准。 

    该公司采用了BEA AquaLogic ESB用于其SOA服务，因为Cidambi期望这个比较新的平台会更适应比较新的SOA概念；更适合公司里面使用的WebLogic服务器环境和Eclipse开发环境。AquaLogic基本上在WebLogic上运行，所以不需要整合。 

    Cidambi没有把EDA服务迁移到AquaLogic上，也是为了避免不必要的工作；他指出， WebSphere运行相当好。要是迁移到新的ESB，势力会出现干扰和意外情况：公司用了七年的时间来优化WebSphere平台、解决运营方面的问题；迁移到像AquaLogic这些新的ESB需要马上投入精力；毫无疑问，新的问题也会暴露出来。 

    Cidambi面临的另一个问题是EDA方面缺乏标准的XML模式（XML Schema）。这样一来，在EDA服务和SOA服务之间传输消息就变得更复杂、更费力。