Mashup 业务场景和模式:第 2 部分

本文是一个分两部分的系列的第 2 篇文章,该系列讨论可用于部署 mashup 以解决业务需求的使用和架构模式的关系。本文描述用于实现第一篇文章 “Mashup 业务场景和模式:第 1 部分” 中谈到的业务场景和使用模式的解决方案架构和架构模式。

Holt Adams, 执行 IT 架构师, IBM

Holt Adams 是 IBM Software Emerging Technology 团队的执行 IT 架构师,目前为 IBM 的 jStart 计划和 Customer Innovation Team 提供支持。技能上的优势使他能够同时胜任解决方案架构师和项目经理的职位,并促进客户采用新兴 Internet 技术。他在客户合作的业务和技术方面都拥有丰富的从业经验,这些客户活动包括潜在顾客开发(lead generation)、经营资格(business qualification)、需求管理、解决方案架构、解决方案设计和合同谈判。作为一名 IT 架构师,在构建最先进的解决方案的过程中,Holt 将客户业务需求提炼成 IT 需求,从而用新兴技术中的 IT 功能来解决这些需求。在从事 jStart 计划和其他服务相关工作期间,他涉及的技术领域包括无线/普及计算、Internet 基础设施、Java/J2EE、XML、Web 服务/SOA、开放源代码、Web 2.0、社会网络和企业 mashup 技术。



2009 年 4 月 30 日

使用 mashup 解决企业需求,这项技术的采用已进入指数级增长阶段。很多行业正在通过一些常见的使用和架构模式,利用这项技术解决独特的业务场景。

mashup 解决方案的不同之处在于用户角色和聚合的数据集,以及由此创造的独特价值。在很多情况下,使用模式(例如捕捉搜索标准、在用户界面中呈现数据、根据主数据选择更新辅助表、操纵数据和与其他人通信)是类似的,但是对于不同的客户,解决的业务目标有所不同。

mashup 可供选择的设计和架构取决于选择的实现平台。可以使用很少的设计和架构模式来实现利用大量常见使用模式的业务场景(例如,RSS/ATOM feed 的使用,REST 服务的调用,通过 pub/sub 模型的 widget 通信,通过中央 hub 的数据源聚集,以及数据源和服务源上的数据过滤)。

简介

近几年来,IBM® software Emerging Technology 团队(jStart)一直与客户和业务伙伴合作,在概念证明环境中利用各种 mashup 技术(例如 QEDWiki、IBM Mashup Center)解决不同的业务需求,以验证这项技术的有用性。正如本系列 第 1 部分 所述,jStart 团队的工作经历产生了这些技术的一些常见的场景和解决方案实现,并且编制了文档,形成了正式的工件。早期的采用者利用这些工件提出企业 mashup 的价值主张,这些工件也是本系列文章的基础。

在所有解决方案开发流派中,资产重用是很常见的(比如方法学、设计概念和组件的重用),所有流派都鼓励资产重用,以提高效率、减少开发成本和加快进度。当这些资产被广泛地、可重复地重用时,它们常常被称作模式(pattern)。该术语本身就是通用的,可以单独或组合使用该术语来描述业务场景、使用交互、架构设计和实现。对于本系列的文章,当描述受支持的交互,以及 mashup 应用程序的设计和实现的架构方面时,将使用这个术语。


业务场景与使用和架构模式

本系列的 第 1 部分 谈到了一些业务目标和场景,包括多个行业中使用的客户服务、资源管理、个人指示板、个人通信、消费者服务、企业资源定位器、现场服务支持和供应链管理场景。这些场景被描述为解决特定业务目标的高级业务活动。场景的实现意味着业务用户以常见的方式和特定的技术通过交互执行任务,这些方式在本系列中被称作使用模式。上一篇 文章中概述的使用模式包括个人在使用 mashup 界面的特性或控件时所执行的常见的步骤(例如登录到 mashup,输入搜索标准,从表中选择数据,将鼠标移到图像上,添加或更新数据记录)。当用户与 mashup 中的控件或显示的数据交互时,执行的一些动作会导致 mashup 进行某种处理,这种处理将改变 UI 本身的呈现(例如导航、控件可见性),调用其他软件中的服务或数据源,或者在 mashup 中显示附加的信息和图像。

