什么是SOA
我们可能应该回答的第一个问题也是最基本的问题。什么是面向服务的体系结构(Service-Oriented Architecture, SOA)？这个问题的答案实际上涉及与开发相关的若干不同方面。
SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求（在有些情况下，甚至不需要人工干预）。
这些服务是自包含的，具有定义良好的接口，允许这些服务的用户——称为客户机或使用者——了解如何与其进行交互。从技术角度而言，SOA 带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库（甚至不一定绑定到特定的基础设施）。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务和访问服务的客户机并未彼此绑定，因此可以完全替换用于处理订单的服务，下订单的客户机-服务将永远不会知道这个更改。所有交互都是基于“服务契约”进行的；服务契约用于定义服务提供者和客户机之间的交互。通常，您将通过创建“基于消息的”系统来实现此目标。
从业务的角度来说，面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术，而不是通过技术约束来规定您的行动。例如，销售过程（制造、运输和收到货款）可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言，此过程包含一系列人工活动，例如：
销售人员找到潜在客户
客户订购产品
生产部门制造产品
生产部门发出产品
收款部门开具产品帐单
客户支付产品货款
面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井 (Silo)。
通过实现 SOA，可以带来大量好处，包括以下各个方面：
更高的业务和 IT 一致性
基于组件的系统
松散耦合的组件和系统
基于网络的基础设施，允许分散于各地且采用不同技术的资源协同工作
动态构建的按需应用程序
更高的代码重用率
更好地标准化整个企业内的流程
更易于集中企业控制
SOA体系结构
Web 服务是用于实现 SOA 的最常见技术标准。不过，这并不是可以用于开发 SOA 的各个部分的唯一技术。很多 SOA——实际上是大部分——都涉及到集成遗留数据，此类数据包含在使用 MQSeries 和 Common Object Request Broker Architecture (CORBA) 等技术的系统中。其中的许多技术都已针对 SOA 进行了调整，不管有无 Web 服务包装均可使用。事实上，可以仅使用 MQSeries、CORBA 甚至远程过程调用（Remote Procedure Call，RPC）技术来实现 SOA。但 Web 服务正迅速成为用于支持 SOA 的事实标准。
SOA生命周期
由于 SOA 涉及到业务的诸多方面，因此需要从一开始就对 SOA 项目进行细心的规划和设计。您需要考虑项目的整个生命周期，从最初的阶段到第一个实现，再一直到可能的修订和重用。
现在让我们看看 SOA 生命周期，如图 1 中所示。此部分概略说明了在生命周期的各个阶段发生的事项，并详细介绍了实现生命周期的各个步骤。
建模
面向服务的体系结构项目的第一步几乎和技术没有任何关系，所有事项都与您的业务相关。请记住，面向服务的方法将业务所执行的活动视为服务，因此第一步是要确定这些业务活动或流程实际是什么。对您的业务体系结构进行记录，这些记录不仅可以用于规划 SOA，还可以用于对实际业务流程进行优化。通过在编写代码前模拟或建模业务流程，您可以更深入地了解这些流程，从而有利于构建帮助执行这些流程的软件。
建模业务流程的程度将依赖于预期实现的深度。另外，这个程度还依赖于您在开发团队中担任的角色。如果您是企业架构师，您将会对实际的业务服务进行建模。如果您是软件开发人员，您将可能对单个服务进行建模。
组装
对业务流程进行了建模和优化后，开发人员可以开始构建新的服务和/或重用现有的服务，然后对其进行组装以形成组合应用程序，从而实现这些流程。在“建模”步骤中，您已经确定了需要何种类型的服务以及它们将访问何种类型的数据。已经存在某种形式的实现这些服务或访问该类数据所需的一些软件。“组装”步骤将要找到已经存在的功能，并为其添加服务支持。另外，还涉及到创建提供功能和访问数据源所需的新服务，以便满足您的 SOA 涉及的业务流程范围内的需求。
部署
进行了建模和组装后，要将组成 SOA 的资产部署到安全的集成环境中。此环境本身提供专门化的服务，用于集成业务中涉及的人员、流程和信息。这种级别的集成可帮助确保将公司的所有主要元素连接到一起协同工作。此外，部署工作还需要满足业务的性能和可用性需求，并提供足够的灵活性，以便吸纳新服务（并使旧服务退役），而不会对整个系统造成大的影响。
管理
系统就位，一切都正常运行。 现在您可以对一切放手不管了，对吗？不对。部署后，需要从 IT 和业务两个角度对您的系统进行管理和监视。在“管理”步骤中收集的信息用于帮助实时地了解业务流程，从而能更好地进行业务决策，并将信息反馈回生命周期，以进行持续的流程改进工作。您将需要处理服务质量、安全、一般系统管理之类的问题。
在本步骤中，您将监视和优化系统，发现和纠正效率低下的情况和存在的问题。由于 SOA 是一个迭代过程，因此，在此步骤中，您不仅要找出技术体系结构中有待改进之处，而且还要找出业务体系结构中有待改进之处。
完成此步骤后就要开始新的“建模”步骤了。在“管理”步骤中收集的数据将用于重复整个 SOA 生命周期，再次进行整个过程
控制
SOA 是一种集中系统；其中可以包含来自组织的不同部门的服务，甚至还能包含来自组织外的服务。如果没有恰当的控制，这种系统很容易失控。
控制对所有生命周期阶段起到巩固支撑作用，为整个 SOA 系统提供指导，并有助于了解系统全貌。它提供指导和控制，帮助服务提供者和使用者避免遇到意外情况。
SOA采用阶段
已经向您介绍了面向服务的体系结构和 SOA 开发的步骤，您现在可能已经确信应该开始构建自己的 SOA 了。如果您已经构建了基于 Web 的软件服务，则已经达到了 SOA 采用的第一个阶段。在此部分，我们将分析各个采用阶段（从偶然构建服务到基于面向服务的体系结构原则对业务进行全面转换），从而帮助您了解自己目前所处的位置以及确定需要实现的目标。
SOA 成熟阶段
您不大可能立即基于 SOA 进行全面的转换。事实上，孤注一掷的方法会增加失败的风险。应该转而采用迭代的方法逐步通过各个采用阶段，首先开发少数试点项目服务，然后逐步将您的 IT 系统更新为在 SOA 内工作的服务。我们将讨论以下 SOA 采用阶段：
构建服务
集成
转换 IT
转换业务
构建服务：具有特殊连接的根据需要提供的服务
在 SOA 采用第一个阶段，公司通常会很偶然地着手构建 SOA 服务。也就是说，由于需要解决特定的问题，他们选择了面向服务的方法，而不使用传统方法。在此阶段，服务构建将更多地关注解决特定的问题，而不是对企业现有系统进行转换。IT 部门将构建一些新服务，或许会将一些现有应用程序转换为一组基于 Web 的服务。它们之间的链接将根据需要提供，而不是源自整个体系结构的要求。
集成：具有可靠连接的系统标准化服务接口
发现了松散耦合体系结构的优势、方便性和易维护性后，下一步就是利用这种灵活性通过组合服务来创建新的组合应用程序。例如，员工状态服务可以与经理审批服务组合，以形成请假服务。这个过程可以采用自顶向下的方法，将重点放在最终结果和查找组件组成部分上。或者，可以采用自底向上的方法，将重点放在各个组成部分上，看看可以基于这些组成部分构建何种服务。他们之间的链接是预先计划的且定义良好。
转换 IT：组合可重用服务，利用多个来源的功能
这个阶段涉及到对您的信息技术基础设施进行转换，以便充分利用 SOA 的优势。在此阶段，所有系统将转换为基于服务的应用程序，松散耦合是其中的规范做法，而不是例外。系统的所有组件都将根据 SOA 进行集成和连接，IT 系统的所有部分都在 SOA 内工作。
转换业务：对服务进行动态的事件驱动的重新配置
在 SOA 成熟的最后一个阶段，业务与 SOA 完全集成，达到了这样一个程度：所有合适的业务活动都被视为服务，可以最终在技术体系结构中对其进行建模、分析和实例化。达到此阶段需要业务部门进行大量的工作和投入；不过，达到此阶段后，业务将从面向服务的体系结构获得最大的回报。
我们可能应该回答的第一个问题也是最基本的问题。什么是面向服务的体系结构(Service-Oriented Architecture, SOA)？这个问题的答案实际上涉及与开发相关的若干不同方面。
SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求（在有些情况下，甚至不需要人工干预）。
这些服务是自包含的，具有定义良好的接口，允许这些服务的用户——称为客户机或使用者——了解如何与其进行交互。从技术角度而言，SOA 带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库（甚至不一定绑定到特定的基础设施）。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务和访问服务的客户机并未彼此绑定，因此可以完全替换用于处理订单的服务，下订单的客户机-服务将永远不会知道这个更改。所有交互都是基于“服务契约”进行的；服务契约用于定义服务提供者和客户机之间的交互。通常，您将通过创建“基于消息的”系统来实现此目标。
从业务的角度来说，面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术，而不是通过技术约束来规定您的行动。例如，销售过程（制造、运输和收到货款）可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言，此过程包含一系列人工活动，例如：
销售人员找到潜在客户
客户订购产品
生产部门制造产品
生产部门发出产品
收款部门开具产品帐单
客户支付产品货款
面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井 (Silo)。
通过实现 SOA，可以带来大量好处，包括以下各个方面：
更高的业务和 IT 一致性
基于组件的系统
松散耦合的组件和系统
基于网络的基础设施，允许分散于各地且采用不同技术的资源协同工作
动态构建的按需应用程序
更高的代码重用率
更好地标准化整个企业内的流程
更易于集中企业控制
SOA体系结构
Web 服务是用于实现 SOA 的最常见技术标准。不过，这并不是可以用于开发 SOA 的各个部分的唯一技术。很多 SOA——实际上是大部分——都涉及到集成遗留数据，此类数据包含在使用 MQSeries 和 Common Object Request Broker Architecture (CORBA) 等技术的系统中。其中的许多技术都已针对 SOA 进行了调整，不管有无 Web 服务包装均可使用。事实上，可以仅使用 MQSeries、CORBA 甚至远程过程调用（Remote Procedure Call，RPC）技术来实现 SOA。但 Web 服务正迅速成为用于支持 SOA 的事实标准。
SOA生命周期
由于 SOA 涉及到业务的诸多方面，因此需要从一开始就对 SOA 项目进行细心的规划和设计。您需要考虑项目的整个生命周期，从最初的阶段到第一个实现，再一直到可能的修订和重用。
现在让我们看看 SOA 生命周期，如图 1 中所示。此部分概略说明了在生命周期的各个阶段发生的事项，并详细介绍了实现生命周期的各个步骤。
建模
面向服务的体系结构项目的第一步几乎和技术没有任何关系，所有事项都与您的业务相关。请记住，面向服务的方法将业务所执行的活动视为服务，因此第一步是要确定这些业务活动或流程实际是什么。对您的业务体系结构进行记录，这些记录不仅可以用于规划 SOA，还可以用于对实际业务流程进行优化。通过在编写代码前模拟或建模业务流程，您可以更深入地了解这些流程，从而有利于构建帮助执行这些流程的软件。
建模业务流程的程度将依赖于预期实现的深度。另外，这个程度还依赖于您在开发团队中担任的角色。如果您是企业架构师，您将会对实际的业务服务进行建模。如果您是软件开发人员，您将可能对单个服务进行建模。
组装
对业务流程进行了建模和优化后，开发人员可以开始构建新的服务和/或重用现有的服务，然后对其进行组装以形成组合应用程序，从而实现这些流程。在“建模”步骤中，您已经确定了需要何种类型的服务以及它们将访问何种类型的数据。已经存在某种形式的实现这些服务或访问该类数据所需的一些软件。“组装”步骤将要找到已经存在的功能，并为其添加服务支持。另外，还涉及到创建提供功能和访问数据源所需的新服务，以便满足您的 SOA 涉及的业务流程范围内的需求。
部署
进行了建模和组装后，要将组成 SOA 的资产部署到安全的集成环境中。此环境本身提供专门化的服务，用于集成业务中涉及的人员、流程和信息。这种级别的集成可帮助确保将公司的所有主要元素连接到一起协同工作。此外，部署工作还需要满足业务的性能和可用性需求，并提供足够的灵活性，以便吸纳新服务（并使旧服务退役），而不会对整个系统造成大的影响。
管理
系统就位，一切都正常运行。 现在您可以对一切放手不管了，对吗？不对。部署后，需要从 IT 和业务两个角度对您的系统进行管理和监视。在“管理”步骤中收集的信息用于帮助实时地了解业务流程，从而能更好地进行业务决策，并将信息反馈回生命周期，以进行持续的流程改进工作。您将需要处理服务质量、安全、一般系统管理之类的问题。
在本步骤中，您将监视和优化系统，发现和纠正效率低下的情况和存在的问题。由于 SOA 是一个迭代过程，因此，在此步骤中，您不仅要找出技术体系结构中有待改进之处，而且还要找出业务体系结构中有待改进之处。
完成此步骤后就要开始新的“建模”步骤了。在“管理”步骤中收集的数据将用于重复整个 SOA 生命周期，再次进行整个过程
控制
SOA 是一种集中系统；其中可以包含来自组织的不同部门的服务，甚至还能包含来自组织外的服务。如果没有恰当的控制，这种系统很容易失控。
控制对所有生命周期阶段起到巩固支撑作用，为整个 SOA 系统提供指导，并有助于了解系统全貌。它提供指导和控制，帮助服务提供者和使用者避免遇到意外情况。
SOA采用阶段
已经向您介绍了面向服务的体系结构和 SOA 开发的步骤，您现在可能已经确信应该开始构建自己的 SOA 了。如果您已经构建了基于 Web 的软件服务，则已经达到了 SOA 采用的第一个阶段。在此部分，我们将分析各个采用阶段（从偶然构建服务到基于面向服务的体系结构原则对业务进行全面转换），从而帮助您了解自己目前所处的位置以及确定需要实现的目标。
SOA 成熟阶段
您不大可能立即基于 SOA 进行全面的转换。事实上，孤注一掷的方法会增加失败的风险。应该转而采用迭代的方法逐步通过各个采用阶段，首先开发少数试点项目服务，然后逐步将您的 IT 系统更新为在 SOA 内工作的服务。我们将讨论以下 SOA 采用阶段：
构建服务
集成
转换 IT
转换业务
构建服务：具有特殊连接的根据需要提供的服务
在 SOA 采用第一个阶段，公司通常会很偶然地着手构建 SOA 服务。也就是说，由于需要解决特定的问题，他们选择了面向服务的方法，而不使用传统方法。在此阶段，服务构建将更多地关注解决特定的问题，而不是对企业现有系统进行转换。IT 部门将构建一些新服务，或许会将一些现有应用程序转换为一组基于 Web 的服务。它们之间的链接将根据需要提供，而不是源自整个体系结构的要求。
集成：具有可靠连接的系统标准化服务接口
发现了松散耦合体系结构的优势、方便性和易维护性后，下一步就是利用这种灵活性通过组合服务来创建新的组合应用程序。例如，员工状态服务可以与经理审批服务组合，以形成请假服务。这个过程可以采用自顶向下的方法，将重点放在最终结果和查找组件组成部分上。或者，可以采用自底向上的方法，将重点放在各个组成部分上，看看可以基于这些组成部分构建何种服务。他们之间的链接是预先计划的且定义良好。
转换 IT：组合可重用服务，利用多个来源的功能
这个阶段涉及到对您的信息技术基础设施进行转换，以便充分利用 SOA 的优势。在此阶段，所有系统将转换为基于服务的应用程序，松散耦合是其中的规范做法，而不是例外。系统的所有组件都将根据 SOA 进行集成和连接，IT 系统的所有部分都在 SOA 内工作。
转换业务：对服务进行动态的事件驱动的重新配置
在 SOA 成熟的最后一个阶段，业务与 SOA 完全集成，达到了这样一个程度：所有合适的业务活动都被视为服务，可以最终在技术体系结构中对其进行建模、分析和实例化。达到此阶段需要业务部门进行大量的工作和投入；不过，达到此阶段后，业务将从面向服务的体系结构获得最大的回报。