Web 2.0 SOA | 快乐成长

来源：http://www.ibm.com/developerworks/cn/webservices/redbooks/soa-case/11.html

本红皮书中案例研究的重点是 Web 2.0 SOA 场景，以及 JKHLE 如何使用该场景的 3 个实现来改进公司的旅行代理业务。本红皮书具体介绍以下 Web 2.0 实现：REST 式服务创建、呈现和使用 REST 式服务、用户界面 (UI) 组合和通信。

Web 2.0 技术概述

Web 2.0 代表一个不断发展的互联网平台。Web 1.0 是指人与计算机的交互以及提高计算机效率的技术。Web 2.0 是指人通过计算机进行交流以及提高使人类生产力的技术（参见图 1）。

图 1. Web 1.0 和 Web 2.0

图 1. Web 1.0 和 Web 2.0 Web 2.0 改变了业务与其客户之间的交互方式。注意关于 Web 2.0 的以下信息：

它是可消费服务、富互联网应用和简化的编程模型。
它构建了环境关系并促进了知识共享。
它与人及其协作方式有关。

代表性状态传输 (REST)

代表性状态传输 (REST) 是互联网构建的体系架构模型。REST 之所以流行是因为其简单性和易用性。

REST 提供了以下原则：

REST 提供了一种资源导向型服务方式（相对于 RPC 导向型服务方式）。
所有资源都可以通过相对 URL 进行寻址，例如：/JKHLE/employees 和 /JKHLE/employees/sandy。
REST 通常使用 HTTP 作为传输协议并支持 HTTP GET、POST、PUT 和 DELETE。
可以使用在 Web 浏览器（或任何其他客户端或服务器）中运行的代码轻松访问 REST 式服务，并且可以轻松保留 REST 式服务并利用现有内容。
REST 中的领先实践源于 Web 的使用，因为它是为使用而构建的。

RESTful SOA

RESTful SOA（有时称为 WOA 或 ROA）是 SOA 的一个实例，它使用来自 Web 的概念作为主服务架构：

更易实现 SOA 的有限选项
主要使用 REST 表示和访问服务
将数据编码为 JSON 或 XML（包括 XML 模式，比如 ATOM）
在适当的时候可以使用其他方法，比如 JSON-RPC
支持使用 AJAX 构建的 富用户界面

REST 风格的架构保留 SOA 原则。它支持以组件为中心的模型，在该模型中各种服务器端和客户端组件可以以一种可伸缩且简单的方式重用。

案例研究简介

如前所述，JKHL Enterprises (JKHLE) 是一个虚拟公司，它期望能扩展其旅行代理部门。在本节中，我们将介绍 JKHLE 公司的业务和技术挑战，并检查其当前的基础设施（当前架构）。

从事旅游业的 JKHL 公司

JKHLE 拥有一个旅行代理部门，该部门使用一个在线旅行网站提供所有旅游资源的一站式访问。该旅行代理公司的主要业务包括：

航班预订
酒店预订
游艇预订
天气状况
交通状况
城市信息（比如方向和感兴趣的领域）

JKHLE 想开发一种最好的旅行网站。该网站应该能够为客户提供易用的服务，并简化公司的基础业务流程。

JKHL 公司的业务挑战

JKHLE 有以下一些急需解决的业务挑战：

提供一种快速且简单的架构，以快速地向客户和合作伙伴交付新产品。
使用第三方的新界面，如天气和交通报告。
通过利用 SOA 基础设施和可消费的服务端消除业务孤立。
持续快速地提供简单的新业务数据和服务。
降低呼叫中心成本。
以可消费的形式向公共网络公开业务数据。

当前架构和技术挑战

KHLE 使用的当前架构如图 2 所示。

图 2. 当前架构

图 2. 当前架构该架构提出了以下技术挑战：

业务策略被嵌入到业务流程中。业务策略的更改需要更新业务流程，但是更新业务流程非常缓慢、昂贵且容易出错。 随着 JKHLE 的持续扩展，此限制将变得尤为突出。
每个业务系统都孤立运行，当试图为客户实现多渠道策略时，这就会造成重大问题。
很难将第三方服务集成到整体解决方案中。但是包含这些第三方服务很重要，因为它们有助于将 JKHLE 的旅行产品与其竞争者区分开来。
类似地，第三方公司在与 JKHLE 的服务集成时也会遇到困难，这就限制了外部各方使用 JKHLE 的旅行服务。

使用 Web 2.0 SOA 场景实现

Web 2.0 SOA 场景可用于帮助 JKHLE 解决其业务和技术挑战。该场景定义了 3 种实现：

RESTful Service 创建实现

描述映射到数据源的基于资源的模式。

Rendering and Consuming RESTful Services 实现

描述呈现数据的格式，以及基于 RESTful 服务架构的数据使用。

UI Composition and Communication 实现

描述从 REST 式服务到用户收集的数据展示。

每个实现都可以组合或单独使用以解决业务解决方案。

将要使用的架构

为了解决其业务和技术挑战，JKHLE 构建了一个新架构，该架构使用 Web 2.0 SOA 场景的原则。图 3 展示了此架构，以及使用实现的位置。

