jQuery

Rich Internet Applications

Definition

Rich Internet applications (RIA) are Web-based applications that have some characteristics of graphical desktop applications. Built with powerful development tools, RIAs can run faster and be more engaging. They can offer users a better visual experience and more interactivity than traditional browser applications that use only HTML and HTTP.
 
Early Internet users mostly exchanged text-based electronic mail messages. Then along came HTML and the World Wide Web, and soon people were looking at graphically enhanced Web pages designed by specialists and served up on demand. All these applications mainly involved reading text on-screen and dealing with material that was preformatted and essentially static.
To do tasks like manipulate data and interact with sophisticated business logic, users relied on specialized software on their computers and networks. Then someone thought about providing applications through standard Web pages that people could access with their browsers.

RIA Characteristics

A number of key features differentiate RIAs from traditional Web applications.

Direct interaction: In a traditional page-based Web application, interaction is limited to a small group of standard controls: checkboxes, radio buttons and form fields. This severely hampers the creation of usable and engaging applications. An RIA can use a wider range of controls that allow greater efficiency and enhance the user experience. In RIAs, for example, users can interact directly with page elements through editing or drag-and-drop tools. They can also do things like pan across a map or other image.

Partial-page updating: Standard HTML-based Web pages are loaded once. If you update something on a page, the change must be sent back to the server, which makes the changes and then resends the entire page. There's no other way to do it with HTTP and HTML. With traditional Web-based apps, network connectivity issues, processing limitations and other problems require users to wait while the entire page reloads. Even with broadband connections, wait times can be long and disruptive.



Better feedback: Because of their ability to change parts of pages without reloading, RIAs can provide the user with fast and accurate feedback, real-time confirmation of actions and choices, and informative and detailed error messages.

Consistency of look and feel: With RIA tools, the user interface and experience with different browsers and operating systems can be more carefully controlled and made consistent.

Offline use: When connectivity is unavailable, it might still be possible to use an RIA if the app is designed to retain its state locally on the client machine. (Developments in Web standards have also made it possible for some traditional Web applications to do that.)

Performance impact: Depending on the application and network characteristics, RIAs can often perform better than traditional apps. In particular, applications that avoid round trips to the server by processing locally on the client are likely to be noticeably faster. Offloading such processing to the client machines can also improve server performance. The downside is that small, embedded and mobile devices -- which are increasingly common -- may not have the resources necessary to use such apps.

The list of current technologies that can be used to build modern RIAs is long. Here are some of them:

• AJAX
• Adobe Flash, Flex and Adobe Integrated Runtime (AIR)
• Microsoft Silverlight
• Curl (an object-oriented language with embedded HTML markup)
• Google Gears
• OpenLaszlo and Webtop
• Oracle WebCenter 

DELTA-COMMUNICATION TECHNOLOGIES

Delta-Communication is the rich communication model used by the rich features of the RIAs,

for client-component(s) to communicate with the server-component(s), to exchange only the needful dataset – for aparticular feature executed at the time – which is smaller compared to the size of the request/response of traditional communication. Since the size of the dataset communicated is smaller, the communication completes faster, eliminating the work-wait pattern. The processing of the response is done by the client-components in the background, therefore the page refreshes are eliminated and replaced by partial page rendering to update the content of the GUI with the results of the response. The user experience can be determined by the implementation of the feature, in either

blocking (synchronous) or non-blocking (asynchronous) modes.

 

 

Simple-Pull-Delta-Communication (SPDC) can be seen as the simplest form of DC
•Used in AJAX 
•Single XHR request to the server
•Client-side: Native JS support 
•Server-side: special technology is not needed

Pollingis used to simulate data-push 
•Send XHR requests periodically to the server 
•Client-side: Native JS support 
•Server-side: special technology is not needed 
•Can increase network traffic (less scalable) 
•Blank responses can waste resources

Comet 

Comet is an umbrella term, which covers Streaming and Long Polling. In Comet techniques, unlike polling, the request is held by the server till there are updates to be sent back to the client. In the case of timeouts, the request is terminated, and the client can send a fresh request. This technique reduces the frequency of the requests, thus, also reduces the overhead on the network compared to polling

 

 

Server Sent Events

a true data-push protocol named Server Sent Events (SSE) was introduced, which is unidirectional, from the server to the client. However, it did not become much popular. Compared to data-push simulation techniques, the complexity is lower, and the development and modifiability are easier since the development overhead for data-push simulation as in polling or long polling is not needed.

 

WebSocket 