图 1. 场景和模式
场景和模式

mashup 应用程序中对受支持的行为和交互的实现是由它的底层架构限定的。mashup 应用程序由一些被称作 widget 的组件构成。这些 widget 被链接在一起,以创建用于聚合要显示的数据和供用户执行动作的 UI 和模型。这些 widget 可以是可视化的,以便用于呈现 UI,也可以是隐藏的,以便用于执行后台处理。可视化 widget 也可以执行或发起后台处理。

widget 之间的链接(编程式耦合或通信)形成了一种机制,它使 mashup 能够为用户提供一种交互式的、响应快的体验(例如,单击一个 widget 的控件,会导致其他 widget 中的数据刷新,或者导致界面中呈现附加的 widget)。如何定义和实现链接取决于 mashup 应用程序平台。

平台还决定如何实现架构模式。本文将阐述这个话题。核心基础设施模式包括发布/订阅消息传递和安全性。一些架构模式定义数据检索、聚合和数据过滤的常见方式,还有一些则概述外部系统集成的设计(例如用于认证的用户注册表)。

这些架构模式提供实现本系列 第 1 部分 中讨论的使用模式,以支持 mashup 的行为和用户交互的设计。归纳起来,第 1 部分中的使用模式可分为以下几类,以支持 图 2 中显示的交互模型:

  • 访问控制和个性化模式
  • 呈现 mashup UI 和数据模式的检索
  • 数据模式的查看和操纵
  • 与其他模式的通信
图 2. 早期采用者交互模型
早期采用者交互模型

无论业务目标、用户角色、数据或者行业焦点是什么,大多数业务场景都可以用图 2 中的交互模型表示。


架构模式

mashup 应用程序通常可描述为在浏览器中呈现的应用程序 widget 组件的轻量级集成(例如,部署为一个 HTML 页面,并将相关 widget 打包为 WAR 文件)。架构模式提供构造 mashup 应用程序的高级设计,并显示解决方案组件之间的事件流。它们具有一定的平台独立性,并为通过使用模式(前面小节谈到)实现一个或多个业务场景提供框架。

IBM Mashup Center

IBM Mashup Center 用于实现前面所述的业务场景和使用模式。IBM Mashup Center 由 IBM Lotus® Mashups、IBM InfoSphere™ MashupHub 和 IBM Lotus Widget Factory 以及一个共享储存库(catalog)组成,如图 3 所示。

图 3. IBM Mashup Center
IBM Mashup Center

Lotus Mashups 和 InfoSphere MashupHub 具有用于创建和管理 mashup 应用程序及其组件的基于浏览器的工具。此外,Lotus Widget Factory 为创建部署到 Lotus Mashups 并注册到 InfoSphere MashupHub 中的 widget 提供环境。Lotus Mashups 提供用于创建 mashup 应用程序的 mahsup 组装器(widget 在浏览器中连到一起),同时还提供一个轻量级 mashup 服务器,用于部署和运行 mashup 应用程序。mashup 服务器将一个 mashup enabler 装载到浏览器,这个 mashup enabler 提供一个 mashup 运行时,以便执行 mashup 组件和在它们运行期间管理它们。InfoSphere MashupHub 为共享用于 mashup 应用程序的 Web、企业、部门和个人信息提供环境。这个 hub 为创建 mashup 应用程序使用的 feed 和 feed mashup 提供便利。这三个产品都使用 HTTP、JSON、XML、Java™Script、Atom 和 RSS 等 Web 技术将相关的内容交付给用户。

图 4. IBM Mashup Center 的架构
IBM Mashup Center 的架构

如图 4 所示,Feed Creation、Data Mashups 和 Catalog 组件是由 InfoSphere MashupHub 提供的,它们使用户可以注册 widget、mashup 页面和可在 Intranet 或 Internet 上访问的已有 feed。在 InfoSphere MashupHub 中,可以用简单的基于浏览器的 UI 创建和注册 feed 和 feed mashup。在这样的 UI 中可以图形化地定义用于聚合和转换从企业、部门和个人数据源提取的数据的操作和函数。通过基于浏览器的工具,mashup 作者还可以发现和共享注册 feed 和 widget,以便在使用 Lotus Mashups 创建 mashup 应用程序时使用它们。创建好 mashup 应用程序之后,还可以将它们存储在 catalog 中,以供其他人使用。

