IBM® 面向服务体系结构（Service-Oriented Architecture，SOA）编程模型使非程序员可以创建和重用 IT 资产，而不需要掌握 IT 技能。该模型包括组件类型，布线，模板，应用程序适配器，统一数据表示和企业服务总线（Enterprise Service Bus，ESB）。本文是系列文章的第一部分，该系列文章介绍了 IBM SOA 编程模型，选择、开发、部署工作所需的内容，以及建议的编程模型元素。本文陈述的内容考虑了使用该模型的开发人员可能具备不同的技术水平和工作角色。
SOA 编程模型系列
对于任何独立程序员来说，有效的掌握和应用飞速增长的软件技术、实践、工具和平台，变得越来越困难，当然更不用说非程序员了。然而，如果业务流程转换能够成功进行，很多的非程序员就可以使用现有的 IT 资产来进行他们的工作，而不用去学习繁琐的底层技术细节。本系列文章描述了一个新的面向服务体系结构（SOA）编程模型，该模型实现了业务关系的分离，因此企业中具备不同技术水平和工作角色的人，即使不是专业的 IT 人员，也可以在软件开发生命周期每个阶段创建和使用 IT 资产。这可以显著提高随需应变企业的业务灵活性。
引言
IBM 产品逐渐应用了 SOA 和编程模型。程序员构建服务、使用服务，并且开发聚集服务的解决方案。我们在这里使用"程序员（programmer）"这个泛称，因为 SOA 编程模型的一个关键方面是将"编程"的概念扩展到非传统开发人员的工作角色和技能，比如业务分析员和脚本语言用户。
大多数关于 Web 服务的文章主要集中在服务接口和这些接口的使用方面。为了补充接口标准和最佳实践，IBM 引入了一个编程模型，来实现服务并将它们组合为解决方案。扩展 IBM 软件平台的范围，使之能够被更多的用户团体使用 -- 包括非传统的开发人员 -- 这个模型提供了新的组件类型与用户的角色、目标、技能和概念框架相匹配。这些组件类型使更直观的开发工具可以使用。另一个主要的主题是通过编程模型特性和功能的逐步透明化来增强可使用性。
这是关于 SOA 编程模型系列文章中的第一篇，特别针对软件开发专业人员。在本系列中，我们介绍了实现这些目标的一些新的编程模型元素。我们介绍了如何利用它们来使您选择、开发、建议或管理的软件能够更加容易的开发、重用和消费。将软件构造为服务对于按需的企业来说更加有价值，因为不具备太多技能的开发人员可以将其"接入"到解决方案中，或者编入一个业务流程编排流中来满足快速变更的业务需求。不管你是大型企业或者小型业务的开发人员、独立软件供应商（ISV），还是应用程序提供者或者中间件供应商，你都可以通过这种方式构造你的软件，从而从中受益。那么，让我们立即开始应用 SOA 原理。
SOA 编程模型的亮点
让我们首先重点介绍 SOA 编程模型的几个主要特性。
服务数据对象（SDO）是 IBM SOA 中的一个基础概念。SDO 大大提高了开发人员的生产力，并且将你从如何访问特定后端数据源、应用程序和服务的技术细节中解脱出来。它们提供了简化的抽象，使程序员可以更多的集中在业务逻辑上。SDO 还提供了统一的消息表示来与服务交互，淘汰了用于数据表示的复杂技术迷宫，仅仅访问单个统一模型。
SOA 编程模型同样需要统一的范型来创建和访问业务逻辑。为了易于使用，服务应该隐藏实现技术之间的差别，并应该建立在比现有编程结构（比如 Enterprise Java™Bean（EJB））更高级别的抽象上。服务可以通过组装到模块（这些模块可以组成解决方案）中的组件来实现。通过组件公开的服务可以使用可定位的接口来调用。您可以使用 Web 服务描述语言（WSDL）、Java 或其他语言来描述接口。这个实现类型可以有对所需服务的待定引用，在将组件结合在一起执行之前，这些服务是满足需求的。
这个编程模型还引入了良好定义的组件类型，对程序员开发和部署到解决方案中的常用构件建模。例子包括"无格式旧 Java 对象"、业务流程执行语言（BPEL）流程、结构化查询语言（SQL）服务、Adaptive Business Objects、通过 Java 连接器体系结构（J2C）资源适配器访问的 CICS®程序、使用 SAP 业务应用程序编程接口的应用程序、Java 2 Enterprise Edition（J2EE）无状态会话 bean 和 MQSeries® 应用程序。
企业服务总线是多协议结构的一个关键角色，将服务组件编成无缝的交互，通过在消息路径中加入被称为中介的特别组件，来代理服务间的交互，而不用更改现有的端点，从而允许在核心级别上处理企业关注的内容 -- 比如审核、日志、路由、不匹配接口的适配、等价组件的增量替换、安全等。
新的流程语言缩小了 IT 概念和业务构件之间的间隙。很重要的一个是 BPEL。虽然流程可以通过业务分析员引入图形化工具来定义，但它也是一个可执行程序。流程在按需业务转换中占有重要的地位，例如为扩展价值链描述长时间运行的可执行流程。通过扩展价值链，我们可以跨越多个供应商和 IT 域来进行业务安排，比如一个零售商和他的多个独立的供应商，保险公司及其众多的第三方理赔员，IT 外购状况等。
业务状态机（business state machine）是业务分析师可以通过图形工具创建流程的另一个编程框架，并且在流程设计引擎中执行。状态机可以表示业务构件 -- 比如采购单、保险索赔等 -- 这些转换通过一些良好定义的状态来响应特定的生命周期"事件"。
需要重用的组件可以封装为具有可变店（points of variability）的模板，可以在放入解决方案中时进行设计。这种适配成为我们的编程模型的第一部分，同时结合规则语言和相关的工具，为新型用户提供定制的能力。
另一个创新领域是新的解决方案模型，它让部署者、管理者和其它业务用户可以将组件组装成解决方案。在开发的时候，你可以将服务实现与托管服务的拓扑（系统架构师建模的部署拓扑）关联在一起。模型捕捉的系统需求和环境假设在早期的实现中进行校验，降低了应用程序生命周期的费用，并且极大的提高了可靠性和可计账性（accountability）。该模型的特性还包括现有应用程序的后期绑定、数据转换中介和适配器，可以通过企业服务总线来实现面向服务的交互。
总的来说，SOA 编程模型将开发和部署活动分割为不同的阶段，这些阶段可以发生在不同的时间，并且可以通过不同的个人使用不同的技能来实现。这就产生了关系的分离，使软件组件可以被重用。它也将软件体验划分为单独用户的业务角色、技能和任务。最终，它使软件生命周期可以适应按需企业的需要，因为它们通过针对业务灵活性重新设计 IT 流程来寻求更高的有效性。
编程模型的概念
编程模型通常是 IBM SOA 和 IBM 产品的核心。它定义了程序员可以构建和使用的概念和抽象。运行时产品，例如 WebSphere® Application Server，DB2®和 CICS，可以运行或托管编程模型构件。开发工具支持编程模型构件的建模和实现、组装到应用程序（解决方案），以及部署到运行时环境中。最后，系统管理产品、代理和设备支持对运行时和它们托管的编程模型构件的管理。
编程模型是什么？虽然目前没有公认的一般定义，但我们喜欢将它定义为：
- 程序员构建的一套部件类型。部件类型包括多种编程模型构件：超文本标记语言（HTML）文件、数据库存储过程、Java 类、可扩展标记语言（XML）Schema 定义、定义 MQSeries 消息的 C 结构，等等。
- 一系列角色，将具备相似技能和知识的开发和管理人员分组。用这种方式对开发人员分类有助于生产适应于角色的工具，使非程序员可以实现服务并将服务组装为解决方案。业务分析人员定义业务流程，销售专家定义顾客分类的策略并计算产品折扣。每一种角色包含：
- 角色所具备的技能。例如，用户界面开发人员开发界面，用来呈现应用程序或者解决方案的功能构件。假设这个角色了解正在开发的应用程序和它的业务目标，充分了解应用程序的用户及他们的任务，精通一些用户界面设计方法，能够通过为每个任务选择恰当的类型来创建易于使用的用户接口。
- 角色交互（消费或者生产）所用的部件类型和应用程序接口。例如，动态页面设计人员 -- 角色 -- 生产 JavaServer Page（JSP）并消费 EJB -- 部件类型 -- 包装现有的信息资源和应用程序。
- 角色使用的工具。例如，Web 开发人员所用的适合于角色的工具是所见即所得的页面设计工具，用来构建动态页面，使用与 HTML 和 JSP 标签库相关的控件，并将控件连接到 EJB。
使 Web 服务易于实现和使用的关键是对现有技术和知识进行增量扩展，从而使 SOA 可以被消费。以 CICS COBOL 事务程序形式存在的服务与用 BPEL 编写的服务差别很大。从数据库存储过程中调用服务与从 JSP 中调用也是不同的；技能和期望值是不同的。通过提供工具的分类来使部件类型适应于各种技能，并适应于开发流程的阶段，你可以实现可消费性（consumability）。
本系列的后续文章更加详细的介绍了 SOA 编程模型的部件类型。
产品架构
图 1. 产品架构
支持 IBM SOA 方案的产品分成两个主要类别：服务端点和连接它们的消息传送结构。这个通用的架构 -- 包含了许多产品，这些产品都不是 IBM SOA 的专用传输工具 -- 如图 1 所示。
核心是服务间的 ESB 提供的连通性。ESB 是多协议的，支持点到点和发布-订阅两种通信类型，并支持快速处理消息的中介服务。IBM WebSphere MQ，IBM WebSphere MQ Integrator Broker 以及支持 Web 服务和 Java 消息服务（JMS）的 WebSphere 都属于第一个类别。
服务存在于抽象的托管环境（容器）中，并且提供了特定的编程框架。容器加载服务的实现代码，提供到 ESB 的连接性，并管理服务实例。不同类型的服务存在于不同的容器中。（在典型的递规设计的例子中，ESB 本身被认为是用于中介服务的容器。）表 1 列出了一些主要的 IBM SOA 托管环境和托管的组件类型。
表 1. 托管各种组件和服务类型的容器
|
服务/组件类型
|
容器
|
| 用 COBOL、PL/1 和其他语言编写的事务处理程序 |
CICS 或者 IMS（信息管理系统 -- 一种企业事务处理系统）。程序员可以使用 SOAP/HTTP、WebSphere MQ 和 J2EE J2C 连接来访问服务。 |
| 业务流程编排 |
WebSphere Business Integration Server Foundation。该容器支持长期存在的工作流，这些工作流实现了 Web 服务接口并调用其他 Web 服务上的操作。它同样支持长期运行的业务活动事务。 |
| 应用程序适配器 -- 为现有的应用程序和系统提供 SOA/Web 服务的会话虚包（facade）。 |
WebSphere Business Integration Server Foundation 提供的应用程序适配器容器。适配器在 SOA 协议和格式，以及现有应用程序和系统的协议和格式之间进行转换。例如，SAP 适配器将 SOA 编码并通过 HTTP 传输的 XML 转换到 SAP 的现有业务应用程序编程接口格式和 Remote Function Call（RFC）。 |
| 预定义的 SQL 查询、XML 查询或数据库存储过程实现的服务 |
DB2 结合 WebSphere Application Server。查询的参数来自 SOA 操作的输入消息以及提供输出消息的结果。 |
| 使用 Java 类和 EJB 实现的服务。 |
WebSphere Application Server。 |
结束语
IBM SOA 编程模型系列文章的第一篇概述了 IBM 工具和产品如何适用于模型，以及开发人员如何有效的在应用程序开发中使用它。
- 使用 SDO 简化数据访问
- 服务定义以及组件模型发展状况的介绍
- 用组件类型来简化开发
- 基本组件类型
- 服务组合和定制
- 流程组件：BPEL 和业务状态机
- 定制服务：设计模式，模板和可变点
- 面向服务的用户接口
- 用于管理的 SOA 方法
- SOA 软件生命周期开发工具
- SOA 的安全性