soa方法可能令人迷惑，并经常造成误解。下面的列表将帮助你了解与soa有关的主要概念和潜在优点。
#1：soa并非纯粹的技术性方法
如果得以成功执行，服务导向架构(soa)并非只是一个技术性架构，理解这一点是非常重要。soa范例旨在于对商业流程进行建模，这些商业流程并不能总是得到技术组件的直接支持。最终，服务可能由技术组件执行，但是商业流程本身要比支持它们的这些服务重要得多。
作为一种技术，soa是一个工具，虽然这种技术本身没有提供直接的价值，但是与EJB或者.NET组件相比，soa是一种更为廉价的代码行服务开发方式。另外，soa应被当作是其它利益的实现者，比如改进更广泛的再利用，提高对商业流程的响应性以及与使商业流程保持更好协调性。
#2：soa不一定意味着网络服务
很多技术人员对soa存在这样一种误解，认为soa意味着必需使用网络服务。虽然网络服务可作为soa策略的一部分，但它并不是必需的部分。服务的定义可以基于除HTTP以外的其它标准。和具体的实现技术相比，关注商业流程和服务的需求更为重要。通常，服务的环境将有助于决定其执行方式。
例如，对于包含了关键商业事务的服务而言，使用网络服务是不利的，因为我们无法通过soaP/HTTP协议来保证交易。而且，很多服务可能需要异步操作，在这种情况下，基于队列和通道的消息系统可能是进行提供服务的最佳方式。当然，有效负载和界面依然可以使用XML来定义。
#3：可以使用现有架构建立soa
很多组织对于soa可以使用现行架构来建立感到非常惊讶，例如，.NET和J2EE平台都可为网络服务开发、XML解析与生成，以及与MSMQ和JMS这类消息系统进行通信提供支持。
soa堆栈常常缺乏流程管理层或自动化层面。不过，许多公司现在已经在企业应用集成 (EAI)工具上进行了投资，很多EAI工具能够提供流程自动化和管理层功能，它们可以从现有的应用程序或在.NET和J2EE平台上建立的应用程序中对服务进行访问。
#4：soa是一种(从组件、对象等)进化而来的方法
服务导向架构并不是一种全新的解决方案；相反，soa是技术与架构的自然进化。系统架构一直在不断进步，与商业保持高度一致。系统设计师与商家很早就认识到将技术与商业流程相协调的重要性，包括充分应用并合理化技术资源，以及为商业提供更好的支持。
soa也在一定程度上源于早已有之的企业架构理论。企业架构对技术进行评估，但是更重要的是，它关注整个企业和全部的商业流程并提供了做出技术决策的背景信息。soa工具则融合了互联网技术，如HTTP和XML，以及综合技术，如消息总线、转译技术和连接技术。
#5：流程自动化是soa的关键优势
许多组织和技术专家错误地关注服务架构内的服务实现与交付，不幸的是，他们没有抓住重点，soa的真正价值体现在它是一个商业自动化工具。最终，软件和系统将会提高商业或组织的效率，这可以根据组织执行的活动或者流程来定义。因此soa不应将焦点放在服务上，而应放在流程以及流程的改进上。
当然，我们也需要服务为流程提供支持。但是对于提高效率和改进流程的目标而言，它们是次要的，服务本身的价值有限。
#6：soa架构可能高度复杂
从某一角度看，SOA架构可以相当简单。例如，开发一个商业流程并确定所需的服务，这种要求就合理而直接。但是，要在数据和服务之间进行平衡，并实现有意义的目标则要复杂得多。
例如，假设有这样一种情况：用户使用订单服务在系统中下订单。这是相当简单的操作。但是如果您希望将订单上的数据和来自其它服务的数据关联起来呢？如果所有的服务共享同一个数据源，这时您可以跳过服务层，并生成报告。但是，如果一些数据属于本地服务，一些数据属于原有的主机系统，并且另外一些数据属于商业应用程序(比如SAP)，将这些数据集成在一起将会特别复杂。
#7：soa需要深入了解商业数据
因为soa关注于商业流程，因此理解这些与流程密切相关的数据至关重要。例如，一个订单流程会包含很多重要的数据项，比如订单、客户、运输信息、发票、付款和收据；更重要的是必须以一种标准的方式来记录这些数据，从而使流程中的每项服务都能以同样的方式理解这些数据。
对于现在拥有信息架构的组织而言，这并不是一个大问题。但如果大型组织没有信息架构或者信息架构支持有限，这一问题会导致实施过程中的长时间中断。因为大型企业通常拥有的数据多种多样，所以一般建议他们采用进化的方式来定义信息架构，即与“大爆炸”方式相反的方法。这意味着不必花费四年的时间来定义数据模型，而只需要在开发服务过程中花费少量时间来定义与那些服务相关的数据。这样，在执行每项服务或者流程时，就可以发展相关的信息架构来包含必需的数据项。