为了部署 mashup 应用程序,Lotus Mashups 提供了一个轻量级 mashup 服务器,而 InfoSphere MashupHub 则提供了一个 feed 生成组件和一个转换引擎。mashup 服务器是用于访问 mashup 应用程序的 URL 的目标,它将页面和相关的 widget 装载到浏览器中。当 widget 访问 InfoSphere MashupHub 中注册的 feed 时,feed 生成器将访问 catalog,以获取连接数据源所需的元数据。feed 生成器使用该元数据访问数据源,并在聚合或转换来自一个或多个数据源的数据时调用转换引擎。

jStart 解决方案架构

图 5 显示了 jStart 团队用于实现早期采用者的 mashup 解决方案的逻辑解决方案组件。用绿色填涂的组件是前面描述的组件和在架构模式中讨论的组件之外的解决方案组件。

图 5. 解决方案架构概图
解决方案架构概图

架构模式中使用的逻辑运行时组件有:

  • Browser Mashup Runtime(通过 mashup enabler 实现)。浏览器中的 mashup 运行时提供一个 JavaScript 框架,用于呈现由 widget 组成的 mashup UI,以及管理 widget 之间的交互与链接、数据源(企业或公共数据源)和从其他供应商那里获得的服务。在浏览器中装载和呈现 widget 之后,这些 widget 就成为 Browser Mashup Runtime 组件的一部分。
  • Mashup Server(通过 Lotus Mashups 轻量级 mashup 服务器实现)。Mashup Server 组件提供用于部署和托管 mashup 应用程序的运行时基础设施。从浏览器向服务器调用 mashup 应用程序后,Mashup Server 组件装载服务器端组件,并将 Browser Mashup Runtime 组件和相关的 widget 组件发送到浏览器。

    mashup 服务器有 2 个子组件,即 Virtual Member Manager 子组件和 AJAX HTTP Proxy 子组件。对于 jStart 实现,这 2 个组件实际上由部署 Lotus Mashups 的 WebSphere® Application Server 提供。

    • Virtual Member Manager。这个子组件增加一个抽象层,并将用户认证委托给一个安全性系统(比如 WebSphere Application Server 安全性)。在安全性系统上,可以使用虚拟成员管理数据库、本地操作系统、LDAP 或定制的用户注册表进行用户凭证的认证。
    • AJAX HTTP Proxy。这个子组件使 Browser Mashup Runtime 组件中运行的 widget 可以访问其他的域,而不仅仅是从中装载 mashup 应用程序的域。浏览器实施一种 “同源(same origin)” 策略,以防止 JavaScript 等客户端脚本(widget 正是基于这种脚本)从使用不同协议、域名或端口的源装载内容。这个逻辑组件是使用 WebSphere Application Server HTTP proxy 实现的。
  • Feed Data Source。提供支持 RSS 或 Atom 格式的 XML 数据的系统就是一个 Feed Data Source 组件。该组件使用这些格式和相关的协议聚合经常更新的内容。
  • Enterprise Data Source。本文将不支持聚合 feed 的企业系统称作已有系统,以便与聚合数据源区分开来。这些系统可以在部门内使用,也可以跨业务线使用,它们是集成到 mashup 应用程序的重要信息源。这些系统的例子包括 Microsoft® Access、IBM DB2®、LDAP、IBM Lotus Domino®、IMS 和 SAP。此外,XML、CSV 和 Microsoft Excel 格式的文件也是 mashup 中使用的重要的信息来源。
  • Mashup Hub(通过 InfoSphere MashupHub 实现)。Mashup Hub 组件为 IT 和商务职业人士提供一个信息管理环境,以便他们开启和共享企业数据,包括 Web 2.0 应用程序和 mashup 中使用的 Web、部门、个人和企业信息。Mashup Hub 组件访问这些数据源(例如 RSS、Microsoft Access、IBM DB2 XML、LDAP、Lotus Domino、IMS、SAP、CSV、XML 和 Microsoft Excel),以创建 Atom feed。同样,Mashup Hub 可以对来自一个或多个数据源的数据进行聚合、转换(即应用操作符和函数进行过滤或重构)或排序,以创建合并的 Atom feed,即所谓的 feed mashup。
  • User Registry。该组件是一个储存库,用于持久化用户账户信息,如用户 ID 和密码、许可和角色,以便提供 Web 资源的认证和授权。
  • Servlet。该组件是一个 Java 服务器端组件,它使在浏览器中运行的 widget 可以访问 Web 服务器上部署的组件和应用程序(例如 IBM Lotus Sametime® server)的 Java API,以扩展 mashup 应用程序的功能。

