使用 Project Zero 和 WebSphere sMash Assemble Flow 构建 Mashup 应用，第 2 部分: 使用 Assemble Flow 开发简单协作流程

文档选项 未显示需要 JavaScript 的文档选项 讨论 样例代码

级别： 中级

朱 可 (zhukecdl@cn.ibm.com), 软件工程师, IBM 中国软件开发中心
李 文兵 (liwenb@cn.ibm.com), 软件工程师, IBM 中国软件开发中心
易立 (markli@cn.ibm.com), 顾问软件工程师, IBM
毛 新生, Web 2.0 首席架构师，资深技术主管, IBM 中国开发中心

2009 年 5 月 11 日

在使用 WebSphere® sMash 中的 Assemble flow 来构建 Mashup 应用的第 1 部分中，我们介绍了 Assemble flow 的基本概念，以及如何使用 Assemble flow 来实现基于 Feed 的 Mashup 服务。本文中，我们将向您介绍如何使用 Assemble flow 来开发简单的协作流程。

引言

本系列将向您介绍如何利用 Assemble Flow 迅速组装 Web2.0 应用程序及创建 Mashup 应用。 第 1 部分: Assemble Flow 简介 第 2 部分: 使用 Assemble Flow 开发简单协作流程

Assemble flow 作为 WebSphere sMash 中的一个重要组件，提供了针对 Web 2.0 应用的一个流程语言。它有以下几个显著特征：

1. 简单：遵循 80/20 原则，Assemble flow 提供了一个简化而灵活的流程模型。与 BPEL（Business Process Execution Language，业务流程执行语言）相比，它实现了最为常用的流程功能来满足简单应用的开发，比如顺序执行、分支、循环、错误处理等等，但是语法却大大简化了。 正因为其简单、快速和敏捷的特点，它非常适合开发情景式 Web 应用。 当然如果需要分布式事务和补偿机制等高级流程特性，我们建议您采用 IBM WebSphere Process Server 和并使用 BPEL 进行开发。
2. 面向 REST：作为面向 Web 的流程语言，REST（Representational State Transfer）服务成为 Assemble flow 中的头等公民。Assemble flow 在流程中可以便捷地访问 REST 服务和资源；而且 Assemble flow 也提供了 REST 风格的接口，使得其他参与者也可以通过 REST 的方式与流程进行交互。
3. 可扩展性：Assemble flow 是一个可扩展的流程语言，用户可以定义扩展活动类型来创建自己领域专用的流程模型。比如，现有的 Assemble flow 可以方便作为：Feed 为中心的数据流程， REST 服务流程和简单的协作流程。

本文将注重介绍如何使用 REST 风格接口与 Assemble flow 进行交互，并利用 Assemble flow 构建简单的协作流程。

开始之前

你需要具备以下先决条件来完成本文的示例应用程序：

• JDK 5.0 或更高版本。
• WebSphere sMash 1.0.0.4 或更高版本的命令行环境。
• 通畅的网络连接来连接 SMTP 邮件服务器。
• Firefox 3.0 用于启动 WebSphere sMash 的集成开发环境 AppBuilder。

下面将介绍如何使用 REST 风格接口与 Assemble flow 进行交互，并利用 Assemble flow 构建简单的协作流程。

回页首

在 Assemble flow 中访问 REST 资源和服务

REST(Representational State Transfer) 是 Roy Fielding 提出的一种以资源为中心的分布式体系架构，而互联网（World-wide web）就是符合 REST 架构的一个大规模分布式系统。 比如我们拥有一个基于 REST 架构的博客服务，它的 REST 接口如下：

在这个服务之中：

