使用Silverlight構建工作流即服務平臺
幾周前新的工作流即服務（Workflow-as-a-Service）平臺SnapFlow發(fā)布了beta版。該平臺構建在微軟系列產品上，其工程副經理Gopinath Dhanakodi說到：
去年在開始構建SnapFlow時，我們曾考慮過Flex，最后選擇了C#進行業(yè)務層開發(fā)、SQL Server 2005作為后端存儲。
考慮使用SilverLight來代替Flash的因素包括：
◆與業(yè)務邏輯層的整合
◆構建時間
◆學習曲線
◆專門技術
◆部署
◆特征集
◆客戶的選擇
◆代價
最初SnapFlow選擇的是Flash，但在原型開發(fā)的幾周后：
我們對進度很失望。用戶界面很起來毫無生氣，每次簡單的改變都要花很長時間。
就在那時，我們對SilverLight進行了深度調研：
盡管大多數(shù)的開發(fā)者并不是UI專家，但在短短的一個月之內我們取得了重大的進展。在不借助于任何幫助的情況下，團隊可以實現(xiàn)一個相當復雜的原型了。
好的方面有：
◆團隊可以快速進入狀態(tài)
◆前端的開發(fā)速度要比使用Flash快2倍
◆開發(fā)起來更有生氣
◆整個的集成設計與開發(fā)環(huán)境
差的方面有：
◆遇到問題時不容易解決
◆Silverlight的高級控件不多
◆缺少自動化測試工具的支持
◆從Silverlight 2 beta遷移到Silverlight 2比較麻煩
Gopinath總結到：
我們是先驅者，遇到了數(shù)不勝數(shù)的挑戰(zhàn)，這些挑戰(zhàn)都伴隨著領域問題。總而言之，我們對自己的決定感到滿意，因此我強烈推薦Silverlight，尤其是你有.NET經驗。
InfoQ又對SnapFlow的CEO Samad Wahedi進行了簡短的采訪，提到了該新PaaS背后的哲學：
我們不同于當前的平臺即服務（Platform-as-a-Service）供應商。我們主要的目標是讓工作流變得像powerpoint一樣簡單，目標用戶是Andy（一個銷售人員），他今年30歲，工作在一個分散的擁有30個成員的銷售團隊中，他們主要為一些更大的公司服務（通常都有500多名員工）。他有一個facebook帳號，對office產品套件非常熟悉。
我們決定從頭開始并對不了解的一切問題追根問底。Andy是怎么想的，對他來說什么東西才有意義，他是如何工作的，他正在解決什么問題，如何解決的等等。就這樣，SnapFlow誕生了。
綜上所述，SnapFlow沒有使用任何傳統(tǒng)的BPM標準（BPMN或BPEL）。Samad說到：
銷售員Andy并不是專業(yè)的流程工程師，因此我們并沒有圍繞BPMN進行設計。
我們的工作流模型以活動（activity）和行為（action）為中心。行為決定了接下來執(zhí)行哪個活動。該模型并沒有使用泳道（Swim Lanes），因為用戶與角色都關聯(lián)到每個活動上了。
我們將繼續(xù)根據(jù)Andy來構建系統(tǒng)，但同時我們也認識到還需要增加更多復雜的功能。我們的目標是對Andy隱藏這些特性，僅僅將其開放給擁有更高權限的用戶。這非常有挑戰(zhàn)性，但我相信我們能夠搞定。
SnapFlow是首個構建在微軟技術之上的PaaS，同時具備完整的基于Web的表單與工作流設計器。當然它還沒有使用Azure，但卻向我們展示了.NET PaaS的樣子。SilverLight程序經理Tim Heuer最近發(fā)表了一些關于SnapFlow的文章，他的文章主要根據(jù)產品的一個三分鐘演示而來。他說到：
其中一個很酷的特性就是一旦工作流的創(chuàng)建者創(chuàng)建完畢后，他還可以將該工作流部署到Web站點或是其他portal（比如演示中就使用了Sharepoint）上，這樣我們就可以使用工作流從站點上收集一些數(shù)據(jù)并將Silverlight應用嵌入到站點中，整個過程無需額外的編碼。
業(yè)界對如何設計BPMN還不是很清楚，更別提在BPMN和BPEL之間定義精準的清晰度了，SnapFlow似乎重提了這個話題：現(xiàn)在是探索BPM模型替代者的時候么——讓更多的用戶參與到設計過程，而不僅僅是BPM分析師。它還拋出了這個問題：PaaS的目標是專業(yè)的開發(fā)者（他們可以將其解決方案部署到EC2或是Azure Windows Services上）還是普通的用戶呢（他們需要快速構建簡單的應用，通常是一次性的項目）？你怎么看待這個問題？
【編輯推薦】