下面的架构模式用于支持本文列出的业务场景和使用模式:

  • 模式 1:用户登录(认证和授权)
  • 模式 2:对辅助数据视图的简单查询
  • 模式 3:对聚合的辅助数据视图的查询
  • 模式 4:对从其他供应商获得的服务聚合的查询
  • 模式 5:对数据源进行数据更新的查询
  • 模式 6:团队协作

有一个模式本文没有明确提到,但是出现在下面的序列图中,即 pub/sub 消息传递。这个低级模式是在 Mashup Browser Runtime 组件中实现的,它使 widget 可以发布和订阅事件,以提供 widget 之间的链接。尽量使用公共的共享参数,减少事件类型,而不是使用惟一的参数并导致很多的事件,这对于减少或消除 widget 之间的级联事件非常重要。开发 widget 之间事件流的详细序列图,以优化事件的使用和公共数据的 post。这也是十分有益的。

模式 1:登录(认证和授权)

作为 mashup 应用程序的进入点,mashup 服务器负责每个用户的认证和授权。这一步可以由 mashup 服务器执行,也可以由 Mashup Server 部署到的基础设施执行,如 图 6 所示。对于 Lotus Mashups,可以使用 IBM WebSphere Application Server 的 Virtual Member Management(VMM)组件在 VMM 数据库中定义用户和用户组。同样,对于受 WebSphere Application Server 支持的本地操作系统注册表、LDAP 目录或定制的用户注册表,Lotus Mashups 可以利用它们执行认证和授权。

图 6. 模式 1 的序列图
模式 1 的序列图

如果需要利用用户注册表保障 mashup 应用程序的安全,那么可以使用 WebSphere Application Server 的联邦储存库功能,以利用用户和组管理功能。

除了保障对 mashup 应用程序本身的安全访问外,还可以控制对 mashup 应用程序使用的特定数据源或服务的访问。当 mashup 应用程序集成受保护的数据源或从其他供应商获得的服务时,若要访问这些系统,需提供凭证。为了避免为每个数据源一一执行用户认证,可以利用单点登录。对于 WebSphere Application Server,在初次认证期间会生成一个安全标志(LTPA 标志),并将该标志返回给浏览器,用于接下来对服务器端数据源和服务的 widget 请求。LTPA 标志使 WebSphere Application Server 可以执行用户授权,以控制对受 WebSphere Application Server 保护的任何 Web 资源(例如 RSS、Atom、Servlet、REST 服务或 Web 服务)的访问。

如果数据源或服务在 WebSphere Application Server 安全域之外,那么可以在 Mashup Hub 中通过注册一个已有的 feed,或者为非聚合数据源创建新的 feed,来捕捉安全凭证(例如用户 ID 和密码)。无论哪种情况,都会为 feed 创建元数据,其中包括必要的凭证。当 mashup 应用程序中的 widget 通过 Mashup Hub 调用 feed 时,会将适当的凭证添加到请求中,以允许托管数据源或服务的后端系统执行认证和授权。后面其他模式图中会展示这个级别的安全性。

模式 2:对辅助数据视图的简单查询