1. 所有的资源都拥有一个明确的 ID，在 Web 中所有资源都是由 URI 来标识。比如一个特定名称的博客资源可以通过如下 URI 进行访问：http://www.example.com/blogs/blog-name。
2. 所有的资源都拥有统一的接口：比如 HTTP 协议中的 GET/POST/PUT/DELETE 分别对应着对 REST 资源的读取/创建/修改/删除操作。使用 HTTP 的 REST 服务应该在应答消息中使用标准的 HTTP 状态码，比如：成功的操作都会返回 200；如果系统无法根据资源的 ID 找到它，就会返回 404。系统故障导致的任何错误都会返回 500 。

1. 创建新博客:
   <POST target=”http://www.example.com/blogs/”>
<input body=”${newBlog}”/>
</POST>
2. 获取博客内容:
   <GET target=”http://www.example.com/blogs/blog-name” />
3. 修改博客信息:
   <PUT target=”http://www.example.com/blogs/blog-name”> <input body=”${blogInfo}”/> </PUT>
4. 删除博客:
   <DELETE target=”http://www.example.com/blogs/blog-name” />

备注： Assemble flow 支持 Groovy 作为流程中的脚本语言，所以我们可以方便地动态构建资源 URI。比如：blogName 变量的值是博客名称，我们可以通过如下方法来返回指定的博客资源信息: <GET target="http://www.example.com/blogs/${blogName}" />

回页首

面向 REST 的流程接口

Assemble flow 提供了一组基本的活动来提供 REST 风格的流程接口。

• receiveGET/replyGET：一组匹配的活动用于接受和响应 GET 请求；
• receivePOST/replyPOST：一组匹配的活动用于接受和响应 POST 请求；
• receive-replyGET：将成对出现的 receiveGET/replyGET 活动的简化为一个活动；
• receive-replyPOST：将成对出现的 receivePOST/replyPOST 活动的简化为一个活动。

receivePOST 活动可以接收 POST 方法的 HTTP 请求，并且根据 HTTP 请求中的“Content-Type”消息头将消息体解析为可以被流程引擎处理的 Java 数据类型.

在流程中我们可以通过 receivePOST 的名称或 outputVariable 指明的变量来访问接收 POST 的方法。

replyPOST 活动的基本定义如下:
<replyPOST name="NCName" url="relative-url"? view="view"? redirect="redirect-url"? outputUri="GC_URI"?>
control*
input?
</replyPOST>

replyPOST 活动支持一个名为“body”的可选 input 作为活动输入，并可以使用如下属性。

注：replyPOST 活动没有输出值

Receive-replyPOST 是一组 receivePOST 和 replyPOST 的缩写，它的的基本定义如下：
<receive-replyPOST url="relative-url"? outputVariable="NCName"? redirect="redirect-url"? name="NCName">
control*
input?
</receive-replyPOST>

下面，我们以一个简单的订单流程来研究 Assemble flow 对 REST 流程的支持。 在图1所示最简单的流程中，orderRcv 活动接收到订单，reply 活动则简单地返回订单内容。

我们创建一个测试工程，并在 /public/orders/index.flow 中新建一个流程定义文件。

<process name="orderProcess"> 
	<receivePOST name="orderRcv"/> 
	<replyPOST name="reply"> 
		<input name="body" value="${orderRcv}"/> 
	</replyPOST> 
</process>
	  

然后我们可以运行该工程，并使用 Firefox 的插件 Poster 来测试我们的流程。 启动 Firefox3，在菜单中选择 View->Sidebar->Poster 来填入必要的信息来进行测试。指定流程 URL 端点为 http://localhost:8080/orders/index.flow 或 http://localhost:8080/orders/，并使用 POST 方法发送一个 JSON 格式的订单文件到订单流程来进行处理。

当流程引擎被触发之后，它会创建一个新的订单流程实例来处理订单。“orderRcv” 活动会接收 POST 请求的消息，并将订单消息其转化为 JSON 对象，而 “reply” 活动就是简单地将 JSON 格式的订单内容加以返回。我们可以在 HTTP 响应消息的 “Location” 头中指明了流程实例的 URI，它为如下的格式 http://localhost:8080/orders/index.flow/{flow-id}。

