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
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
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
$.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 returnasync: Set these options tofalseto perform an asynchronous requestbeforeSend: A pre-request callback function that can be used to modify thejqXHRtheobject before it is sentcache: Set these options tofalseto force requested pages not to be cached by the browsercomplete: A function to be called when the request finishes (aftersuccessanderrorcallbacks are executed)contents: An object that determines how the library will parse the responsecontentType: The content type of the data sent to the servercontext: An object to use as the context (this) of all Ajax-related callbacksconverters: An object containing dataType-to-dataType converterscrossDomain: Set this property totrueto force a cross-domain request (such as JSONP) on the same domaindata: The data to send to the server when performing the Ajax requestdataFilter: A function to be used to handle the raw response data of XMLHttpRequestdataType: The type of data expected back from the servererror: A function to be called if the request failsglobal: Whether to trigger global Ajax event handlers for this requestheaders: An object of additional headers to send to the serverifModified: Set this option totrueif you want to force the request to be successful only if the response has changed since the last requestisLocal: Set this option totrueif you want to force jQuery to recognize the current environment as “local”jsonp: A string to override the callback function name in a JSONP requestjsonpCallback: Specifies the callback function name for a JSONP requestmimeType: A string that specifies the mime type to override the XHR mime typepassword: A password to be used with XMLHttpRequest in response to an HTTP access authentication requestprocessData: Set this option tofalseif you don’t want that the data passed into thedataoption (if not a string already) will be processed and transformed into a query stringscriptCharset: Sets the charset attribute on the script tag used in the request but only applies when the “script” transport is usedstatusCode: An object of numeric HTTP codes and functions to be called when the response has the corresponding codesuccess: A function to be called if the request succeedstimeout: A number that specifies a timeout (in milliseconds) for the requesttraditional: Set this totrueif you wish to use the traditional style of param serializationtype: The type of request to make, which can be either “POST” or “GET”url: A string containing the URL to which the request is sentusername: A username to be used with XMLHttpRequest in response to an HTTP access authentication requestxhr: A callback for creating the XMLHttpRequest objectxhrFields: 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.
