Flex简介
       Macromedia公司被公认为新兴的RIA市场的领导者。今天98%的浏览器上都使用Macromedia Flash客户端软件，因此几乎每个人都可以使用基于Flash的RIA。Macromedia Flex是Macromedia的新服务器产品，它使企业应用程序开发人员能够全面访问RIA的功能。Flex具有基于标准的架构，与当前企业开发人员的工具、方法和设计模式互补。

    Flex应用程序与传统的HTML应用程序的主要区别在于Flex应用程序处理最适合在客户端运行，如字段校验、数据格式、分类、过滤、工具提示、合成视频、行为及效果等。Flex 可使开发人员更好地交付应用程序，这种应用程序使用户可以迅速反应、在不同状态与显示间流畅过渡，并提供毫无中断的连续的工作流。

                                             Flex 应用程序框架

  如上图所示，Flex应用程序框架由MXML、ActionScript 2.0及Flex类库构成。开发人员利用 MXML及ActionScript 2.0编写Flex应用程序。利用MXML定义应用程序用户界面元素，利用ActionScript 2.0定义客户逻辑与程序控制。Flex类库中包括Flex组件、管理器及行为等。利用基于Flex 组件的开发模型，开发人员可在程序中加入预建的组件、创建新组件或是将预建的组件加入复合组件中。

      这里重点介绍一下MXML。与HTML一样，都是标记语言，它描述了反映内容与功能的用户界面。与HTML不同的是，MXML 可对表示层逻辑与用户界面和服务器端数据绑定提供声明抽象。MXML可将表示与业务逻辑的问题彻底分开，以实现最大程度地提高开发人员的生产率及应用程序的重复使用率。

    Flex的不足
      目前Macromedia最新推出了Flex 1.0 Updater，但它代号为“Brady”的IDE还没有正式推出，目前还在进行Beta 3测试。抛开IDE不说，笔者认为Flex目前还很不成熟，还不利于在实际项目中使用。

    例如，Flex自带的ZipCodeValidator，里面只提供了美国和加拿大的邮编规则，没有其他选择，也无法个性化它。看来只有自己来定义Validator了，但这样一来，和在JS中写正则表达式有什么区别（代码量和JS差不多）？用户需要的是国际化的ZipCodeValidator，这样才能提高工作效率。

    一句话概括
      现在的Flex才是1.0版本，很多地方都不完善，只好自定义才能完成特定的要求。期待着Brady以及Flex后续版本的推出！

RIA方案—基于JS的Bindows

Bindows简介
    “Bindows把JavaScript发挥到了第九层！”——网友这样评价Bindows。

                             运行中的Bindows

    的确如此，Erik等编写这个框架已经将JavaScript的OOP和基于IE6的DHTML发挥到极点！Bindows 0.93发布的时候已经将IE内置的功能开发得淋漓尽致了，包括Filter、XMLHTTP、Web Service、VML。JavaScript用于客户端界面的显示和处理，XMLHTTP用于客户端与服务器的信息传输。JavaScript在客户端的表现力不容置疑，看看www.bindows.net所表示出来的能力，利用JavaScript几乎可以实现Windows应用程序所能干的大部分事情，XMLHTTP一直以来常被用于实现“无刷新”的Web页面，它和JavaScript配合，可以完成数据从服务器和客户端的传输。
   
    Bindows的不足
    Erik喜欢那种一次全部载入的方式来实现脚本库，使用过Bindows会发现，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。按照V0.93，脚本文件的大小是600多K，在一个普通的Web应用中，我们更多时候不会用到Bindows的全部功能，这点Bindows根本没有遵循“用多少去多少”的准则。另外，过多的JS会使CPU占用率陡然增加，产生潜在问题。

    内部大量利用了IE6的技术，没有考虑到非微软平台的浏览器，限制了Bindows的流行。在图表方面，大量采用了VML技术，在IE5，IE5.5这两个版本，VML引擎不是那么的成熟，很多地方的显示不够流畅，会受到带宽和硬件的限制，过分绚丽的图形最终会给用户带来崩溃。“图形方面我是采用VML的，当初太偏执，如果使用SVG来实现可能好许多的，也就是那段日子，我花了非常多的时间去折腾web方面开发。”——有网友这样说。

  一句话概括
    在技术的角度上，从Bindows是可以学到不少东西的，但好像它的学术价值大于它的商业价值。