图 7 中显示的架构模式是最基本的,它支持对多个数据集进行简单的查询。用户登录到 mashup 服务器(详细的交互没有显示)之后,mashup 服务器返回所需的 widget,这些 widget 将呈现 mashup 应用程序的 UI,其中包括一个搜索表单。捕捉到搜索标准后(关键词、单选按钮、复选框或菜单选择),用户提交搜索请求,系统从一个或多个 Atom/RSS 数据源检索主数据集和辅助数据集。如果检索的数据量较小,这种方法比较有利。然后,用户可以通过选择特定的主数据记录,并将更详细的数据填充到辅助表或图形中,或者反映在图像或地图中,以便查看它们,这样不会延误接下来的请求。当选择 widget(例如一个表)中呈现的数据时,Browser Mashup Runtime 组件中会自动开始发布一个事件,以通知侦听该事件的其他 widget,使它们可以进行相应的处理,以便在用户界面中呈现附加信息。

图 7. 模式 2 的序列图
模式 2 的序列图

在最简单的情况下,当需要控制访问时,mashup 应用程序的创建者可以确定允许使用 mashup 应用程序的用户或组。因此,部署 mashup 应用程序后,mashup 服务器可以通过集成的 WebSphere Application Server VMM 功能轻松地控制访问。图 7 中显示的模式假设登录期间捕捉到的用户凭证足以访问托管主数据和辅助数据的系统,因而可以为用户提供单点登录。登录期间创建的安全标志(LTPA)随数据请求传递到后端系统,使后端系统可以执行授权,从而提供对数据的有控制的访问。还应注意通过 AJAX HTTP Proxy 发出的对数据源的请求,通过这种方式可以访问与 mashup 服务器不同源的系统。

这个模式及后续的一些模式主要集中于聚合 feed 的使用,mashup maker 工具中有很多已有的使用 feed 的 widget,因此不必开发定制的 widget 就可以轻松创建 mashup 应用程序。而模式 4 和模式 5 则涉及访问非聚合格式的数据的其他选项。

模式 3:对聚合的辅助数据视图的查询

图 8 所示,这个模式扩展了模式 2,在检索组合的辅助数据集时将两个已有的聚合 feed 聚合成一个 feed mashup。当从初始主数据集选择一个数据记录之后,会从 mashup hub 调用一个 feed mashup,从而产生两个不同的对独立的 feed 数据源(RSS 或 Atom)的请求。在创建作为 Atom feed 返回给 mashup 应用程序的聚合 feed 时,可以使用 mashup hub 转换(过滤、重构、排序)数据。

图 8. 模式 3 的序列图
模式 3 的序列图

通过由 mashup hub 执行数据的转换,这方面的工作负载就从浏览器转移到后端组件,而且可以通过配置后端组件获得最佳性能。同样,如果需要访问企业内外受保护的数据 feed(不是部署在 WebSphere Application Server 上),或者访问 Internet 上的付费 feed,那么可以通过将这种 feed 注册到 mashup hub,捕捉登录和安全凭证。mashup 应用程序通过 mashup hub 访问受保护的 feed,mashup hub 充当一个代理,为系统提供适当的凭证,以允许访问数据源。mashup 应用程序的创建者注册受保护的 feed 和它们的凭证,并负责确保 mashup 应用程序的用户获得访问受保护 feed 的授权。

上面的模式假设 mashup 服务器和 mashup hub 安装在同一个系统上,因此不需要 AJAX HTTP Proxy。而且,这个模式可以聚合两个以上的数据源,为 mashup 应用程序提供高度相关的来自不同数据源的数据集。

模式 4:对从其他供应商获得的聚合数据源和服务聚合的查询

图 9 所示,这个模式类似于模式 3,但数据源不一定是 RSS 或 ATOM 聚合 feed,而是从其他供应商获得的企业数据源或服务(例如 Microsoft Access、DB2 XML、LDAP、Lotus Domino、IMS、LDAP、SAP、CSV、XML、Microsoft Excel 和已有的 feed)。

在这个模式中,mashup hub 扮演着关键的角色,它与不支持聚合格式的已有系统交互,使 mashup 应用程序可以利用它们。mashup hub 具有用于每个受支持的已有系统的适配器和插件,mashup 可以配置这些适配器和插件,为利用已有系统的 API 提供 feed 的登录凭证、参数和其他元数据。可以单独访问已有的系统,为每个数据流创建单独的 feed,也可以与多个系统交互,将它们的数据流组合成一个聚合的 feed。

图 9. 模式 4 的序列图
模式 4 的序列图

