在企业架构（EA）的背景之下，面向服务架构（SOA）不仅仅是一个集成框架。它是一个定义视图，企业架构可以从代表异种业务功能的同种软件服务中进行收集它。在这个简单的思想背后，却有一个相当规模的实施限制性因素的存在。通过竞争 SOA 视图与实施，使这一点看起来更加明显。同时，私人 SOA 技术通常用于解决集成性问题，它们的使用都得到了良好的定义，专一的企业 SOA 动机很稀少，并且很少能够成功。这是由于端到端的进程 SOA 框架现在还没有得到广泛的应用，一些属性框架则除外。

面向服务架构（SOA）可以从不同的视角来查看。基本上，它是用于描述松散耦合系统的结构性形式。当与方法学指南和一个支持性软件相联系时，这些软件可以识别业务功能，设计匹配的系统界面或者服务，并通过操作性生命周期来支持这些服务，SOA 在笔者的观念中，就是改进业务活动和效率的一种总体方法。

尽管将 SOA 当作解决系统界面问题的一种当前方法，它所能做的远不止于此。通过使用支持业务移动性能的软件服务，框架鼓励方案的集成性设计。这些服务代表了不相联系的完全不同的功能性单元，它们之间一般是没有关联的。通常情况下它们实施大多数人认为是 服务 的业务功能，例如“检查一个账户程序”。“订一间房间”，但是它不是将调用嵌入到实施它们的软件构件之中，而是定义事件发生时，服务之间如何进行交流。该方法需要业务架构去查看、识别和定义服务（它通常不同于业务进程）以及 SOA 集成架构本地联系这些服务和事件到一个所谓 乐队 的进程之中。

在发现，分析，设计，实施和维护 SOA 功能的过程之中，有大量的 SOA 模型与逻辑性框架会随着大量的软件实现而存在。本文评审了采用最广或者引用最广的部分，从理论上重要的模型和框架，到当前可得到的销售商 SOA 实施方案。

SOA 引用模型

OASIS SOA 引用模型（SOA-RM）定义了 SOA 元素和目的及其相关关系的词汇表。模型由一个元素词汇，以及一些关系图组成。它提供了一个逻辑性的基础，在这个基础之上可以构建引用架构，实施框架以及软件产品。在 SOA 成素时，SOA-RM 会随着标准化术语语义的目标而得到创建。SOA-RM 的描述性部分并没有超出定义元素多少，例如下面的一些：

1.服务 是让进程或者实体使用的行为的集合。

2.服务描述 是让一个潜在客户去决定服务是否可用，并能促进 调用 所需信息的规格。

3.广告 是一种向潜在客户传递服务存在性信息的方法。广告使得人们有可能 发现 服务。

4.数据模型 是与服务消费相关系的一系列信息项目 。

5.协约 提供了管理服务 调用的一种语义的，逻辑性的限制性规则。

6.服务政策 描述了服务消费者或者提供者所必须坚持或者提供的原则和义务。

SOA-RM 图定义了如图 1 所示的之类元素背景组。

图 1. 政策与协约背景组的引用模型图

SOA-RM 应该是 SOA 概念，元素以及逻辑性分析视图的一点。它除了具有教育性价值之外，SOA-RM 还是筛选 SOA 框架，模型，方案与产品的一种固定引用方案。

SOA 引用架构

SOA 引用架构（RA）由一系列的模型和规格组成，这些模型和规格定义了一个构建于其上的逻辑性实施平台。该平台对于 SOA 的意义在于使用普通的域架构模型和视图，来将 SOA-RM 元素，与来自 IT 架构的概念联合起来。它使用一种层次化的方法，来影射 SOA-RM 到普通的 IT 架构元素，这个过程是根据它们的实施，角色与用户而进行的。它还引入了其他的以及更多的 SOA 平台实施概念以及元素，包括企业服务总线（ESB），演练与演示，以及服务层（SL），它是每一次实施过程中最常见的方面。SOA-RA 由一系列的富有声誉的模型组成。

信息架构

通过使用系统与过程包，信息流，信息架构模型实现了 SOA 信息环境架构以及交流。刚开始时，它显示了典型的 EA 规则，例如企业安全和系统管理，它通常是关键的 SOA 实施方面。然后它联合主要的 SOA 生命周期包和规则企业组成包，来显示它们在环境之中的匹配情况（图 2）。

图 2. 引用信息架构

程序架构