后 记

    兴奋归兴奋，冷静下来仔细想想，运用RIA改造现有B/S模式还为时尚早。制约我们的首先是网络环境和硬件环境的不完善性，我想没有哪个用户愿意花大量的时间来等待想要看见的“花哨”页面，更不愿意等来的东西使自己的机器不堪重负，而换来的只是一些良好体验吧？市场决定一切，而不是任何的新技术！其次，目前RIA的解决方案也不成熟，笔者看好Flex，可惜还需要长时间的等待才有结果。当然，还有很多RIA的方案，感觉MS的Smart Client + Web Service来头不小。

    本文叫“迎接RIA时代的来临”，笔者充满了对RIA的美好憧憬，期待着有一天能够在RIA的环境中进行虚拟现实的交互式体验！

鸣 谢：RIA中国 没有他们，我想今天也不会对RIA有如此的认识！！！


参考文献:

Flex 白皮书
IDC--RIA白皮书
回归C/S?解释Bindows
迎接Client/Server模式的回归
Flex: RIA 的先驱，无坚不摧的银弹？
Return of Rich Client


请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen

    看了几篇关于“回归C/S”的文章，作为一名多年开发B/S的程序员，不免热血沸腾，深受鼓舞！曾经，我是B/S结构的忠实拥护者，同时也为了所谓的“零部署”陷入过技术泥潭。正当为B/S烦愁的时候，RIA走进了我的视线… …

什么是RIA

    Internet已经日益成为应用程序开发的默认平台。用户对应用程序复杂性要求日增，但现在的Web应用程序对完成复杂应用方面却始终跟不上步伐。用户与今天中等复杂程度的Web应用程序交互时，其体验并不能令人满意。Web模型是基于页面的模型，缺少客户端智能机制。而且，它几乎无法完成复杂的用户交互（如传统的C/S应用程序和桌面应用程序中的用户交互）。这样的技术使得Web应用程序难以使用，支持成本高，并且在很多方面无法发挥效应。

    为了提高用户体验，出现了一种新类型的Internet应用程序。那就是Rich Internet Applications（RIA）。这些应用程序结合了桌面应用程序的反应快、交互性强的优点与Web应用程序的传播范围广及容易传播的特性。RIA简化并改进了Web应用程序的用户交互。这样，用户开发的应用程序可以提供更丰富、更具有交互性和响应性的用户体验。

                           基于主机模式→C/S模式→B/S模式→RIA模式

   我们的行业经历了几次系统架构方面的重要转变，在此过程中，客户端的表现功能有起有落。上图介绍了每个阶段的计算功能所带来的应用程序体验方面的变化，这一过程从大型机开始，到RIA的出现为止。

   随着各企业组织认识到RIA模型可产生显著的商业利润、提高生产率及降低成本的优势后，这种模型的发展势头越来越猛烈。这些应用程序结合了桌面应用程序的反应快、交互性强的优点与Web应用程序的传播范围广及容易传播的特性。系统架构发展的下一步是RIA，它最大程度地提高了广泛性和丰富性。