图 3. 将要使用的架构

图 3. 将要使用的架构新的架构具有以下优势：

业务逻辑和业务策略现在是独立的实体，这就支持对业务流程变量的快速、简单且不间断的补充。
简化的开发界面使 JKHLE 业务流程能够更容易地调用第三方服务，并使得第三方服务能够更方便地调用 JKHLE 的服务。
新服务和新渠道可以快速集成到架构中。

客户端和 RESTful 服务器的解决方案

JKHLE 要采用的架构将充分利用客户端和 RESTful 服务器之间的设计模式，如图 4 所示。

图 4. 客户端和 RESTful 服务器的解决方案模式

图 4. 客户端和 RESTful 服务器的解决方案模式该解决方案模式的使用如下所示：

客户端（通常是 RIA）向 RESTful 服务器发出一个基于资源的调用。
服务器将 JSON、XML、RSS 或 ATOM 的负载返回到客户端。通过 RIA 或调用服务来使用返回的负载。
客户端对 XMLHttpRequest (XHR) 调用使用 GET、POST、PUT 或 DELETE 方法，以映射到 RESTful 实体行为。

产品映射

图 5 展示了 JKHLE 用于实现将要使用的参考架构的产品。

图 5. 产品映射

图 5. 产品映射在本红皮书的其他部分，我们将更详细地介绍每个实现，以及 JKHLE 用于实现每个实现的产品。

RESTful Service 创建实现

JKHLE 使用 RESTful Service 创建实现来解决互联网服务域和服务集成域之间的交互，如图 6 所示。

图 6. JKHLE 使用 RESTful Service 创建实现的位置

图 6. JKHLE 使用 RESTful Service 创建实现的位置以下架构考虑因素与 RESTful Service 创建实现有关：

创建 REST 式服务的数据源（比如 Web 服务、数据库和屏幕抓取）
Java™ 对象（比如 Java beans、EJB™ 3 和 JPA）
映射到后端实体的资源模型
安全性
治理

设计模式

本节将介绍 REST 式服务创建实现的 2 种设计模式。第一种设计模式如图 7 所示。

图 7. 设计模式

图 7. 设计模式该设计模式描述了以下信息：

现有遗留数据被转换为 REST 式服务。
每个资源有一个 URI/URL，并且这些资源使用 REST 实体模式进行公开。
可以使用简化的实体命名规则。例如：GetOrderServices?ordernumber=12345 可更改为 /rest/orders/12345。
REST 式服务提供的每种操作都是一种 HTTP 方法。例如，URI 为 /JKHLE/hotel/reserve 的资源能够使用 GET /JKHLE/hotel/reserve 进行调用。
REST 服务负责调用应用程序服务。该应用程序服务可以通过一个适配器与另一个后端服务的企业服务总线进行连接。

第二种设计模式如图 8 所示。

图 8. 设计模式

图 8. 设计模式这个设计模式描述了模式的构建方式：

构建 Java EE 工件，比如 EJBs、servlets 或重用现有 Java EE 工件。
使用 WebSphere® Application Server Feature Pack for Web 2.0 公开这些工件，如通过 HTTP 的 JSON，或通过 HTTP 实体的 XML。
必要时使用 WebSphere DataPower® in the DMZ 添加更多 Web 2.0 安全性服务和转换。
根据客户端发送正确的 HTTP 内容。例如，将 JSON 发送到 Web 浏览器，将 XML、ATOM 和 RSS 发送到其他客户端。

Rendering and Consuming RESTful Services 实现

JKHLE 使用 Rendering and Consuming RESTful Services 实现来解决消费者渠道和互联网服务域之间的交互，如图 9 所示。

图 9. JKHLE 使用 Rendering and Consuming RESTful Services 实现的位置

图 9. JKHLE 使用 Rendering and Consuming RESTful Services 实现的位置以下架构考虑因素与 Rendering and Consuming RESTful Services 创建有关：

响应负载（比如 XML、JSON、 ATOM 和 RSS）
REST 界面分组治理
安全性（包括 HTTPS 和 SPNEGO）

运行时考虑因素

以下产品可用于实现 Rendering and Consuming RESTful Services 创建：

WebSphere Application Server Feature Pack for Web 2.0
通过 REST 公开基于 Java EE 的工件。
WebSphere sMash
为创建 Web 2.0 应用提供了开发和运行时环境。
提供与 Dojo widgets 和 Groovy 或 PHP 脚本的紧密 REST 集成。
WebSphere DataPower
提供了 Web 2.0 应用，支持 REST-SOAP 和 JS 检查。

本节将介绍这些产品的作用，以及在 Rendering and Consuming RESTful Services 实现中使用这些产品的设计模式。

WebSphere Application Server Feature Pack for Web 2.0

Web 2.0 Feature Pack 扩展了 WebSphere Application Server 的功能，它具有以下组件：

Web 2.0 到 SOA 的连接性

该组件用于支持从 Ajax 客户端到 SOA 服务和其他 Java EE 资产的连接性。该组件通过 Web 提要将企业数据扩展到客户和合作伙伴。