程序架构视角使用服务层，来追踪信息架构包与子系统之中的 SOA 平台构件（图 3）。这里提到的层是分布式的 SOA 程序架构层与企业系统和过程层。

该模型可以用于企业程序和数据架构分析，服务构件和业务过程分析，架构性影响分析，项目规划，以及系统管理规划活动。它还强调了 SOA 作为框架扮演的基础性角色，并显示了它对公司的信息系统和管理服务所拥有的潜在性影响。

图 3. 引用程序架构

基础架构

基础架构视图显示了创建、构建、维护以及优化 SOA 平台构件所需要的基础服务。一个典型的销售商产品可能关注于一个或者少数几个模型包。

除了在企业架构分析和实施项目阶段应用一个规划和平台设计模板，该视角还是一种工具，可以识别已存在的基础资源和资源组，它们可能受 SOA 实施的影响。当作出框架和平台抉择时，以及在销售商产品分析以及选择活动期间，这一点也很有用。

图 4. 引用基础架构

当这些引用架构一起考虑时，就很容易看出 SOA 是怎样通过企业系统，实践活动及过程，以决定 SOA 系统实施期间，哪些业务和 IT 资源受到了影响。这就是为什么软件销售商广泛采用 SOA-RA 模型，来设计和销售他们的产品和框架，以及企业和项目架构师为什么使用它，来设计企业和系统架构的逻辑性和物理性模型的一个原因。除了这些，SOA-RA 还是一款非常有价值的工具，去查看 SOA 在企业架构框架方面的角色。

实施技术标准

随着 SOA 的概念得到了越来越多的推广，它管理概念的列表也在不断增长。但是SOA 核心的标准，在第一次 XML 网络服务流行之后就一直没有什么大的变动。这些标准不是为 SOA 创建的，而是用于处理那时所存在的具体集成性挑战问题。

标准一般都与 SOA 相联系

其中有一些标准需要“SOA 基底标准”的状态：

XML（可扩展标记语言），以一种数据代表，转化，以及存储格式

XML 方案，一种服务定义及确认语言

SOAP，一种传递信息的标准（通常来说，简单的对象访问协议）

WSDL（网络服务描述语言），一种界面定义语言

XPath，XQuery 以及 XSLT 数据元素引用，查询以及转化语言（XML Path、XQuery 和 XSL Transformation）

UDDI（通用描述，发现以及集成），一种服务发布注册和发现标准

在 SOA 出现之前以及稍后一段很长的日子内，IT 界一直在位出台一种完美的基础标准而努力。尽管他们仍然在将所有 SOA 系统集成到一起这个领域内苦苦挣扎，但是已经有一些新出现的标准，它们关注实施活动更加广泛的活动，包括过程建模，服务信息架构，以及治理。这些新标准的一些提供了基底标准的顶级层次。其他的一些简单地规范了基底标准的使用。还有一些扩展了 SOA 平台的选择方面。尽管 SOA 附近标准浮动的总体数量会超过一百（根据 Forrester Research，2007），但是其中只有下面的一些技术已经成熟，并且得到了广泛的接受：

1.WS-Basic Profile 是基底标准的分类，例如 SOAP，UDDI 以及 WSDL，这可以确保它们之间的可相互操作性，并定义了操作信息的逻辑性服务基础

2.WS-Security 是一种交流协议，通过对 SOAP 信息执行集成签名，加密，以及其他的安全性以及隐私性策略，它确保网络服务的私密性以及整体性。

3.XML Signature 定义了 XML 以及非 XML 服务的数字签名实施，以确保它们的认证

4.XML Encryption 实施了 XML 以及二进制内容的加密，这些内容可以通过服务调用来得到传递

5.BPMN 以及 WS-BPEL 是可见的建模注释以及声明和执行语言，它用于描述基于网络服务的业务进程

进程生命周期

SOA 仍然缺乏一个规范的引用实施生命周期，而销售商想要用他们自己的理解来填补这个空白。它们中的大多数都可以实行，但是却不会超出如图 5a 和 5b 所示的演示太远。

图 5a. 进程生命周期代表的范例

图 5b. 进程生命周期代表的另一个范例

尽管 OMG 及 OASIS 之类的标准实体进行了授权，但是一个引用 SOA 实施生命周期一般是循环的，并且包括三到五个阶段，以及十个或者更多的规则。图 6 中的生命周期模型充满了普通的活动，这些活动可以在过程阶段中发生。就算该生命周期图引入了过程规则，例如分析，架构和集合，SOA 实施可以有大量的同等体。您应该考虑一下最后统一的 SOA 实施进程，并处理它所暗含的意思。