论传统B/S之不足

    过程复杂性
    过程复杂性是由于需要表达一个多步骤或多选项任务或互动作用所引起的。在HTML里，一个多步骤的任务可以在单页内表达出来。但是由于HTML的互动性有限，便可能产生一份很长的页面，使用户感到混乱、笨拙而难以使用。为了避免这种难以忍受的用户体验，便需将任务在表面上看来“自然”的部分处区分成多个步骤，甚至需多个网页共同完成。这种以网页为主的用户界面通常需要反复翻转网页，以解决在顺序步骤中有牵连性的改变。其结果是缓慢、不自然、混乱而且令人感到懊恼的用户体验。
    
    配置复杂性
    许多Web应用程序允许用户配置自己所要的定制产品——可以是皮包或是计算机，甚至是汽车等产品。但是配置产品是一项很困难的过程，因为在向用户展示所有有效的产品选项组合时，应用程序必须能够表达出有关的复杂性，尤其是当用户可以从数十、数百或数千选项中定制出一个产品时。表达这些复杂性包括指出所需条件、有效和无效组合、一些导致问题的元素以及它们的适当解决方法；为每一项个人选择提供费用信息以及费用总计（一旦有所更改）；还有最重要的是容许用户观看最后结果。这些是传统Web应用程序相当难以表现的。

 规模复杂性
    今天，网站内的搜索工具大多是文本性质，间中夹着一些锦上添花的图像。当用户输入他或她的数码照相机准则，有可能是价格、以像素等，网站便接着回复数页符合准则的产品，而大部分都是说明文本。反之，另一种方法则是使用视觉化来简化搜索空间（也就是提供立即和动态的视觉反馈）。在一个视觉化选择照相机的网站，其搜索过程可能如下：网站从一个包含所有照相机种类图像的单屏幕开始。当用户通过复选框、游标或数据输入域来选择筛选准则时，所有不符合准则的照相机图像将被删除，只余下符合准则的照相机可在屏幕上看到。因此，在把选择聚焦至符合准则的数部照相机的过程中，用户可经历一个截然不同，而且和现实生活中的购物经验更相似的体验。

  反馈复杂性
     高度互动性的应用程序如游戏，能使反馈变得复杂，也即是指用户行动和快速移动或情节不断改变的屏幕元素之间的反馈环路。传统的HTML页面一向来都可以说是无法表达这类复杂性。它所需要的是拥有高度互动性和局部智能型的客户端应用程序，以便可以在无需刷新全页或干扰与服务器之间的通信的情况下，响应用户的输入和改变它们的状态或界面。放弃如今依赖服务器的客户机将使用户体验更吸引，同时也解决了反馈复杂性的问题。Web应用程序必须拥有表达复杂性的能力，以容许用户视看复杂的数据、配置多选项的产品、搜索大型数据集以及容许用户与数据之间的互动交换。

真正的RIA

    为了解决如今的问题，理想中的Web应用程序应该能够：
1、 利用无处不在的客户机
2、 在多种硬件平台上毫无更改的操作互联网
3、 无论低或高带宽的连接都可毫无妨碍的执行
4、 将处理能力复原给客户（而不仅是提供能力而已）
5、 提供吸引人的高度互动的用户界面
6、 表达过程、数据配置、规模和反馈复杂性
7、 无缝的利用声音、视像、图像和文本
8、 容许用户在线和离线工作以支持移动工作流程
9、 容许客户自行决定要在何时存取何种内容和数据（异步内容检索）
10、 存取多种中间层服务（.NET或Java）和后端数据存储
11、 采用新崛起的标准如XML和SOAP，为演进中的Web Service为主的网络提供动态高效的前端应用
12、 与遗旧的应用程序和系统集成
13、 容许在现有Web应用程序和环境内逐步添加新功能以充分利用现有网络应用投资

       

JavaScript 的任务是通过 DWR servlet 来调用指定的 Java 代码，动态创建 iframe。DWR servlet 的任务是配置一些参数，调用服务器端 Java 代码为调用者向 iframe 提供返回数据。

译者语

    DWR 是个新东东，目前仅仅被认为是 alpha 版。在这一领域，据我了解还有 XML HTTP Request object（一般称作XMLHttp） 和 XML-RPC。国内使用 XMLHttp 的很多，包括我前几个月所参与的项目，实现了很多以前认为 B/S 很难办到的需求，不过遇到的问题也不少，相同版本的 IE 有的却要报错，让人很恼火。XML-RPC 国内用户就少多了，我未接触过 XML-RPC，在此不作过多评价。

在这样一个日新月异的时代，希望 DWR 能经受住考验！



请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen