一个纯静态的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的动态部件