在这个简单例子中，我们可以了解到 REST 风格的 Assemble 流程的一些基本概念：

• 在 /public 目录下的 Assemble 流程定义可以通过 HTTP 请求进行访问。启动流程的端点 URL 和访问其他部署在 /public 目录下的 REST 资源（比如 HTML , JavaScript 或是 Groovy 脚本）是一致的：http://{server}/{directory}/{flow-file}。如果流程文件名为 index.flow，我们可以省略 URL 中的流程文件名，直接用 http://{server}/{directory}/ 的方式访问。但需要注意的是，当该目录中存在 index.html, index.gt 等文件时，sMash 会根据配置顺序决定查找缺省文件。
• 当流程启动之后会有一个新的流程实例被引擎创建出来用以来接收并处理 REST 请求。每个流程实例都是一个 REST 资源，我们可以在 HTTP 响应消息中的 Location 消息头中获得该流程实例的 URL。
• 在流程中我们可以使用 receiveGET/replyGET，receivePOST/replyPOST，receive-replyGET 和 receive-replyPOST 等活动来接收 HTTP 请求和返回 HTTP 响应消息。

回页首

使用 REST 风格实现流程会话

在流程应用中存在两种典型场景：短期运行流程（Short-running）和长期运行流程（Long- running）。短期运行流程在执行过程中无须等待外部事件输入，比如本系列第 1 部分中提供的 Feed 数据集成流程。它是一个自动化流程，它的生命周期和 HTTP 请求处理的周期一致。由一个 HTTP 请求启动，并在返回 HTTP 响应消息之后完成执行。长期运行流程在运行过程中通常需要等待外部事件，比如用户输入，来继续流程处理。长期运行流程对于需要与流程多次交互的场景非常重要，比如需要多人协作的工作流。

Assemble flow 可以很好地支持短期流程以及长期运行流程。关于长期运行流程的更多信息，比如持久化处理，会在本系列中的后续文章中进行说明。本文将专注于如何使用 REST 方式来与长期运行流程进行会话。

我们可以扩展上文中定义的订单流程如下。我们加入了一个活动“approve”使用 REST 方式进行审批。然后根据审批结果发送邮件来通知客户是否订单被批准。

下面是这个流程的 flow 的描述:

<?xml version="1.0" encoding="UTF-8"?> 
<process name="orderProcess" persistPolicy="on"> 
	 <receivePOST name="orderRcv"/> 
	 <replyPOST name="reply"> 
		 <input value="${orderRcv}"/> 
	 </replyPOST> 
	 <receive-replyPOST name="approve" url="approve"> 
		 <input value="Your input is received." name="body"/> 
		 <control source="reply"/> 
	 </receive-replyPOST> 
	 <sendMail name="sendApproval" subject="Your order is approved." 
				address="${orderRcv.requester}"> 
		  <input value="${orderRcv}" name="body"/> 
		 <control source="approve" transitionCondition="approve.approved"/> 
	 </sendMail> 
	 <sendMail name="sendRejection" subject="Your order is rejected"
			address="${orderRcv.requester}"> 
		 <input value="${orderRcv}" name="body"/> 
		 <control source="approve" transitionCondition="!approve.approved"/> 
	 </sendMail> 
</process> 
		 

我们可以看到“approve”使用 receive-replyPOST 活动来接收 JSON 格式的审批输入。而后续的“sendApproval”和“sendRejection”活动会使用邮件来通知顾客是否通过审批。 注意：为了支持邮件发送，开发者必须在 zero.config 中添加如下配置来指定相应的 SMTP 服务器地址。并且需要重新启动应用来使更改生效。
/config/connection/defaults/smtp/hostname = "…"
我们可以继续使用 Poster 来进行测试。首先再次提交订单，注意请使用你自己的邮件地址。

