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