There is a wide range of web-based applications, which use a rich communication model such as Rich Internet Applications, mobile apps, cloud-based systems, Internet of Things based systems, etc.; however, a proper term to address them all and a definition, which covers and explains the common characteristics of them are missing. A definition of a concept is important as the definition provides a precise common understanding of the focused artifacts, which helps in increasing the realization of these artifacts towards proper utilization of them. We propose the umbrella term Rich Web-based Application to address the aforementioned types of applications, and also propose a definition for it, aligning to the common architectural characteristics of these applications. In addition, we deliver a set of taxonomies to classify the techniques and technologies related to the development of Rich Web-based Applications, in the direction of improving the understanding of the proper utilization of them. In future, we expect to introduce an architectural style for these Rich Web-based Applications, based on the proposed definition.
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.
But RIAs incorporate additional technologies, such as real-time streaming, high-performance client-side virtual machines, and local caching mechanisms that reduce latency (wait times) and increase responsiveness. A number of commercial development tools (see below) permit this partial-page updating.
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.
DELTA-COMMUNICATION
TECHNOLOGIES
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
Polling is 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 is used to simulate data-push
• Long-lived XHR requests
•Client-side: Native JS support
•Server-side: Need a streaming server. Special technology is not needed, can be implemented with standard web technologies
•Reduce network traffic than polling (more scalable)
•Blank responses are eliminated
Server-Sent-Events (SSE) is used (only) for true data-push
•Similar to Comet, but no client requests
•Client-side: HTML5 provides native JS support
•Server-side: Need a streaming server. Special technology is not needed, can be implemented with standard web technologies
•Reduce network traffic than polling/Comet (more scalable)
•Blank responses and requests are totally eliminated
WebSocket (WS) is bi-directional
•Supports both data-pull and true data-push
•Client-side: HTML5 provides native JS support
Server-side: Need a WS server. Complex.
•Reduce network traffic than polling/Comet/SSE
(highly scalable, 10CK is addressed)
| Advantages | Disadvantages | |
|---|---|---|
| Asynchronous transmission |
|
|
| Synchronous transmission |
|
|
Delta Communication
Web applications have evolved into much complex Rich Internet Applications, providing rich features and enhanced user experience. Proper definitions, which deliver abstract realization of the fundamental concepts of the Rich Internet Application are still missing. Definitions provide proper understanding of the subject and help in increasing the realization of the characteristics of the same. This paper focuses on conceptually identifying the characteristics of the rich communication model of the Rich Internet Applications – commonly known as the “Asynchronous Communication” – suggesting a better term “Delta-Communication”, followed by a definition for it. Based on the definition, we propose a term and a definition for the abstract model of the simplest rich communication technique, which is exploited in AJAX. Additionally, based on the proposed definition for the rich communication model, the paper proposes a new term to replace the term AJAX to overcome the limitations expressed by the term AJAX. These terms and definitions specify and express the fundamental characteristics of the abstract concepts of the rich communication model of the Rich Internet Applications. Index Terms—AJAX, asynchronous, communication, delta, rich internet applications.
AJAX : Asynchronous JavaScript And XML
AJAX stands for Asynchronous JavaScript And XML. AJAX is not a new technology but it is a technique. It is a term that is firstly penned by James Garrett in 2005. Basically, It is a way of using many existing technologies like HTML, CSS, JavaScript, XML, Document Object Model, and main important part is XMLHttpRequest object. When all these technologies work together with AJAX technique, User Interface updates itself without reloading the whole web page. Basically, AJAX will communicate with the server, get data from the server, update UI on the basis of that data without reloading the whole web page.
History of AJAX
Before 2005, communication between client-side and server-side was harder to establish. Developers use hidden iframes to populate the server data to the client-side. But in 2005, James Garrett write an article named AJAX: a new approach to Web applications. The key technology is used in AJAX is XMLHttpRequest(XHR), firstly invented by Microsoft and then use by other browsers. XHR has capabilities to retrieve data from server-side and populate on client-side with the help of existing technologies. Before 2005, developers use different technologies for communication with server-side such as Java Applets or Flash movies.
Role of the DC-engine in RiWAs.
Delta-Communication can be seen as the power of Rich Internet Applications, and there are different Techniques and Technologies available for the development of Delta-Communication, which should be selected carefully into the Rich Internet Application development. Enough discussions are not available, which compare and contrast these Delta-Communication development Techniques and Technologies towards supporting decision making of selecting them. This paper provides an overview of the contemporary Techniques and Technologies available for the Delta-Communication development, contextually compares them aligning to some selected criteria, and finally discusses some facts to be considered when selecting them for the Rich Internet Application development. A literature survey on the Delta-Communication development Technologies and Techniques was conducted, which was followed by a series of experiments towards getting the empirical evidence for the comparison. During the contextual comparison, the Simple Pull Delta-Communication was identified as the least complex technique and the Websocket was noted as the highest complex technology.
Role of the DC-Bus
The DMCNET (Delta Motion Control Network) communication bus is a motion control communication protocol employing the high-speed bus developed by Delta; it employs different CRC code when engaging in two-way communications, has a transmission rate of 10Mbps in each channel, and supports a maximum communication distance of up to 30 m. Physical communication cables consist of CAT-5e STP Ethernet cable (24AWG/4Pairs).
The algorithms for the request and response processing of DC.
HTTP
Delta-Communication can be seen as the power of Rich Internet Applications, and there are different Techniques and Technologies available for the development of Delta-Communication, which should be selected carefully into the Rich Internet Application development. Enough discussions are not available, which compare and contrast these Delta-Communication development Techniques and Technologies towards supporting decision making of selecting them. This paper provides an overview of the contemporary Techniques and Technologies available for the Delta-Communication development, contextually compares them aligning to some selected criteria, and finally discusses some facts to be considered when selecting them for the Rich Internet Application development. A literature survey on the Delta-Communication development Technologies and Techniques was conducted, which was followed by a series of experiments towards getting the empirical evidence for the comparison. During the contextual comparison, the Simple Pull Delta-Communication was identified as the least complex technique and the Websocket was noted as the highest complex technology.
Role of the DC-Bus
The DMCNET (Delta Motion Control Network) communication bus is a motion control communication protocol employing the high-speed bus developed by Delta; it employs different CRC code when engaging in two-way communications, has a transmission rate of 10Mbps in each channel, and supports a maximum communication distance of up to 30 m. Physical communication cables consist of CAT-5e STP Ethernet cable (24AWG/4Pairs).
The algorithms for the request and response processing of DC.
HTTP
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This is the foundation for data communication for the World Wide Web (ie. internet) since 1990. HTTP is a generic and stateless protocol which can be used for other purposes as well using extension of its request methods, error codes and headers.
Basically, HTTP is an TCP/IP based communication protocol, which is used to deliver data (HTML files, image files, query results etc) on the World Wide Web. The default port is TCP 80, but other ports can be used. It provides a standardized way for computers to communicate with each other. HTTP specification specifies how clients request data will be constructed and sent to the serve, and how servers respond to these requests.
Read more:
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
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 domainsjQuery’s Ajax-Related Methods
While jQuery does offer many Ajax-related convenience methods, the core
$.ajax() method is at the heart of all of them, and understanding it is imperative. We'll review it first, and then touch briefly on the convenience methods.
It's often considered good practice to use the
$.ajax() method over the jQuery provided convenience methods. As you'll see, it offers features that the convenience methods do not, and its syntax allows for the ease of readability.
$.ajax()
$.ajax()
jQuery’s core
$.ajax() method is a powerful and straightforward way of creating Ajax requests. It takes a configuration object that contains all the instructions jQuery requires to complete the request. The $.ajax() method is particularly valuable because it offers the ability to specify both success and failure callbacks. Also, its ability to take a configuration object that can be defined separately makes it easier to write reusable code. For complete documentation of the configuration options, visit http://api.jquery.com/jQuery.ajax/.
// Using the core $.ajax() method
$.ajax({
// The URL for the request
url: "post.php",
// The data to send (will be converted to a query string)
data: {
id: 123
},
// Whether this is a POST or GET request
type: "GET",
// The type of data we expect back
dataType : "json",
})
// Code to run if the request succeeds (is done);
// The response is passed to the function
.done(function( json ) {
$( "<h1>" ).text( json.title ).appendTo( "body" );
$( "<div class=\"content\">").html( json.html ).appendTo( "body" );
})
// Code to run if the request fails; the raw request and
// status codes are passed to the function
.fail(function( xhr, status, errorThrown ) {
alert( "Sorry, there was a problem!" );
console.log( "Error: " + errorThrown );
console.log( "Status: " + status );
console.dir( xhr );
})
// Code to run regardless of success or failure;
.always(function( xhr, status ) {
alert( "The request is complete!" );
});
Note: Regarding the
dataType setting, if the server sends back data that is in a different format than you specify, your code may fail, and the reason will not always be clear, because the HTTP response code will not show an error. When working with Ajax requests, make sure your server is sending back the data type you're asking for, and verify that the Content-type header is accurate for the data type. For example, for JSON data, the Content-type header should be application/json.
$.ajax() Options
$.ajax() Options
There are many, many options for the
$.ajax() method, which is part of its power. For a complete list of options, visit http://api.jquery.com/jQuery.ajax/; here are several that you will use frequently:
async
Set to
false if the request should be sent synchronously. Defaults to true. Note that if you set this option to false, your request will block execution of other code until the response is received.
cache
Whether to use a cached response if available. Defaults to
true for all dataTypes except "script" and "jsonp". When set to false, the URL will simply have a cachebusting parameter appended to it.
done
A callback function to run if the request succeeds. The function receives the response data (converted to a JavaScript object if the
dataType was JSON), as well as the text status of the request and the raw request object.
fail
A callback function to run if the request results in an error. The function receives the raw request object and the text status of the request.
always
A callback function to run when the request is complete, regardless of success or failure. The function receives the raw request object and the text status of the request.
context
The scope in which the callback function(s) should run (i.e. what
this will mean inside the callback function(s)). By default, this inside the callback function(s) refers to the object originally passed to $.ajax().
data
The data to be sent to the server. This can either be an object or a query string, such as
foo=bar&baz=bim.
dataType
The type of data you expect back from the server. By default, jQuery will look at the MIME type of the response if no
dataTypeis specified.
jsonp
The callback name to send in a query string when making a JSONP request. Defaults to "callback".
timeout
The time in milliseconds to wait before considering the request a failure.
traditional
Set to
true to use the param serialization style in use prior to jQuery 1.4. For details, see http://api.jquery.com/jQuery.param/.
type
The type of the request, "POST" or "GET". Defaults to "GET". Other request types, such as "PUT" and "DELETE" can be used, but they may not be supported by all browsers.
url
The URL for the request.
The
url option is the only required property of the $.ajax() configuration object; all other properties are optional. This can also be passed as the first argument to $.ajax(), and the options object as the second argument.
Convenience Methods
If you don't need the extensive configurability of
$.ajax(), and you don't care about handling errors, the Ajax convenience functions provided by jQuery can be useful, terse ways to accomplish Ajax requests. These methods are just "wrappers" around the core $.ajax() method, and simply pre-set some of the options on the $.ajax() method.
The convenience methods provided by jQuery are:
$.get
Perform a GET request to the provided URL.
$.post
Perform a POST request to the provided URL.
$.getScript
Add a script to the page.
$.getJSON
Perform a GET request, and expect JSON to be returned.
In each case, the methods take the following arguments, in order:
url
The URL for the request. Required.
data
The data to be sent to the server. Optional. This can either be an object or a query string, such as
foo=bar&baz=bim.
Note: This option is not valid for
$.getScript.
success callback
A callback function to run if the request succeeds. Optional. The function receives the response data (converted to a JavaScript object if the data type was JSON), as well as the text status of the request and the raw request object.
data type
The type of data you expect back from the server. Optional.
Note: This option is only applicable for methods that don't already specify the data type in their name.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
|
$.fn.load
$.fn.load
The
.load() method is unique among jQuery’s Ajax methods in that it is called on a selection. The .load() method fetches HTML from a URL, and uses the returned HTML to populate the selected element(s). In addition to providing a URL to the method, you can optionally provide a selector; jQuery will fetch only the matching content from the returned HTML.
1
2
|
|
1
2
3
4
|
|
Ajax Events
Often, you'll want to perform an operation whenever an Ajax request starts or stops, such as showing or hiding a loading indicator. Rather than defining this behavior inside every Ajax request, you can bind Ajax events to elements just like you'd bind other events. For a complete list of Ajax events, visit Ajax Events documentation on docs.jquery.com.
1
2
3
4
5
6
7
8
|
|
References:
