与语言无关、基于组件的面向服务的体系结构 (SOA) 编程模型简化了实现 Web 服务以及将其组装到解决方案中的过程。使用编程模型，非编程人员可以在没有掌握复杂的技术的情况下使用现有的 IT 资产。它满足了解决方案设计人员和业务分析人员的需要，提供了更高级别的抽象来隐藏实现技术之间的差异，同时还提高了业务可靠性。
为什么需要基于组件的编程模型？
推动 IBM 的 SOA 编程模型的远景依赖于两个重要的观察结果，请看以下两段引言中的精辟描述：
“根据时髦词语设计 (Design-by-buzzword) 是一种常见的情况。至少在软件行业，这种行为或多或少与缺乏对一组给定的有用体系结构约束的理解有关。换句话说，在选择要重用的软件体系结构时，设计人员并没有真正弄清楚这些体系结构之所以好的原因。”
——Roy Thomas Fielding，“Architectural Styles and the Design of Network-based Software Architectures”（请参阅参考资料以获得指向此研究报告的链接）。
这个问题可以通过将详细了解体系结构约束的原因的人的经验融入一组模式、编程构件和工具来解决。
第二个重要的观察结果同人以及人与技术的交互有关：
“创建面向服务的体系结构 (SOA) 意味着重新考虑当前用于构建系统的实践、组织的技能，以及团队成员协作的方式。面向服务的作用在于通过组装不同的应用程序来开发解决方案，SOA 是体系结构样式，强调独立服务提供者的松散耦合。”
——A.W. Brown 等，“Realizing service-oriented solutions with the IBM software development platform”（请参阅参考资料以获得指向这篇文章的链接）。
基于 XML 的 Web 服务标准使人想到了基于组件的编程模型的某些方面。诸如 Web 服务互操作性 (WS-I)、Web 服务描述语言 (WSDL) 和 Web 服务策略 (WS-Policy) 之类的标准尝试创建与平台无关的抽象和统一的框架来进行业务软件集成。而 Web 服务的价值来源于在 SOA 中使用它们。
大多数关于 Web 服务的资料都集中于互操作性协议和服务接口及其使用。而本文把重点放在用于实现服务并将服务组装成解决方案的编程模型上。组件模型简化了构建和组装服务的过程。
良好定义的组件应该支持生态系统中的各种用户角色——例如业务分析人员、集成开发人员、适配器开发人员和解决方案管理员——通过实例化、使用、组装和自定义符合用户目标、技能和概念性框架的不同组件类型，来创建面向服务的应用程序。（注意：编程人员作为专业人员和重要的软件开发角色仍然存在，但并非每个人都必须成为专业编程人员才能高效地使用 SOA 构件。）
Web 服务标准中的组件模型明确地定义了组件和组件类型，以及定义和构造组件的方式，以便由适合角色的工具重用和操作，这与我们对技术使用中人的方面的观察结果是一致的。
基于组件的编程模型有许多好处，最显著的好处是可以减少复杂性。没有哪个角色需要了解实现功能的所有方式或所有的系统接口。公开给每个角色的复杂性是有限的，而公开给开发人员角色的复杂性有助于他们使用适合于其任务的工具以定义良好的方式开发解决方案。
组件模型必须是抽象的，并且与语言无关，因为它的作用在于隐藏技术细节和差异。
组件模型还必须简化非编程人员组装和定制“解决方案部分”的过程。因此，与组装和调整有关的组件（或组件集合）的所有方面必须以与语言无关的方式显式地声明，这样无需编程人员修改源代码就可以通过工具操作它们。我们使用 XML 来表示这些声明。
SOA 的确切特征还有待探讨，不过一些关键的方面已经得到广泛承认：
- SOA 是一种分布式组件 体系结构。不管在企业内部还是企业外部，SOA 组件都是透明的，并且可以通过一系列统一支持的、可互操作远程过程调用和消息传递协议来统一访问。接口定义标准支持开发人员工具之间的互操作性。网络上 (on the wire) 协议互操作性——相对于代码可移植性——是 SOA 组件的中心部分，支持统一访问和平台独立。调用方不知道组件的基础实现技术，例如 Java™ 2 Platform、Enterprise Edition (J2EE)、Microsoft® .Net 和 PHP。
- SOA 组件封装功能，并支持通过业务分析人员和业务模型建模的抽象级别的重用。这使 IT 功能和它所支持的业务功能之间的映射更加直接，从而提高了可靠性。
- 声明性的、计算机可处理的约定允许第三方访问 SOA 组件提供的服务。这些约定显式地声明功能性特征以及非功能性（服务质量或 QoS）特征和需求。SOA 组件使用 WSDL 记录它们的操作。还可以使用用于 Web 服务的业务流程执行语言 (BPEL4WS) 来定义组件的有效操作序列。
- 可以动态地发现、选择、绑定（通过其声明性属性）和集成（使用组合机制，例如本系列第 3 部分“Process choreography and business state machines”（developerWorks，2005 年 7 月）中描述的组合机制）SOA 组件。
组件实现和专用组件类型
开发人员可以选择使用 J2EE、PHP 或其他工具实现基本组件。作为一种编程模型，从根本上讲，SOA 更多地关系到与组件的交互以及如何将这些交互集成到复合组件、应用程序和解决方案。
我们的编程模型还引入了一些定义良好的组件类型，可以建模开发人员生产和部署到解决方案中的常见构件。其中包括 Plain Old Java Objects (POJOs)、Business Processes (BPEL4WS)、Structured Query Language (SQL) 服务、Adaptive Business Objects、通过 J2EE Connector (J2C) 体系结构资源适配器访问的 Customer Information Control System (CICS) 程序、使用 SAP 的业务应用程序编程接口的应用程序、J2EE 无状态会话 Bean 和 IBM MQSeries® 应用程序。
因为在性质上 SOA 组件模型是虚拟的，所以许多 SOA 组件自然支持多种实现技术。另一方面，不同的实现技术更好地适合于不同的任务。为了提高透明度，我们引入了服务组件类型的概念，每种类型都适合于具有特定技能、执行特定任务和使用特定工具的开发人员。对于查询，编程人员实现了一个 SQL 文件和一个包含一组 XQuery 语句的文件；对于文档转换，使用为此任务优化的工具实现 XSLT 样式表等等。不需要知道 Web 服务、Enterprise JavaBean (EJB) 或其他组件是在部署时生成的，这是因为总体结果是作为通用 SOA 组件公开和使用的。
编程人员构建一种适合于该任务的特定组件类型，集中于要解决的问题和要使用的工具，而不是结果构件。SOA 开发工具应该集中于开发人员的技能和他或她理解的概念。后续文章将简要介绍一些组件类型，通过三个完全不同的示例——Java 对象、信息管理系统 (IMS) 事务和 SQL 语句——演示如何将任何实现技术映射到公共 SOA 组件模型，同时满足特定开发人员的需要。
组合
虽然可以使用特定于平台的技术实现 SOA 组合，但是新的以 SOA 为中心的组合类型可以自己实现，而无需转换为另一种编程模型。
使用组合模型，可以发现具有所需的接口和所需的基础设施 (QoS) 策略的服务，并且将这些服务聚合到新的服务、模块和解决方案中。可以组合这些新的服务。
我们的方法统一了创建和访问业务逻辑的范型。我们的 SOA 编程模型比现有的编程构造复杂，隐藏了实现技术之间的不同。在这种模型中，组件组装到模块中，而模块又可以组合到解决方案中。组件公开了可以通过可寻址接口调用的接口。接口是使用 WSDL、Java 或其他语言描述的。实现可能有无法解析的对所需服务的引用，这些服务是执行之前由连接在一起的组件提供的。可以由解决方案集成人员或解决方案组装人员使用适合于角色的工具进行连网操作，他们可以运用可能不为最初开发这些组件的人所知的企业策略和企业服务总线 (ESB) 部署拓扑知识来进行工作。
在没有进行编程的情况下自定义
不可能始终在没有进行配置、自定义或调整的情况下按原样重用服务。在需要更改时，当前的技术发展水平是修改源代码。然而，是否能够交付可以大量重用的组件在很大程度上取决于组件适应其使用环境的功能。SOA 编程模型应该支持构建“编程人员”可以在没有修改源代码的情况下进行自定义的服务和模块。当使用组件的编程人员与构建组件的编程人员不在一个单位时，这一点尤为重要。
基于组件的 SOA 编程模型提供了几种在没有进行编程的情况下自定义组件的机制。
旨在重用的组件可以打包成具有可变点 (points of variability) 的模板，在将模板放入解决方案时可以对其做一些调整。这种适应性是我们的编程模型最重要的部分，此外，编程模型还包括规则语言和相关工具，用于给新的用户提供自定义功能。
中介主要用于处理动态消息。通常可以在没有进行编程的情况下组合中介。作为一个多协议构造，企业服务总线发挥了重要的作用，可以将服务组件组合在一起进行无缝交互，另外，还允许在消息的路径中插入称为中介 的组件，以在不改变现有端点的情况下代理服务之间的交互，从而在主要方面解决整个企业范围内的问题，例如审核、记录、路由、不匹配接口的适应性、等效组件的增量替换和安全性。
SOA 编程模型的另一个好处（来源于前面提到的特性）是能够在软件生命周期的不同阶段用一个组件替换另一个组件。通过将声明的接口延迟绑定到支持这些接口的实现可以做到这一点。企业为什么需要替换功能单元，有许多方面的原因。其中最重要的原因可能是减少在大型企业中管理更改的困难。以增量的方式引入更改并且通过遵循定义的接口限制其影响可以提高灵活性。这种做法也适合于松散耦合，而松散耦合常常是大型组织的特征。此外，使用服务组件，有不同的技能、需求和时间安排的组可以以人力资源和系统资源两方面的效率都最高的方式在 IT 基础设施中协同工作，这样企业就可以快速地响应业务级的更改，从而使企业大大获益。
组件定义
我们的 SOA 是由以下规范定义的：
-
服务规范 以组件提供和使用的一组服务的形式提供了组件的视图。它由以下三组规范定义：
- 接口，通常是 WSDL
portTypes。
- 策略，记录 QoS 属性，例如事务行为和安全性。
- 行为描述，例如 BPEL4WS 抽象流程。另一个例子可能是统一建模语言 V2 (UML2) 状态模型，该模型指定了哪些操作对不同的状态和操作所引发的状态事务是有效的。调用方可以通过状态模型计算有效的操作序列。
-
服务组件实现 是由以下四组规范定义的：
- 提供的服务规范。
- 需要的服务规范。
- 可以在组件上设置以调整或自定义的属性。
- 为此提供基本支持的属性；更复杂的方案使用可变点和对自定义组件的外部调用。
- 对所有实现实例都保持不变的容器指示（策略）。
- 定义组件实现的实现构件（例如 Java 类、BPEL 文档或 XSLT 规则集）。
-
服务组件（实例）由以下规范定义：
- 名称。
- 服务组件实现。
- 实现的任何属性的值，设置用于调整实例。
- 任何服务的规范，解析实现需要的服务规范。它们可以是连接组件实例的“网络”，也可以是在运行时执行以查找组件的“查询”，所查找的组件实现相关接口，具有相关的 QoS 策略，并且匹配指定的行为（例如抽象流程或状态模型）。
有两种定义 SOA 组件的基本方法。这些定义可以通过开发工具生成，也可以由开发人员手动创建。
第一种方法是控制文件，顾名思义，控制文件即关联或联接组件的所有部分的文档。例如，控制文件可以引用 WSDL 定义（提供的接口）、实现组件的 Java 类（实现构件）或相关的策略文档（策略断言）。 它们可以是对文件系统、类路径、源代码管理系统或 Web URL 的引用。控制文件方法将多个单独开发的构件聚合在一起组成组件。应用程序开发工具可以帮助定义控制文件。
第二种方法是使用 pragmas，指定相同信息的语言元素，但是包含在单个源文件的主体中。Java 方面的支持正在不断增加（例如，JSR 175 中的 XDoclet 标记），以用 Java 语言编写这些批注部分。但是这种方法尚不支持其他等同的有效 SOA 组件实现技术（如 SQL 或 XQuery 语句集）。每种组件类型都有用于其实现构件的相关源文件格式，例如 Java 文件、状态机或 SQL 文件。IBM WebSphere® Rapid Deployment 中的批注支持可以生成所有组成包含 pragmas 的源文件中的组件的单个元素。例如，Java 源文件中的结构化注释指示哪些 Java 方法将成为所生成的定义组件的服务接口中的 Web 服务操作。
总结
基于组件的编程模型——由面向任务的工具和运行时基础设施支持——是快速采用 SOA 的关键。借助于期望的优势（如新的软件重用方法），专业人员（不必是编程人员）可以在新的业务需求出现时使用 SOA 组件创建新的业务解决方案和改写现有的业务解决方案。