使用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上）還是普通的用戶呢（他們需要快速構建簡單的應用，通常是一次性的項目）？你怎么看待這個問題？
【編輯推薦】
