几周前新的工作流即服务（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上）还是普通的用户呢（他们需要快速构建简单的应用，通常是一次性的项目）？你怎么看待这个问题？
【编辑推荐】
