–文章摘要如下

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

–文章目录如下:

本文内容包括：
	引言
	开始之前
	在Assemble flow中访问REST资源和服务
	面向 REST 的流程接口
	使用 REST 风格实现流程会话
	简单人工协作流程
	webUI 活动
	使用 webUI 活动构建人工协作流程
	配置 sMash 应用程序
	结束语
	下载
	参考资料
	作者简介
	对本文的评价

–另外，发了另外两个blog在projectzero的中文博客上面；

• developerWorks文章：使用 Assemble Flow 开发简单协作流程
• 在TechTarget中国中的BPM活动

首先当然是要到GMail的Lab中enable这个功能了。

这个时候到Setting->General中的Signature中会多出这么一个东西，

默认是http://www.brainyquote.com/link/quotefu.rss这个地址，这个时候当你新建一个邮件，就会发现有签名档随机插入到邮件中。但是这个并不是我想要的签名档，我需要它是从我自己的签名档列表中去找。这个功能的签名档的信息是由一个RSS来给出的，那么何不使用Google App Engine来做一个自己的签名档管理的小系统，这样我可以加入自己新的签名档，然后还可以提供签名档的RSS给它呢？

说动手就动手吧，很快就完成了。http://liwb-quote.appspot.com/。界面是抄twitter的，因为我的功能的确就是和它一样。我不得不说，在App Engine上面开发这样的应用的效率是惊人的。我很久没有动python了，App Engine的东西也是边看它的tutorial来完成的。但是我还是没有碰到太多的障碍就完成这些事情。看截图吧。

然后再是提供RSS就可以了：http://liwb-quote.appspot.com/rss。 再将这个地址放到gmail中设置就可以了。嘿嘿，当你再新建一个邮件的时候，签名档就是你在appspot上面的自己的了。是不是很high呢？

Conclusion

App Egine来开发这样的应用的效率是极高的。无非是数据库的一些操作，开发、调试和上线的体验只有用过才知道是如何的high。

另外，Gmail中的Random Signature还是非常不成熟，它并不是实时地去拿我当前的记录。也不知道它多久抓一下，这点让人沮丧。

Download

这个是我的App Engine的工程，如果你管理自己的签名档或者类似一句话的东东，这个都可以用。

下载App Engine应用

一些注意事项：

1. 下载后，修改app.yaml 文件中的application: {{ 你的应用名字  }}。
2. 在main.py中需要把users.get_current_user().email()==’wbinglee@gmail.com’改成你自己的email，因为我让只有本人才有添加的能力，其他人只有浏览的权限。
3. 然后appcfg.gy update 就好了。

show一下变态的界面。

在Jaxar里面写code倒是很有意思，所有你需要做的事情就是写Javascript/CSS/HTML。你根本不需要使用任何其他server-side语言,所有的事情就是写Javascript就可以了。来看一个例子：

 <script type="text/javascript" runat="server">
	function getAuthenticatedUser()
	{
		var username = Jaxer.session.get("username");
		if (typeof username == "undefined") return null;
		var rs = Jaxer.DB.execute("SELECT * FROM users WHERE username = ?", [username]);
		if (rs.rows.length == 0)
		{
			return null;
		}
		return rs.rows[0];
	}
</script>

用‘runat=server’就可以让上面对数据库的操作运行在server端，而client端对该方法的调用不变，这样在写Web应用时就不用在Server side和client side两边跑来跑去了。并且还有对template的支持。

这个和原来老毛和科长做的project zero client programming model是非常相似的，目的是都用来屏蔽client和server之间的boundary。不过Jaxar做的更加彻底，通过扩展Apache的server，加入自己的Server side framework和client side framework，让所有的一切都通过写JS就搞定了。并且对session，database, web ,SMTP 进行支持，对于一般的应用差不多就够了。老毛原来做的也是通过加入client framework以及扩展server的一些能力来让开发者在client和server之间进行无缝交互。可惜还是需要写Javascript和groovy，并且有一大堆的convention，不知道为什么没有发展下去（又是政治问题?).

那么这种开发模式到底好不好呢？我觉得对于比较小的应用，不考虑扩展和与外界交互，还是一个比较快捷的开发方式。毕竟client和server的无缝交互所带来的好处是非常大的，比如说学习的门槛低（只需要知道一个Javascript就搞定了), 数据传输中麻烦的异步调用，编码，解码，格式转换等等都将消失。但是一旦你的web应用大一些的时候，我想这种模式就面临着很大的问题。关键还是不容易扩展，当它把UI和数据逻辑混合的时候，要做分离是比较困难的。当然你可以在它的编程模型上写一层数据操作层，但是这样就变成了典型的RPC了。另外，这样做并不REST,Jaxer开发出来的应用根本提供不了service(更谈不上RESTful)，这样就无法被它人所用了。如果Jaxer应用以后要做整合，那绝对是一个大麻烦。