图 6. SOA 系统实施生命周期更加完整的实现

实施生命周期模型（图 6 ）是一种关键性的工件，它向 SOA 规划者提供了 SOA 实施进程以及实施活动治理的视角。在接下来的部分中，笔者将会应用这个生命周期模型，以组织 SOA 实施框架以及生命周期产品。

实施框架

一些由 SOA 销售代表，私人顾问以及独立 SME（对象事务专家）组成的开放标准团队，通过实施 SOA 引用架构，来将业务和技术性框架概念化。SOA 引用架构的基础是如此的广泛，以至于一个典型的框架不能包含它的整个生命周期，而只是关注于选中的阶段或者方面。实施框架主要是为那些想要理解 SOA 构建框架的企业及集成架构师和开发员准备的，它们还可以指导 SOA 软件销售商设计他们的团队。下面是一个关于笔者认为由最基础框架组成的范例，不分先后次序：

SCA

服务构件架构（SCA）试着将提供服务和 SOA 系统的组成部分统一起来。它的命令包括通过为可执行业务进程的潜在晚期集合使用不同的交付技术，来适应已存在的程序和信息及服务构件的实施。

为了创建一个流线型的 SOA 集合进程，服务不得不模仿关键的功能，得到统一定义，并且已经可以使用。SCA 假设功能-服务形式的排列，因为它关注于服务构件、界面、服务、集合服务以及 SOA 方案的组成方面。框架解释了怎样去定义、描述和物理性地实施这些和其他的逻辑性架构和它们之间的联系，也就是所谓的 线。它还概括了称为 SCA 域 的逻辑性配置和管理环境（图 7）。SCA 并没有涉及到不同的层次；但是，它们代表了基于 SCA 实施的潜在性附加元素。

图 7. SCA 框架

SCA 是一种声明性的科技，可以适应各种不同的物理性构件实施以及包裹选项。它支持多种构件实施语言，包括 Java?，BPEL（业务进程扩展语言），C++，SQL，JavaScript 以及 XML，加上绑定网络服务之类的构件，Java Messaging Service（JMS），CORBA/IIOP，以及 Database Stored Procedures，还有主界面定义标准，包括 WSDL 以及 Java 界面格式。适应构件和基础来扩展该列表的方法也包含在框架规格之中。SCA 构件是不关注基础的，这有助于开发的构件及基础。方法还支持将一些 SCA“引擎”集成到企业服务总线（ESB）之中。

在所谓的遵循 SCA 的产品之中，有 Oracle BPEL Process Manager（OBPM）以及 IBM? WebSphere? Process Server。

图 8. SCA 生命周期

SDO

SOA 是交换业务信息的统一方法。该前提需要一个新的架构与方法，以适应大量不同种类的界面选择。服务数据对象（SOD）标准被设计成通过为数据代表和数据对象的传递性创建一个普通的模型，从而为在构件交流中交换数据提供了一个基础。SOD 标准精化了一系列自我封装的数据对象，这些对象可以由服务构件控制并在服务调用的过程之中进行交换。简单来说，SDO 标准改进了 DTO（数据转移对象）、“价值对象”，POJO（简单 Java 对象）、ADO（活动数据对象）、RowSet、DataSet，以及其他的在 SDO 之前提供的数据框架。

SDO 框架之中的固定构筑是 数据对象容器，它由数据对象以及主要的类型成员组成。一个数据对象架构代表了一个图，除了成员元素，它还封装了对关于每一个元素类型及使用元数据的引用。另一种 SDO 构筑就是 服务信息对象（SMO），它模仿了服务之间信息交换的过程。就像 SDO 标准一样，SMO 是一种封装了数据与历史引用的集合体。SDO 框架包括了转移对象数据所用的一些 API，SDO 产品与 SOA 团队可能想要决定实施这些 API。它包含了连接的及非连接的方法，两种方法对于基于服务的松散耦合的架构来说都是不可或缺的。

图 9. SDO 生命周期

SDO 是一种关注于数据转移性的标准。它在很大程度上补充了其他的 SOA 实施框架，并且很长时间内被 SOA 介质所采用，例如 Aqua Logic 和 IBM WebSphere，以及区域中其他的销售商工作，例如 SAP，IONA 及 Sybase。值得注意的是 Microsoft? 拥有它自己带有相似特征的技术：ADO.NET。

