本来是想写一个RIA综述的文章，后来因为各个方面的原因就写成这样的文字了，也懒得去做任何修改，近期我会写一篇Smart Client相关的文章，里面会比较多篇幅的应用此文，Smart Client的文章将在《软件世界》发表，因此如果是商业站点要转载本文，请提前和我打一个招呼。
英国人改变世界
不管如何，通过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提供的技术)。却无法做到客户自己进行应用的集成。