之后，我们提交审批输入。注意下面 URL 为流程实例 URL 再附加上 "approve" 活动中定义的相对路径：http://localhost:8080/orders/index.flow/{flow-id}/approve

当“approve”接收到审批消息之后，会在 HTTP 响应中返回“Your input is received.”之后流程会继续执行。根据流程分支条件的定义，“sendApproval”活动会执行，并根据订单中的“requester”值来发送邮件通知。然后你应该可以在邮箱中接收到流程发送出来的邮件。

在这个例子中，在使用 REST 风格与长期运行的 Assemble 流程进行会话时，我们需要使用流程实例的 URL，以及活动定义的相对 URL 构成的端点进行通信。Assemble 流程的 URL 结构如下： http://{server}/{directory}/{flow-file}/{flow-id}/{relative-url}

回页首

简单人工协作流程

Assemble flow 在面向 REST 的流程接口基础之上，支持一种简单的人工协作场景，允许程序员根据业务需求开发具有业务流程功能的 Web 应用程序。

Assemble flow 通过在流程中提供 REST 风格的交互模式，允许不同的参与者查看、编辑流程上下文中的资源。采用邮件提醒的方式通知参与者完成流程中指定的操作。

在常见的企业业务活动中，审批操作是最典型的人工协作场景。主要协作模式可以概括为：

1. 通知审批人进行审批操作；
2. 审批人根据通知内容，打开待审批的文档；
3. 完成相应操作后提交文档，流程会执行之后步骤。

Assemble flow 将以上协作模式作为一个工作单元设计成为流程中的一个“活动” (Activity)，程序员可以将这样的活动与其他内建或扩展活动连接起来，根据运行时的输入输出数据来控制流程流转。也可以连接多个活动指定不同的审批人实现多步骤、不同参与者的协作审批流程。

回页首

webUI 活动

目前 Assemble flow 提供 webUI 类型的活动实现以上协作模式。通过设置该活动的一系列参数，可以指定活动的参与人、通知内容和提供查看、编辑操作的 Web 页面。webUI 活动在运行时的状态变迁如图所示。当处于“已挂起”状态时，该活动将等待用户的编辑操作（实际上是一个 POST 请求），然后根据活动内建的验证机制来决定是否将活动标记为“已完成”还是回到“已挂起”状态。下文会对这种内建的验证机制进行详细介绍。

在 Assemble flow 描述语言中，创建一个 webUI 活动如清单3所示 ：

 
<webUI name="approval" assignTo="zhukecdl@cn.ibm.com" 
title="Ask for create new account in svn server" 
view="newaccount/approval.gt"> 
	 <control source="requestNewAccount"/> 
	 <input data="${requestNewAccount}"/> 
</webUI>	 
		 

清单 3 所示名为 approval 的 webUI 活动在运行时将：

• 向 zhukecdl@cn.ibm.com 发送提醒邮件；
• 邮件标题为 "Ask for create new account in svn server" 的提醒邮件，邮件正文中包括一个查看上下文数据的 Web 页面的链接；
• 使用一个 Groovy 模版文件生成审批人查看上下文数据的 Web 页面。

除此之外，活动的输入数据将作为查看的数据供审批人查看，而审批人提交的数据内容将作为活动的输出数据进入流程的上下文，Assemble flow 中的表达式可以访问这些数据来决定流程流转。如在审批人审批通过之后可以连接另一个活动自动完成某业务操作，而审批不通过后可以使用一个 sendMail 类型的活动向申请人发送审批意见。

回页首

使用 webUI 活动构建人工协作流程

我们仍旧以开头的订单审批流程作为应用场景，通过使用 webUI 活动对流程稍加修改，介绍如何使用 Assemble flow 开发简单的人工协作应用程序。

下面是这个流程的 flow 的描述:

<process name="approve-order" persistPolicy="on">
	<webUI name="submitOrder" view="order/submit.gt"/>
	<webUI name="approveOrder" view="order/approve.gt" 
	assignTo="zhukecdl@cn.ibm.com"
	title="Please approve submitted order">
		<control source="submitOrder"/> 
		<input value="${submitOrder}"/>
	</webUI>
	<sendMail name="sendApproval" 
	subject="Your submitted order is approved!" 
	address="${submit.requester}"> 
		<control source="approveOrder" 
		transitionCondition="approveOrder.approved"/>
		<input value="${approveOrder}"/>
	</sendMail>
	<sendMail name="sendRejection" 
	subject="Your submitted order is rejected!" 
	address="${submit.requester}"> 
		<control source="approveOrder" 
		transitionCondition="!approveOrder.approved"/>
		<input value="${approveOrder}"/>
	</sendMail>
</process>	 
		 

我们可以看到，这里用webUI活动代替 receiveGET/receivePOST 活动来接收 REST 请求。名为 submitOrder 的活动为申请人提供 web 页面来填写申请信息的详细内容；名为 approveOrder 的活动为审批人提供邮件通知提醒、审批订单的页面和处理审批请求。审批人打开该邮件提供的链接查看申请信息，填写意见并给出审批结果。最后系统根据审批结果向申请人发送不同审批结果的邮件。

备注： 如果没有为 webUI 活动指定 assignTo 属性，Assemble flow 在运行时会根据流程上下文自动重定向用户的请求到指定资源。如第一个名为 submitOrder 的活动将自动为流程的请求者（申请人）重定向到填写表单信息的页面。 如果指定了 title 属性和 assignTo 属性，那么 webUI 活动会根据这些属性内容发送通知邮件。

webUI 活动在运行时提供和 receivePOST/replyPOST 以及 receiveGET/replyGET 活动一致的 REST 接口： http://localhos:8080/{flow-uri}/{flow-id}/{activityName}

• 当用户向这个 URL 发送 GET 请求时，将获得相应活动提供的 Web 页面；
• 当用户向这个 URL 发送 POST 请求时（通常为提交一个表单），提交内容将作为相应活动的输出变量保存在流程的上下文中。

下面将使用 AppBuilder 来构建整个人工流程；

创建 sMash 应用程序

打开 http://localhost:8070 进入 AppBuilder。点击 New Application,填入 orderDemo 作为项目名称，点击 Create 创建该项目。

创建 zero 资源模型（ZRM）

首先创建名为 sampleOrder 的资源模型作为订单的数据模型。这个资源模型将用于自动生成表单页和验证用户提交的数据。

订单的数据模型 sampleOrder 将包括如下字段：

• item：代表物品名称的字符串
• quantity：整数，表示物品数量
• applicant：email 表示申请人的 email 地址的字符串
• manager：email 表示审批人的 email 地址的字符串
• approved：布尔类型，表示订单状态是否审批通过

创建审批流程

首先，我们需要创建一个流程文件，如下图所示，其路径和文件名是：/public/orderDemo/index.flow

当创建完流程文件后，AppBuilder 将打开该流程文件的可视化编辑工具。本流程由由 4 个活动组成。其中 2 个 webUI 活动，分别代表申请人提交订单，审批人审批订单。

从 Appbuilder 的流程编辑器的右侧面板的 collaboration 栏目中找到 webUI 类型的活动，将其拖拽至流程工作区:

再拖拽 2 个 sendMail 活动用来发送审批结果：

添加分支连线将这些活动连接起来；

我们可以再连接线上添加文字说明，让流程更加清晰；

打开各个活动的属性编辑框，完成所需要的活动属性编辑。下图显示了 sendMail 活动属性编辑。如果某活动的流程图上显示一个黄色的小三角警告标示，表明该活动的某些必要属性没有填写完毕。

备注:在编辑 webUI 活动的属性时，对于其 view 属性暂先不填，下面我们将使用表单设计器来给 webUI 活动完成该属性的编辑。

