[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#author]Donald Ferguson[/URL], IBM 顶尖学者及 Software Group 首席架构师, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#author]Marcia Stockton[/URL], Senior Technical Staff 成员和主席，Software Group 编程模型工作组, IBM

2005 年 7 月 01 日

IBM® 面向服务体系结构（Service-Oriented Architecture，SOA）编程模型使非程序员可以创建和重用 IT 资产，而不需要掌握 IT 技能。该模型包括组件类型，布线，模板，应用程序适配器，统一数据表示和企业服务总线（Enterprise Service Bus，ESB）。本文是系列文章的第一部分，该系列文章介绍了 IBM SOA 编程模型，选择、开发、部署工作所需的内容，以及建议的编程模型元素。本文陈述的内容考虑了使用该模型的开发人员可能具备不同的技术水平和工作角色。
SOA 编程模型系列

对于任何独立程序员来说，有效的掌握和应用飞速增长的软件技术、实践、工具和平台，变得越来越困难，当然更不用说非程序员了。然而，如果业务流程转换能够成功进行，很多的非程序员就可以使用现有的 IT 资产来进行他们的工作，而不用去学习繁琐的底层技术细节。本系列文章描述了一个新的面向服务体系结构（SOA）编程模型，该模型实现了业务关系的分离，因此企业中具备不同技术水平和工作角色的人，即使不是专业的 IT 人员，也可以在软件开发生命周期每个阶段创建和使用 IT 资产。这可以显著提高随需应变企业的业务灵活性。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

引言

IBM 产品逐渐应用了 SOA 和编程模型。程序员构建服务、使用服务，并且开发聚集服务的解决方案。我们在这里使用"程序员（programmer）"这个泛称，因为 SOA 编程模型的一个关键方面是将"编程"的概念扩展到非传统开发人员的工作角色和技能，比如业务分析员和脚本语言用户。

大多数关于 Web 服务的文章主要集中在服务接口和这些接口的使用方面。为了补充接口标准和最佳实践，IBM 引入了一个编程模型，来实现服务并将它们组合为解决方案。扩展 IBM 软件平台的范围，使之能够被更多的用户团体使用 -- 包括非传统的开发人员 -- 这个模型提供了新的组件类型与用户的角色、目标、技能和概念框架相匹配。这些组件类型使更直观的开发工具可以使用。另一个主要的主题是通过编程模型特性和功能的逐步透明化来增强可使用性。

这是关于 SOA 编程模型系列文章中的第一篇，特别针对软件开发专业人员。在本系列中，我们介绍了实现这些目标的一些新的编程模型元素。我们介绍了如何利用它们来使您选择、开发、建议或管理的软件能够更加容易的开发、重用和消费。将软件构造为服务对于按需的企业来说更加有价值，因为不具备太多技能的开发人员可以将其"接入"到解决方案中，或者编入一个业务流程编排流中来满足快速变更的业务需求。不管你是大型企业或者小型业务的开发人员、独立软件供应商（ISV），还是应用程序提供者或者中间件供应商，你都可以通过这种方式构造你的软件，从而从中受益。那么，让我们立即开始应用 SOA 原理。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

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 流程来寻求更高的有效性。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

编程模型的概念

编程模型通常是 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 编程模型的部件类型。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

产品架构

图 1. 产品架构

支持 IBM SOA 方案的产品分成两个主要类别：服务端点和连接它们的消息传送结构。这个通用的架构 -- 包含了许多产品，这些产品都不是 IBM SOA 的专用传输工具 -- 如[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#figure1]图 1[/URL] 所示。

核心是服务间的 ESB 提供的连通性。ESB 是多协议的，支持点到点和发布-订阅两种通信类型，并支持快速处理消息的中介服务。IBM WebSphere MQ，IBM WebSphere MQ Integrator Broker 以及支持 Web 服务和 Java 消息服务（JMS）的 WebSphere 都属于第一个类别。

服务存在于抽象的托管环境（容器）中，并且提供了特定的编程框架。容器加载服务的实现代码，提供到 ESB 的连接性，并管理服务实例。不同类型的服务存在于不同的容器中。（在典型的递规设计的例子中，ESB 本身被认为是用于中介服务的容器。）[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#table1]表 1[/URL] 列出了一些主要的 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。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

结束语

IBM SOA 编程模型系列文章的第一篇概述了 IBM 工具和产品如何适用于模型，以及开发人员如何有效的在应用程序开发中使用它。

使用 SDO 简化数据访问
服务定义以及组件模型发展状况的介绍
用组件类型来简化开发
基本组件类型
服务组合和定制
流程组件：BPEL 和业务状态机
定制服务：设计模式，模板和可变点
面向服务的用户接口
用于管理的 SOA 方法
SOA 软件生命周期开发工具
SOA 的安全性

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

参考资料

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel/index.html]英文原文[/URL]。

查阅 [URL=http://java.sun.com/products/jms/docs.html]Java Message Service 规范[/URL]。

[URL=http://java.sun.com/j2ee/connector/index.jsp]J2EE Connector Architecture[/URL] 提供了用于解决多个应用服务器和当前企业信息系统之间连接性问题的 Java 解决方案。

IBM developerWorks 的教程 [URL=http://www.ibm.com/developerworks/edu/j-dw-javajca-i.html]Introduction to the J2EE Connector Architecture[/URL] 很好的介绍了 J2EE 连接器体系结构。

访问 [URL=http://devworks.krcinfo.com/]Developer Bookstore[/URL] 以获取技术书籍的完整列表，其中包括数百篇 [URL=http://devworks.krcinfo.com/WebForms/ProductList.aspx?Search=Category&id=1700]Web 服务主题[/URL]的文章。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks blogs[/URL] 加入到 developerWorks 社区。

想获取更多信息吗？developerWorks [URL=http://www-128.ibm.com/developerworks/cn/webservices]SOA 和 Web 服务[/URL]专区有数百篇信息文章，以及关于如何开发 Web 服务应用程序的入门级、中级和高级教程。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html#main]回页首[/URL]

作者简介

[B][/B]

[B][/B] Donald F. Ferguson，Ph.D，是 55 个 IBM 顶尖学者（IBM Fellow）中的一个，在 IBM 工程社区的 200，000 个技术专家中拥有最高技术职位。Don 是 IBM Software Group 产品家族（包含 Lotus®，Rational®，WebSphere，DB2 和 Tivoli®）的首席架构师和技术带头人。Don 主持 SWG Architecture Board，这里汇集了 SWG 的高级产品架构师。Don 最近主要专注于 Web 服务、业务流程管理、客户端平台、外购和托管平台、网格服务和 WebSphere 应用程序开发。从 WebSphere 最早的研发开始，Don 就是 WebSphere 产品家族的首席架构师，直到 2003 年成为 SWG 首席架构师。您可以通过 [URL=mailto:dff@us.ibm.com]dff@us.ibm.com[/URL] 与他联系。

  Marcia L. Stockton 是位于北卡罗莱纳州 Research Triangle Park 的 IBM Software Group 的 Senior Technical Staff Member 和 Master Inventor（她居住在 California）。她也是 IEEE 高级会员。Marcia 领导着 Software Group Architecture Board 的编程模型工作组，她在 Lotus、Rational、WebSphere、DB2 和 Tivoli 产品方面推动横向集成并促进编程模型的简化。她拥有 73 项美国专利，包括网络、Web、安全、保密、多媒体、无线、周边设备和射频 ID 等方面。她最近领导了身份管理和边界服务器分布式编程的架构定义。在开发了 5 年网络软件后，她于 1988 年加入 IBM。1975 年她在 Swarthmore College 获得 B.A. 学位。你可以通过 [URL=mailto:mls@us.ibm.com]mls@us.ibm.com[/URL] 与她联系。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#author]Stephen A. Brodsky[/URL], 高级技术人员, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#author]Marcia Stockton[/URL], 高级技术人员, IBM

2005 年 8 月 04 日

利用服务数据对象简化面向服务的软件中的数据访问和表示。SDO 用统一的抽象代替各种各样的数据访问模型来创建、检索、更新和删除供服务实现使用的业务数据。这是我们有关用于 IBM® 面向服务的体系结构 (SOA) 的编程模型系列文章的第二篇。
服务对象数据

服务对象数据（Service Data Object，SDO）使用统一的抽象代替了各种各样的数据访问模型来创建、检索、更新和删除供服务实现使用的业务数据。SDO（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#Resources]参考资料[/URL]部分中的 Service Data Objects 2.0 和 Next-Generation Data Programming： Service Data Objects）是 IBM 面向服务的体系结构 (SOA) 的基础概念。SDO 将开发人员从如何访问特定的后端数据源的技术细节中解放出来，提高了他们的工作效率，这样他们就可以主要专注于业务逻辑（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#Resources]参考资料[/URL]部分中的 Integrating relational data into Web applications、Next-generation data programming in the Java™ environment 以及 Using Service Data Objects with Enterprise Information Integration technology）。SDO 是与 BEA Systems, Inc. 联合制订的规范，并且在 IBM 系列产品中得到了广泛的使用，包括 WebSphere® Application Server 和 Rational® Studio 工具。Java™ 数据库连接（Java™ DataBase Connectivity），通常称为 JDBC，是执行结构化查询语言（Structured Query Langauge，SQL）语句的 Java 接口。目前，用于 JDBC、Web 服务描述语言（Web Services Description Language，WSDL）定义的服务、企业 JavaBean（Enterprise JavaBean，EJB）等等由 Java 编写的服务实现的编程模型都是相似的，但却又有一些让人讨厌的不同。

SDO 定义了一种单一的、统一的方法来访问和操作来自异构数据源的数据，包括关系型数据库、可扩展标记语言（eXtensible Markup Language，XML）数据源、Web 服务以及企业信息系统 (EIS)。它们是基于数据图（data graph）的概念。数据图就是一组可以从数据源中分离出来的树形结构的对象。SDO 可以在整个应用程序体系结构中使用。

应用程序体系结构的领域  如何使用 SDO  
SOA SDO 是服务的输入和输出。

数据访问 SDO 访问关系型、XML、EJB、Java 数据对象（Java Data Object，JDO）和 Hibernate 数据源。
SDO 是数据传输对象（Data Transfer Object，DTO）——也被称为值对象（Value Object）。

Web 服务 SDO 表示网络上的 XML。

消息传递 SDO 表示消息。

XML 使用 SDO 的情况：
支持 XML 的应用程序。
访问 XML 文件、文档、资源和消息。

连接器/适配器（EIS，CICS） SDO 表示数据记录。

EJB SDO 是 DTO（也被称作值对象）。
Java 2 企业版（Java 2 Enterprise Edition，J2EE）设计模式。

ADO.NET ADO DataSet 是 SDO 数据图的子集。

企业服务总线（Enterprise Service Bus，ESB） SDO 是服务的输入和输出。

跨语言编程模型 完整的应用程序可能横跨层和语言。
用于很多种语言技能集的相同的编程模型。

模型驱动的体系结构（Model-driven architecture，MDA） SDO 模型（类型（Type）和属性（Property））是通过统一建模语言（Unified Modelling Language，UML）类和组件定义的。
SDO 应用程序遵循 UML 顺序 (Sequence)、流 (Flow)、状态 (State) 和协作 (Collaboration)。

Java SDO 是带有 POJO 接口的智能的“传统 Java 对象（plain old Java object，POJO）”。

在 SOA 中，应用程序并不直接地连接数据源。它访问一个叫做数据访问服务（data access service，DAS）的中介并接收响应中的数据图。DAS 是为特定数据源种类处理技术细节的服务。它为客户机将数据转换成 SDO 图。客户机应用程序与数据图进行交互来获得数据和改变数据。为了将更新应用于原始的数据源，应用程序将更新过的图发送回 DAS，而 DAS 又与数据源交互。通常，运行时提供 DAS 的实现，而应用程序开发工具提供对数据图的支持。

SDO 通过封装数据访问的细节将业务应用程序与技术改变相隔离，从而避开了技术改变产生的影响——重新编写应用程序以便跟上改变的技术（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#Resources]参考资料[/URL]部分中的 Wikipedia）。例如，考虑一个设计用来从数据库中读取产品描述并将其作为网页显示的 Java Web 应用程序。为了访问数据库中的产品描述，应用程序很可能使用 JDBC。假设不久后应用程序拓扑发生了改变，在应用程序和数据库之间放置了 Web 服务。现在，应用程序不能再使用 JDBC 访问数据，而是需要重做大量的工作来替换 Web 服务应用编程接口 (API)，例如文档对象模型（Document Object Model，DOM）或者基于 XML 的远程过程调用的 Java API（Java APIs for XML-Based Remote Procedure Call，JAX-RPC）。SDO 避免了这个问题；使用 SDO 编写的应用程序不必改变。

另外，SDO 提供了支持元数据 API 的应用程序、工具和框架来以统一的方式自省数据模型，而不管它的来源。DAS 将后端元数据转换成标准的 SDO 格式。

SDO 类型可以由 Java 接口、XML Schema、关系型表和列、EJB、COBOL 记录、消息或者 UML 来定义（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#Resources]参考资料[/URL]部分中的 Catalog of OMG Modeling and Metadata Specifications）；实现人员可以选择自己喜欢的系统类型。简单 Java 和 XML 数据类型是有效的 SDO 数据类型，这为 Java 实现人员简化了一步。SDO 支持动态的和静态的数据访问模型，两者也可以一起使用。我们将更详细地考虑这些内容：

动态模型（缺省值）允许编程人员通过名称（字符串）获得和设置数据图中的数据元素。当 SDO 的类型在编译阶段未知时，或者当程序部署完以后可能要添加新的属性时，这特别有用。客户机应用程序或服务查询 SDO 来了解它的结构，然后按名称读取和更新任何元素。例如，可以编写一个泛型 SDO 访问函数并用特定于元素的元数据填充它来访问单独的 SDO。SDO 同样也使用 XML 路径语言( XML Path Language，XPath）表达式的子集来支持快速遍历许多 DataObject，例如 customer[1]/address/zip，以便快速访问 customer DataObejct 的 zip 代码。
静态模型使用命名和类型化 Java 接口。每个数据元素有自己的“getter”和“setter”方法。工具从 SDO 类型和属性生成静态接口。
SDO 对于数据表示非常重要，即使没有典型的数据源也如此。这种用法的例子包括使用 Web 服务交换的 XML 消息、[URL=http://docs-pdf.sun.com/816-5904-10/816-5904-10.pdf]Java 消息服务 (JMS)[/URL] 消息、XML 文件等等。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#main]回页首[/URL]

示例

下面的例子——定义了包含客户数据的数据对象——说明了使用 Java 或 XML 来定义和使用 SDO 是多么的容易。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex1]示例 1[/URL]（使用 XML）是 SDO 类型的基础。

示例 1. 使用 XML 的 SDO 类型定义

    
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
                xmlns:tns="http://www.myvalue.com"
  targetNamespace="http://www.myvalue.com">
 <element name="customer" type="Customer"/>
 <complexType name="Customer">
  <sequence>
   <element name="customerID" type="string"/>
   <element name="firstName" type="string"/>
   <element name="lastName" type="string"/>
   <element name="stockSymbol" type="string"/>
   <element name="stockQuantity" type="int"/>
  </sequence>
 </complexType>
</schema>

在[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex2]示例 2[/URL] 中，由前面的 XML 所生成的 Java 接口说明了如何使用静态接口。

示例 2. 使用 Java 的 SDO 类型定义

    
public interface Customer {
 String getCustomerID();
 void setCustomerID(String customerID);
 String getFirstName();
 void setFirstName(String firstName);
 String getLastName();
 void setLastName(String lastName); 
        String getStockSymbol();
 void setStockSymbol(String stockSymbol);
 int getStockQuantity();
 void setStockQuantity(int stockQuantity);
}

一旦 SDO 类型定义好，就可以通过将类型定义传递给 SDO 数据工厂 (data factory) 来将其实例化（为数据对象分配存储空间）。这个工厂仅仅是运行时的一个组件，它的功能就是根据 SDO 类型定义实例化 SDO 数据对象。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex3]示例 3[/URL] 和[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex4]示例 4[/URL] 分别展示了如何通过传递 XML Schema 名称空间和复杂的类型名称（在[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex1]示例 1[/URL] 中定义的）或者 Java 接口类（在[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex2]示例 2[/URL] 中定义的）作为参数来创建 SDO。

示例 3. 使用 XML Schema 名称空间和复杂的类型名称参数创建 SDO

    
DataObject customer = DataFactory.INSTANCE.create("http://www.myvalue.com", "Customer");

示例 4. 使用具有 Java 接口类参数的 SDO DataFactory 创建 SDO

    
Customer customer = (Customer) DataFactory.INSTANCE.create(Customer.class);

在 SDO 实例化之后，实现就可以访问它了。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex5]示例 5[/URL] 和[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#ex6]示例 6[/URL] 中的代码示例分别展示了对 Customer SDO 的动态和静态访问。

示例 5. 动态访问 SDO

    
DataObject customer = ... ;
customer.setString("customerID", customerID);
...
customer.setInt("stockQuantity", 100);
String customerID = customer.getString("customerID");
...
int stockQuantity = customer.getInt("stockQuantity");

示例 6. 静态访问 SDO

    
Customer customer = ... ;
customer.setCustomerID(customerID);
...
customer.setStockQuantity(100);
String customerID = customer.getCustomerID();
...
int stockQuantity = customer.getStockQuantity();

我们使用访问 XML 文件服务和关系数据库的例子来进一步说明由 SDO 推动的编程模型的简单性。请注意，尽管技术之间存在差异，但是这些应用程序是如此的相似。应用程序开发人员能够专注于业务逻辑，而让服务去处理更新持久数据存储的实现细节。

示例 7. XML 文件服务

这个简单的例子将数据从 XML 文件加载到 SDO 数据图，打印并更新数据，然后将它写回文件。（业务目标是将“quot;Adam”改为“Kevin”。）

根据根 XML 元素和一个多值的 customer 属性定义将要作为根 customers 数据对象读入的 XML 文件。在 XML 文件中 Customers 为每个 customer 元素包含一个数据对象。每个 customer 具有两个属性：SN 和 firstName。
<customers xmlns="http://customers.com">
 <customer SN="1" firstName="Adam" />
 <customer SN="2" firstName="Baker" />
</customers>

读取文件数据。
DataObject root = xmlService.load(InputStream);

遍历 customer 数据对象列表并打印出每个名 (first name)。
Iterator i = root.getList("customer").iterator();
while (i.hasNext()) {
 DataObject cust = (DataObject) i.next();
 String name = cust.getString("firstName");
 System.out.println(name);
}

将第一个客户数据对象的 firstName 属性设为 Kevin。中间件更新变更摘要（这里并没有显示出来）来指示改变了的数据。
DataObject customer1 = root.getDataObject("customer[1]");
customer1.setString("firstName", "Kevin"); // or

root.setString("customer[1]/firstName", "Kevin");

将数据对象写入文件。
xmlService.save(OutputStream, root);

结果是更新的 XML 文档。
<customers xmlns="http://customers.com">
  <customer SN="1" firstName="Kevin" />
  <customer SN="2" firstName="Baker" />
</customers>

示例 8. 访问关系数据库

虽然复杂的关系数据库到 SDO 的映射是可行的，但是这个例子使用的是一个非常简单的映射：每个数据库表都是一个 SDO 类型，表的每行是 SDO 数据对象，而每列是 SDO 属性。应用程序逻辑是相同的：通过执行预先定义好的查询从数据库中读取、打印并更新数据（将“Adam”改为“Kevin”），将更改保存到数据库。数据库查询返回 CUSTOMER 表中的两行：

CUSTOMER ID（整数，主键） CUSTOMER FIRSTNAME（字符串） CUSTOMER LASTNAME（字符串）
1 Adam  Smith
2 Baker Street

下面给出了带有解释的 SDO 实现。

rdbService 查询数据库以获得数据。
DataObject root = rdbService.get();

相同的数据可能已经用 XML 等价地表示了。
<customers>
  <CUSTOMER ID="1" FIRSTNAME="Adam" LASTNAME="Smith"/>
  <CUSTOMER ID="2" FIRSTNAME="Baker" LASTNAME="Street"/>
</customers>

打印每个客户名。
Iterator i = root.getList("CUSTOMER").iterator();
while (i.hasNext()) {
 DataObject cust = (DataObject) i.next();
 String name = cust.getString("FIRSTNAME");
 System.out.println(name);
}

将第一个数据对象的 FIRSTNAME 设为 Kevin。中间件更新变更摘要（这里并没有显示出来）来指示改变。
DataObject customer1 = root.getDataObject("CUSTOMER[1]");
customer1.setString("FIRSTNAME", "Kevin"); // or

root.setString("CUSTOMER[1]/FIRSTNAME", "Kevin");

将更新的数据写入数据库。
rdbService.update(root);

现在数据库包含：

CUSTOMER ID（整数，主键） CUSTOMER FIRSTNAME（字符串） CUSTOMER LASTNAME（字符串）
1 Kevin  Smith
2 Baker Street

注意，第一行已经被更新了。

如果在我们的示例应用程序已经获得数据图之后，另外一个应用程序访问数据库并更改了值会怎么样？在写入时，数据访问服务检查变更摘要来决定如何对数据源应用更新。数据库可以使用开放式并发控制 (optimistic concurrency control) 来确保这个改变之前最后包含的值是“Adam”（否则，另外一个应用程序可能先改变数据，可能在该应用程序中需要某些错误恢复）。某些服务实现了更为高级的开放式并发形式；变更历史记录提供了那些算法所需要的原始值。

使用 EJB 时，SDO 作为 [URL=http://www.martinfowler.com/eaaCatalog/dataTransferObject.html]DTO[/URL]（也称作值对象）J2EE 设计模式。一般来说，访问实体 EJB（Entity EJB）的每个属性的开销非常大，所以传输几个数据图中的 SDO 对象效率更高。会话 EJB（Session EJB）可能有方法产生和使用 SDO 图来更加高效地直接访问实体 EJB。Customer 实体 EJB 封装了对 Customer 记录的数据库访问。会话 EJB 提供了访问方法来从 Customer 实体 EJB 产生和返回 Customer SDO 图。

示例 9. 返回 SDO 和由 SDO 更新实体 EJB 的会话 Bean 接口

    
public interface CustomerSession {
 Customer getCustomerByID(String customerID);
 Customers getCustomersByLastName(String lastName);
 void updateCustomers(Customers customers);
}

Customers 是包含若干客户的 SDO 根数据对象。Customers 的 List 包含 Customer 数据对象。ChangeSummary 用来记录对 Customer 对象所做的全部更改，包括任何的添加、删除或更新。updateCustomers() 方法利用所做的更改来更新 Customer 实体 EJB，并且可以在一个事务中批处理对数据源的更改。

示例 10. 使用 Java 的 Customer 的 SDO 类型定义

    
public interface Customers {
 List<Customer> getCustomers();
 ChangeSummary getChanges();
}

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#main]回页首[/URL]

总结

SDO 为所有数据源启用了对应用程序数据的统一访问和公共编程模型，而不管数据存储在何地以及如何存储。SDO 利用了 XML 的简易性，而又没有引入 XML Schema 的复杂性或序列化的性能问题。通过同时使用 SDO 和 SOA，可以将系统编程任务从业务逻辑中分离出来，并且将其封装在可重用的服务之中，而不是所有编程人员都必须掌握这些技能才能入门。它们在没有陷入技术和实现细节的情况下简化了业务应用程序的编程，防止了技术改变产生的影响。有了 SDO，业务应用程序就是名副其实的业务应用程序。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html#main]回页首[/URL]

参考资料

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel2.html]英文原文[/URL]。

浏览 [URL=http://www.ibm.com/developerworks/library/specification/j-commonj-sdowmt/index.html]Service Data Objects 2.0[/URL]（developerWorks，2005 年 6 月）规范。

“Next-Generation Data Programming: Service Data Objects”，由 IBM 和 BEA 联合编写的白皮书，提供有关服务数据对象 API 的其他信息。

请阅读 [URL=http://java.sys-con.com/read/46652.htm]An Introduction to Service Data Objects: Integrating relational data into Web applications [/URL]，Java 开发人员期刊（2004 年 10 月），K. Williams 和 B. Daniel 合作撰写，从中可以获得简要的概述。

请查看“[URL=http://www-128.ibm.com/developerworks/cn/java/j-sdo/]服务数据对象简介: Java 环境中的下一代数据编程 [/URL]”（developerWorks，2004 年 9 月），从中可以获得全面的综述。

学习“[URL=http://www.ibm.com/developerworks/db2/library/techarticle/dm-0407saracco/index.html]Using Service Data Objects with Enterprise Information Integration technology[/URL]”中的一个 SDO 示例（developerWorks，2004 年 7 月）。

从 Eclipse 上的 EMF 项目下载 [URL=http://eclipse.org/emf]SDO 代码[/URL]。

了解更多关于 [URL=http://c2.com/cgi/wiki?TechnologyChurn]Wikipedia[/URL] 技术改变产生的影响的信息。

浏览 [URL=http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML]Catalog of OMG Modeling and Metadata Specifications[/URL]，对象管理小组（Object Management Group）（2004 年 10 月）。

请阅读 [URL=http://docs-pdf.sun.com/816-5904-10/816-5904-10.pdf]Java Message Service Specification[/URL]（1999 年 11 月）。

想要获得对 IBM SOA 编程模型的介绍，请阅读“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/]用于实现 Web 服务的 SOA 编程模型，第 1 部分[/URL]”（developerWorks，2005 年 6 月）。

访问 [URL=http://devworks.krcinfo.com/]Developer Bookstore[/URL] 可以获得完整的技术书籍清单，其中包括数百本关于 [URL=http://devworks.krcinfo.com/WebForms/ProductList.aspx?Search=Category&id=1700]Web 服务主题[/URL]的图书。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks blogs[/URL] 来加入到 developerWorks 社区。

想了解更多内容吗？developerWorks [URL=http://www-128.ibm.com/developerworks/cn/webservices]SOA and Web services[/URL] 专区有数百篇关于如何开发 Web 服务应用程序的文章以及入门级、中级和高级教程，将让您大开眼界。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#author]Matthias Kloppmann[/URL], 高级技术人员, IBM Software Group
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#author]Donald Ferguson 博士[/URL], IBM 院士, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#author]Marcia Stockton[/URL], 高级技术人员和杰出发明人, IBM Software Group

2005 年 8 月 29 日

组合服务的一种方法是使用业务流程执行语言（Business Process Execution Language，BPEL）将服务定义为业务流程，或者将它们表示为业务状态机 (business state machines)。编排这样一系列服务的调用的主线代码在一个称为流程编排引擎 (process choreography engine) 的特殊容器中运行。容器提供的功能可以支持甚至跨企业的边界执行长时间运行的流程，承受计划的和未计划的停用，并且促进企业到企业（business-to-business，B2B）的协作。
这是我们关于 IBM 的面向服务的体系结构（Service-Oriented Architecture，SOA）的编程模型系列的第三篇文章。上一篇文章介绍了 SOA 编程模型的概念和服务数据对象 (Service Data Object)。

业务流程

业务流程编排中的服务编排的概念对于二十世纪七十年代的 FORTRAN 编程人员来说或许并不陌生。它只不过就是调用函数或者子例程的主线代码的概念，其中每个函数或者子例程实现了更大的程序的一个单独的部分。现在，在二十一世纪，子例程变成了 Web 服务。主程序的实现语言是用于 Web 服务的 BPEL（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#resources]参考资料[/URL]以获得更多关于 BPEL 的信息）。执行环境是 IBM WebSphere&reg; Business Integration Server Foundation 中的 Business Process Choreography 容器。而程序可以将许多可能跨多个企业的长时间运行的任务组合在一起来实现一个业务功能。

图 1. 简单的业务流程

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#fig1]图 1[/URL] 展示了一个简单的内部旅行审批和预订流程的 BPEL 流程，涉及检查请求数据的程序、实际管理审批的人工任务，以及为实际执行预订而与合作伙伴进行的 B2B 交互。

由于没有重复提及许多关于 BPEL 的参考资料和教程（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#resources]参考资料[/URL]），因此我们在这里概要地列出了 BPEL 的一些特性以及 IBM 的 WebSphere Business Integration 中的 BPEL 实现所提供的扩展：

可以与多个合作伙伴交互的长时间运行的业务流程。所有的交互都是通过标准的无状态 Web 服务调用执行的。相关性用来利用应用程序级数据处理特定的实例，例如根据员工序号审批某人的旅行请求。补偿功能用来在必要时（部分地）撤消流程的作用，例如，在已经预订了一个航班之后取消旅行请求。
将人员整合到流程。一些业务流程的步骤常常是人工执行的（例如，在审批或者异常处理工作流中）。这些步骤包括分配人员工作的复杂情景识别 (context-aware) 的情况，例如双人监控原则 (four eyes principle)，该原则规定第二个审批步骤由除第一个审批者之外的审批者来执行。这些要求可以通过将人工任务作为流程步骤来满足。Business Process Choreography 引擎和 IBM WebSphere Studio Application Developer Integration Edition 工具提供了对人工任务的支持。
将流程嵌入到 Java™ 2 Platform, Enterprise Edition (J2EE)，并且除 XPath（它是 BPEL 中的标准）之外，在流程中使用 Java 作为首选语言。当任何 Java 功能超出 BPEL 范围时，IBM 和 BEA Systems Inc. 就会在一个称为 BPELJ 的研究计划中提出对 BPEL 的 Java 扩展。这些扩展使编程人员能够使用 Java 代码段来实现流程中的活动，在 BPEL 允许表达式的地方使用 Java 作为表达式语言，以及使用 Java 操作流程中的工作数据。
服务质量。生产系统所需的服务质量扩展，例如微调事务边界、适当地修复错误情况或者产生审核日志的功能。
与 WebSphere 集成。流程编排引擎与事务引擎和 WebSphere 中的 Activity Service 集成在一起。与人有关的流程利用 WebSphere 用户目录和安全性。BPEL 流程是作为 WebSphere 应用程序部署的一部分进行部署的。业务流程的管理集成到 WebSphere 管理控制台中。
您可以使用 IBM Rational&reg; 和 WebSphere 工具套件中的可视化业务流程编辑器来构建 BPEL 流程。将服务接口导入到资产视图 (asset view) 使您能够从 BPEL 流程调用外部服务。该工具套件还有一个用于调试流程的可视化调试器，包括调试长时间运行的流程的并行分支以及通过适当的用户界面与面对人 (human-facing) 的活动进行交互的功能。该工具套件同样也允许测试 BPEL 流程，以及将它们作为服务进行部署。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#main]回页首[/URL]

业务状态机

工作流过程与可能采取多个步骤和路径的动作或动词——例如，CreatePurchaseOrder 或者 BookTravel——相似，调用许多 Web 服务、Java 类或 Enterprise JavaBeans (EJB)。

如果工作流过程是一个动词，那么业务状态机就是一个表示事物 的名词，例如订购单、故障单或保险单应用程序。这里，动词——例如 CreatePurchaseOrder 或 BookTravel——是对事物的操作。业务状态机上的操作可以调用任何服务，例如直接通过状态机指定的 BPEL 流程或者 Java 代码。

两种方法——过程或者状态机——中没有哪个是更好的。两者在功能上都是等价的服务抽象。无论选择哪一个对当前任务来说都是很好的服务抽象。

业务状态机是由状态转移图以图形方式指定的，状态转移图显示其状态、状态间可能的转移和触发状态转移的事件，以及作为结果的操作。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#fig2]图 2[/URL] 是一个表示 PurchaseOrder 的简单状态机的流程图。

图 2. 表示订购单的业务状态机

节点（矩形）表示 PurchaseOrder 的可能状态，可以是 Created、Ready、InApproval、Purchased、Canceled、Shipped、Delivered 或者 Archived。弧线（箭头）表示可能发生的事件，导致 PurchaseOrder 从一个状态转移到另外一个状态。

业务状态机可以通过 BPEL 流程来实现。如果这样的话，事件就仅仅是 Web 服务描述语言 (WSDL) 所描述的流程的 portType 上的操作。当前状态（存储在一个变量中）决定了哪些事件（操作）是活动的。如果调用者试图调用无效的操作，那么运行时将抛出异常。您也可以查询状态机的当前状态来确定操作的有效性。

当一个事件发生时（例如，当调用一个操作或者定时器超时的时候），状态机转换到新的状态并执行与这个转换相关联的动作（例如调用操作或者方法）。在[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#fig2]图 2[/URL] 中，转移是通过带有事件注释的弧线、可选的条件以及将要执行的动作来反映的。转移只在其相关联的条件为真时才执行。在状态进入和退出时可能执行其他动作。在[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#fig2]图 2[/URL] 中，处于 Ready 状态的状态机具有两种可能的事件（已启用的操作）：purchase 和 Cancel。对于 purchase 操作来说，有两个可能的条件：要么需要审批，要么不需要审批。

当调用者调用购买操作时，业务状态机框架执行以下操作：

确定操作对于当前状态是否有效。
执行状态的退出动作（如果存在的话）。
计算与该事件相关联的所有转移的条件。假定对于此次购买需要审批，就选择转移到 InApproval 状态，而忽略到 Purchased 状态的转移。
执行与该转移相关联的动作，在本例中即 doApprovalAction()。例如，这个操作可能发送电子邮件给销售经理或者简单地调用另一个 SOA 组件（如 BPEL 流）上的操作。
进入新的 InApproval 状态。
执行新的状态的进入动作（如果存在的话）。
您可以使用 Rational/WebSphere 工具套件的可视化业务状态机编辑器来创建业务状态机。这个工具以类似的方式处理业务状态机和业务流程：它们可以具有相同的外部服务关系，并且它们的测试和部署环境完全相同。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#main]回页首[/URL]

总结

IBM 用于 SOA 的编程模型提供了若干构造新的面向服务的应用程序或者将现有的应用程序组合成服务框架的方法。本文重点介绍了使用业务流程执行语言的业务编排方法，它与调用传统的过程性编程中的子例程相似，增加了对于长时间运行的工作和并行工作的支持。业务状态机是另一个编程模型构件，它可以用 BPEL 来表示。没有哪种方法是更好的。选择最适合当前问题的方法。后续的文章将介绍其他组件类型，它们是 SOA 开发人员的常备工具。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/#main]回页首[/URL]

参考资料

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel3/index.html]英文原文[/URL]。

请阅读本系列前两篇文章“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/index.html]用于实现 Web 服务的 SOA 编程模型，第 1 部分: IBM SOA 编程模型简介[/URL]”（developerWorks，2005 年 6 月）和“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel2.html]用于实现 Web 服务的 SOA 编程模型，第 2 部分: 使用服务数据对象简化的数据访问[/URL]”（developerWorks，2005 年 6 月）。

要了解更多关于 BPEL 及其如何与 Web 服务一起工作的信息，请阅读“[URL=http://www.ibm.com/developerworks/webservices/library/specification/ws-bpel/]Business Process Execution Language for Web Services (BPEL4WS) v1.1[/URL]”（developerWorks，2003 年 5 月）。

通过阅读 IBM Systems 期刊中的“[URL=http://www.ibm.com/developerworks/websphere/library/techarticles/wasid/WPC_Concepts/WPC_Concepts.html]WebSphere Application Server Enterprise Process Choreographer: Concepts and Architecture[/URL]”（developerWorks，2002 年 10 月）和“[URL=http://www.research.ibm.com/journal/sj/432/kloppmann.html]Business process choreography in WebSphere: Combining the power of BPEL and J2EE[/URL]”获得更多关于业务流程编排的信息。

通过阅读“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-bpelj/]BPELJ：针对 Java 技术的 BPEL[/URL]”（developerWorks，2004 年 3 月）以获得更多关于 BPELJ 的信息。

访问 [URL=http://www.ibm.com/developerworks/webservices]developerWorks SOA and Web services 专区[/URL]以获得大量关于 SOA 和 Web 服务技术的“How to”信息、工具和项目更新。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks 博客[/URL]加入到 developerWorks 社区。

浏览 [URL=http://www.ibm.com/developerworks/cn]developerWorks[/URL] 中所有的 [URL=http://www.ibm.com/developerworks/cn/views/webservices/articles.jsp]SOA and Web services 文章[/URL]和[URL=http://www.ibm.com/developerworks/cn/views/webservices/tutorials.jsp]免费的 SOA and Web services 教程[/URL]。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#author]Dr. Beth Hutchison[/URL] ([URL=mailto:beth_hutchison@uk.ibm.com?subject=IBM 企业服务总线介绍&cc=flanders@us.ibm.com]beth_hutchison@uk.ibm.com[/URL]), 高级技术人员, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#author]Marc-Thomas Schmidt[/URL] ([URL=mailto:mtschmidt@uk.ibm.com?subject=IBM 企业服务总线介绍&cc=flanders@us.ibm.com]mtschmidt@uk.ibm.com[/URL]), ESB 首席架构师, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#author]Dan Wolfson[/URL] ([URL=mailto:dwolfson@us.ibm.com?subject=IBM 企业服务总线介绍&cc=flanders@us.ibm.com]dwolfson@us.ibm.com[/URL]), 首席技术官，Business Integration, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#author]Marcia Stockton[/URL] ([URL=mailto:mls@us.ibm.com?subject=IBM 企业服务总线介绍&cc=flanders@us.ibm.com]mls@us.ibm.com[/URL]), 高级技术人员, IBM

26 日 7 月 2005 年

企业服务总线（Enterprise Service Bus，ESB）体系结构模式支持在面向服务的体系结构 (SOA) 中虚拟化服务交互并对其进行管理。它使得交互可以在服务提供者和服务请求者之间进行，并且可以使用各种中间件技术和编程模型加以实现。它对本系列的前一篇文章中介绍的 SOA 编程模型进行了扩展。

引言

SOA 提供了一种灵活的、可扩展且可组合的方法来重用和扩展现有应用程序以及构造新的应用程序。服务声明它们实现的或期望其他服务实现的接口，并且声明控制潜在伙伴交互的策略，从而公布各种功能（包括提供的和请求的）。Web 服务描述语言（Web Services Description Language，WSDL）和其他 Web 服务标准（如 WS-Policy）提供了用于这些声明的词汇。（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#resources]参考资料[/URL]，以获得指向 WSDL Version 2.0 Part 0: Primer 的链接。）

业务功能的虚拟化（SOA 的一个主要目标）是通过将服务的定义和使用与服务的实现分离开来而实现的。我们可以使用各种技术实现服务，这些技术包括 IBM WebSphere&reg; MQ、IBM CICS&reg; 或 IBM IMS™、Java™ 2 Platform Enterprise Edition (J2EE) Enterprise JavaBeans (EJB)、Java 类、IBM DB2&reg; 查询、Java 消息服务 (JMS) 或 Microsoft&reg; .NET。服务请求者将请求发送到提供其所需功能的服务提供者，而不必考虑它如何实现。

ESB 是一种体系结构模式，支持虚拟化通信参与方之间的服务交互并对其进行管理。它提供服务提供者和请求者之间的连接，即使它们并非完全匹配，也能够使它们进行交互。此模式可以使用各种中间件技术和编程模型实现。

本文将定义 ESB 模式和它在 SOA 内的角色。后续文章将详细描述其使用场景、使用目前的技术实现 ESB 模式的方法，以及 ESB 技术未来的发展方向。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

什么是 ESB？

在 ESB 模式中，服务交互的参与方并不直接交互，而是通过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。IBM ESB 模式提供以下几方面的虚拟化：

位置和标识：参与方不需要知道其他参与方的位置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者，而不会带来任何干扰。
交互协议：参与方不需要采用相同的通信协议或交互方式。表达为 SOAP/HTTP 的请求可能由仅理解 Java 远程方法调用 (RMI) 的提供者提供服务。
接口：请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转换为提供者所期望的格式来处理此类差异。
（交互）服务质量 (QoS)：参与方声明其 QoS 要求，包括性能和可靠性、请求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由（如根据工作负载分布标准将请求路由到可用的实现）。描述请求者和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的 ESB 实现。
因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。连接到 ESB 是部署决策；应用程序源代码不会受到影响。

ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件），以产生一个事件作为该系列中的关系的结果。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#fig1]图 1[/URL] 对基本 ESB 模式进行了描述。消息流过将各个通信参与方相互连接在一起的总线。某些参与方会调用其他参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、WebSphere MQ 队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据：SIP 的要求和功能（例如，提供或需要的接口）、它们希望与其他 SIP 的交互方式（例如，同步或异步，通过 HTTP 或 JMS）、它们的 QoS 要求（例如，首选的安全、可靠交互）以及支持与其他 SIP 交互的其他信息（例如，语义注释）。

图 1. 基本 ESB 模式

将总线插入参与方之间，提供了将它们的交互通过称为中介 的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互，可以按顺序将中介连在一起。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#medpat]中介模式[/URL]部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。

ESB 模式为 SOA 实现提供了灵活且易于管理的方法。总线透明地插入端点之间，可以提高服务质量，可以促进请求者和提供者间的交互（而不受协议、交互模式或服务功能不匹配的影响），还可以支持监视和管理。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

SOA 用户角色及其任务

通过研究创建和管理 SOA 解决方案的用户的角色及任务，可以进一步深入了解 ESB 模式。ESB 工具和运行时将 SOA 解决方案的生命周期划分为四个阶段：

发现与描述：对可以在整个 ESB 中进行互连的 SIP 进行标识和描述。这包括创建新的服务、发现现有服务、以及描述其接口、要求和功能。
建模与构建：通过新建的或现有的中介进行 SIP 互连，以描述解决方案的端到端交互。
配置与部署：针对特定的运行时拓扑配置解决方案的抽象声明，并对其进行部署，同时创建必要的运行时构件。
监视与管理：通过 SIP 和中介的行为监视和管理解决方案。此阶段将使用 ESB 运行时中的检测和控制点、以及观测和响应消息流的中介。
对于 ESB 中间件，最重要的 SOA 解决方案开发角色是集成开发人员和解决方案管理员，但其中也涉及到业务分析人员、解决方案架构师、实现人员、适配器开发人员和操作人员。（这些角色都是概念性的；一个人可以担任其中的多个角色。）[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#fig2]图 2[/URL] 显示了这些角色交互的方式。

业务分析人员确定业务需求，并检查业务流程。他们将概括出解决方案的目标、涉及的业务流程、监视解决方案的运行状况和状态的关键指标，以及 IT 系统需要提供的业务服务的类型。

解决方案架构师确定哪些业务需求可以通过对现有 IT 资产进行重用、修改或组合得到满足，哪些需要编写或购买新的 IT 资产。他们定义 IT 资产间的交互，包括消息交换的内容。

开发工作在三个角色中分配。实现人员编写新的应用程序代码，这些代码将通过服务接口调用。适配器开发人员构建包装现有或新采购的应用程序和软件包的服务，从而为其他服务提供可访问性。集成开发人员使用 ESB 的相关工具和技术构建逻辑，以控制请求在这些服务间路由的方式。

图 2. 用户角色

解决方案管理员部署新的 IT 资产并将其服务定义导入到服务注册表中，从而使新的 IT 资产可用。当解决方案就绪后，操作人员将监视其执行，根据需要启动和停止 IT 系统，并给解决方案管理员提供建议（后者可能将据此调整解决方案配置）。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

ESB 模式

集成开发人员和解决方案管理员会使用一组模式对 SOA 解决方案进行设计和部署。

图 3. 基本 ESB 模式的元素

基本 ESB 模式将应用程序组件抽象为一个服务集，这些服务通过总线进行交互（而不是通过直接的点到点通信交互）。某个给定的服务既可以是提供者，也可以是请求者，或者同时兼有两个角色。任何 SOA 实现都会支持基本虚拟化，允许在不影响依赖请求者的情况下替换等效提供者实现。ESB 模式通过其对请求者/提供者交互的显式管理提高了此基本 SOA 功能。只要能提供与请求者所需的功能相似的功能，且 ESB 能对其进行协调，任何提供者都可以由另一个提供者替代。

ESB 提供了交互点，服务可以在此将消息放到总线上或从总线取走。它会对动态消息应用中介，并保证这些托管交互的 QoS。

从 ESB 的角度来看，所有的服务交互端点都是类似的，因为它们都发送或处理请求/事件；它们都要求特定的 QoS；它们可能都需要交互协助。ESB 模式允许集成开发人员以与处理新业务逻辑、流程编排组件或外部 Web 服务同样（面向服务）的方式对待与用户交互的请求者或提供者。

用于构建基于 ESB 的解决方案的模式分为以下几类：

交互模式：允许服务交互点将消息发送到总线或从总线接收消息。
中介模式：允许对消息交换进行操作。
部署模式：支持将解决方案部署到联合基础设施中。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

交互模式

ESB 允许端点通过总线以其本机交互模式进行交互。它支持各种端点协议和交互方式。交互模式的例子包括：

请求/响应：处理端点间的请求/响应方式的交互。此 ESB 基于消息传递模型，因此由两个相关的单向消息流对请求/响应交互进行处理，一个用于请求，一个用于响应。
请求/多响应：上述类型的变体，可以发送多个响应。
事件传播：事件可以匿名分发到由 ESB 管理的相关方列表。服务可以将自身添加到该列表中。

图 4. 交互模式

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

中介模式

中介模式处理总线上的动态消息（请求或事件）。由请求者发出的消息会转换为稍微有些不兼容的提供者（从潜在的端点集中选择）能够理解的消息。

这些中介操作单向消息而不是请求/响应对，因为 ESB 将交互模式放在中介模式上。

图 5. 中介模式

中介有多种基本模式；更为复杂的模式可以通过组合简单模式构建：

协议变换：允许服务请求者使用各种交互协议或 API（如 SOAP/HTTP、JMS 和 MQ Integrator——MQI）发送其消息。将请求代码转换为目标服务提供者的格式。可以应用到交互的请求者端或提供者端，或同时应用到两端或两者之间的任何位置。
转换：将消息的有效负载（内容）从请求者的模式转换为提供者的模式。可以包含包封、反包封或加密。
充实：通过添加来自外部数据源的信息（如由中介定义的自定义参数或者来自数据库查询的自定义参数）来增加消息的有效负载。
路由：更改消息的路由，可从支持请求者的意图的服务提供者中选择。选择标准中可以包含消息内容和上下文、以及目标服务提供者的功能。
分发：将消息分发到一组相关方，通常由订阅者的相关概要驱动。
监视：在信息通过中介时观测其是否发生改变。可以用于监视服务水平；帮助确定问题或对用户进行后续支付使用的货币单位；或记录企业级事件（如价值超过一定数额的购买行为）。还可以用于将消息记入日志，以供审核和后续数据挖掘之用。
相关：从消息或事件流中派生复杂事件。包括模式标识规则和响应模式发现的规则（例如，通过生成派生自触发事件流的内容的复杂事件）。
可以在解决方案中显式地配置中介。例如，集成开发人员可以配置一个 enrich 中介来修改消息内容。解决方案管理员可以配置一个 route 中介来允许其将某个服务提供者切换到脱机状态。

其他中介由 ESB 设置，以满足服务请求者和服务提供者的 QoS 要求。例如，如果服务提供者的安全策略声明要求使用加密消息，则 ESB 可以自动配置一个 encryption 中介。

策略同样也是服务的属性，解决方案管理员可以为交互（或交互集）设置策略。例如，为了将要发送到特定外部提供者或交易值超过 1 百万美元的所有消息记录到日志中。ESB 将通过配置中介（在本例中为monitor 中介）来实现策略。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

复杂模式

图 6. 复杂模式

中介模式和交互模式可以进行组合，以实现更为复杂的模式。

例如，在协议变换后转换格式可以实现规范化适配器 模式，在这种模式中，所有相关方使用的消息和业务对象集都标准化为规范的格式。规范化适配器模式将端点的本机总线附加协议转换为标准协议，实现有效负载规范化，并在交付时进行这些转换的反向转换。

另一种常见的复杂中介是转换、记录和路由 模式。

网关 模式是一个复杂的协议变换变体。它可以合并转换和监视中介，以提供加密、日志记录或审核等功能。它还可以对一对多关系中的消息进行聚合和反聚合。服务门户是此类模式的代表，它为多个服务提供单一联系点，并隐藏内部服务的细节。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

部署模式

解决方案管理可以选择多种 ESB 拓扑。下面是一些常见的例子：

全局 ESB：所有服务共享一个名称空间，每个服务提供者对环境（异构、集中管理但分布在多个地理位置）中所有服务请求者均可见。供部门或小型企业使用，其中，所有服务都可能在整个组织中应用。
直接连接的 ESB：公共服务注册中心使几个独立的 ESB 安装中的所有服务均可见。用于由业务部门提供和管理服务但整个企业中均可使用这些服务的场合。
代理 ESB：桥接服务有选择地将请求者或提供者公开给其他域中的合作伙伴，从而控制多个 ESB 安装（每个安装都管理自己的名称空间）间的共享。ESB 间的服务交互通过实现桥接服务的公共代理进行。供各个部门使用，这些部门开发和管理自己的服务，但共享其中部分服务或者有选择地访问企业提供的服务。
联合 ESB：将多个依赖 ESB 联合到其中的主 ESB。服务使用者和提供者连接到主 ESB 或某个依赖 ESB，以访问整个网络中的服务。供希望在一个监管部门的保护下联合有适度自治权的部门的组织使用。

图 7. ESB 部署模式

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

结束语

ESB 模式扩展了 SOA 的虚拟化功能。可以由标准功能单元组成中介，然后进行部署，以帮助不匹配的请求者和提供者进行交互。ESB 还提供了用于部署和管理服务的通用模型。ESB 概念允许根据用户角色单独进行考虑，从而减少了单个工作人员的概念上的负担，并改进了体系结构的可用性。ESB 的综合编程模型、组件化工具以及基础设施极大地支持了 SOA 原则的提前实现。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

致谢

本文作者要对 Birgit Schmidt-Wesche、John Whitfield、Malcolm Ayres、Mandy Chessell、Peter Lambros、Rick Robinson 和 Robert Berry 表示感谢，感谢他们对本文作出的贡献。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel4/index.html]英文原文[/URL] 。

请阅读本系列文章的第 1 部分“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel/]IBM SOA 编程模型简介 [/URL]”（developerWorks，2005 年 7 月）。

指向 [URL=http://www.w3.org/TR/2004/WD-wsdl20-primer-20041221/]Web Services Description Language (WSDL), Version 2.0 Part 0: Primer[/URL] 的链接。

请访问 [URL=http://www-128.ibm.com/developerworks/cn/webservices]developerWorks 中国网站 SOA and Web services 专区[/URL]以获得大量关于 SOA 和 Web 服务技术的“How to”信息、工具和项目更新。

浏览 [URL=http://www.ibm.com/developerworks]developerWorks[/URL] 中所有的 [URL=http://www-128.ibm.com/developerworks/cn/views/webservices/articles.jsp]SOA and Web services 文章[/URL]和[URL=http://www-128.ibm.com/developerworks/cn/views/webservices/tutorials.jsp]免费的 SOA and Web services 教程[/URL]。

讨论

[URL=http://www.ibm.com/developerworks/forums/dw_wsforums.jsp]参与论坛讨论[/URL]。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks 博客[/URL]加入 developerWorks 社区。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/#main]回页首[/URL]

作者简介

[B][/B]

[B][/B] Beth Hutchison 博士是高级技术人员兼 Web 服务架构师，致力于 IBM 的企业服务总线技术的研究。她一直从事尖端技术领域的工作，最初是第一个分布式平台上的 WebSphere MQ 版本的首席开发人员，随后她担任了 IBM 的 Java 虚拟机的性能架构师。现在她又重新回到 MQ 家族，负责整个 ESB 中的系统管理。

  Marc-Thomas Schmidt 是 IBM 的杰出工程师 (Distinguished Engineer)，已从事了十多年 IBM 的业务集成技术方面的工作，涉及到的领域包括从工作流管理系统，到面向消息的高级中间件，再到业务流程管理技术等方面。他目前负责 IBM 的 ESB 技术的技术架构方面的工作。

  Dan Wolfson 是 IBM 的杰出工程师 (Distinguished Engineer)，在 IBM Software Group 担任 Business Integration Software 的首席技术官。他负责 IBM 的集成软件（运行库和工具）的体系结构和技术策略的制定与实施，并同整个 SWG（特别是 IBM Websphere Business Integration 和 Information Integration 产品）的体系结构与开发团队全面协作。Dan 在商业分布式计算技术的研究方面有 20 多年的经验，涉及的领域包括面向事务和对象的系统、编程语言、消息传递和数据库系统。

  Marcia L. Stockton 在北卡罗莱纳州的三角研究工业园 (Research Triangle Park) 工作，居住在加利福尼亚州，她是 IBM Software Group 的高级技术人员和主要发明人。她也是资深的 IEEE 成员。Marcia 是 Software Group Architecture Board 的 Programming Model Workgroup 的主管，推动横向集成的创新并促进跨 Lotus、Rational、WebSphere、DB2&reg; 和 Tivoli&reg; 产品的编程模型简化。她申请的 73 项 U.S. 专利涵盖的范围从网络、Web、安全、保密、多媒体、无线、普遍设备到无线电频率 ID。最近她致力于为身份管理和边缘服务器分布式编程定义体系结构。她在开发了五年网络软件之后于 1988 加入 IBM。她于 1975 年在 Swarthmore College 获得学士学位。您可以通过 [URL=mailto:mls@us.ibm.com]mls@us.ibm.com[/URL] 与 Marcia 联系。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#author]Stefan Hepper[/URL], WebSphere Portal 编程模型架构师, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#author]Marcia Stockton[/URL], 高级技术人员, IBM

2005 年 11 月

面向服务的编程模型可以简化程序到用户 (program-to-human) 的交互的开发，方法是在用户或者管理员控制下在表示层抽象化接口、标准化消息以及聚合独立信息源。本文是关于 IBM 的 SOA 编程模型的系列文章的第 5 部分，介绍了用户面对的服务并提供了用户界面 (UI)。本系列前面的文章介绍了与语言无关的数据访问和基于面向服务的体系结构（Service-Oriented Architecture，SOA）概念的 Web 服务的编程模型。

面向服务的体系结构的用户界面

在文献中，对 Web 服务的讨论通常是在程序到程序 (program-to-program) 交互的上下文中进行的。然而，

模型-视图-控制器（Model-View-Controller，MVC）范例是现代大多数 UI 应用程序框架的基础。SOA 操作提供模型层，而 UI 位于视图层。UI 技术可以在各种设备上呈现信息，这些设备包括的范围很广，从窗口小部件和智能电话到浏览器和能够进行大量客户端处理的富客户机。中间件和工具将视图层 UI 技术连接到模型层 Web 服务和数据。

在 SOA 方法中，宿主组件的环境抽象成容器，它提供已知的服务集。从 UI 的角度来说，承载客户端 UI 组件的三个主要的容器是：

基本 Web 浏览器。
使用 Java™Script 和动态 HTML 增强的 Web 浏览器。
IBM Workplace™ Client Technology™——具有本地 IBM WebSphere&reg; Application Server 客户机支持的 Eclipse 富客户机。
这些容器可以通过支持下列技术得以增强：Servlet、JavaServer Page (JSP) 和 JSP Tag；用于页面排序的 Struts；用于高级页面组合的 JavaServer Face (JSF)；以及合并在同一页面上的多应用程序视图的 Portlet 技术。

UI 开发框架

UI 开发框架可以简化创建面对用户的复杂应用程序的过程。通常使用下列的 UI 框架来创建 UI 组件：

Struts，拥有最大的开发人员社区和异常工具支持，是 Apache 开放源代码项目，它早于 Java Portlet 规范 JSR 168（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#resources]参考资料[/URL]以获得 Struts Web 站点的链接）。Struts 是使用 servlet/JSP 范例开发基于服务器的 UI 的多页 MVC 框架。Struts 的一个特殊版本 V1.1 库支持 IBM WebSphere Portal 上的 JSR 168 Portlet。
JavaServer Faces 是 Java Web 应用程序的 MVC 实现，以增量方式构建于以前的技术之上。它很好地适应了 Portlet 开发，提供 Portlet 和 Servlet、声明处理、确认和事件处理。JSF 页面具有一个或多个与该页面上的 UI 控件交互的本地模型。这些控件将 UI 属性呈现给输出，而复杂的逻辑确保它们的表示是在“正确的”地方。客户端模型可以连入[URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel4/index.html]企业服务总线 (Enterprise Service Bus)[/URL] 来发送和接收事件。
Java Widget Library (JWL)，是一个可供门户和 Portlet 程序员使用的扩展窗口小部件集，向 JSF 添加 JavaScript 客户端处理，而且将得到 IBM Rational&reg; Suite&reg; DevelopmentStudio 的支持。更新客户机本地视图省去了往返服务器的过程，缩短了几个数量级的响应时间，而且极大地改善了用户体验。
门户 提供了最好的 UI 支持。在门户体系结构中，Portlet（通常是使用上面提到的某种 UI 框架开发的）是基本构件。使用这种体系结构，开发人员可以把主要精力放在他们的应用程序的独特方面，并且将生命周期、每个用户的自定义、聚合以及与其他组件的集成等公共功能委派给中间件。

下面几部分将单个服务和门户的 Portlet 组件描述成服务聚合机制。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#main]回页首[/URL]

面向服务的 UI 的 Portlet

Portlet 组件实现了标准服务接口和协议。Java Portlet 规范和用于远程 Portlet 的 Web 服务（Web Services for Remote Portlet，WSRP）标准分别定义了 Java 和 Web 服务的这个接口（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#resources]参考资料[/URL]以获得更多关于 WSRP 的信息）。这两个标准非常相似，以致如果存在合适的容器或者代理，为任一接口编写的 Portlet 都可互换。

Java Portlet 示例

每个 Java Portlet 都实现了该 Portlet 接口或者扩展了实现它的类。这个接口定义了 Portlet 和它的容器之间的服务约定，以及 Portlet 的生命周期：

初始化 Portlet 并将其放入服务中（init 方法）
处理请求（processAction 和 render 方法）
除去服务的 Portlet（destroy 方法）
在处理请求期间，Portlet 容器调用 Portlet 的：

processAction 方法来通知 Portlet 用户行为。每个客户机只有一个基于用户的行为被触发。Portlet 可以发出一个重定向、改变它的 Portlet 模式或窗口状态或者更改它的状态。
render 方法来请求标记片段。
Portlet 还可以调用更多的服务来执行所需的功能。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#list1]清单 1[/URL] 示例使用 Web 服务来检索和显示特定用户的股票报价。

清单 1. 股票报价 Portlet 代码示例

    public class StockQuotePortlet extends GenericPortlet {

 private ServiceManager serviceManager;

 public void init(PortletConfig config) throws PortletException {
  serviceManager = new ServiceManager();
 }

 public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
  
         response.setContentType("text/html");    

         // invoke autogenerated wrapper to locate service
  NetXmethodsServicesStockquoteStockQuoteServiceLocator loc =
   new NetXmethodsServicesStockquoteStockQuoteServiceLocator();
  NetXmethodsServicesStockquoteStockQuotePortType port =
   loc.getNetXmethodsServicesStockquoteStockQuotePort();

  // loop through all stock quotes the user is interested in
  PortletPreferences prefs = request.getPreferences();
  Iterator quoteKeys = prefs.getMap().keys().iterator();
  String key;
  Float quote;
  StockBean quoteBean = new StockBean();
  while ( quoteKeys.hasNext() ) {
   key = quoteKeys.next();
       quote =  port.getQuote (key);
   quoteBean.add(key, quote);
  }

  request.setAttribute("StockQuoteBean", quoteBean);

  // render stock quotes using a JSP        
        PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher("jsp/View.jsp");
        rd.include(request,response);

 }
}
   

这一部分演示了您可以如何使用 Java Portlet 规范来实现 UI 服务，以及您的 Portlet 可以如何调用其他 Web 服务。下一部分将展示如何使用 WSRP 将 UI 作为 Web 服务发布。

用于远程 Portlet 的 Web 服务

WSRP 是远程呈现 Portlet 的标准，使门户能够从多个源聚合内容。WSRP 将 Web 服务的集成能力扩展到面向表示的组件，并将视图层公开为跨平台、实现语言和供应商共享。可以发现内容和应用程序提供者并将其插入遵循标准的应用程序中，而不必进行任何额外的编程工作。

典型的 Web 服务使用远程表示范例，这意味着所有的视图逻辑在客户机上执行，而应用程序逻辑和数据层（控制器和模型）则驻留于服务器上。与此相反，WSRP 使用分布式范例将客户机和服务器的表示分开。

图 1. 面向数据的 Web 服务和 WSRP 面向表示的 Web 服务的比较

上图展示了这一差异。左边是典型的面向数据的 Web 服务，它提供了无格式的数据；它必须完全依赖于客户端的呈现代码来表示数据。（这意味着需要在客户机上安装和管理客户端应用程序组件。）右边是 WSRP 服务；它的分布式表示逻辑将表示任务分成：

生成标记语言。
将标记片段聚合成一个 Web 页面（没有显示）。
通过标准客户端容器呈现标记语言。

WSRP 示例

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#list2]清单 2[/URL] 展示了一个通过简单对象访问协议（Simple Object Access Protocol，SOAP）从 WSRP 使用者发出的 WSRP getMarkup 请求的示例。

清单 2. 通过 SOAP 发出的 WSRP GetMarkup 请求

    <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"     
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <soapenv:Body>
         <getMarkup xmlns="urn:oasis:names:tc:wsrp:v1:types">
            <registrationContext>
               <registrationHandle>192.168.66.57_1096235652731_0</registrationHandle>
            </registrationContext>
            <portletContext>
               <portletHandle>0.1</portletHandle>   
            </portletContext>   
            <runtimeContext>    
               <userAuthentication>wsrp:none</userAuthentication>    
               <portletInstanceKey>ProxyTest_row1_col1_p1</portletInstanceKey>    
               <namespacePrefix>Pluto_ProxyTest_row1_col1_p1_</namespacePrefix>   
            </runtimeContext>   
            <userContext>    
               <userContextKey>dummyUserContextKey</userContextKey>   
            </userContext>   
            <markupParams>    
               <secureClientCommunication>false</secureClientCommunication>    
               <locales>en</locales>    
               <locales>de</locales>    
               <mimeTypes>text/html</mimeTypes>    
               <mode>wsrp:view</mode>    
               <windowState>wsrp:normal</windowState>    
               <clientData>     
                  <userAgent>WSRP4J Proxy Portlet</userAgent>    
               </clientData>    
               <markupCharacterSets>UTF-8</markupCharacterSets>    
               <validNewModeswsrp:view</validNewModes>    
               <validNewModes>wsrp:help</validNewModes>    
               <validNewModes>wsrp:edit</validNewModes>    
               <validNewWindowStates>wsrp:normal</validNewWindowStates>>    
               <validNewWindowStates>wsrp:maximized</validNewWindowStates>    
               <validNewWindowStates>wsrp:minimized</validNewWindowStates>   
            </markupParams>  
         </getMarkup>
      </soapenv:Body>
   </soapenv:Envelope>
   

WSRP 生产者对这个请求的响应是 HTML 片段，使用者（通常是门户）可以将其聚合成一个完整的文档，例如门户页面。

不是将每个应用程序或 Portlet 部署到有意使用它的每个服务器上，而是跨网络边界共享应用程序，这具有明显的优势。WSRP 支持：

更简单的管理——门户管理员可以浏览要提供的 WSRP 服务的注册中心，而不是管理可插入组件的本地部署。用户受益于及时使用随需应变的新服务和内容集成。
负载分配——跨多个服务器分配负载。
减少基础设施成本——应用程序可以共享承载的基础设施。例如，只分配后端银行应用程序的表示层（通过 WSRP）保护了应用程序提供者的安全计算环境，而与此同时，用户仍可以与共享的 UI 进行交互。
控制内容表示——在门户重新分配内容时，内容和应用程序提供者可以极大地扩展新用户的范围。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#main]回页首[/URL]

门户：面向服务的 UI 的动态集成

门户的视图层将多个后端服务的 UI 集成为一个集中管理的 UI，这样可以统一分离的 IT 基础设施，并通过控制单一的 UI 向用户提供 IT 服务的单一视图。最初分开设计的应用程序可以连接起来构成组合应用程序，用于支持新的功能。例如，连接到协作 Portlet 的电子邮件 Portlet 可以过滤收件箱，使仅当寄件人在线并可以聊天时才显示所收到的电子邮件——这种能力是这两个原始应用程序所不具备的。

这种 portal 模型的重要意义在于改善了随需应变业务 (On Demand Business) 的敏捷性。管理员成为应用程序集成者，定义新的页面，向它们添加 Portlet，将 Portlet 连接在一起并设置权限（访问控制）——不用编程——来创建新的组合应用程序。自服务的门户使用户可以改变他们的工作环境，以适应他们独特的需求。门户体系结构解放了应用程序开发人员，使其能够全神贯注地创造新的业务价值。

将来，门户甚至能够集成组合服务，因而能够在更高的层次上聚合 UI。门户可以无缝地与来自其他门户的内容相集成，从而提供水平的、企业级的内容集成。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#main]回页首[/URL]

总结

使用门户/Portlet 体系结构，将 SOA 概念应用到用户界面，并委派公共的软件生命周期功能给 UI 容器，这改善了软件开发人员的时间价值 (time-to-value)。WSRP 标准通过 Web 服务交付 UI 组件，为内容提供者和内容使用者提供便利，从而在不用进行任何编程的情况下支持某种类型的应用程序集成。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#main]回页首[/URL]

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel5/index.html]英文原文[/URL]。

请阅读 [URL=http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=ZU4VFsoBdj&isbn=1930110960&itm=1]Eclipse In Action: A Guide for the Java Developer [/URL]。

请阅读 [URL=http://search.barnesandnoble.com/booksearch/results.asp?WRD=Pattern%2DOriented+Software+Architecture%2C+Vol%2E+1%3A+A+System+of+Patterns&userid=ZU4VFsoBdj&cds2Pid=946]Pattern-Oriented Software Architecture, Vol. 1: A System of Patterns [/URL]，这是一本介绍本文所涵盖的许多主题的好书。

了解：
[URL=http://www.eclipse.org/]Eclipse 建模框架[/URL]
[URL=http://struts.apache.org/]Apache Struts Web 应用程序框架[/URL]
[URL=http://jcp.org/en/jsr/detail?id=168]Java Portlet 规范 JSR 168[/URL]
[URL=http://jcp.org/en/jsr/detail?id=127]JavaServer Faces[/URL]
[URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp]Web Services for Remote Portlets specification[/URL]

请访问 [URL=http://www-128.ibm.com/developerworks/cn/webservices]developerWorks SOA and Web services 专区[/URL]以获得大量关于 SOA 和 Web 服务技术的“How to”信息、工具和项目更新。

浏览 [URL=http://www.ibm.com/developerworks/cn]developerWorks[/URL] 中所有的 [URL=http://www.ibm.com/developerworks/cn/views/webservices/articles.jsp]SOA and Web services 文章[/URL]和[URL=http://www.ibm.com/developerworks/cn/views/webservices/tutorials.jsp]免费的 SOA and Web services 教程[/URL]。

讨论

[URL=http://www.ibm.com/developerworks/forums/dw_wsforums.jsp]参与论坛讨论[/URL]。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks 博客[/URL]加入 developerWorks 社区。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel5/#main]回页首[/URL]

作者简介

[B][/B]

[B][/B] Stefan Hepper 负责 WebSphere Portal 编程模型和公共 API 的体系结构设计，并且是 Java Portlet 规范 JSR 168 的两位领导者之一。Stefan 还在 Apache 上启动了 Pluto 项目，该项目提供了 JSR 168 的参考实现。他在国际会议（如 JavaOne）上做过许多演说，发表过论文，并且是《Pervasing Computing》一书的合著者。他的研究兴趣包括基于组件的软件体系结构、普及基础设施，当然还有门户和 Portlet。Stefan 获得了德国 University of Karlsruhe 计算机科学的毕业证书，并于 1998 年加入 IBM Boeblingen Development Laboratory。

  Marcia L. Stockton 在北卡罗莱纳州的三角研究工业园 (Research Triangle Park) 工作，居住在加利福尼亚州，她是 IBM Software Group 的高级技术人员和主要发明人。她也是资深的 IEEE 成员。Marcia 是 Software Group Architecture Board 的 Programming Model Workgroup 的主管，推动横向集成的创新并促进跨 Lotus&reg;、Rational、WebSphere、DB2&reg; 和 Tivoli&reg; 产品的编程模型简化。她申请的 73 项 U.S. 专利涵盖的范围从网络、Web、安全、保密、多媒体、无线、普遍设备到无线电频率 ID。最近她致力于为身份管理和边缘服务器分布式编程定义体系结构。她在开发了五年网络软件之后于 1988 加入 IBM。她于 1975 年在 Swarthmore College 获得学士学位。您可以通过 [URL=mailto:mls@us.ibm.com]mls@us.ibm.com[/URL] 与 Marcia 联系。

级别: 中级

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#author]Donald F. Ferguson, Ph.D.[/URL], IBM 名士，Software Group Chief Architect, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#author]Marcia L. Stockton[/URL], 高级技术人员，Chair of Programming Model Workgroup, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#author]Martin Nally[/URL], 首席技术官，IBM Rational Software, IBM

2005 年 12 月 02 日

与语言无关、基于组件的面向服务的体系结构 (SOA) 编程模型简化了实现 Web 服务以及将其组装到解决方案中的过程。使用编程模型，非编程人员可以在没有掌握复杂的技术的情况下使用现有的 IT 资产。它满足了解决方案设计人员和业务分析人员的需要，提供了更高级别的抽象来隐藏实现技术之间的差异，同时还提高了业务可靠性。

为什么需要基于组件的编程模型？

推动 IBM 的 SOA 编程模型的远景依赖于两个重要的观察结果，请看以下两段引言中的精辟描述：

“根据时髦词语设计 (Design-by-buzzword) 是一种常见的情况。至少在软件行业，这种行为或多或少与缺乏对一组给定的有用体系结构约束的理解有关。换句话说，在选择要重用的软件体系结构时，设计人员并没有真正弄清楚这些体系结构之所以好的原因。”
——Roy Thomas Fielding，“Architectural Styles and the Design of Network-based Software Architectures”（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#resources]参考资料[/URL]以获得指向此研究报告的链接）。

这个问题可以通过将详细了解体系结构约束的原因的人的经验融入一组模式、编程构件和工具来解决。

第二个重要的观察结果同人以及人与技术的交互有关：

“创建面向服务的体系结构 (SOA) 意味着重新考虑当前用于构建系统的实践、组织的技能，以及团队成员协作的方式。面向服务的作用在于通过组装不同的应用程序来开发解决方案，SOA 是体系结构样式，强调独立服务提供者的松散耦合。”
——A.W. Brown 等，“Realizing service-oriented solutions with the IBM software development platform”（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#resources]参考资料[/URL]以获得指向这篇文章的链接）。

基于 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&reg; .Net 和 PHP。
SOA 组件封装功能，并支持通过业务分析人员和业务模型建模的抽象级别的重用。这使 IT 功能和它所支持的业务功能之间的映射更加直接，从而提高了可靠性。
声明性的、计算机可处理的约定允许第三方访问 SOA 组件提供的服务。这些约定显式地声明功能性特征以及非功能性（服务质量或 QoS）特征和需求。SOA 组件使用 WSDL 记录它们的操作。还可以使用用于 Web 服务的业务流程执行语言 (BPEL4WS) 来定义组件的有效操作序列。
可以动态地发现、选择、绑定（通过其声明性属性）和集成（使用组合机制，例如本系列第 3 部分“[URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel3/index.html]Process choreography and business state machines[/URL]”（developerWorks，2005 年 7 月）中描述的组合机制）SOA 组件。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

组件实现和专用组件类型

开发人员可以选择使用 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&reg; 应用程序。

因为在性质上 SOA 组件模型是虚拟的，所以许多 SOA 组件自然支持多种实现技术。另一方面，不同的实现技术更好地适合于不同的任务。为了提高透明度，我们引入了服务组件类型的概念，每种类型都适合于具有特定技能、执行特定任务和使用特定工具的开发人员。对于查询，编程人员实现了一个 SQL 文件和一个包含一组 XQuery 语句的文件；对于文档转换，使用为此任务优化的工具实现 XSLT 样式表等等。不需要知道 Web 服务、Enterprise JavaBean (EJB) 或其他组件是在部署时生成的，这是因为总体结果是作为通用 SOA 组件公开和使用的。

编程人员构建一种适合于该任务的特定组件类型，集中于要解决的问题和要使用的工具，而不是结果构件。SOA 开发工具应该集中于开发人员的技能和他或她理解的概念。后续文章将简要介绍一些组件类型，通过三个完全不同的示例——Java 对象、信息管理系统 (IMS) 事务和 SQL 语句——演示如何将任何实现技术映射到公共 SOA 组件模型，同时满足特定开发人员的需要。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

组合

虽然可以使用特定于平台的技术实现 SOA 组合，但是新的以 SOA 为中心的组合类型可以自己实现，而无需转换为另一种编程模型。

使用组合模型，可以发现具有所需的接口和所需的基础设施 (QoS) 策略的服务，并且将这些服务聚合到新的服务、模块和解决方案中。可以组合这些新的服务。

我们的方法统一了创建和访问业务逻辑的范型。我们的 SOA 编程模型比现有的编程构造复杂，隐藏了实现技术之间的不同。在这种模型中，组件组装到模块中，而模块又可以组合到解决方案中。组件公开了可以通过可寻址接口调用的接口。接口是使用 WSDL、Java 或其他语言描述的。实现可能有无法解析的对所需服务的引用，这些服务是执行之前由连接在一起的组件提供的。可以由解决方案集成人员或解决方案组装人员使用适合于角色的工具进行连网操作，他们可以运用可能不为最初开发这些组件的人所知的企业策略和企业服务总线 (ESB) 部署拓扑知识来进行工作。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

在没有进行编程的情况下自定义

不可能始终在没有进行配置、自定义或调整的情况下按原样重用服务。在需要更改时，当前的技术发展水平是修改源代码。然而，是否能够交付可以大量重用的组件在很大程度上取决于组件适应其使用环境的功能。SOA 编程模型应该支持构建“编程人员”可以在没有修改源代码的情况下进行自定义的服务和模块。当使用组件的编程人员与构建组件的编程人员不在一个单位时，这一点尤为重要。

基于组件的 SOA 编程模型提供了几种在没有进行编程的情况下自定义组件的机制。

旨在重用的组件可以打包成具有可变点 (points of variability) 的模板，在将模板放入解决方案时可以对其做一些调整。这种适应性是我们的编程模型最重要的部分，此外，编程模型还包括规则语言和相关工具，用于给新的用户提供自定义功能。

中介主要用于处理动态消息。通常可以在没有进行编程的情况下组合中介。作为一个多协议构造，企业服务总线发挥了重要的作用，可以将服务组件组合在一起进行无缝交互，另外，还允许在消息的路径中插入称为中介 的组件，以在不改变现有端点的情况下代理服务之间的交互，从而在主要方面解决整个企业范围内的问题，例如审核、记录、路由、不匹配接口的适应性、等效组件的增量替换和安全性。

SOA 编程模型的另一个好处（来源于前面提到的特性）是能够在软件生命周期的不同阶段用一个组件替换另一个组件。通过将声明的接口延迟绑定到支持这些接口的实现可以做到这一点。企业为什么需要替换功能单元，有许多方面的原因。其中最重要的原因可能是减少在大型企业中管理更改的困难。以增量的方式引入更改并且通过遵循定义的接口限制其影响可以提高灵活性。这种做法也适合于松散耦合，而松散耦合常常是大型组织的特征。此外，使用服务组件，有不同的技能、需求和时间安排的组可以以人力资源和系统资源两方面的效率都最高的方式在 IT 基础设施中协同工作，这样企业就可以快速地响应业务级的更改，从而使企业大大获益。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

组件定义

我们的 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&reg; Rapid Deployment 中的批注支持可以生成所有组成包含 pragmas 的源文件中的组件的单个元素。例如，Java 源文件中的结构化注释指示哪些 Java 方法将成为所生成的定义组件的服务接口中的 Web 服务操作。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

总结

基于组件的编程模型——由面向任务的工具和运行时基础设施支持——是快速采用 SOA 的关键。借助于期望的优势（如新的软件重用方法），专业人员（不必是编程人员）可以在新的业务需求出现时使用 SOA 组件创建新的业务解决方案和改写现有的业务解决方案。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel6/index.html]英文原文[/URL]

通过这些资源更好地了解不断发展的组件模型：
[URL=http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]Architectural Styles and the Design of Network-based Software Architectures[/URL]
[URL=http://researchweb.watson.ibm.com/journal/abstracts/sj/444/brown.html]Realizing service-oriented solutions with the IBM software development platform[/URL]
[URL=http://www.ws-i.org/Profiles/BasicProfile-1.1.html]Web Services Interoperability Organization, WS-I Basic Profile 1.1[/URL]
[URL=http://www.w3.org/TR/2004/WD-wsdl20-primer-20041221/]Web Services Description Language (WSDL) Version 2.0 Part 0: Primer[/URL]
[URL=http://www.ibm.com/developerworks/library/specification/ws-polfram/]Web Services Policy Framework (WS-Policy)[/URL]
本系列的第 4 部分，“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/]IBM 企业服务总线介绍[/URL]”
[URL=http://www.com/developerworks/library/ws-bpel/]Business Process Execution Language for Web Services v1.1[/URL]
本系列的第 3 部分，“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel3/] 流程编排和业务状态机[/URL]”
[URL=http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML]Object Management Group, Modeling and Metadata Specifications[/URL]
[URL=http://www.jcp.org/en/jsr/detail?id=175]JSR 175: A Metadata Facility for the Java Programming Language[/URL]

请访问 [URL=http://www.ibm.com/developerworks/webservices]developerWorks SOA and Web services 专区[/URL]以获得大量关于 SOA 和 Web 服务技术的“How to”信息、工具和项目更新。

浏览 [URL=http://www.ibm.com/developerworks/cn]developerWorks[/URL] 中所有的 [URL=http://www.ibm.com/developerworks/cn/views/webservices/articles.jsp]SOA and Web services 文章[/URL]和[URL=http://www.ibm.com/developerworks/cn/views/webservices/tutorials.jsp]免费的 SOA and Web services 教程[/URL]。

讨论

[URL=http://www.ibm.com/developerworks/forums/dw_wsforums.jsp]参与论坛讨论[/URL]。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks 博客[/URL]加入 developerWorks 社区。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel6/#main]回页首[/URL]

作者简介

[B][/B]

[B][/B] Donald F. Ferguson 博士是 IBM 的 55 位名士之一，在拥有二十万位技术专业人员的 IBM 工程技术界，名士是 IBM 的最高技术职位。Don 是 IBM Software Group 的首席架构师兼技术主管，负责包括 DB2&reg;、Lotus&reg;、Rational&reg;、Tivoli&reg; 和 WebSphere在内的产品系列。Don 还是 SWG 体系结构委员会 (SWG Architecture Board) 主席，他将 SWG 众多的一流产品架构师团结在一起。Don 最近主要研究 Web 服务、业务流程管理、客户机平台、外包/宿主平台、网格服务以及 WebSphere 应用程序开发。Don 自 WebSphere 产品系列开发以来一直担任其首席架构师，直到 2003 年担任 SWG 的首席架构师。

  Marcia L. Stockton 在北卡罗莱纳州的三角研究工业园 (Research Triangle Park) 工作，居住在加利福尼亚州，她是 IBM Software Group 的高级技术人员和主要发明人。她也是资深的 IEEE 成员。Marcia 是 Software Group Architecture Board 的 Programming Model Workgroup 的主管，推动横向集成的创新并促进跨 Lotus、Rational、WebSphere、DB2 和 Tivoli 产品的编程模型简化。她申请的 73 项 U.S. 专利涵盖的范围从网络、Web、安全、保密、多媒体、无线、普及设备到无线电频率 ID。最近她致力于为身份管理和边缘服务器分布式编程定义体系结构。她在开发了五年网络软件之后于 1988 加入 IBM。她于 1975 年在史瓦斯摩学院 (Swarthmore College) 获得学士学位。

  Martin Nally 是 IBM 的杰出工程师，他于 1990 年加入 IBM，之前具有 10 年工作经验。他是 IBM VisualAge&reg; Smalltalk 的首席架构师兼开发人员和 IBM WebSphere Studio 的首席架构师兼总体开发经理。他设计和构建工具以及设计编程模型抽象达 10 年之久。他目前的头衔是 IBM Rational 软件的首席技术官。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#author]Anthony Nadalin[/URL], 首席安全架构师和杰出工程师, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#author]Nataraj Nagaratnam[/URL], 高级技术人员, IBM
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#author]Maryann Hondo[/URL], Web 服务安全标准主管, IBM

2005 年 12 月 02 日

保护面向服务的体系结构（service-oriented architecture，SOA）中的应用程序具有挑战性，因为 SOA 的松耦合特性可能暴露现有安全实现的弱点。以下解决方案包括定义明确的信任模型（基于可接受的验证形式），并糅合了策略、Web 服务安全性和安全工程最佳实践。
引言

对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则构造的实现的服务、应用程序以及跨组织操作的松耦合，因此安全对其甚至更为重要。这种环境往往会暴露现有安全实现的弱点或局限性。

即使不考虑通过由模型驱动的开发和基于 SOA 的服务管理所提高的效率，业务应用程序仍须保护信息。只保护周边设施（如防火墙和路由器）是不够的，因为随需应变的企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态信任关系。因此，安全的随需应变企业需要灵活的、可自定义的基础设施，以适应新要求和规章制度。要提供这种灵活性，不应将策略生搬硬套到基础设施中；应该通过由策略驱动的基础设施满足安全模型的要求，这任务可不简单。

本文将阐释业务应用程序利用随需应变安全基础设施的安全功能的方式，以及建立用于保护面向服务的应用程序的编程模型的设计原则。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

业务应用程序和安全基础设施

安全集成以及对业务应用程序和信息的访问通常是通过身份验证、授权和责任实现的。企业探讨管理身份验证、授权和责任的方式在很大程度上取决于其对客户、雇员和合作伙伴之间的信任关系的看法；这些关系对业务应用程序安全的影响；以及这些应用程序的相对重要性和安全性。

在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护。可能还需要用安全的方式保存敏感信息。必须保证消息源的完整性（如通过公证服务）才能在必要时启用验证、审核和认可。可能需要对敏感信息进行加密以实现机密性，或对其进行数字签名以实现完整性。（数字签名也可用于认可。）完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保护保存的内容以遵守政府规章制度和业界最佳实践的需要。

安全策略的制定和执行以及所执行的安全级别，基本上都取决于企业及其雇员、客户和合作伙伴之间的信任关系。证书和密钥之类的相关技术可用于反映和管理这些信任关系。工具可用于建立业务合作伙伴、客户和企业等之间的信任关系模型并指定信任关系，还可以将信任定义转换成适用于 IT 环境的技术。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

SOA 安全模型

SOA 安全模型基于 Web 服务可能需要其中的传入消息以验证一系列声明的过程。名称、密钥、权限和功能都是声明的例子。根据所提供的证据，会在请求者、服务端点和一系列可能的中介之间应用适当的信任模型。

消息可能会通过请求者和目标服务之间的若干中介。端到端安全性必须考虑到请求者、中介和最终端点服务（提供者）之间的信任模型，如[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#fig1]图 1[/URL] 所示。

图 1. 从请求者通过中介到提供者的信任模型

对于消息处理，网络和传输中介（如防火墙、路由器和代理服务器）一般不受信任。应该防止传输中的所有消息受到不可靠中介的篡改。

OASIS Web 服务安全性（Web Services Security，WSS）规范提供对传输中的简单对象访问协议（Simple Object Access Protocol，SOAP）消息的保护。可用 WSS 防止消息的真实性、完整性和机密性受到不可靠网络和传输中介的攻击。

图 2. 消息中介代理信任关系和联合

并不是所有中介都不可靠。Web 服务网关和企业服务总线中介服务都是消息转换中介的例子，其在 SOA 内的功能包括检查，在某些情况下还包括对消息有效负载的修改 [请参阅此系列中的第 4 部分，“[URL=http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel4/index.html]IBM 企业服务总线简介[/URL]”（developerworks，2005 年）]。在设计 SOA 安全基础设施时，请考虑允许某些受信任的中介。

处理请求者和应用程序服务主机之间的信任关系的消息代理可能是另一个受信任的中介。在这种设计中，安全责任由代理和服务端点来分担。如[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#fig2]图 2[/URL] 所示，消息中介将负责消息级安全、请求者和提供者环境之间的身份联合，以及管理请求者和服务提供者之间的信任关系。服务只有为了满足特定于服务的安全要求（如建立（通过中介映射和联合）访问特定于消息有效负载中应用程序数据的服务、完整性和机密性数据的身份）才会继续起安全作用。通过分解业务应用程序中脆弱或复杂的基础设施代码并将其委派给容器，基于 SOA 的安全方法可以提高灵活性并降低发生不测事件的可能性。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

消息安全性

WSS 规范还提供一系列有助于 Web 服务开发人员保护 SOAP 交换的基本消息级完整性、机密性和身份验证机制。可用各种方式组合这些机制，以便用各种加密技术建立各种安全模型。

WSS 还提供可扩展的机制，以便将安全令牌与含有各种身份验证及授权格式和机制的消息相关联。例如，客户机可能会提供身份证据及其具有特定业务证书的已签名声明。然后收到这种消息的 Web 服务就可以确定是否要信任其声明和信任的程度。

安全令牌声明可由授权机构核准或不核准。一组已核准的声明通常表示为安全令牌（经过数字签名或受到授权机构加密保护）。X.509 证书就是一个熟悉的已签名安全令牌例子；它断言某人的身份和公钥之间的绑定关系。安全令牌可以“推送到”消息中或者在消息中携带安全令牌，也可以通过引用表示安全令牌，以便接收方从授权机构“拉取”该声明。

因为安全令牌是在信任域内起作用的，所以需要有链接信任域作用范围的方式。可通过协议或通过实现一系列规则强制执行信任策略来手动链接。这样，如果发送方和接收方之间有已确立的信任关系，则可信任未经核准的声明。例如，如果发送方和接收方使用的是其通过带外信任关系建立的可靠连接，则发送方为 Bob 的未核准声明足以让某些接收方认为发送方实际上就是 Bob。在本例中，此可靠连接的存在可作为确凿的证据。

防止消息内容受到非法访问（机密性）或非法修改（完整性）是主要的安全事务。WSS 规范提供通过对主体、标题、附件或其任意组合（或部分）进行加密和/或数字签名保护消息的方法。

身份验证请求基于可选网络、由传输支持的安全性和消息中已批准的信息（声明）的组合，这种技术称为消息源身份验证可能更好一些。通过网络和由传输提供的安全性、消息中已批准的声明，以及用收件人已知的密钥对请求进行加密，请求者可以对收件人进行身份验证。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

信任模型

演示安全令牌已授权应用的一种方式是，添加采用相关联密钥（来自于占有证据令牌）的数字签名。这会使请求者可通过将安全令牌（如 X.509 公钥基础设施（Public Key Infrastructure for X.509，PKIX）证书或 X.509 证书）与消息相关联来证明所请求的声明组。

如果请求者没有向服务证明请求的声明所必要的令牌，则可与相应的授权机构（我们称为安全令牌服务）联系，并用正当的声明请求所需的令牌。安全令牌通过发布一系列安全令牌（可用于在不同的信任域之间代理信任关系）来形成信任的基础。

一种机制是应用 WS-Trust（对于有关 WS-Trust 规范的更多信息，请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#resources]参考资料[/URL]）中所定义的质询回应协议。这种机制由 Web 服务用来对请求者进行更多质询，以确保消息不过时，以及验证安全令牌的使用是否已经授权。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#fig3]图 3[/URL] 所示的就是此模型，可以看出任何请求者也都可以是服务，请求者和目标服务都具有受信任的第三方安全令牌服务，这种服务有助于验证每个目标服务策略所需的安全令牌。

图 3. 安全令牌服务

此 SOA 安全模型（声明、策略和安全令牌）还含有并支持若干特定模型，如基于身份的授权、访问控制列表和基于功能的授权。通过该模型可使用现有的技术，如 X.509 公钥证书、基于 XML 的令牌、Kerberos 共享秘密票证，甚至口令摘要。SOA 模型结合 Web 服务安全对话语言（Web Services Secure Conversation Language，WSSC）和 Web 服务策略框架基本要素，这足以构造高级密钥交换、身份验证、基于策略的访问控制、审核和复杂的信任关系。

将对 Web 服务应用策略，Web 服务会从请求者收到可能包括安全令牌的消息，还可能会对其通过 WSSC 机制应用某些保护措施。下面是由 Web 服务的信任引擎执行的主要步骤：

验证令牌中的声明是否足以遵从策略，以及消息是否与策略一致。
验证申请人的特征是否可由签名来证明。在代理式信任模型中，签名不可以证明申请人的身份；签名可以证明中介（只是可断言申请人的身份）的身份。声明经过批准或不是基于策略。
验证安全令牌（包括所有相关和即将颁发的安全令牌）的颁发者是否可信，可以颁发其所作的声明。信任引擎可能需要外部验证或代理令牌（也就是向安全令牌提供服务发送令牌，以便用其交换其他可直接用在其评估中的安全令牌）。
如果满足了这些条件，而且请求者有权执行操作，则服务可以处理服务请求。

可将 IP 安全（IP Security，IPSec）或传输层安全/安全套接字层（Transport Layer Security/Secure Sockets Layer，TLS/SSL）之类的网络和传输保护机制与此 SOA 安全模型结合使用，以支持不同的安全要求和方案。如果可用，作为附加安全技术，请求者应该考虑采用网络或传输安全机制，以便在颁发、验证或更新安全令牌时对收件人预先进行身份验证。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

编程模型设计原则

从安全的角度来看，编程模型包括对于谁负责实现安全策略（如基础设施或应用程序）所作的决策，以及需要让请求者得到此信息的哪一部分。除了操作方面，某些设计期间的策略（如在 J2EE 描述符中捕获的）也有助于管理应用程序。是通过使基础设施能够实现安全模型，还是通过将安全的实现转换成每个应用程序中的代码来最大程度地满足业务需求，这是关键实现决策之一。要考虑的另一方面是调用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性？最后，在实现安全解决方案时，应该考虑安全工程——用于构建安全应用程序的工程方法。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

由基础设施管理的安全与由应用程序管理的安全

每个组织通常都会让某些人负责确定和实现其安全策略。在许多情况下此过程都是手动的，从而导致组织投入大量资源在不同的实体和应用程序之间协调访问。

我们建议复杂的组织在基础设施中集中实现与解决方案相关的安全策略——也就是验证用户质询（如用户 ID/密码）、控制对应用程序的访问（如对 travelService 执行 reserve() 方法），以及委派身份（如运行方式 travelAgency id），以确保方法一致。可在某些部署构件（如 J2EE 应用程序的部署描述符）中定义初始应用程序安全策略。部署完毕后，熟悉大部分应用程序逻辑时就可以向部署环境提供策略信息了。可将策略声明概括成高级策略要求，以备将来细化成实现约束条件，这被认为是部署阶段的工作。

应用程序设计中引入了有关由基础设施管理的安全与由应用程序管理的安全的决策。安全约束和条件是附加到实现构件的。决定是让基础设施处理安全，还是将安全转换成应用程序中的代码的时机在实现阶段，此时通常可以得到有关应用程序平台（如 Java™ Platform Enterprise Edition (J2EE) 和 Microsoft&reg; .NET）的信息。

我们建议将应用程序的重点放在业务逻辑、延迟服务访问的保护和送往基础设施的消息（承载应用程序的运行时容器）上。在这种由基础设施管理的方法中，附加到设计构件的安全策略将被转换成特定于平台的策略 [例如，通过统一建模语言（Unified Modeling Language，UML）模型表示的要求将转换成 J2EE 部署描述符]。

在由应用程序管理的方法中，安全实现是在应用程序中实现的，必须实现相应的安全调用。即使是由应用程序管理的安全也必须通过 Java 身份验证和授权服务（Java Authentication and Authorization Service，JAAS）将其安全调用（如 authenticate()）转换成相应的特定于平台的功能[如 loginContext.login()]。

授权和访问控制的粒度粗细不等。细粒度访问（对于解决方案本身）与粗粒度访问（对于其操作之一）的选择通常取决于业务和技术考虑。粒度也会受各种因素的影响，包括信息实体的实例（如特定游客的信用帐户概要信息）、上下文信息，如用户特征（如旅行社）、时间约束（如从早上九点到下午五点）、访问目的（如进行旅游预订的目的）、访问路径（例如，内部网请求与外部请求），以及许多其他因素。

可通过定义应用程序角色概括与授权相关的策略，其中的角色是指一组通过其可对特定应用程序资源执行某些操作的权限。例如，旅行应用程序可声明对 ReservationBean 执行的 view() 或 change() 预订方法可由 TravelAgent 角色访问。换句话说，TravelAgent 是由实现方案定义的角色，可以确定可由“旅行社”执行的操作；根据一组用于对各自企业 JavaBean（Enterprise JavaBean，EJB）调用特定方法的权限。在实现阶段不大可能定义的是谁拥有 TravelAgent 特权。用户到角色的指派通常是在部署时开始的，然后会在应用程序的整个生命周期内对其进行管理。[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#list1]清单 1[/URL] 所示的是用于定义某些基于角色的方法权限的示例代码。

清单 1. 用于定义某些基于角色的方法权限的代码
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
   <method-name> view</method-name>
   <method-name> change</method-name>
</method>
</method-permission>
   

在执行某些业务逻辑之前要求提供通过身份验证的身份信息的应用程序必须从基础设施中得到该信息。例如，在 J2EE 环境中，运行时会在身份验证后确定用户的身份；应用程序可通过 API（如 getCallerPrincipal()）检索此信息。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

选择的灵活性

客户机运行时有时需要某些对访问服务本身的要求或约束（包括身份验证、完整性和机密性要求）。而支持各种客户机运行时（如浏览器客户机、非浏览器客户机和 PDA 瘦客户机）可能是令人满意的。要支持各种客户机运行时，请发布断言客户机运行时必须确保消息机密性，并必须提供用户身份的证据（用户 ID/密码或证书）的策略。身份验证的策略概括可列出替代选项，如可接受的凭据类型，或所信任的凭据颁发机构。

例如，TravelService Web 服务可声明其要求某些安全令牌类型的意图和机密性要求。实现方案可通过描述符支持意图声明。工具则可进而生成必要的机器级详细信息（如 WS-SecurityPolicy 表达式），如[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#list2]清单 2[/URL] 所示。

清单 2. WS-Security 策略描述符示例
<wsp:Policy>
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:KerberosV5APREQToken
              sp:IncludeToken=".../IncludeToken/Once" />
        </wsp:Policy>
      </sp:ProtectionToken>
      <sp:SignBeforeEncrypting />
      <sp:EncryptSignature />
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>
   

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

安全工程

在开发安全解决方案的过程中，安全工程是最佳实践之一——请遵循定义明确的模式，以使您的应用程序、服务或组件可以完全实现其设计者和用户的期望。您应该估计每个实现方案构件中固有的风险，对其进行设计和实现以防其暴露在弱点下（例如，高效的内存管理并避免出现隐蔽的通道）。工具支持和代码评审也有助于将对从中部署解决方案的环境的损害降到最低（或彻底避免）。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

总结

SOA 编程模型必须确保每个服务调用都符合对请求者和服务端点均有效的安全策略。安全基础设施（包括对请求者进行身份验证和对其授予服务访问权的能力、基于基本信任模型跨 Web 服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容）形成了有助于保护组件和服务的 SOA 环境的结构。所有 SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。基于 Web 服务安全规范的 Web 服务安全模型和方法有助于解决保护面向服务的应用程序的难题。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/library/ws-soa-progmodel7/]英文原文[/URL]

访问 OASIS 网站，以获得更多关于 [URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss]OASIS Web 服务安全性：SOAP 安全性[/URL]的信息。

阅读本系列的第 4 部分“[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel4/]IBM 企业服务总线介绍[/URL]”（developerWorks，2005 年）。

获得更多关于 [URL=http://www.ibm.com/developerworks/library/specification/ws-trust/]Web Services Trust Language[/URL] 的信息。

查找更多关于 [URL=http://www.ibm.com/developerworks/library/specification/ws-secon/]Web Services Secure Trust Conversation Language[/URL] 的内容。

了解更多关于 [URL=http://www.ibm.com/developerworks/webservices/library/specification/ws-polfram/]Web Services Policy Framework[/URL] 的内容。

访问 [URL=http://www-128.ibm.com/developerworks/cn/webservices/]developerWorks SOA and Web services 专区[/URL]，以获得范围广泛的关于 SOA 和 Web 服务技术的“如何”信息、工具和项目更新。

浏览 [URL=http://www.ibm.com/developerworks/cn]developerWorks[/URL] 中所有的 [URL=http://www.ibm.com/developerworks/cn/views/webservices/articles.jsp]SOA and Web services 文章[/URL]和[URL=http://www.ibm.com/developerworks/cn/views/webservices/tutorials.jsp]免费的 SOA and Web services 教程[/URL]。

讨论

[URL=http://www.ibm.com/developerworks/forums/dw_wsforums.jsp]参与论坛讨论[/URL]。

通过参与 [URL=http://www.ibm.com/developerworks/blogs/]developerWorks 博客[/URL]加入 developerWorks 社区。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-progmodel7/#main]回页首[/URL]

作者简介

[B][/B]

[B][/B] ANadalin 是 IBM Software Group 的首席安全架构师。作为杰出的工程师，他负责安全性基础设施设计和开发。他是 Sun Microsystems JavaSoft Division 的首席安全联络人，从事 Java 安全的设计及开发协作。在他 24 年的 IBM 职业生涯中，承担了各种职务，从 IBM VM/SP 首席安全性架构师和 AS/400 安全性架构师，到 OS/2 安全性架构师。他撰写和与他人合著了 40 多篇技术期刊文章和会议文章。他还出版了 Java 安全性及 Internet 方面的几本书籍。此外，他是各种 Web 服务安全规范的作者和编辑。

  Nagaratnam 博士是标识管理的首席架构师和随需应变的安全性基础设施和技术策略的安全性架构师主管。作为高级技术人员，他推动跨 IBM 产品和平台的安全性体系结构和设计活动。在他的 IBM 职业生涯中，曾担任 IBM WebSphere Application Server 的安全性体系结构主管和 IBM WebSphere 平台的安全性体系结构主管。他领导和参与了包括 JCP、OASIS、WS-I 和 GGF 在内的标准组织的各种开放标准活动。他撰写和与人合著了许多期刊文章、论文、书籍和安全性规范，其中包括 [URL=http://www.amazon.com/exec/obidos/tg/detail/-/0321118898/qid=1125512812/sr=8-1/ref=pd_bbs_1/104-0003506-0558311?v=glance&s=books&n=507846]Enterprise Java Security[/URL] 一书。

  Hondo 是 IBM Software Group 新兴技术方面的 Web 服务安全标准主管。她于 1996 年加入 IBM Lotus，担任 Lotus e-Suite 的安全性架构师，并参与 JAAS 的开发。她的工作背景包括在 HP 研究基于 DCE 和 PKI 的 Single SignOn、在 Digital 研究 B1/CMW 操作系统，以及在 AT&T Bell Labs 研究 B2 Unix。她是由 IBM 和其他业务合作伙伴于 2002-2004 发布的 WS-Security、WS-Policy、WS-Trust 和 WS-Secure Conversation 规范的合著者。在加入新兴技术组之前，她管理 IBM Tivoli IETF PKIX 参考实现开发组 (Jonah)，并是 SOA 研究团队的一员，SOA 研究团队开发了第一个新兴技术工具包（可以在 IBM developerWorks 上找到）。她的标准活动包括担任 Open Group 的 Single SignOn 工作组的主管、Electronic Business XML (ebXML) 的安全性团队的主管和 Universal Description Discovery and Integration (UDDI) 的安全性工作组的主管，参与 OASIS 技术委员会（SAML、WS-Sec、和 XACML）的工作，并且是 Open Mobile Alliance MWS 和安全性工作组的一员。