JBI

Java? 业务集成（JBI）是一种开放性的框架，用于设计一种模块化的信息基础。它在 SOA RA 之中的孪生兄弟是企业服务总线（ESB），它通常假设 SOA 架构的连接性功能。JBI 定义了一个信息运行时是如何实现在 SOA-RM 中获取的 SOA 需求的，例如服务定义与发现，服务绑定的传递协议，基于规则的交流，信息路径，以及信息内容转化。框架处理了信息运行时的逻辑性故障，包括他的构件框架，信息路由器，因为它描述了构件部件及连接性逻辑。它包含了引用实施模型以及界面，JBI 的产品或者室内 JBI 方案必须实施这些模型与界面。

JBI 之中的固定构筑是 服务容器对象，它通过信息路由器来支持插件之间的交流。框架的关键特性就是它的 信息层。不管交流协议与格式的不同，信息层可以确保可插入的构件架构（见于图 10）。

图 10. JBI 框架

JBI 拥有架构性及教育性的价值。它的方法通过了时间的考验，因为它已经由多种产品及通用实施执行过了。例如，一般习惯于实施系统集成（例如，IBM? WebSphere? MQ 与 Microsoft? BizTalk）的合法信息掮客，拥有与 JBI 相类似的特征。尽管公司一般倾向于通用 JBI 实施（笔者并不推荐这样），像 Oracle 这样的销售商（现在它已经包括了属于 Sun Microsystems 的产品 ），已经使用 JBI 作为它们的 ESB 软件的基础。JBI 已经适应了作为 OpenESB 项目的基础。

图 11. JBI 生命周期

Windows 交流基础（WCF）

这个来自 Microsoft 的框架是其 .NET 运行时和开发平台的扩展。通过使用 WCF 来实施 SOA，.NET 开发环境类，方法，以及其他的成员架构都被宣布为 .NET 汇编器“可服务的”。生成的服务然后可以使用 Windows Activation Services，Internet Information Server 或者作为通用处理器汇编到 Microsoft? Windows? 服务或者 Windows 程序之中。

框架的主要逻辑性单元是 服务类，末端点 以及 主机环境。服务类 代表了一种支持 SOA 的 .NET 类文件，在汇编时，该文件可以部署到任意的 Microsoft 服务主机之上。末端点 是一种界面声明。它由协议，地址以及绑定部分组成。它们的作用分别是 WSDL 服务和数据界面定义，服务位置 URL，以及访问协议和信息交付规则。WCF 支持多种协议，其中有 SOAP/HTTP，以及确认，例如对于同步交流和非同步交流的 SOAP/TCP，SOAP/MSMQ 和 SOAP/Named Pipes。实施不同绑定的多个末端点可以由服务类来定义（图 12）。

图 12. Windows 交流基础框架

从 SOA 点的观点来看，WCF 是一种服务友好实施的编程模型以及可执行基础。除了这些，它还是正统技术与新微软技术之间的统一和交互性平台，这些技术例如 DCOM（分布式构件对象模型），Microsoft 信息查询（MSMQ），ASMX，.NET 远程，它还可以作为微软及非微软网络服务之间的交流平台。框架扩展了所有的 .NET 语言，并作为设计和运行时构件包含在所有当前的微软操作系统之中。

图 13. Windows 交流基础生命周期

OASIS SOA 方法

业务排列是驱动企业 SOA ，并将其与合法技术集成项目相区别的一个因素。OASIS SOA 方法是一种使用 SOA 来更好理解排列业务与 IT 的过程和治理框架。框架的目的在于分析业务目标，查看目标并实现可以赋予和作为服务实施的功能性方面。这种类型工作的背后，是将已存在的过程分解，以创建基于关键业务功能的同类业务架构。方法就是通过渐渐加强动机限制，并不断地将其活动与核心业务目标相排列，来逐步改进设计和开发业务架构。

方法基于一个轻量级的过程，该过程致力于 SOA 系统实施的初始化与精化阶段流线型服务探索以及功能性设计活动（图 14）。方法生命周期被划分为三个阶段：Pre-work，Event 以及 Complete Architecture。主要的交付工件是 Service 和 Actor Relationships Models，Service Agent 与 Service Interactions ，还有服务治理。因为得到正确的服务是任何 SOA 实施的最为关键的一个方面，虽然这种方法富有争议，SOA 团队不应该忽略 OASIS SOA 方法之类的技术，该技术应该得到联合使用，或者作为企业架构进程的一个输入。