An advanced bi-directional DC protocol named WebSocket (WS) was introduced in 2011, which supports both data-pull and data-push modes. WS helps to reduce the number of request-response pairs in the network compared to polling, and the header size of the WS is smaller than HTTP, which

leads to increase the scalability by addressing the C10K problem compared to the other DC TTs. The WS gained the attraction of the web engineers, however, the complexity of WS applications is higher

 

 

 

Microsoft was working on a technology named XMLHTTP in their Exchange 2000 project and it was first introduced to the world as an ActiveX control in Internet Explorer 5.0 in March 1999  and

later it was called the XMLHttpRequest (XHR) object, which has an Application Programme Interface (API) in JavaScript (JS).In 2005, Jesse James Garrett from Adaptive Path coined the

name AJAX, introducing the first JS based DC technique for the web applications, utilizing the XHR object .This technique became popular and took the traditional web applications to a whole new era called Web2, which is the era of the RIAs. Later W3C acquired the control of the XHR object and released the first specification on 2006 . Since then the term AJAX has become another name

for the RIAs, where even some developers refer the RIAs as AJAX applications. AJAX can be seen as the beginning of the JS based RIA development approach, and it became a major breakthrough in the web development area  . After its introduction, developers were learning how to use AJAX to create desktop-like GUIs in the web applications such as Google Maps; and later they subsequently used AJAX even to create entire enterprise RIAs. Using the JS’s ability to manipulate the Document Object Model (DOM) in HTML documents, AJAX achieves and enhances the interoperability capability of the web applications . It should be noted that the AJAX itself is not a technology, it

is a technique; and the technology behind AJAX is the XHR object with its JS API. The AJAX is a data-pull technique, employing the traditional request-response model. Combining HTML and CSS with JS, AJAX has become a powerful tool in RIA development, providing the fundamental implementation of the DC.

 

•The client-side controller contains the event-handlers for the GUI

•The events are triggered at the GUIs of the Views 

•Views are in the client-side, thus the events are triggered at the client-side

•Therefore, placing the controller in the client-side can be seen as an optimal solution

•Some business-logic are not highly data centric, complex, or critical 

• Forms validations
• GUI elements manipulations 

•They can be implemented in client-side

•Client-side controller and model reduce the roundtrips to the server. 

•Thus, improve the performance and increase the scalability 

•Delta-communication further improves the performance, increases the scalability, and as a result provides higher user experience.  

SPDC/AJAXDC FLOW

 ajax() function 

  

Ajax

Traditionally webpages required reloading to update their content. For web-based email this meant that users had to manually reload their inbox to check and see if they had new mail. This had huge drawbacks: it was slow and it required user input. When the user reloaded their inbox, the server had to reconstruct the entire web page and resend all of the HTML, CSS, JavaScript, as well as the user's email. This was hugely inefficient. Ideally, the server should only have to send the user's new messages, not the entire page. By 2003, all the major browsers solved this issue by adopting the XMLHttpRequest (XHR) object, allowing browsers to communicate with the server without requiring a page reload.
The XMLHttpRequest object is part of a technology called Ajax (Asynchronous JavaScript and XML). Using Ajax, data could then be passed between the browser and the server, using the XMLHttpRequest API, without having to reload the web page. With the widespread adoption of the XMLHttpRequest object it quickly became possible to build web applications like Google Maps, and Gmail that used XMLHttpRequest to get new map tiles, or new email without having to reload the entire page.
Ajax requests are triggered by JavaScript code; your code sends a request to a URL, and when it receives a response, a callback function can be triggered to handle the response. Because the request is asynchronous, the rest of your code continues to execute while the request is being processed, so it's imperative that a callback be used to handle the response.
Unfortunately, different browsers implement the Ajax API differently. Typically this meant that developers would have to account for all the different browsers to ensure that Ajax would work universally. Fortunately, jQuery provides Ajax support that abstracts away painful browser differences. It offers both a full-featured $.ajax() method, and simple convenience methods such as $.get(), $.getScript(), $.getJSON(), $.post(), and $().load().
Most jQuery applications don't in fact use XML, despite the name "Ajax"; instead, they transport data as plain HTML or JSON (JavaScript Object Notation).
In general, Ajax does not work across domains. For instance, a webpage loaded from example1.com is unable to make an Ajax request to example2.com as it would violate the same origin policy. As a work around, JSONP (JSON with Padding) uses <script> tags to load files containing arbitrary JavaScript content and JSON, from another domain. More recently browsers have implemented a technology called Cross-Origin Resource Sharing (CORS), that allows Ajax requests to different domains