设计表单页

两个参与者都需要系统提供相应的 Web 页面来完成操作，包括为申请人提供填写订单内容的表单页，和为审批人提供查看和审批订单的 Web 页面。

打开 webUI 活动的属性页面，单击 "create UI" 链接打开表单设计器。在该编辑器中，分为显示输入数据和提交输出数据两个部分。通过选择不同的数据模型和编辑数据域来定制 webUI 的 Web 视图。

下图显示为 approveOrder 的表单设计界面。在该界面中，你可以编辑表单的显示方式。在这里，我们将 approved 设置为单选按钮。

为流程分支添加判断条件

实现订单审批流程在运行时的条件分支，我们需要为连线增加判断条件。当审批人提交审批结果之后，包括订单数据在内的审批内容将作为流程上下文中 approveOrder 活动的输出变量，我们通过 Groovy 表达式引用这个输出变量的 approved 字段来表示判断条件，approved 字段值为真表示审批通过，否则表示不通过。这样就可以实现根据审批人提交的审批结果自动判断分支的操作。

单击标记为"approved"的连线，选择“扳手”图标打开属性编辑对话框，在名为 condition 的文本框中输入 approveOrder.approved 作为执行条件，见图：

同样，单击标记为“rejected”的连线，再打开属性编辑对话框输入"!approveOrder.approved"

从 Assemble flow 使用的流程描述语言的角度来看，分支条件实际上是通过控制链接（Control link）的 transitionCondition 属性来实现的。请访问开发文档获取详细介绍。

回页首

配置 sMash 应用程序

以上步骤完成了这个人工流程的开发部分。除此之外，你还需要增加配置来连接 SMTP 服务器来实现发送邮件的功能。如果你还需要保护订单审批流程不被随意访问（如只有经理才可以审批订单），可以参考“访问控制与授权”部分，使用 WebSphere sMash 为 REST 资源提供的安全支持来保护你的审批流程。

连接 SMTP 服务器

你需要连接一个 SMTP 服务器来发送提醒邮件。请在 zero.config 文件中添加如下所列配置：
/config/connection/defaults/smtp/hostname = "IP address of your SMTP server
完成 SMTP 服务器的配置之后，本文所介绍的简单人工协作流程已经完成。你可以打开 http://localhost:8080/orderDemo/index.flow 来打开流程

注意： 如果你使用 WebSphere sMash 1.0.x 版本，上述 SMTP 配置只支持不包括安全连接和发送方认证的基本的 SMTP 协议。如果你需要连接如 163.com 或 Gmail 这样需要安全连结和发送方认证的邮件服务器，请使用最新的 WebSphere sMash 1.1.x 或 2.0.x 版本，并使用如清单 5 所列配置。你可以在参考资源中找到下载方法。

# connecting gmail SMTP server 
/config/connection/defaults/smtp/hostname = "smtp.gmail.com" 
/config/connection/defaults/smtp/userid="xxxx@gmail.com" 
/config/connection/defaults/smtp/password="xxxx" 
/config/connection/defaults/smtp/smtpsConfig="gmailConfig" 

@include "ssl/defaultTrustStore.config" { 
"configKey": "/config/connection/smtps/gmailConfig" 
}
		 

访问控制与授权

WebSphere sMash 实现了系统级的认证与授权功能，允许在 sMash 应用程序中定义安全规则来保护 REST 资源。在文本提供的应用场景中，申请人和审批人通过访问一系列 URL 来与订单审批流程进行交互，这些 URL 代表了由 Assemble flow 提供的一系列 REST 资源，包括：

• 启动流程: GET /orderdemo/index.flow
• 申请人打开订单输入页面：GET /orderdemo/index.flow/{flow-id}/submitOrder
• 申请人提交订单：POST /orderdemo/index.flow/{flow-id}/submitOrder
• 审批人查看订单信息：GET /orderdemo/index.flow/{flow-id}/approveOrder
• 审批人提交审批结果：POST /orderdemo/index.flow/{flow-id}/approveOrder

