Web-based applications have been used widely and are quite popular - from booking tickets to checking e-mail, they are all Web-based. As the popularity of and demand for Web-based applications has grown, users expectations have also grown.
Users want their Web interfaces to be robust and they want instantaneous reactions. The present Web-based applications are typically client/server-based applications with a thin JSP/HTML client. The user has to wait for the response from the server since all the processing is done on the server side. The biggest drawback in Web-based applications is that the response time and waiting period is long. After sending the request, the client has to wait for the processing and subsequent response from the server. This major drawback can be solved by using Rich Internet Applications.
What Are Rich Internet Applications?
There are two kinds of user interface applications: desktop and Web-based. The desktop application has good user interaction experience and a faster response. The Web-based application has low-cost deployment, simple architecture, high availability, low maintenance, and platform independence. Rich Internet Applications (RIA) have all the benefits of both desktop and Web-based applications.
RIAs provide a faster response by taking advantage of a client's CPU. This richer functionality may include anything that can be implemented in the system that's being used on the client side including using a slider to change data, calculations that happen on the client, drag-and-drop features, and those things that don't need to be sent back to the server.
There are also performance benefits; for example, the resources that both the client and server handle are almost equal, thus freeing server resources and allowing the same hardware to handle more sessions concurrently. The traffic within the network decreases since the client knows exactly what it needs to send to the server side. Thus, it takes less time to transfer any single request or response for two reasons: they are smaller and the overall network load is lower.
Overview of AJAX
Asynchronous JavaScript And XML (AJAX) is a Web-development technique for creating interactive Web applications and is one way to develop Rich Internet Applications. AJAX programming techniques have recently created a lot of hype with their robustness and the way they create browser-based applications that are more interactive and fast. AJAX can send and receive data to and from the server without requiring the browser to refresh or reload.
AJAX isn't a technology; it's a mixture of several technologies.
Constituents of AJAX
AJAX incorporates:
- The standard-based presentation that is done using XHTML and CSS. Standard-based presentation helps to increase the speed of development, simplify maintenance, open up bandwidth cost, and improve the user experience.
- Dynamic display and interacting using Document Object Model (DOM). The DOM scripting method helps to create documents on the fly. DOM also helps to modify the documents, for example, moving parts of the document around.
- Data interchange and manipulation using XML and XSLT. XML - Extensible Markup Language - is similar to HTML, but differs in the way that the user can create his or her own tag. XML was designed to describe data. XSLT - Extensible Stylesheet Language - is based on XML and it transforms XML documents.
- Asynchronous data retrieval using XMLHttpRequest. XMLHttpRequest Object enables JavaScript to make HTTP requests to a remote server without reloading the page. In essence, HTTP requests can be made and responses received, completely in the background and without the user experiencing any visual interruptions.
- Java Script binding everything together. Java Script is a client-level scripting language that helps validate the user interaction and many more functionalities.
Workings of a Typical Web Application
A typical Web application model works as shown in
Figure 1. Almost every user action in the interface triggers an HTTP request back to a Web server. The server does some processing - retrieving data, talking to various legacy systems, and then returning an HTML page to the client. This approach makes a lot of technical sense, but it doesn't make for a great user experience. The user has to wait while the server is doing its thing, and, at every step in a task, the user waits some more. Through the browser, the user accesses a Web application and his request gets passed as an HTTP request to the server-side systems. The server-side systems have a Web server and a datastore, back-end processing, and legacy systems. The response from the Web server is in the form of HTML data that's passed on to the user interface.
How AJAX Works
Using AJAX, the drawbacks of a normal Web application are eliminated. AJAX works in a way that's similar to a Web application except there's an AJAX engine between the user and the server. The browser loads the AJAX engine first, when we run the application. The AJAX engine is typically written using JavaScript and is responsible for both the user interface through which the user interacts and also a communication layer through which it contacts the server. The interaction with the application happens asynchronously because of the presence of the AJAX engine, so the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something. In this way AJAX helps reduce the response time from the server.
Each and every user action (which is nothing but an HTTP request) takes the form of a JavaScript call to the AJAX engine. Any response to a user action that doesn't require going to the server is handled by the AJAX engine. Just like a simple data validation part, editing data in memory and some navigation is handled by the engine.
This is how an AJAX-based application works. The user accesses a Web application through the browser and his request gets passed to the AJAX engine. An AJAX engine written using JavaScript loads. From this point onward the user interacts with the engine, not with the server. The HTTP requests from the AJAX engine are passed on to the server-side systems, which have a Web server and a datastore. The response from the Web server is in the form of XML, which is passed onto the AJAX engine. The AJAX engine operates asynchronously and is independent of any server communications, so that a user can interact with the application, even while requests and responses are being sent back and forth between the engine and the server (see Figure 2).
What SOA and Web Services Can Add to AJAX
AJAX has given a new lease on life to the presentation layer just as Web services have given a new lease on life to the application layer. AJAX is a UI model. It's important in the sense that it allows people to use their browsers to directly interact with Web services; it's the best way for people to get at Web services and SOA assets. Currently, Web services perform well on a machine-to-machine level, but there have been problems building usable interfaces to interact with services. AJAX will be the answer to that problem.
AJAX communicates through XMLHttpRequest. XMLHttpRequest helps communications between HTTP servers through XML. From the client side of the application, instantiate XMLHttpRequest and, through its methods, issue an HTTP command such as GET or PUT to the Web server. Through the XMLHttpRequest object you can now easily implement a Web service. Client code invokes them via HTTP, where they accept and return XML code. On both sides of the connection the XML code is managed and traversed.
AJAX is a user interface model and Web services is a back-end functional layer mechanism. AJAX is very helpful in handling multiple Web services where there is a need for updating part of the user interface.
The following are the logical steps for a Web service invocation using AJAX (see Figure 3):
- Acquire a copy of the WSDL by sending XMLHttpRequest to the Web service. This sends an HTTP request the same way a browser does when we enter the URL in the address bar except here it's done programmatically.
- When we get the WSDL, it's cached and then parsed using XPath queries of different browsers and a SOAP request is generated and sent to the Web service using XMLHttpRequest. Generally, the SOAP request call should always be asynchronous so that the user can keep on interacting with the user interface while a response is received from the Web service
- Once the SOAP response is received, it's parsed using the browser APIs (such as the "document.getElementsByTagName" method) for obtaining the Web service result, which in turn is displayed as output to the user.
References
Subscribe to AJAX & RIA Journal Email News Alerts
Subscribe via RSS
