Tutorial 10 – Client-side development 2 - RiWAs

PROGRAMMING APPLICATIONS AND FRAMEWORKS                                              
Tutorial 10


Distinguish the term “Rich Internet Applications” (RIAs) from “Rich Web-based Applications” (RiWAs)

•Rich Web-based applications
   •Use advanced GUIs
   •Use Delta-Communication
   •Provide rich user experience
 •Most of the web-based applications nowadays are RiWAs

 The key features of RiWAs, which make them more advanced than the standard web-based applications

•Rich GUIs in RiWAs use Delta-Communication to communicate with the server components
•DC happens behind the GUI
  •Eliminates page refreshes

•DC can process asynchronously
  •Eliminates page freezing

•DC works faster
  •Eliminates the work-wait pattern

 Different technologies and techniques used to develop the client-side components of the RiWAs, explaining their use in dedicated environments.

• 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 is, discussing the advantages of using it

Simple-Pull-Delta-Communication (SPDC) can be seen as the simplest form of DC

“Simple Pull Delta-Communication” (SPDC). Since the. SPCD concept is abstract, it is TTs independent and can be developed for both browser-based and non-browser-based clients. We defined the SPDC technique as follows

•Used in AJAX

 •Single XHR request to the server 

•Client-side: Native JS support 

•Server-side: special technology is not needed

 Synchronous and asynchronous communication in the context of DC

 Synchronous vs. asynchronous mode The distinct feature of the rich communication model of the RIAs is generally considered as the asynchronous mode of it, and this model is generally called asynchronous communication, because of this ability. However, the asynchronous mode is a controversial aspect In asynchronous mode, the GUI of the web page does not get blocked once the request is sent, till the response is arrived, processed, and the results are displayed [28]; instead, the user can continue using the application/GUI. In this asynchronous mode, once the response is received, it is processed in the background, by a dedicated application components in the client-side [28]. The asynchronous communication model facilitates the user to experience the results of the communication, even without knowing the execution or the processing of the request. Basically, there is nothing synchronous or asynchronous in this communication; it’s only the way the features, which utilize this communication is developed. Through the experiments we noted that the user experience of the rich features, which utilize the rich communication model, can be offered in either synchronous (blocking) or asynchronous (non-blocking) mode; and it is determined upon the requirements. For example, in the case of performing the transaction, the user has to wait until the transaction is completed, before continuing to use some other features of the application; therefore it should be implemented in synchronous mode. In the case of sending a mail, the user can click on the send mail button and continue reading other mails, while the mail is being processed and sent in background; thus it can be implemented in asynchronous mode.

Different types of technologies and techniques available for DC

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.

The history and the evolution of the XHR and AJAX.

AJAX:
In the article that coined the term Ajax, Jesse James Garrett explained that the following technologies are incorporated: HTML (or XHTML) and CSS for presentation.
AJAX is a technique for creating fast and dynamic web pages. AJAX allows web pages to be updated asynchronously by exchanging small amounts of data with the server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page

XHR:
XMLHttpRequest (XHR) is an API in the form of an object whose methods transfer data between a web browser and a web server. The object is provided by the browser's JavaScript environment.
XMLHttpRequest (XHR) is a browser-level API that enables the client to script data transfers via JavaScript. ... However, the power of XHR is not only that it enabled asynchronous communication within the browser, but also that it made it simple.

The role of the DC-engine in RiWAs

TTs for the non-browser-based client-components of RiWAs The standard desktop application development TTs like JAVA or.Net and related libraries/frameworks can be utilized for non-browser-based client-components development. For DC development, these frameworks may contain their own tools or some third-party frameworks/libraries can be incorporated. The TTs discussed under the proprietary plugin based approach (in Section IV.1.a) also have the capability of developing non-browser-based client-components, which are executed on dedicated runtimes; for example, Flash/Flex [13] use the Flash player or Adobe AIR runtimes. They are usually augmented with rich tools for developing communication connectors to utilize the service of the Web. Nowadays, the mobile apps also communicate with server components thus, they can be seen as the client-components of RiWAs. Popular mobile development frameworks like Android and IOS encompass communication development tools into their packages. Additionally, even devices in IoT based systems can be exploited as client components of RiWAs. Therefore, related TTs like Arduino Programming Language [17] for Arduino devices, Python for Raspberry Pi devices [18], and related frameworks/libraries/protocols like MQTT [19] [20] can also, be listed under the non-browser-based client-component development TTs. B. TTs for the Server-Components of RiWAs The server-components of RiWAs are similar to Web-based applications [2]. Additionally, in server-side, they need a dedicated component(s) for handling DC. Fig. 2 illustrates the taxonomy for the server-component(s) development TTs of RiWAs. The “Web application” node, represents the standard server-side development TTs such as PHP, JAVA, ASP.Net, Python, etc. and related frameworks/Libraries like CodeIgniter for PHP [21], Struts for JAVA [22], etc. 