图 14. OASIS SOA 方法生命周期

SMART

面向服务迁移和重用技术（SMART）是分析、规划、以及管理所谓合法资源转移到 SOA 形式架构的过程框架。它追踪大多数关键性的 SOA 实施问题，例如服务排列，以及企业业务架构，技术评价优于转移，SOA 实施生命周期活动的治理（服务探索，设计，拥有权，销售，SLAs，以及监控），还有组织变更管理。

框架完善了主流企业架构以及方案实施方法学，及其特定 SOA 的任务与工件。在 SMART 的心脏地区是信息收集、筛选以及业务架构工件分析的序列性过程。它的开头是引出关于源环境及目标环境的背景性信息，它可能包括已存在的构件与业务进程，功能性与组织性的架构和服务，以及目标架构方案蓝图。在执行分析和映射之后，接着是交付 Service Migration Strategy 文件。其中还包含有信息收集和系统分析的指南，例如问题调查，活动映射，以及模板等等（图 15）。

图 15. SMART 生命周期

如果，在阅读完以后，您感到实施框架中的共同点太少，或者您意识到了其他的技术拥有相似的特征，那么您是对的。许多新出现的方法已经存在，它们中的一些已经投入了使用，另外一些则没有。该列表与提供一个代表性范例，以填补 SOA 产品之间空白的想法相一致，接下来的部分将会讨论到这一点，而 SOA 方法基础出现在 RA 与 SOA-RM 之中。笔者希望您发现它的教育性意义，所以让我们继续下一个章节“平台与产品提供”，完成这一部分的学习。

平台与产品提供

通过共同授权 SOA-RM、RA 以及基底技术标准，自由专家、产品销售商，以及服务提供者就他们之间存在的差异进行了协商，行业关注变成了实施的框架。这就是关注热度最高的地方，这并不令人吃惊，因为大多数的公司在 SOA 出现之前，就已经掌握了它们的产品提供以及提供的技术集成服务。结果，销售商会有选择地支持的实施框架以及新的技术，它们提供了与现存产品和战略适应最佳的选项；但是，一个 SOA 团队不应该害怕使用一种不知名的产品或者框架，将会损害一致性。这是由接受 SOA-RM、RA 以及基底标准（见于图 16）来确保的，它反过来，促进了（在一定程度上）SOA 产品的集成交互性。

图 16. SOA 标准一致性层次

销售商坚持基底标准和框架，以达到最大程度的一致性；尽管如此，它们实施通用特性，以获得竞争上的优势。这些组织中有一些声称一个 SOA 销售商实际上提供了全部的 SOA 产品。IBM，Microsoft 以及最近的 Oracle 已经开发了“即广且深”的实施框架，而其他的机构拥有好的特定点方案，通过一些开放标准，例如 XML 和 SOAP ，来与其他 SOA 销售商的产品相交流。例如，根据 Gartner（2009），SOA 软件提供了 SOA 治理自动化的实施方案（治理，信息架构，以及信息引用架构的服务质量（QoS）层），同时依赖于软件合伙人来实施软件架构基础和程序基础。

来自 IBM

尽管 IBM 公司在最近的几年时间里重新调整了它的 SOA 策略，但是它的核心支持产品并没有发生什么大的变化。也就是所谓的“灵活 SOA? 方法”，该方法代表了一种业务架构中心的进程，该进程拥有多种记录的业务和技术进入点，并被一系列的正统 IBM 技术、框架和进程所支持。其中最中心的产品是 Java? Enterprise Edition（Java EE）技术以及 IBM WebSphere 和 IBM? Rational? 开发及执行软件，还有大量的插件与工具。

IBM SOA 方法包括了指南和工具，您可以使用它来查看、建模、定义、描述、部署、执行和管理服务系统及业务进程。它还有助于您适应不断变化的 SOA 系统场景：小型或者大型的，本地的或者分布的，单个“大集团”项目中交付的，并从头交付或者从 COTS 构件集合。IBM 将其称为一个“SOA Foundation”。以支持 SOA 生命周期。图 17 显示了作者对它们之间如何相互磨合的理解。

图 17. IBM 技术所支持的 SOA 系统生命周期

