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关注于商业流程，因此理解这些与流程密切相关的数据至关重要。例如，一个订单流程会包含很多重要的数据项，比如订单、客户、运输信息、发票、付款和收据；更重要的是必须以一种标准的方式来记录这些数据，从而使流程中的每项服务都能以同样的方式理解这些数据。

　　对于现在拥有信息架构的组织而言，这并不是一个大问题。但如果大型组织没有信息架构或者信息架构支持有限，这一问题会导致实施过程中的长时间中断。因为大型企业通常拥有的数据多种多样，所以一般建议他们采用进化的方式来定义信息架构，即与“大爆炸”方式相反的方法。这意味着不必花费四年的时间来定义数据模型，而只需要在开发服务过程中花费少量时间来定义与那些服务相关的数据。这样，在执行每项服务或者流程时，就可以发展相关的信息架构来包含必需的数据项。

　　8：服务可简单可复合

　　定义服务可能是一个艰巨的任务。在某些情况下，我们很清楚需要哪些服务；很多时候，服务相当简单。例如一个查找客户的服务，可能需要使用一些标准来查找用户并为服务的使用者提供标准化的客户记录。

　　然而，服务也可以复合形式存在。这意味着“超级服务”可以提供一个标准的界面，就像我们刚才查找客户的服务所提供的那样。在前面的例子中，暗指所有的客户信息都存储在同一个资料库中，所以很容易进行查找。但如果一些客户资料存放在大型主机中，一部分存放在SAP中，一部分存放在其它应用程序中，而另外一部分存放在Oracle数据库中呢？让我们假定在每一种系统上已经建立了查找服务的界面。换句话说，我们拥有在大型主机、SAP、其他的应用程序和Oracle数据库上查找客户的服务。我们新的查找客户的服务可以使用所有这些现有的服务来查找客户。现在，因为我们的服务要调用其它服务，它变成一个复合式的服务。当一个自动化流程模型自己成为一项服务时，也会建立复合式服务。

　　9：SOA的自动化可能有很多层面

　　自动化可以发生在不同的层面，这是服务架构经常被忽视的一个特点。很多SOA架构的错误在于只看到某一个层面的自动化，然而，在一个SOA解决方案中，自动化至少可以应用到两个关键领域。

　　第一个也是最明显领域的是商业流程层，在设计流程的时候，其中的步骤已经进行了连接并形成自动化。因为这些流程通常是基于日常商业活动，往往与人类的交互活动有关。在人类交互流程中实现自动化是一个重要的自动化层面。

　　另外一个重要的自动化层面是没有人参与的系统交互层，过去几年来，集成工具已经应用到这一领域。通过对系统间任务进行自动化，往往可以提高流程的总体效率。

　　在这些层面上使用不同的工具也是很重要，应该对人类交互、程序或系统间的交互区别考虑，从而采取不同的策略。

　　10：服务应当遵循相同的界面标准(包括协议和数据)

　　使用标准化的方法进行通讯对于服务而言非常重要。在SOA世界中，通讯由两个组件构成。一个是服务进行通信的网络协议，就好比是人们每天使用的通讯媒介一样，例如，如果您想和老板通讯，最好搞清楚老板喜欢接电话还是电子邮件。

　　第二个组件是通讯的数据或者语言，一旦您同意将HTTP或者JMS作为通讯机制，就等于确定了您交流的语言，例如，您的老板说法语而您说英语，可能就会造成通讯困难。在服务领域，通常使用XML作为语言，但这并没有提供足够的信息。必需对服务需要的数据进行清晰定义并达成一致，这样服务提供商与服务用户就能进行有效的通讯。

　　11：可以将服务外包

　　服务的另外一个优点就是它们不必作为整体组件购买，不必在内部进行管理，也不必从头进行开发。相反，可以将服务外包。这意味着在您需要一项服务向政府部门提交法规遵从文件时，您不必自己建立这项服务。各类公司为几乎每个产业部门提供各种服务。利用服务外包，您可以将主要精力放在与最重要的SOA策略——流程——上面。

　　外包方式的一个不足之处在于，如果您的竞争对手使用了同样的服务，您可能会丧失一些竞争优势。

　　另外一个需要考虑的问题是性能，这依赖于很多因素，主要包括网络连接性、可用性和反应时间。采用外部网络的服务可能会使您商业流程的性能降级。

　　12 服务可以在现有的系统和软件基础上建立

　　许多组织误认为SOA方式没有考虑到原有系统，如大型主机应用程序。实际上，SOA的一个最强大的价值就在于它允许组织重新利用大型主机和其它原有资产，这一点尤其重要，因为核心商业逻辑和核心商业数据通常保存在私有的原有系统中。通过服务来访问核心商业逻辑和数据，可以立即在自动化流程模型中重新利用这些资产。

　　当然，大型主机并不是唯一的原有数据源。微型计算机系统，如AS/400、VAX和HP3000等等，都可以以各种方式提供服务。很多工具都可以帮助与这些所有权系统进行通讯，并将它们的信息作为标准化的服务来传递。

　　13：性能是SOA系统的关键

　　尽管SOA为一个组织提供了很多利益，包括协调技术与商业，增强灵活性等；它与性能有着密切的关系。因为在典型的SOA环境中，应用程序往往被高度细分，而程序之间的数据关联也很缓慢，在决策支持和报告系统中特别需要考虑这一点，以往这些系统只依赖少量数据源。

　　性能最大化的关键在于了解应用程序和系统性能在何处对于商业最重要。构建一个高性能的系统来支持一个并不需要它的商业流程是无益的。一旦确定关键流程，您只需要在有必要的地方改进并提升性能就行了。

　　14：SOA以四个组件为基础

　　一个成功的SOA交付计划有四个组件。第一个组件是定义商业流程，需要哪些服务来支持它们，以及哪些数据与它们相关。这是关于SOA的商业分析。

　　第二个组件是SOA的架构和模式，这是一组描述如何定义与实现服务的规则，指定通用的交付与使用模式，并制订开发服务需要遵循的原则与标准。

　　第三个组件是SOA的基础结构，这包括网络、服务器、存储设备、消息工具、整合工具以及流程自动化工具等等，它们支持服务与商业流程的开发与交付。

　　第四个组件是SOA的开发计划。该计划确定了服务开发与流程实现的先后次序，并且指导形成新服务与新流程项目。

　　15：建立SOA可能相当麻烦

　　尽管SOA是一个进化性技术，尽管在SOA领域已经具备相当丰富的知识储备，但由于各种原因，建立SOA仍然相当麻烦。最主要的原因在于SOA和其它变革一样：它需要大量的沟通与社会化，使组织为变革做好准备。

　　在克服了变革的困难之后，还可能有其它技术性问题。这些问题包括建立适当的服务交付和使用模式、培训技术开发团队、以及为支持SOA开发模式对组织进行的可能的结构变化。尽管SOA的技术组件可以在隔离的环境下进行测试和验证，SOA依然是一个全企业参与的方法，因而需要付出更多的努力来规划服务架构的控制与管理。