围绕服务导向架构(Service Oriented Architecture，SOA)，企业用户存在各种各样模糊的认识，这些模糊认识很可能将企业的SOA项目引入误区。

　　1. 为什么不同的人对SOA有不同的解释?

　　SOA 的定义取决于你在组织业务中的角色。

　　对于业务执行人员，SOA创建了企业希望向其客户和合作伙伴或组织的其他部分公开的一组服务。对于IT架构师，SOA是一种体系结构样式，此样式至少需要有服务提供者、请求者和服务描述。对于程序员，SOA是一个由标准、工具和Web服务等技术加以补充的编程模型。

　　当然，企业信息技术系统及流程管理人员之所以存在似是而非的SOA概念，还可能因为软件厂商没有向企业用户解释清楚SOA的含义。比如，SOA中的服务(Service)并非我们理解的传统企业服务，而是软件开发的专业用语，指技术层面的、细颗粒度的功能模块，还远未达到与企业业务流程直接对应的程度。软件厂商在强调SOA给企业带来巨大商业价值的同时，并没有具体阐释这一点。

　　2. 业务流程管理(BPM)和SOA是何关系?

　　BPM与SOA既可以单独部署，也可以组合使用。

　　如果企业的IT系统比较简单，企业规模比较小，用同样的一组IT人员就可以控制所有IT系统，那么，部署一个不使用SOA的BPM套件，就可以获得快速创建、执行和监控/管理业务流程的能力，而不必部署SOA。但是，如果BPM套件由一个IT小组部署，而同时使用来自另一个IT小组的系统服务，那么SOA就可以帮上忙了。

　　如果企业的IT系统足够复杂，可以考虑将BPM和SOA组合使用，通常在SOA上实施BPM解决方案可以获得更大的业务灵活性。如果BPM项目达到一定的范围和规模时效果才能显现，最好先开发出BPM，而将SOA组件留待以后考虑。

　　最好一开始就让业务流程团队和IT架构团队保持持续良好沟通，针对未来进行可行性规划。例如，BPM套件本身应该能够提供丰富的连通性，以便无需全面应用完善的SOA来使得BPM运行，不要让BPM与SOA成为互不连通的两套系统。

　　3. “瀑布式”开发与迭代式开发哪个适合SOA?

　　企业部署SOA最好是通过迭代模型来实现。

　　迭代模型将标识一组对业务非常关键且价值高的功能来进行服务支持工作。此模型可随后供后续服务支持项目和活动使用。如果采用传统应用程序开发时使用的“瀑布式”开发方法部署SOA，可能导致创建仅能部署一次的服务，而无法在以后对其进行重用。

　　使用迭代式开发部署SOA，可通过允许组织逐步纳入到系统中，从而减少出现业务故障的风险。

　　同时，任何组织接受和容纳更改的能力都是有限的，迭代式开发可确保引入新的流程和系统带来的更改非常适应企业的容量，且不会在企业中引起大的混乱。

　　同时，在SOA中，新功能并不一定总是仅受单个业务部门(Line Of Business，LOB)的约束，需要考虑很多跨组织的依赖关系，迭代式开发也有助于解决跨组织的协调。

　　4.Web服务与SOA是一样的吗?

　　Web服务仅仅是目前最流行的SOA实现技术，但并非可以用于开发SOA的唯一技术。

　　SOA与Web服务(Web Service)的数量无关。对于SOA来说，真正有价值的是对于Web服务的再利用而不是Web服务本身。即使将所有信息技术系统都用Web服务实现，也不见得就等于部署了SOA。有些企业使用了太多的Web服务来做同样的IT服务，结果部署SOA的效果非常差。将Web服务等同于SOA，很容易发生在一些希望快速实现SOA但是并未真正理解SOA的企业身上。

　　很多SOA项目都涉及到集成遗留数据，此类数据包含在使用MQSeries和CORBA(Common Object Request Broker Architecture)等“旧”技术的系统中。其中的许多技术都已针对SOA进行了调整，不管有没有Web服务都可使用。事实上，企业可以只使用MQSeries、CORBA甚至远程过程调用(Remote Procedure Call，RPC)技术就能实现SOA。