传统网络程序的开发是基于页面的、服务器端数据传递的模式，把网络程序的表示层建立于HTML页面之上，而HTML是适合于文本的，传统的基于页面的系统已经渐渐不能满足网络浏览者的更高的、全方位的体验要求了，这就是被Macromedia公司称之为的“体验问题”（"Experience Matters"），而富因特网应用程序（Rich Internet Applications，缩写为RIA）的出现也就是为了解决这个问题。
富因特网应用程序是下一代的将桌面应用程序的交互的用户体验与传统的Web应用的部署灵活性和成本分析结合起来的网络应用程序。富因特网应用程序中的富客户技术通过提供可承载已编译客户端应用程序（以文件形式，用HTTP传递）的运行环境，客户端应用程序使用异步客户/服务器架构连接现有的后端应用服务器，这是一种安全、可升级、具有良好适应性的新的面向服务模型，这种模型由采用的Web服务所驱动。结合了声音、视频和实时对话的综合通信技术使富因特网应用程序（RIA）具有前所未有的网上用户体验。
“富”的概念包含两方面，分别是数据模型的丰富和用户界面的丰富。数据中的“富”意思是用户界面可以显示和操作更为复杂的嵌入在客户端的数据模型，它可以操作客户端的计算和非同步的发送接收数据。这种模式相对于传统的HTML页面的优点是程序运行于客户端并且程序更多的是和用户进行交互同时更少的和服务器进行交互。平衡客户端和服务器端的复杂的数据模型可以让你有更大的空间去创建更高效和更具有交互性的网络应用程序。“富”同样也描述了全面提升的用户界面，HTML只给用户提供了非常有限的界面控制元素，而富因特网应用程序（RIA）的用户界面提供了灵活多样的界面控制元素，这些控制元素可以很好的与数据模型相结合。传统的因特网模型使用线性的设计，提供给用户一些选择然后用户发送选择结果给服务器，这种单一的模式不符合应用程序的灵活交互的要求和用户的意愿。频繁的服务器请求和页面刷新有很多的缺点包括页面打开缓慢和降低网络带宽。如果采用富客户界面，可以从以前的服务器响应影响整个界面，转移到只有收到请求的应用程序部分才会做出相应的变化。这本质上意味着界面被分解成许多独立的模块，这些模块都会对收到的信息做出相应的反应，有些会和服务器端进行交互，有些是这些模块之间的通信。
请关注那些超越正在失去生命力的HTML标准的技术
在过去的大约两年中，人们的兴趣一直是想构建一个"富客户端"：这是一个用户接口，它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA（Rich Internet Application，富互联网应用系统）技术允许我们在因特网上以一种象使用Web一样简单的方式来部署富客户端程序。无论将来RIA是否能够如人们所猜测的那样完全代替HTML应用系统，对于那些采用胖客户端技术运行复杂应用系统的机构来说，RIA确实提供了一种廉价的选择。
在本专栏中，我将列举一些当前的RIA产品和技术，并且提供一些如何开始应用这些产品和技术的启示。在DevTrends站点和即将发行的近几期Oracle Magazine杂志上，我将详细探讨使用Oracle平台部署RIA的特定技术和策略。
为什么用RIA？
基于HTML的应用程序之所以变得流行是由于应用系统的部署成本低、结构简单，且HTML易于学习和使用。很多用户和开发人员都乐于放弃由桌面计算机带来的用户界面改进，来实现对新数据和应用系统的快速访问。与丧失一些重要的UI功能相比，基于Web的方式所带来的好处要更大得多。
然而，某些应用系统并不完全适合采用HTML技术。复杂的应用系统可能要求多次提取网页来完成一项事务处理，在某些领域中，如医药和财务领域，这往往导致交互速度低得无法接受。让我考虑一个项目管理系统：我们可以将其实现为一个HTML应用系统，但是如果用户可以看到并且操作图表、进度表和各种层次结构，那么显然会工作得更好。
此外，虽然HTML开始走向简单，但是即使简单的交互活动也仍然需要用很多的脚本来完成。即使一个输入窗体经过仔细的布置和全面的脚本设计，它从浏览器所能发送的也仅仅是简单的"名字/值"对。如果一个HTML窗体能够以XML文档形式发送和接收更复杂的数据结构，那就好多了。
RIA利用相对健壮的客户端描述引擎，这个引擎能够提供内容密集、响应速度快和图形丰富的用户界面。除了提供一个具有各种控件（滑标、日期选择器、窗口、选项卡、微调控制器和标尺等）的界面之外，RIA一般还允许使用SVG（Scalable Vector Graphics，可伸缩向量图）或其他技术来随时构建图形。一些RIA技术甚至能够提供全活动的动画来对数据变化作出响应。
RIA的另一个好处在于，数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。对于无线设备和需要偶尔连接的设备来说，将来的趋势肯定是向富客户端的方向发展，并且会逐渐远离基于文本的Web客户端。那些运行在膝上设备上的应用系统，可以被设计成以离线方式工作，或者至少当连接丢失的时候能基本上以离线的方式工作。
图1给出了一个典型的RIA体系结构。XML通常被用作数据传输的格式，有时也被用来描述窗体的布局。在很多的实例中，客户端可以保持与数据源的连接，这样服务器能够实时地对客户端数据进行更新。对一个Oracle数据的访问可以通过Web服务调用来完成。
用于富客户端的技术
下面是一些可用的RIA技术：
Java：一些相当复杂的客户端应用程序（Oracle的JDeveloper，Eclipse）都是用Java编写的，这说明可以用Java来建立几乎任何一个能够想象得到的富客户端应用程序。到目前为止，Java已经出现几年了，并且完全支持创建基于窗体的用户界面。除了Java基础类（JFCng）中的用户界面组件之外，开发人员还可以使用来自于Eclipse Project的SWT工具箱和许多第三方工具箱进行开发。对于图形来说，可以采用Java 2D API--一个非常完整且非常复杂的图形API。Java还具有对XML和Web服务无人匹敌的支持能力。你可以通过一个Web浏览器使用Java插件软件，或使用Java运行时环境中较新的Java Web Start技术来部署应用程序。使用Java建立富客户端程序的主要缺陷是它的复杂性（即使对简单的窗体和图形也要求编写非常烦琐的代码）。它的优点在于Java对Web标准的全面支持，及该语言和类库的深刻内涵。
XUL：XUL（念作"zool"）是一个基于XML的用户界面语言，它来自于Mozilla的开放源码项目。它可用于建立窗体应用程序，这些应用程序不但可以在Mozilla浏览器上运行，而且也可以运行在其他描述引擎上，如Zulu（一个Flash MX组件）和Thinleys（一个Java实现）。XUL描述引擎都非常小（100K以下），它可以使用XML数据也可以生成XML数据。同Java的情况一样，XUL也有一个非常大的用户团体，这个团体有大量的开放源工具，如Theodore ThinletEditor（见“下一步”）——一个使你能够以图形化方式布局用户界面，且可以生成相应XUL的Java应用程序。XUL的一个主要缺点在于它目前还没有获得一个主要商业实体的支持。XUL最大的优点在于它与Gecko引擎的集成（打开了通向大量Web标准的大门），以及与大多数其他XML用户界面描述语言相比它是一种非常具有表达力和简洁的语言。
Macromedia Flash和Flex：Flash是一个已经成熟的商业产品，它可以在Web网页中引入交互式的图形界面。最近经过升级后，新版本包含了建立窗体风格的应用程序的功能。尽管Flash作为一个在Web上最广泛部署的前端技术还有争议（取决于所选用的Flash Player版本），但据称已经有98％以上的桌面系统都支持Falsh。由于用来创建动画式图形的Flash工具其功能十分强大和是可视化的（与之相反其它技术要求进行低级的图形编码），所以图形设计人员使用起来十分得心应手。Flah采用的脚本语言是ActionScript--ECMAScript 1.5的一个变种，该脚本语言又被称为JavaScript。Flex产品对Flash增加了一个XML描述语言，使得可以编译用户界面，并且能够用Flash Player来随时进行描述。Flex使得传统的开发机构能更好地了解和使用Flash。Flex和Flash的最大缺点在于对XML和Web服务等标准的支持很有限，而且作为应用开发工具的环境还不大成熟。Flex和Flash的优点在于它可以很容易的用来创建复杂的动画式显示，以及可以使用第三方附件。
Oracle Forms：Oracle Forms是用来构建以数据库为中心的互联网应用系统的一个成熟的商品化产品。通过Oracle Forms，你可以使用一个输出窗体模块文件的可视化设计器创建窗体。为了便于在该设计工具外部进一步进行处理，模块文件要么采用私有的FMT格式，要么采用XML格式。这些模块文件驱动一个描述窗体的Java运行时环境。除了所有窗体的标准窗口小部件之外，还可以通过集成附加的可插入的Java组件和一些定制的JavaBean来实现更多的功能性。Oracle Forms采用的脚本语言为PL/SQL，Oracle数据库也采用同样的脚本语言。Oracle Forms的一个非常有趣的特点就是，用来建立、编辑和编译窗体模块文件的Java API--开发人员可以通过创建脚本来生成众多的窗体应用程序，或者进行全局性的改动。Oracle Forms的主要缺点是，进行Web部署需要获得Oracle应用服务器的使用许可。它的优点是，它可以与Oracle数据库和Oracle平台的其他部分（如Single Sign-On（单一登录）和Enterprise Manager（企业管理器））紧密集成，对国际化的广泛支持，以及创建以数据为中心应用程序的极高效率。
开始选择和使用RIA技术
这里只讨论了可用于创建RIA的技术中的一些有代表性的例子，还有很多其他的技术。当选择一项RIA技术的时候，你需要权衡以下几个因素：
开放源产品与商品化产品进行对比；
成熟的功能与最新的特性进行对比；
轻量级的功能特性范围与UI的丰富性进行对比；
以媒体为中心的应用程序与以数据为中心的应用程序进行对比；
无论你选用哪种技术，我都可以提供最好的创建RIA应用程序的实践经验：
在后台线程获取数据。对于一个富客户应用程序所期望的性能是很高的，如果该应用程序在从一个Web服务收集数据的时候出现暂停，则将被看作是无反应的。
保持客户端与远程数据的同步。由于不再经常刷新页面，所以如果有可能，将数据的变化以异步的方式推送到客户端是非常重要的。
雇佣一个图形艺术家，或者至少一个好的UI设计人员。当然，伴随着创建具有可视化的有趣功能的UI的能力，它也带来了将事情搞混乱的机会。
请给我发邮件，让我了解在你们的组织内部是如何计划使用RIA的，并且一定要经常查看devtrends.oracle.com 站点以获取补充的资源。
论传统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应用程序和环境内逐步添加新功能以充分利用现有网络应用投资
结 构
RIA本身有能力提供这类Web应用解决方案。如上图，RIA将桌面型计算机软件应用的最佳用户界面功能性与Web应用程序的普遍采纳和低成本部署以及互动多媒体通信的长处集于一体，终于成就了一种可以提供更直观、响应性和有效的用户体验应用程序。它所具备的桌面型计算机长处包括了在确认和格式编排方面提供互动用户界面；在无刷新页面之下提供快捷的界面响应时间；提供通用的用户界面特性如拖放式(drag and drop)以及在线和离线操作能力。Web网的长处如立即部署、跨越平台可用性、采用逐步下载来检索内容和数据、拥有杂志式布局的网页以及充分利用被广泛采纳的互联网标准。通信的长处则包括双向互动声音和图像。
客户机在RIA内的作用不仅是展示页面，它可以在幕后与用户请求异步地进行计算、递送和检索数据、重新画出屏幕的一部分和密切综合使用声音和图像，这一切都可以在不依靠客户机连接的服务器或后端的情况下进行。
RIA提供一个强劲的技术平台，使客户机的能力复原到差不多与桌面型计算机软件应用或传统的C/S系统中的客户机能力相似。它适合传统的N层开发过程，同时也能够和遗旧的环境集成以延展现有的应用程序而无需进行修改。它也可以作为基础网络服务的互动表现层，允许用户在线和离线工作。RIA有能力解决各种复杂性，使需要复杂性的应用得以开发并且减少开发成本，同时在很多时候这类应用之所以能够成形主要是拜RIA所赐。
RIA方案—基于Flash的Flex
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把java script发挥到了第九层！”——网友这样评价Bindows。
运行中的Bindows
的确如此，Erik等编写这个框架已经将java script的OOP和基于IE6的DHTML发挥到极点！Bindows 0.93发布的时候已经将IE内置的功能开发得淋漓尽致了，包括Filter、XMLHTTP、Web Service、VML。java script用于客户端界面的显示和处理，XMLHTTP用于客户端与服务器的信息传输。java script在客户端的表现力不容置疑，看看www.bindows.net所表示出来的能力，利用java script几乎可以实现Windows应用程序所能干的大部分事情，XMLHTTP一直以来常被用于实现“无刷新”的Web页面，它和java script配合，可以完成数据从服务器和客户端的传输。
Bindows的不足
Erik喜欢那种一次全部载入的方式来实现脚本库，使用过Bindows会发现，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。按照V0.93，脚本文件的大小是600多K，在一个普通的Web应用中，我们更多时候不会用到Bindows的全部功能，这点Bindows根本没有遵循“用多少去多少”的准则。另外，过多的JS会使CPU占用率陡然增加，产生潜在问题。
内部大量利用了IE6的技术，没有考虑到非微软平台的浏览器，限制了Bindows的流行。在图表方面，大量采用了VML技术，在IE5，IE5.5这两个版本，VML引擎不是那么的成熟，很多地方的显示不够流畅，会受到带宽和硬件的限制，过分绚丽的图形最终会给用户带来崩溃。“图形方面我是采用VML的，当初太偏执，如果使用SVG来实现可能好许多的，也就是那段日子，我花了非常多的时间去折腾web方面开发。”——有网友这样说。
一句话概括
在技术的角度上，从Bindows是可以学到不少东西的，但好像它的学术价值大于它的商业价值。
转载自：http://www.cnblogs.com/ksuifeng/archive/2009/06/03/1495131.html
扫一扫
1313
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
