什么是RIA？这是业界关于软件开发一个共同问题了。简单说来，RIA就是丰富体验的因特网应用程序。但是这并没有解释清楚什么是RIA。这篇文章的目的就是阐明我所理解的RIA，什么是RIA的特点？
丰富的用户体验，我认为这是丰富体验的因特网应用程序的最根本特点。但是这并不等于说，分离的界面，一步的数据传输，有状态的客户端，或者任何特定的技术就是丰富体验。虽然这些看起来可能是丰富体验的应用应用程序的共同特征，但是他们并没有定义丰富体验的因特网应用程式，只是说应用程序应该怎样使用，应该用来干什么？因特网应用程序首先要给用户带来丰富的体验，他应该易于使用，易于投入，专业于他所设计的任务。
这些要求听上去像和桌面应用一样，但是RIA应用却通过网络发布。RIA应用和桌面应用包含一些共同的特点，例如：数据的拖放处理，绘图制表功能。然而丰富体验的因特网应用程序又不强制要求包含这些特点。那么丰富体验的因特网应用程序的共同特点是什么呢？
正如上面所述，最基本的要求是丰富的用户体验，当然丰富用户体验可以通过多种手段来达到，例如：有状态的客户端，异步的数据传输并不是RIA的要求但却是RIA实现的最通常手段．
l 有状态的客户端接口 ，顾名思义它在客户端维持的应用程序的状态，它并不需要通过服务端来了解用户正在做什么，这使得用户逻辑可以更加面向服务以及异步，分到端的服务可以通过传递进的参数调用来决定当前的动作，不管是谁调用这个函数，用户接口也不需要等待服务端到来的业务逻辑，异步的数据服务在后台被执行，与此同时，用户接口仍可，用户甚至不知道服务端哪一个方法被调用了。这使得用户可以无间断的使用程序，从而获得一种桌面应用的感觉，另外异步的数据服务只包含数据而没有界面逻辑。由有状态的客户端来决定使用什么样的界面，这同时也减轻了与服务器端通讯的负担（当然通讯的时候用户界面一样可用）用户可以继续使用程序。应用程序动态地呈现交互结果，例如执行请求调用的时候显示动画。
l 界面对拖放的支持也不是RIS应用程序的一个强制要求，但同时也是实现丰富体验的因特网应用的一个重要手段。可以问任何人特别是非技术人员，相比向信息框输入数据和拖动一个条目进入某个区域同时传出结果哪一个更简单的？答案显然是拖放，拖放实现起来根据约束和执行的需要可以分为不同的实现手段，但是使用它的好处却是显而易见的，在线地图的拖放，在线购物的拖放物品进购物车，在办公系统中创建可拖放的对象也是一项可以提高生产效率的技术手段。甚至说在线的图像编辑中可拖放的元素都是丰富因特网应用的体现。这种现象在RIA革命前并不多见，直到现在才流行开来，在网络上随处可见。绘图分析的工具虽然不一定要包含，但是恰到好处地使用却为应用程序增色不少。许多的RIA技术提供了在运行时处理图像的功能，图表绘制，数据可视化甚至3D建模.一张图胜过千句话，这些技术使得你的应用程序交互性良好。而不是让用户面对着1,000行的表格自己去分析趋势；用户只需要看着图表，应用程序应该立刻呈现出数据所体现的趋势。
什么样的技术可以用来创建丰富体验的因特网应用程序？有很多吗？并没有哪样技术最适合丰富体验的因特应用程序，有那么多的技术可以采用来创建不同的应用程序，是用什么样的技术取决于你的需求，用户的需求。我特别推荐FLEX是因为它使得客户端的开发变的非常容易，使得开发周期缩短。当然你有多种选择例如：FLEX,AJAX SILVERLIGHT,JAVAFX 当然我不能列出所有的选项，关键是你自己的选项。没有确定是正确的选项而适应所有的场合，选项取决于应用程序所需求的功能和特色以及可用的资源T，技术需求，当前的架构。服务端不需要使用任何的丰富体验因特网应用技术，可以采用任何的服务端语言，我个人用过COLDFUSION，JAVA/J2EE,.NET/PHP当然我知道还有无数的选项。使用什么样的客户端技术，服务端技术取决于应用，你的资源，你的架构。你服务的是动态的数据吗？是流媒体吗？你采用了即时通信吗？你在升级现有系统吗？或者是重新开发？你的组织支持开源吗？你的组织更倾向于商业软件有技术支持吗？该技术的预算是多少？对于解决问题的预案有很多参变量。
RIA并不是特指任何的技术，也不是我所希望他呈现的那样，Web2.0是RIA吗?不Web2.0是一个市场促销的手段罢了，虽然我深信Web2.0和RIA原来的意思是一样的，但是Web2.0现在已经退化为设计上一些细节例如：圆角的矩形，颜色渐变，透明度，反射。但是我不担心RIA也会退化成那样。也许RIA这个术语会被滥用但是RIA背后的思想不会变，它包含了应用程序用户体验以及应用程序成功地完成任务需要。
RIA永远是明智的选择吗？对RIA的选择取决于他的上下文。在很多情况下，它确实是合理的选择，但是当然也有例外。RIA适用于应用程序而不是网站，当然这里有一个显著的区别，我认为合理数量的RIA应用，例如异步文本框查询对于网站很有用，但是如果用得太多会使得这网站可用性很差。RIA对于提高办公效率的应用程序，业务数据分析应用程序，媒体程序，图像形式很有用，但是他也不是万能的。许多RIA程序使得网站被搜索引擎索引出现困难。如果这样的网站要与搜索引擎协作那么必须对RIA进行优化。如果使用的恰当那么网站从中受益。和所有其他的技术一样RIA可能被滥用，开发者只有对用户的需求详细了解的时候才能从这项技术中受益。
原文：
What really is RIA? This is a common question for the development industry in general. In its most basic sense, RIA is an acronym for “Rich Internet Application”, but that doesn’t really shed much light upon what a RIA actually is. The goal of this post is to help shed some light onto what RIA means to me. What is the defining characteristic of a RIA? Rich User Experience: I think the most defining characteristic of a “Rich Internet Application” is a rich user experience. This does not necessarily mean a slick interface, or asynchronous data transfer, a stateful client interface, or any specific technology. While these may be common characteristics of RIAs, they do not define them. It boils down to how the application is used, and what it is being used for. A Rich Internet Application provides a great experience for its users. It should be easy to use, engaging, and targeted to perform its task very well. To many this means a “desktop-application-like-experience” delivered through the web. This may include common features such as drag-and-drop data manipulation and imaging/drawing/charting capabilities, but it is not a requirement to include any of these. What are common characteristics of a Rich Internet Application? As I mentioned above, the only real requirement of a RIA is the rich user experience. However, the richness of experience can be achieved through many common techniques: Stateful Client and Asynchronous Data Transfer Although not a requirement of RIA, it is very common that Rich Internet Applications employ stateful clients and asynchronous data transfer to achieve their tasks. A stateful client interface is exactly as the name describes; it maintains state of the application completely on the client side. It does not rely on the server to maintain information about what the current user is doing. This enables the ability to simplify backend logic to be more service oriented and asynchronous. The back-end services can perform specific actions or logic based on parameters passed into them, regardless of who invoked them. The user interface also does not need to wait on the backend logic. Asynchronous data services are performed behind the scenes, while the user interface is still accessible to the user. The user may not even know that a remote service method has been invoked. This enables the user to keep using the application seamlessly, which helps lend to the desktop-application feeling. Additionally, asynchronous data services typically only contain data, no UI declarations; it is up to the stateful client to determine how the data will be displayed. This typically reduces the size of the requests back and forth to the server, and often results in reduced server load and better interface responsiveness. Not to mention, the client application does not loose its place when the service request has been made. The user can keep working with the application, and can show active feedback to the user, such as a loading animation while the service request is being executed. Drag-and-Drop UI Paradigm Also not a requirement, but a common paradigm implemented within Rich Internet Applications is “drag-and-drop”. Ask anyone, especially non-technical people, what is easier: typing into a bunch of forms to enter information, or dragging an item onto a “cart” and having the information automatically populate? The answer is clearly drag-and-drop. This technique varies based on the technology implementations and restrictions, but its benefits can been seen clearly. Dragging items onto online maps, dragging commercial goods into shopping carts, creating “drag-able” objects in online office productivity applications, and even “drag-able” elements in online image editing applications are all rich features that are capable because of the drag and drop paradigm. This type of capability didn’t exist in mainstream online applications until the “RIA Revolution”
Now you see it everywhere. Drawing and Analytical Tools Not every application has these either, but they really add a lot when they are used properly. Many RIA technologies enable the capability to manipulate graphics onscreen at runtime. This enables charting and complex data visualizations, and in some cases, even 3D modeling. An image is worth a thousand words, and these types of capabilities enable your application to say a lot. Without the bloat of large tables of data that the user has to analyze in order to see the trends; the user can simply look at it, and instantly see what is going on. What technologies are used to create Rich Internet Application? Lots of them
there is no single technology that is best suited for RIA. There are lots of great technologies that enable various capabilities. The choice of technology should be determined based upon your needs, and your application users’ needs. Typically I prefer Adobe Flex on the front end because it makes a lot of these paradigms easier, and enables rapid development cycles, but there are many options: AdobeFlex, AJAX (there are many AJAX frameworks available), Microsoft Silverlight, Java FX, etc... I know I didn’t name every option, but the truth of the matter is that you have an option. There is no definitive “right choice” for all occasions. The desired capability and features of your application, in conjunction with your available development resources, technical requirements, and current infrastructure should determine which technology suits your needs most adequately. On the back end, there is not any requirement for RIA. You are not limited to any specific application server or language. I have personally worked on RIAs that employ ColdFusion, Java/J2EE, .NET, and PHP, and I know that there are numerous other options out there. As with your client-side interface technology, your backend technology should be determined by the needs of your application, your resources, and your infrastructure. Are you serving dynamic data? Are you streaming media? Are you employing real-time messaging? Are you upgrading an existing system, or building one from the ground up? Does your organization support open source initiatives? Does your organization prefer commercial products that have technical support? What is your budget for technology? There are many variables in the equation, and many solutions to the problem. RIA is not locked in to any one specific technology, nor do I expect it to ever be. Is Web 2.0 RIA? No! Web 2.0 is a marketing buzzword. I truly believe that “Web 2.0” originally meant the same thing as RIA, however it has been completely overused and abused. Web 2.0 has been degraded to a reference for common graphic design elements such as rounded corners, gradients, transparencies, and reflections. I don’t doubt that the term RIA will also become overused and abused, but the ideas behind RIA will not. It all boils down to the application, the user experience, and the ability to for the application to perform its task well. Is RIA always the right choice? The choice of RIA depends on the context. In many cases, yes it is the right choice. In many cases, it is not. RIA is best suited for applications, not web sites. There is a definite distinction there. I think a limited amount of RIA concepts, such as asynchronous lookups for text boxes can be helpful in a web site, however too much could potentially kill the web site and make it difficult to use. RIA is great for office productivity applications, business/data analysis applications, media applications, graphics applications, and online mapping, but it does not suit every need and every purpose. Many RIA technologies cause sites to have problems being indexed by search engines. RIA technologies must be designed with search engine optimization in mind for them to work properly with search engines. When employed properly, applications benefit from RIA principles and technology. As with any technology, RIA methodologies can be overused and abused, and it is up to the discretion of the developers and providers to implement them correctly. The developer/provider company *should* know their users/customer/consumers best.
