** 本来是想写一个 ** ** RIA ** ** 综述的文章，后来因为各个方面的原因就写成这样的文字了，也懒得去做任何修改，近期我会写一篇 ** ** Smart Client ** ** 相关的文章，里面会比较多篇幅的应用此文， ** ** Smart Client ** ** 的文章将在《软件世界》发表，因此如果是商业站点要转载本文，请提前和我打一个招呼。 **
英国人改变世界
没错，就是这位仁兄在不经意之间改变整个世界。在 CERN( European Particle Physics Laboratory ，欧洲量子物理研究所 ) 工作期间，他发现了 CERN 在信息的内部沟通存在信息遗漏的弊端，于是在 1989 年 3 月 Tim 向 CERN 提交了名为“ Information Management: A Proposal ”的建议书，这个也是迄今为止我们能够看到的关于互联网概念的第一份公开文件。在这份文件中， Tim 提出利用 Hypertext （超文本）构造链接信息系统的设想 。同样，我们也可以从文件中看到 “Browser （浏览器） ” 概念的最初提出。 1991 年，在此基础上 Tim 开发了第一个真正意义上的 Web 服务器 ——httpd 、第一个客户端浏览器 ——WorldWideWeb ，之后又在 1991 年建立并开通第一个 WWW 网站 http://info.cern.ch/ （该网站至今仍然是 CERN 的官方站点）。从此互 
联网真正开始向社会普及。至于后来 Tim 加入麻省理工大学 LSC( 计算机科学实验室 ) 和后来成立的 W3C 又是另外一件有深远意义的事情了。
不管如何，通过 WWW ，这个有点憨厚的英国人已经彻底改变整个世界。
1993 年 5 月，伊利诺斯州大学的天才少年 Marc Andreessen 开发了第一个浏览器 Mosaic,1994 年上半年他和 Jim Clark 成立了 Mosaic Communications （也就是 Netscape 的前身） , 同年 10 月发布了 Netscape 0.9, 这个是我们看到的第一个浏览器的 Logo, 虽然今日已经面目全非。
而 Netscape 的出现终于让 WWW 得到了爆炸性的普及。
Browser/Server, 一个无法完美的名字
随着浏览器大战的开始，世人真正意义的享受了科技进步给人类带来的福旨。一夜之间， B/S 结构成为应用开发最主流架构，浏览器成为客户端的唯一工具，这种不需要部署的软件应用确实给了很多人无限的疯狂。 ISV 、解决方案提供商及其企业用户也不约而同的提出采用 B/S 架构作为企业信息应用的架构，因为那样可以免去之前 C/S 时代高昂的部署和升级费用，能够快速适应不断变动的企业业务。
渐渐的，他们发现自己不断复杂的业务通过简单的页面浏览已经无法满足要求，这个时候相关的客户端脚本技术走上舞台，说起来有点戏剧性， Netscape 设计脚本的初衷是为了让网页有更好的浏览性，从而增加页面浏览的乐趣，他们一定没有想到这个概念却在他们的对手发挥到极致，等到那场浏览器大战的硝烟渐渐淡去的时候，我们发现脚本已经面目全非，或者说已经臃肿不堪。
为了沿袭 C/S 结构下的界面使用体验，开发人员不得不利用大量的 JavaScript 和 DHTML 去实现或者说“模拟”传统应用程序的使用界面，比如菜单，工具条，还有那复杂的图形和表格。也因为如此， Web 开发成为当今最火爆的应用领域，除了相关的服务器开发技术如 ASP,PHP,JSP 还有后来的王者 ASP.NET ，客户端技术则包括了 HTML,CSS,JavaScript,DHTML 等等方面的技术，这些都成为开发人员的一种追逐。更有甚者，利用客户端技术开发了一整套完整的类库，这点最著名的莫过于 Bindows( 可以从 http://www.bindows.net 下载 ) 。
在解决了部署和更新的问题之后， B/S 同样引入了一些令人头痛的问题：
1） 始终没有一个非常标准的技术规范来约定，由此造成了各个浏览器在 w3c 之外做的扩展，在应用开发中，更多的是需要依赖于这些扩展去实现更加绚丽的图形表现和灵活的交互。比如 IE 里面提出了 HTC 的概念，也增加了许多相关的滤镜（ Filter ）， Mozilla 也提出了 XUL 用来扩展用户界面。但是如果需要设计一个具有强大功能的用户系统，我们更多情况下不得不依赖于专有浏览器的扩展实现。
2） 作为浏览器大战的胜利者 IE 从 2001 年之后就没有推出过重要版本更新，那么也就意味者我们所有的开发技术是停滞在 2001 年之前的理念，这点和服务器端技术的不断发展已经渐渐脱节。
3） 作为基于浏览器的应用，因为安全等等方面的原因始终做不到能够成为应用的集成者，更多时候是被动的去接受单一服务器提供的应用，比如对于客户端希望能够跨越不同网络调用相关的 Web Services ，因为安全模型的畸形（不是非常完善的资源访问控制），我们无法做到在同一浏览器内流畅的实现跨应用集成 [1] 。
4） 基于浏览器的技术严格意义来说是依赖于在线访问而构建的应用，在需要一些离线 (Office Line) 的应用中，就显得有心无力，毕竟从浏览器设计的一开始就是希望能够在意个最小权限的“沙盒”模型下去运行，因此对于本地资源的访问默认情况下是拒绝的，而某些浏览器如 IE 允许通过设置来跨越这个安全模型，但是没有提供一个非常良好的权限分层机制，闸门一开，一切犹如洪水猛兽。
Browser/Server, 这个近 10 年来风光无限的词眼，依旧不是那么尽善尽美。
我们需要什么？
** ** 其实理由已经很简单，虽然网络上已经出现了许多 C/S 或者 Rich Client 回归的论调，我想更多的是因为对于目前 B/S 架构存在的问题而提出的，因为从本质上来说许多问题在 C/S 结构下是不存在的。无论如何，我想回归只是一个倾向，希望利用 C/S 的优势去解决 B/S 存在的种种问题，而不是简单的回归，假若真的如此，我们又要重复过去的那种灾难如令人头痛的部署，频繁升级带来的版本兼容问题，我想对于企业的 IT 工作者，谁也不愿意重蹈覆辙。
那么，我们需要什么？ Tim 通过互联网已经改变了这个世界，那么下一步将要走向何方？这个时候关于 RIA(Rich Internet Application) 的论调也就形成，并且在 2004 年逐渐得到开发人员和系统架构师的认同。严格意义上来说，我们不会关心哪个名字缩写会是下一代的主流，我们更多的是着眼于需要解决的技术
1） 需要一个更加强大的客户端运行环境，同时提供统一简便的开发模型。某种意义上来说目前的浏览器正是 HTML 和脚本这种混合“程序”的运行时，所有的代码（ HTML,CSS,JavaScript ）等等都是在浏览器这个受控的环境下去运行的。但是目前的运行环境远远不够，同时没有一个统一的编程模型。
2） 尽大可能的利用客户端资源，并且资源的访问是在一个可以控制的环境下完成的，随着 HTML 和 CSS 的演变，已经不是最开始一个 Hyperlink （超连接）那么简单，但是相对于 Windows 运行环境，在浏览器上能够完成的图形表现远远不够。
3） 天生具备访问网络的能力，同时能够比较“ Smart ”的集成 Internet 上的应用。
4） 能够自动完成安全和升级
5） 拥有一个完整的安全模型和 CAS( 代码访问安全 ) 。
6） 具备离线应用的能力，因为访问终端的多样化，对于“有时离线”的支持已经成为一个关键点，例如在基于智能手机的应用时，要求客户端实时在线有点勉为其难，这个时候在 Mobile 的应用上采用传统的 B/S 结构已经不太现实。
针对上述要求，一些主流的应用厂商也提出了各自不同的概念，比如微软的 Smart Client （智能客户端）技术， MacroMedia 的 Rich Client 还有 Mozilla 的 XUL ，下面就针对这三种主流的 RIA 应用架构做一些阐述。
主流的 RIA 应用架构
Microsoft Smart Client （智能客户端）
从某种意义上来讲，微软提出的智能客户端和上述提到的是最为接近的，也提供了最为完善的运行环境支持。智能客户端在设计和实现方面差异极大，这既包括应用程序要求，也包括可以使用它们的方案和环境的数量。因此，智能客户端可以采取许多不同的形式和风格。根据智能客户端应用程序所面向的平台，可以将这些形式划分为三大类：
n Windows 智能客户端应用程序
Windows 智能客户端应用程序适合于需要将应用程序作为熟悉的桌面类型应用程序进行部署和访问的情况。这些类型的应用程序通常由其自身提供其大部分功能，但是在适当的时候可以与其他应用程序集成或者协调其他应用程序。它们提供针对特定任务进行调整的应用程序功能，以提供特定的或高性能的处理或图形能力。
n Office 智能客户端应用程序
Microsoft Office System 2003 为您提供了用来生成智能客户端应用程序（尤其是在企业设置中）的有用平台。这样的 Office 智能客户端应用程序可以成为组织的信息管理周期的集成部分，而不只是文档数据的静态容器。当用户在文档内工作时，它们可以提供上下文相关的数据，以及可以将 Web 服务公开的数据转换为有用信息的工作流和任务指导、数据分析、协作、报告和呈现功能。
n 移动智能客户端应用程序
移动智能客户端是在智能设备上运行的应用程序，这些智能设备包括 Pocket PC 、 Smartphone 以及其他超小型台式设备（如机顶盒）。这些应用程序是使用 .NET 框架压缩版（它是完整 .NET 框架的子集）开发的。
说到这里，我们不得不提 .NET ，正是这一个统一的编程模型才让 Smart Client 的成为可能，从某种意义来说， .NET Framework 具备了上述我们提到的所谓几个需要，包括 Internet 访问能力，包括 Web Services 访问，包括 CAS ，包括强大的 WinForm 等等，而 MSDN 站点上提供的相关 Application Block 能够加快这些应用开发的步伐。
在 Longhorn 的 Avalon 没有到来之前， .NET 在一些 Rich Client 的实现应该是最完备的，虽然 Java 也提出了 WebStart 的概念，但是我们知道，在桌面应用领域， Java 并没有太大的优势，包括最早的 Applet ，后来的 SWT 和 Swing 等等，除非需要跨越平台应用，不然在桌面应用领域， Java 并没有太多的优势。
如果说 .NET Framework 已经为 RIA 打好家底了，那么 Visual Studio.NET 则是其实现的利器，作为目前最好的 IDE ，对于 Smart Client 也提供了内置的支持。对于开发人员而言，能够利用 VS.NET 轻松的构建自己的应用系统。
MacroMedia Flex
相对于微软的 Smart Client ，作为互联网多媒体应用领域的老大 MacroMedia 也提出了 Rich Client 的概念，和 .NET 相反，不是提供给客户一个强大的运行环境，而是将所有的应用放在了 Flash 上，毕竟全球 99 ％的浏览器都会安装 Flash 播放器。
Flex 更加侧重于 UI 方面的实现，在交互方面通过 ActionScript 来完成，内置提供了 Web Services 访问、 XML 应用等等各个方面的技术。和 Longhorn 的 Avalon 有点类似，提出了一个相对于 HTML 更加强大的 UI 描述语言—— MXML ，让开发人员更加方便的进行应用开发，同时通过内置组件和脚本（ ActionScript ）提供了将大的表现能力，不要以为 ActionScript 是简单的 JavaScript ，除了完整实现 ECMA 262 Edtion 3 的规范之外，同时加入了许多自己的扩展，因此动作脚本的名字已经名不符实，客观的说，已经是一门强大的语言。
图形表现方面， Flex 的应用比 Smart Client 更胜一筹，但是在离线应用和开发方面远远不如 .NET 支持的好。虽然 Flex 足够强大，但是其昂贵的软件许可和谈不上特别流畅的开发环境限制了其的发展， Flex 要成为主流还需要一些时日。
Mozilla XUL
XUL 的核心思想是“用 XML 来表达界面”，是 Mozilla 的创新， Mozilla 浏览器本身就是一个经典的 XUL 应用。作为 Netscape 的继承者， Mozilla 成为一些技术追随者吹捧的浏览器，最近的 FireFox 则有点出乎意料的得到更多人的认可。
从直接的感觉来说， XUL 是一个客户端运行环境支持的一个框架，相对于 HTML ， XUL 提供了更多的支持，这点和 IE5 就提出的行为 (Behivor) 有点接近。但是 XUL 提供了比 HTC 更加灵活的模型，并且因为 Mozilla 本身就是设计成运行在不同的操作系统，因此从这个角度来说通用性更好一点。
但是因为 IE 占据绝对的主流， XUL 更多只是一种实验性的理念。
一切已经明了。我坚信， RIA 会在将来几年中替代许多基于浏览器的应用程序。
这并不意味着转换没有给他们带来任何痛苦。它要求开发人员学习新的分布式体系结构和新技术。在许多情况下，他们必须更好地进行面向对象的开发和用户界面设计。
那些花费最近五年时间学习基于浏览器部署的开发人员可能不希望进行改变。他们已习惯了作为他们那个时代的领先的开发人员。但是所有的技术都会经历鼎盛期、衰落期，最后被更新的技术所替代。尽管我们继续会看到基于浏览器的应用程序仍会在某些情况下使用许多年，但是我相信基于浏览器的开发现在已经过了其鼎盛期。从鼎盛到衰落可能会经过一段时间，但是这一方向是明确的。准备好迎接 RIA 的到来吧！
[1] 打一个简单的比方，远程站点 A 提供了天气预报的服务，站点 B 提供了日程管理服务，站点 C 提供了一些旅行相关的 Web 服务，这个时候如果需要集成者三个站点的服务，需要在服务器端去集成这些服务，然后通过预定的方式提供给客户端，在定制方面更多的采用了 Portalet(Java 术语 ) 或者 Web Parts(Microsoft SharePoint 提供的技术 ) 。却无法做到客户自己进行应用的集成。