目前 WebSphere sMash 提供多种认证方法来实现访问控制，包括 HTTP 基本认证、基于表单的认证，基于单点登陆（SSO）的认证、基于 OpenID 的认证以及编程方式的认证。本文以 HTTP 基本认证为例，配置内容清单如下：

# 启用 sMash 安全功能 
@include "security/enableSecurity.config" 

# 订单审批流程的用户认证 
@include "security/basicAuthentication.config"{ 
"conditions": "(/request/path =~ /orderDemo(/.*)?) && (/request/method =~ (GET|POST))" 
} 
	

以上安全规则表示，访问订单审批流程提供的所有REST资源都需要经过 HTTP 基本认证。

除了认证我们还需要增加授权规则来保护 REST 资源，即访问不同的 REST 资源需要不同的权限。
第一部分表示只有 EMPLOYEE 群组的用户才可以提交订单。第二部分表示只有 MANAGER 群组的用户才可以完成订单审批：

# 授权给 EMPLOYEE 群组提交订单 
@include "security/authorization.config"{ 
"conditions": "(/request/path =~ /orderDemo/index.flow/.+/submitOrder) 
&& (/request/method =~ (GET|POST))", 
"groups" : ["EMPLOYEE"] 
} 

# 授权给 MANAGER 群组审批订单 
@include "security/authorization.config"{ 
"conditions": "(/request/path =~ /orderDemo/index.flow/.+/approveOrder) 
&& (/request/method =~ (GET|POST))", 
"groups" : ["MANAGER"] 
}
			

除了以上认证和授权的配置，我们还需要使用 WebSphere sMash 提供的用户服务来定义用户和群组。下面的步骤演示了如何使用命令行命令为 sMash 应用程序定义新用户。 创建新用户的命令为：
zero user [-f USER_FILE_PATH] create USERNAME PASSWORD "[GROUP]*"

在 Appbuilder 中打开创建的 orderDemo 应用程序，单击 Console 标签打开控制台，输入命令：
zero user create zhuke mypassword "EMPLOYEE"

创建一个属于 EMPLOYEE 群组的新用户 zhuke：

再创建一个属于 MANAGER 群组的新用户 liwenb：
zero user create liwenb mypassword "MANAGER"

至此，访问控制与授权部分的配置就完成了。这时候重新启动 orderDemo 应用程序，访问 http://localhost:8080/orderDemo/index.flow，你会发现与之前没有访问控制不同的是，弹出了一个对话框要求你输入用户名和密码。

回页首

结束语

本文引介绍如何使用 Assemble flow 来开发简单的协作流程，通过一个例子展现如何通过 Assemble flow 以及可视化工具 AppBuilder 来 快速构建简单的协作流程。在下一篇文章中，将进一步展示更多 Assemble flow 的功能，以及如何使用 Assemble flow 构建更加复杂的 Mashup 应用。

新版本中的增强与改进

在WebSphere sMash 未来的版本中，Assemble flow 将继续增强对简单人工协作流程的功能支持，来简化常见的人工协作场景的应用开发。比如，我们会实现更为灵活的安全机制，并简化基于表单的流程应用等等。我们将在未来的文章中对其进行详细介绍

我们也欢迎您加入 Project Zero 社区、参与项目工作，并分享您的意见和建议。

回页首

下载

	关于下载方法的信息

参考资料

