使用 SilverLight 构建工作流即服务平台

几周前新的工作流即服务（Workflow-as-a-Service）平台 SnapFlow 发布了 beta 版。该平台构建在微软系列产品上，其工程副经理 Gopinath Dhanakodi 说到：

去年在开始构建 SnapFlow 时，我们曾考虑过 Flex，最后选择了 C#进行业务层开发、SQL Server 2005 作为后端存储。

考虑使用 SilverLight 来代替 Flash 的因素包括：

• 与业务逻辑层的整合
• 构建时间
• 学习曲线
• 专门技术
• 部署
• 特征集
• 客户的选择
• 代价

最初 SnapFlow 选择的是 Flash，但在原型开发的几周后：

我们对进度很失望。用户界面很起来毫无生气，每次简单的改变都要花很长时间。

就在那时，我们对 SilverLight 进行了深度调研：

尽管大多数的开发者并不是 UI 专家，但在短短的一个月之内我们取得了重大的进展。在不借助于任何帮助的情况下，团队可以实现一个相当复杂的原型了。

好的方面有：

• 团队可以快速进入状态
• 前端的开发速度要比使用 Flash 快 2 倍
• 开发起来更有生气
• 整个的集成设计与开发环境

差的方面有：

• 遇到问题时不容易解决
• Silverlight 的高级控件不多
• 缺少自动化测试工具的支持
• 从 Silverlight 2 beta 迁移到 Silverlight 2 比较麻烦

Gopinath 总结到：

我们是先驱者，遇到了数不胜数的挑战，这些挑战都伴随着领域问题。总而言之，我们对自己的决定感到满意，因此我强烈推荐 Silverlight，尤其是你有.NET 经验。

InfoQ 又对 SnapFlow 的 CEO Samad Wahedi 进行了简短的采访，提到了该新 PaaS 背后的哲学：

我们不同于当前的平台即服务（Platform-as-a-Service）供应商。我们主要的目标是让工作流变得像 powerpoint 一样简单，目标用户是 Andy（一个销售人员），他今年 30 岁，工作在一个分散的拥有 30 个成员的销售团队中，他们主要为一些更大的公司服务（通常都有 500 多名员工）。他有一个 facebook 帐号，对 office 产品套件非常熟悉。

我们决定从头开始并对不了解的一切问题追根问底。Andy 是怎么想的，对他来说什么东西才有意义，他是如何工作的，他正在解决什么问题，如何解决的等等。就这样，SnapFlow 诞生了。

综上所述，SnapFlow 没有使用任何传统的 BPM 标准（BPMN 或 BPEL）。Samad 说到：

销售员 Andy 并不是专业的流程工程师，因此我们并没有围绕 BPMN 进行设计。

我们的工作流模型以活动（activity）和行为（action）为中心。行为决定了接下来执行哪个活动。该模型并没有使用泳道（Swim Lanes），因为用户与角色都关联到每个活动上了。

我们将继续根据 Andy 来构建系统，但同时我们也认识到还需要增加更多复杂的功能。我们的目标是对 Andy 隐藏这些特性，仅仅将其开放给拥有更高权限的用户。这非常有挑战性，但我相信我们能够搞定。

SnapFlow 是首个构建在微软技术之上的 PaaS，同时具备完整的基于 Web 的表单与工作流设计器。当然它还没有使用 Azure，但却向我们展示了.NET PaaS 的样子。 SilverLight 程序经理 Tim Heuer 最近发表了一些关于 SnapFlow 的文章，他的文章主要根据产品的一个三分钟演示而来。他说到：

其中一个很酷的特性就是一旦工作流的创建者创建完毕后，他还可以将该工作流部署到 Web 站点或是其他 portal（比如演示中就使用了 Sharepoint）上，这样我们就可以使用工作流从站点上收集一些数据并将 Silverlight 应用嵌入到站点中，整个过程无需额外的编码。

业界对如何设计BPMN 还不是很清楚，更别提在BPMN 和BPEL 之间定义精准的清晰度了，SnapFlow 似乎重提了这个话题：现在是探索BPM 模型替代者的时候么——让更多的用户参与到设计过程，而不仅仅是BPM 分析师。它还抛出了这个问题：PaaS 的目标是专业的开发者（他们可以将其解决方案部署到EC2 或是Azure Windows Services 上）还是普通的用户呢（他们需要快速构建简单的应用，通常是一次性的项目）？你怎么看待这个问题？

查看英文原文： A Workflow-as-a-Service Platform using SilverLight