和模式 3 中一样,可以使用 mashup hub 转换数据(过滤、重构或排序),并支持对受保护数据源的访问控制。由于 mashup hub 充当一个网关,在已有系统与 mashup 应用程序之间执行协议转换,并且可以进行配置,以执行数据转换,因此在设计 mashup 应用程序的导航时,为了减少 UI 延时,考虑它的性能影响很重要。例如,可以考虑在呈现数据之前预先访问已有系统并下载数据,利用已有系统的 API 在数据源上进行过滤,将数据迁移到常见的已有系统以减少集成的系统的数量。此外,还可以调用粗粒度的服务,最大化已有系统的处理能力。

模式 5:对数据源进行数据更新的查询

大多数 mashup 应用程序的初始阶段都实现搜索和查看交互和行为,以改善决策、提供生产力和帮助定位专门技术和内容。然而,由于不能更新或创建数据记录,改善非正式业务流程或团队成员之间的协作这方面的价值受到很大的妨碍。如 图 10 所示,这个模式扩展了其他模式,它允许用户更新主数据集和辅助数据集,或者创建在后端系统上的持久化新记录。

到目前为止谈到的这些模式只展示了使用聚合 feed 访问数据源的 Browser Mashup Runtime 组件(即 widget),实际上还可以使用一些无需修改就可使用的 widget 来快速创建 mashup 应用程序。但是需要注意,还可以开发与服务器端组件(例如 servlet)交互的 widget,以提取需要或可用格式的信息。

图 10. 模式 5 的序列图
模式 5 的序列图

由于 widget 是 mashup 应用程序中的主要构建块,因此可以开发支持系统端组件的适当协议和 API 的 widget,以便直接访问那些系统托管的资源。这些接口包括用于聚合 feed 资源的 Atom Publishing Protocol,REST 或 Web Services Description Language(WSDL)服务,或支持访问 Java Platform, Enterprise Edition(Java EE)上 Java API 的 servlet 等 Java 组件的调用。为了支持更新和协作交互和行为,需要在用于 widget 开发的 IT 资源上放置依赖。同样,任何可以从这些接口提取的信息,都可以由一个 widget 获取,以便用于填充主数据视图和辅助数据视图(例如关于联系人列表中每个联系人的在线信息)。

模式 6:团队协作

除了更新和创建供其他成员执行业务流程时使用的数据记录外,还可以通过允许团队成员轻松地进行通信,为他们提供帮助。现在有一些供 IT 专业人士使用的通信选项和工具,但是当主数据集或辅助数据集包含联系方式信息(例如姓名、电话号码和电子邮件地址)时,将它们集成到 mashup 应用程序可以创造价值。通过在 mashup 应用程序中提供通信选项,用户可以直接发起消息传递或语音呼叫,而不必切换到另一个应用程序,复制用户联系方式信息,并将它输入到应用程序(电子邮件客户机、即时消息传递客户机或电话键盘)。如 图 11 所示。

图 11. 模式 6 的序列图
模式 6 的序列图

为简单起见,这个流图中省略了 AJAX HTTP Proxy,但是当访问从中装载 widget 的 mashup 服务器以外的数据源或系统时,对 widget 的调用都要经过 AJAX HTTP Proxy。


结束语

如今的 mashup 应用程序可以使用一个简单的交互模型来描述,这个模型支持搜索、查看、协作和更新行为。mashup 可用于业务场景,为常见的交互提供支持。在这些交互中,用户采取行动,mashup 应用程序则返回一个或多个响应。使用 mashup 的每个行业的用户角色和数据不尽相同,它们为解决行业的业务需求提供独特的价值。但是,使用模式是相似的,因为底层的 IT 需求基本相同。业务场景可通过一些常见的使用模式实现,这些使用模式则可以用一组有限的架构模式来实现。

这个系列的文章根据早期采用者的使用经验,浅谈了 mashup 技术所能创造的一些可能性。让业务用户自主创建情景应用程序,解决自身的需求或问题,这是可以用 mashup 技术和 IBM Mashup Center 实现的价值。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Lotus
ArticleID=386388
ArticleTitle=Mashup 业务场景和模式:第 2 部分
publish-date=04302009