• 使用 Project Zero 和 WebSphere sMash Assemble Flow 构建 Mashup 应用，第 1 部分: Assemble Flow 简介：本文介绍了 IBM WebSphere sMash Assemble Flow 的简单概念和功能。之后通过一个示例，向您介绍如何设置环境、创建 Zero 项目，并利用 Assemble Flow 实现一个基于 Feed 的 Mashup 服务。
  
  
• WebSphere sMash 产品专题：为您提供了更多关于 WebSphere sMash 的文章、教程、多媒体课堂等最新技术资源。
  
  
• 从 Project Zero 社区了解 Project Zero/WebSphere sMash 如何基于流行的Web技术创建应用程序。
  
  
• WebSphere sMash Developer Guide上给出了 sMash 应用程序的体系结构以及相关核心概念。
  
  
• Assemble flow 的参考文档。
  
  
• WebSphere sMash 应用构建器的参考文档。
  
  
• developerWorks 中国 Project Zero 资源中心。
  
  
• WebSphere sMash 中文博客。
  
  
• “为 WebSphere sMash 做好准备”（developerWorks，2008 年 6 月）：IBM® WebSphere® sMash 提供了允许您利用现有 SOA 投资来快速、简单地交付基于 Web 2.0 的环境应用程序的敏捷开发和运行时环境并支持 Mashup，从而推动智能 SOA™ 的发展。
  
  
• “Project Zero、WebSphere sMash 和 PHP 入门”（developerWorks，2007 年 9 月）：本教程将演示如何轻松掌握 Project Zero 基础，包括开发工具的安装，以及使用 PHP 作为后端脚本语言构建一个 Ajax Web 2.0 示例。
  
  
• “Project Zero 简介，第 1 部分: 为 Web 应用程序构建 RESTful 服务”（developerWorks，2007 年 10 月）：在 Project Zero 系列的第 1 部分中，获得 Project Zero 的动手指导以便创建、组装和部署功能强大的 Web 应用程序。
  
  
• “Project Zero 简介，第 2 部分：SOA 中的 RESTful 应用程序”（developerWorks，2008 年 3 月）：通过这个有关 IBM Project Zero 的系列文章，了解 Zero 在创建、组装和部署 Web 应用程序方面的创新。
  
  
• “利用 Project Zero 和 REST 设计原理创建相册应用程序”（developerWorks，2007 年 11 月）：通过本文，您还会了解到有关 RESTful 设计、通过 HTTP 连接组件以及使用 JavaScript 实现 Zero 没有的功能的更多内容。
  
  
• Assemble flow 的 参考文档。
  
  

• 最新 WebSphere sMash 软件下载。

• 参与论坛讨论。

作者简介

		朱可，任职于 IBM 中国软件开发中心，目前在 CETI Web 2.0 小组从事开发工作。

		李文兵，是 IBM 中国软件开发实验室的一名软件工程师。目前在 CETI Web 2.0 小组 , 主要从事 WebSphere sMash 相关的开发工作。

		易立，顾问软件工程师，2001 年加入 IBM 中国开发中心，对 Web2.0，SOA，Web Service，Portal，VoIP 和普及计算都有丰富的经验。目前负责 WebSphere sMash (Project.0) Assemble flow 和相关工具的开发。

		毛新生先生现任 IBM 中国开发中心 Web 2.0 首席架构师。此前他曾任 IBM 软件集团企业解决方案部大中华区和北亚地区首席架构师与 IBM SOA 中国设计中心技术主管，在企业级软件方面拥有广泛、扎实、深厚的理论功底和丰富的设计与项目实施经验。2006 年，毛新生先生被授予“IBM 资深技术主管”称号（STSM ，Senior Technical Staff Member），成为中国内地第一位获此殊荣的 IBM 技术人员，在全球也仅有 1000 多位 IBM 员工享有这样的荣誉。毛新生先生于 2000 年加入 IBM，曾先后在北京大学和 IBM 中国研究院从事研发工作，以研究人员，开发经理和架构师的身份从事过信息检索，语音技术及其中间件，门户，普及计算，Linux，网格计算，Web Service 和 SOA 等领域的很多工作。毛新生先生毕业于北京大学，拥有计算机专业硕士学位。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 将您的建议发给我们或者通过参加讨论与其他人分享您的想法.

回页首