The Web services use dedicated TTs such as SOAP [23], REST [24], and frameworks/libraries like JAX-WS [25] and JAX-RS [26] for JAVA, Slim for PHP [27], etc. The behavior of the web services is different from the Web applications in the context of service exposure to other components via Application Program Interfaces (API). The Enterprise Service Bus (ESB) in Service Oriented Architecture (SOA) [28] or similar concepts can be used to extend the standalone RiWAs into multi-tire RiWAs using dedicated TTs. The concept of cloud computing [29] can also be related to these TTs, where the cloud-based systems provide a platform to deliver a service oriented functionalities. The concepts of Web services, SOA, and cloud computing incorporates wide and self-contained domains, which the deep discussions are intentionally avoided in this paper. In the given taxonomy for the server-component(s) of RiWAs, all the types of TTs are supposed to be contained with DC implementation tools. C. TTs for the Connector Elements of RiWAs Connector development TTs can be seen as the core of RiWAs development TTs. In addition to the connector of Web-based applications, the connectors in RiWAs incorporate DC, where both the client and server should contain components for handling DC. For the communication in RiWAs, a union of the communication development TTs of traditional Web-based systems and the DC development TTs is accepted.

 The role of the DC-Bus, indicating how a web-service can be effectively used to implement it

 Algorithms for the request and response processing of DC

The server is not required to transmit a delta-encoded response.  For
   example, the result might be larger than the current size of the
   resource.  The server might not be able to compute a delta for this
   type of resource (e.g., a compressed binary format); the server might
   not have sufficient CPU cycles for the delta computation; the server
   might not support any of the delta formats supported by the client;
   or, the network bandwidth might be high enough that the delay
   involved in computing the delta is not worth the delay avoided by
   sending a smaller response.

   However, if the server does want to compute a delta, and the set of
   encodings it supports has more than one encoding in common with the
   set offered by the client, which encoding should it use?  This is
   mostly at the option of the server, although the client can express
   preferences using "Quality Values" (or "qvalues") in the "A-IM"
   header.  The HTTP/1.1 specification [10] describes qvalues in more
   detail.  (Clients may prefer one delta encoding format over another
   that generates a smaller encoding, if the decoding costs for the
   first format are lower and the client is resource-constrained.)

   Server implementations have a number of possible approaches.  For
   example, if CPU cycles are plentiful and network bandwidth is scarce,
   the server might compute each of the possible encodings and then send
   the smallest result.  Or the server might use heuristics to choose an
   encoding format, based on things such as the content-type of the
   resource, the current size of the resource, and the expected amount
   of change between instances of the resource.

   Note that it might pay to cache the deltas internally to the server,
   if a resource is typically requested by several different delta-
   capable clients between modifications.  In this case, the cost of
   computing a delta may be amortized over many responses, and so the
   server might use a more expensive computation.

 variation of the jQuery ajax() function and related options 

Sometimes, we need more control over the Ajax calls we want to make. For example, we want to specify what should happen in case an Ajax call fails or we need to perform an Ajax request but its result is only needed if retrieved within a certain amount of time. In such situations, we can rely on another function provided by jQuery, called $.ajax(),

There are a lot of different options you can specify to bend $.ajax() to your need. In the list below you can find their names and their description sorted in alphabetic order:

• accepts: The content type sent in the request header that tells the server what kind of response it will accept in return
• async: Set these options to false to perform an asynchronous request
• beforeSend: A pre-request callback function that can be used to modify the jqXHRthe object before it is sent
• cache: Set these options to false to force requested pages not to be cached by the browser
• complete: A function to be called when the request finishes (after success and error callbacks are executed)
• contents: An object that determines how the library will parse the response
• contentType: The content type of the data sent to the server
• context: An object to use as the context (this) of all Ajax-related callbacks
• converters: An object containing dataType-to-dataType converters
• crossDomain: Set this property to true to force a cross-domain request (such as JSONP) on the same domain
• data: The data to send to the server when performing the Ajax request
• dataFilter: A function to be used to handle the raw response data of XMLHttpRequest
• dataType: The type of data expected back from the server
• error: A function to be called if the request fails
• global: Whether to trigger global Ajax event handlers for this request
• headers: An object of additional headers to send to the server
• ifModified: Set this option to true if you want to force the request to be successful only if the response has changed since the last request
• isLocal: Set this option to true if you want to force jQuery to recognize the current environment as “local”
• jsonp: A string to override the callback function name in a JSONP request
• jsonpCallback: Specifies the callback function name for a JSONP request
• mimeType: A string that specifies the mime type to override the XHR mime type
• password: A password to be used with XMLHttpRequest in response to an HTTP access authentication request
• processData : Set this option to false if you don’t want that the data passed into the data option (if not a string already) will be processed and transformed into a query string
• scriptCharset: Sets the charset attribute on the script tag used in the request but only applies when the “script” transport is used
• statusCode: An object of numeric HTTP codes and functions to be called when the response has the corresponding code
• success: A function to be called if the request succeeds
• timeout: A number that specifies a timeout (in milliseconds) for the request
• traditional: Set this to true if you wish to use the traditional style of param serialization
• type: The type of request to make, which can be either “POST” or “GET”
• url: A string containing the URL to which the request is sent
• username: A username to be used with XMLHttpRequest in response to an HTTP access authentication request
• xhr: A callback for creating the XMLHttpRequest object
• xhrFields: An object to set on the native XHR object

That was pretty long, isn’t it? Well, as developers you probably have stopped reading this list at the fifth or sixth element I guess, but that’s fine. The next section will be more exciting because we’ll put them $.ajax() function and some of these options into action.