来自 Microsoft

Microsoft 的完全不同的 SOA 方案就是人们所熟知的“软件作为一个服务”或者 SaaS，它是通过因特网来部署的。关键在于关注客户端的构件以及服务，这可能会产生大量的客户端构件，Microsoft 客户将会在过去的十几年间部署它们，并想要完全使用它们作为“云计算”，它组成了大量功能强大的桌面与便携机，在“轻度计算”模型之中它们一般都是很轻松的。不像其他的 SOA 销售商一样，微软的关注点一直放在私人开发员身上。它的 SOA 方法很好地反映了这一点。值得注意的是，微软并没有发布它自己的生命周期中心的 SOA 视图。相反，它的“软件+服务”版本全是关于技术家族的，其客户可能会选择其中之一来创建他们自己的方案。

Microsoft 的 SOA 战略围绕着四个包：.NET 框架，BizTalk 服务器，Windows Communication Foundation（WCF），以及一个较小的程度上，Windows Presentation Foundation。所有这些都没有清晰地实施任何讨论过的框架；但是，它们支持多种基底标准，包括 XML，WSDL 以及 SOAP 以及“WS-*”（“WS-*”一般会引用由行业标准实体和成员开发及发布的一组网络服务标准，这些实体和成员包括 W3C，OASIS，IBM, Microsoft，Oracle，Adobe 以及 Novell）（图 18）。

图 18. Microsoft 技术所支持的 SOA 系统生命周期

来自 Oracle

Oracle 也开始提供跨越整个 SOA 生命周期的产品。

它所提供的系列组成了公司自己的资源，以及其他一些公司的资源，这些公司包括 BEA 系统以及 Sun Microsystems。Oracle SOA 产品被分割为 SOA 实施和 SOA 治理两部分，其代表分别是 Oracle SOA Suite 以及 Oracle SOA Governance 系列的技术，其开发构件仍然坚持留在 Java Enterprise Edition（JEE）类别之上。

系列包括了 SOA 集成和分析的大多数方面，包括其享有盛誉的 ESB - BPEL Process Manager，业务规则和事件管理服务，以及集成和开发工具。其文献由规划的模型和模板，操作设置，以及控制 SOA 实施所组成。大多数来自 SOA Governance Suite 的重要文献 ，是 Maturity Model 以及（BEA） SOA Framework 文献。SOA Governance 使用 SOA 处理自动化的工具来支持 SOA 系列。Enterprise Repository，Web Services Manager，Service Registry 以及 Enterprise SOA Management Pack 只是其中的一部分（图 19）。而且，尽管它的产品混合看起来没有其他的多，但是其产品拥有更少的功能重叠，同时交付 Java EE 框架所支持的最高层次的普通性。

图 19. Oracle 技术支持的 SOA 系统生命周期

来自其他的销售商

除了“三巨头”销售商的产品，对于特定的实施或者治理方面，SOA 实施市场还有其他一些很好的解决方案。人们可以轻松找到一些功能强大的 SAB 实施方案，企业和服务注册以及存储库，以及系统操作和管理包。对于服务集成和暂时性服务数据存储来说也有一些产品。

笔者鼓励的是在包装软件市场上的开发。一些 ERP，ERM，CRM 及其他的“M”和“P”销售商，最近在从事 服务 的概念，而更多的销售商则是在做相同的事情。有一些甚至已经远至提供与核心产品想绑定的完整的 SOA 集成框架。该领域的领导是 SAP 及其 NetWeaver 范围，它是由销售商作为 SOA 介质优化 SAP 末端服务来销售的，它还可以用于组织其他的服务。这些产品有机会增长它们的“M”与“P”根，因为它们可以用于构建企业范围 SOA 的框架。图 20 显示了 Adobe?，SAP，HP 与其他销售商 SOA 产品的产品。

图 20. 其他销售商技术支持的 SOA 系统生命周期

SOA 引用表

这个系列的初始安装（见于“本系列更多内容”）的结论是，呈现 TOGAF 框架的层级架构。该表区分了架构性与过程元素，并给出了大多数关键性元素的概述。

为了让 SOA 与 TOGAF 置于相同的位置上，图 21 中的模型对 SOA 应用相同的格式。该系列的第三个安装与最后一个安装，将会引用这些模型，以协调两种框架的相同处与不同处，并将它们汇编到一个公共的实施方法之中。

图 21. SOA 引用表