Ajax 消息传输

该组件用于将 Ajax 客户端连接到即时更新数据，比如股票报价或即时通信。

Ajax 开发工具集

该组件是 WebSphere Application Server 基于开源 JavaScript™ 运行环境的最佳 Ajax 开发工具集。

Web 2.0 Feature Pack 可以在设计模式中使用，如图 10 所示。

图 10. 设计模式

图 10. 设计模式该设计模型支持将 Ajax 客户端和混搭应用程序连接到外部 Web 服务、内部 SOA 服务和其他 Java EE 资产。它通过 Web feeds 向客户和合作伙伴扩展企业数据。

WebSphere sMash

WebSphere sMash 支持开发人员使用集成运行环境和工具包中的 PHP 脚本、REST 和 Dojo 快速构建并灵活地执行基于 Web 2.0 的应用程序。WebSphere sMash 侧重于快速面市、易于开发和部署，以及惯例优先原则。

WebSphere sMash 提供了干净且简单的 REST 界面。每个 REST 都由一个事件处理程序文件定义，并具有映射到 REST 动词的独特函数。例如，REST 动词 POST 映射到事件方法 onCreate()， 并拥有名为 /resources/people 的示例 URL。

WebSphere sMash 提供了将响应数据到 XML、JSON 和 ATOM 的自动化转换。

WebSphere DataPower

WebSphere DataPower 是一个特殊的网络应用集合，它有助于集成、简化和加速 SOA，并加强安全性。 WebSphere DataPower 可以多种方式支持 Rendering and Consuming RESTful Services 实现：

RESTful 资源聚合：

场景：跨多个服务实现的资源请求。这些调用的结果需要聚合或组合成一个复杂的报告。
解决方案：WebSphere DataPower 充当定义聚合资源 URI 的中介。该中介将请求传送给供应商并聚合响应。

媒体类型转换：

场景：现有供应商实施一种媒体类型，而客户端需要其他媒体类型。
解决方案：WebSphere DataPower 充当在请求信息中转换 Accept 头部和在响应信息中转换 Content-Type 头部的中介。该解决方案扩展了线速转换。

REST / SOAP 仲裁：

场景：供应商支持 REST，但是现有客户端需要 SOAP。
解决方案：WebSphere DataPower 充当公开 SOAP 的中介。它将请求信息从 SOAP 转换到 REST，并将响应信息从 REST 转换到 SOAP。

版本仲裁：

场景：消费者和供应商各自发展。目标是最小化供应商实现的数量。
解决方案：WebSphere DataPower 充当代理多个资源版本的中介。资源请求转换为新版本。还将执行任何需要的标题和实体转换、改进或筛选。

服务仲裁质量：

场景：消费者签订使用资源配额的合同。必须监控该使用合同，并且根据请求率和请求数量执行。
解决方案：必要时，WebSphere DataPower 充当监控和执行服务限制质量、调速和请求形成的中介。

UI Composition and Communication 实现

JKHLE 使用 UI Composition and Communication 实现，以提供业务域的更多功能，如图 11 所示。

Figure xxx. Requires a heading

图 11  JKHLE 使用 UI Composition and Communication 实现的位置

以下架构考虑因素与 UI Composition and Communication 实现有关：

无状态实体
框架（比如 Dojo 和 JSF）
容器（比如 portlets、iWdigets 和 iViews）
治理
安全性（包括 HTTPS 和单点登录）

运行时和工具考虑因素

因为有很多客户端软件和技术可供选择，所以 IBM 意识到它必须支持从异构到客户端 SOA 这一范围内的所有领域。为了实现该目的，IBM 制定了以下策略：

支持通过标准进行 UI 聚合。

这包括 Web 标准（比如 JSR 53 和 JSR 127）、portlet 应用（比如 JSR 286 和 JSR 168）、混搭（比如 OpenAjax 和 iWidget）和丰富的台式机 / 设备（比如 Eclipse 和 iView）。

通过产品交付开源聚合。

IBM 提供并宣传应用内容的技术。这包括客户端容器的 W3C 开源 / Web 标准和开源框架（比如 Web 浏览器和 Lotus® Expeditor），以及台式和移动应用的 Eclipse 和 SWT。

支持通过中间件进行客户端 UI 集成。

IBM 完全支持用户集成、边缘集成和 SOA 层之间的集成。

IBM 端到端软件客户端平台策略如图 12 所示。

图 12. IBM 端到端软件客户端平台策略

Dojo

Dojo 是一个用 JavaScript 编写的开源 DHTML 工具集。Dojo 支持将动态功能轻松地构建到 Web 页面中。Dojo 提供了许多功能，并且由 3 个主要层构成：Dojo Core、Dijit 和 DojoX。

Dojo 工具集是一个 JavaScript 工具集，它具有丰富的用户界面，用于开发 Ajax 应用。它在大多数现代客户端容器上都能很好地工作，并且占用资源少、性能高。IBM 支持 Dojo 工具集；在 Dojo 工具集中创建的 Ajax 应用可以被 WebSphere Application Server 和 WebSphere Portal 使用。

可从以下网址下载 Dojo 工具集：