一個純靜態的B/S系統的做法估計不會有太多的爭執，純靜態的網站由美工即可完全完成，而一個動態的B/S系統則需要各種角色的人的共同努力去完成，例如一個典型的團隊角色就是業務分析師+設計師+程序員+美工來完成，傳統的開發過程通常是這樣：
1、業務分析師對業務進行分析，形成業務模型；
2、美工和業務分析師一起完成靜態系統的制作，通常稱為系統原型(html or html+css+javascript)；
3、設計師根據業務分析師形成的業務模型以及需求形成系統設計；
4、程序員根據系統設計進行系統功能的實現，同時結合系統原型完成界面的集成；
在這樣的一個開發過程中，1、2、3步是比較難以通過自動化的系統或框架來逾越的，目前的框架也同樣是鎖定在對于第4步的提升上，我們可以看到現在已經有非常非常多的框架來提升實現系統功能的效率了，但界面集成的這塊呢，仍然需要耗費非常大的工作量，基于現有的框架在做界面集成時通常是采用這樣幾種方法：
● 將用于實現動態性質的代碼嵌入至html中；(例如ASP、JSP等)
● 將用于實現動態性質的代碼進行封裝，暴露出其中用于外部傳入的參數，采用標簽的方式嵌入至html中；(如taglib等)
● 修改現有的html，將其中需要綁定動態性質的表格或域、或元素加上一個特殊的屬性；(如tapestry的jcwid方式等)
在上面的三種界面集成的方法中，我們發現都需要對現有的html進行一定的修改，其實按順序的可以看出界面集成的一種演變，從最早的直接嵌入至html中，到采用標簽的方式的嵌入，又到只是增加html元素的屬性的過程，在這樣的一個演變過程中，最明顯的變化就是可以看到越來越強調對于html的無侵入性，為什么要這么強調對于html的無侵入性呢，如果做過界面集成的話就很容易發現，在直接嵌入代碼至html的方式的時候，功能的實現做起來確實比較簡單，但界面集成就極為痛苦了，調試起來就更為痛苦了；在標簽的方式嵌入html的方式中，會發現稍微好一點，至少調試起來會更方便，但痛苦仍在，在界面發生變化的時候這點就很明顯；在元素上加新屬性的方法調試起來就很方便了，但它的痛苦就在于還是得不斷的去手動修改html，在界面變化頻繁的情況下還是挺麻煩的。
為什么界面集成這么的麻煩呢，要做界面集成就是為了將動態性質的實現增加到靜態的html上去，而這個步驟在現在還沒有什么好的框架或者說好的IDE來支撐，導致了現在的這個步驟很麻煩，這也是為什么在做系統的時候很多時候最怕的不是用戶所要的功能的變化，而往往是界面的變化，界面集成的這個步驟是這么的索然無味而且工作量奇大，怎么來提高這塊的效率呢？
以系統設計時的一個基本原則："職責單一"來看界面集成這個步驟，會發現其實現在做界面集成時通常來講都是將html的職責進行了擴充，使一個本來只是單純的html頁面擴充為了一個具備動態和靜態性質的雙重職責的頁面，從系統設計角度上就可以看出這是個很明顯的問題，很明顯會導致的一個問題就是在修改的時候或擴充的時候都會變得很麻煩，兩種職責不同的東西為什么一定要混淆在一起呢，在界面變化這塊很多時候可以發現或許只是頁面布局、頁面風格的些許靜態變化，或許又只是其中的某個動態表格中要增加一列，如果可以分開來管理這兩種變化不是會更方便嗎？
RIAWork遵循的就是這么一個思想，在RIAWork中非常強調靜態職責和動態職責的區分，靜態職責由頁面來完成，頁面遵循標準的web頁面規則，由html+css+javascript來構成，而動態職責則交由另外的一個部分來完成，系統的一個完整的功能頁面需要由動態職責和靜態職責來共同完成，那么這個時候很簡單的可以看出需要RIAWork提供動態職責和靜態職責結合方式的支持，為了不影響靜態職責頁面，在RIAWork中由動態職責的描述文件來完成這個步驟，在動態職責描述中指定綁定的html頁面，在這樣的方式下，當我們要修改靜態相關的東西時只需去修改html、css或js，而如果要修改動態職責的東西時則只需要修改動態職責描述文件，在保證了職責單一的基礎上使得原本負責的界面集成的工作變成了一個更為簡單的步驟，可以想像這樣的一種方式可以靈活的應對靜態部分的變化，而不至于導致靜態部分的變化帶來整個系統的巨大的工作量。
系統中目前很容易被忽略的一個部分就是交互部分的考慮，在傳統的系統開發中，當交互發生變化時通常會導致系統極大程度的改變，而這也是RIAWork的關注點，RIAWork將關注多種交互方式的實現，并使得使用者可通過配置即完成交互方式的改變。
功能、界面和交互三者結合在一起才共同的決定了一個系統的好壞，在目前用戶對于界面和交互需求還沒達到成熟的情況下，我覺得為用戶多考慮一點界面和交互，必然是會得到用戶更多的認可的。
ps：可以想像如果美工在ps或dreamweaver之類的工具中可以直接選擇動態性質的部件(如動態表格、動態交互方式)來直接替換靜態性質的部分，那是多么爽的一件事，在這樣的一種方式下，自然界面集成的工作就沒有了，^_^，或許可以關注下ps、dreamweaver的插件開發，不過這仍然需要基于一種靜態職責和動態職責分離的基本思想上....
后續篇章：
RIAWork介紹之三：RIAWork的擴充以及擴展
RIAWork介紹之四：RIAWork的開放性
RIAWork介紹之五：RIAWork的靈活性以及智能性
RIAWork介紹之六：RIAWork的動態部件