现在谈起SOA，很多人首先想到的就是EAI，甚至还有人认为SOA就是要取代EAI。这个观点我觉得有些模糊。对于EAI与SOA具体而明确的概念定义，在此我不做过多的理论纠缠，只是针对我开发的一些经验来说说自己的感觉。

　　从我的观点来看，EAI是个很大的概念。企业领域的EAI应该分为4个层次来看，从下往上依次是：数据层集成，逻辑操作层集成，流程层集成，用户界面层集成。

　　数据层集成是目前EAI领域使用最广泛的集成方式。传统的EAI产品对此的支持非常完备。比如我使用过的Axway的EAI产品，对数据报文和文件的分发传输提供了非常稳定可靠的支持。目前在供应链和公用EDI平台方面，有着很广泛的使用。比如我参与建设的某个电子口岸系统，就使用文件传输的方式实现了货代，船代，海关，仓库等不同系统之间进出口提单等单据数据的交换。

　　逻辑操作层的集成，传统方式都是使用远程过程调用的方式，为了支持跨语言或者跨平台，就需要corba这样的技术进行支撑。当然，自从Web Service出现后，渐渐的成了逻辑操作层集成的首选方式。

　　流程层的集成即实现不同系统间业务流程的集成和处理，这是以逻辑操作层的集成的为基础的。

　　用户界面层的集成目前最主流的方式就是portal.但是实际使用中，portal是个非常笨重的东西。开发的工作量很大，而且标准也不是那么好使，我们有一个项目使用过IBM的portal来开发，你会发现JSR-168其实是个很小的标准，稍微要干点漂亮的事情就得使用IBM对JSR-168的扩展实现。

　　这以上四个层次，技术上从简单到容易，实现代价上从小到大的。其实要做到用户界面的集成是个非常难得事情。目前很多单位建设的portal都是些空portal,花哨而不实用。用户不会闲着没事把一个小窗口拖来拖去找乐子。不能将业务流程有效的进行集成组合，你就是感觉集成后的界面并不能为用户带来多少价值。我们也在实际项目遇到用户买了portal而不使用，还是采取传统的JSP来开发首页面，只不过增加许多到其他系统的跳转链接来实现单点登录而已。

　　从以上的分析来看，SOA从实现企业应用集成的技术层面来看，其实关注的是逻辑操作层和流程层的集成。进行数据复制和文件传输不是SOA技术手段要解决的。

　　可以说在很长一段时间里，传统的EAI产品和SOA产品各有各的用处，相安无事，甚至EAI产品仍然主导企业应用的集成。直到用户真的能够实现以业务组件化(CBM)为前导的流程重组后，才能体验到SOA为企业带来的深远影响与巨大价值。