Für neue Autoren:
kostenlos, einfach und schnell
Für bereits registrierte Autoren
139 Seiten, Note: 1.0
2. The Trend to Rich Internet Applications
2.1. What is a Rich Internet Application?
2.2. Architectural Overview of RIAs
2.3. Advantages and Disadvantages of RIAs
3. Technologies for Rich Internet Applications
3.5. AIR (Adobe Integrated Runtime)
4.1. Technical Overview
4.2. Pure Hype or real Business Value?
4.2.1. Creating Business Value
4.2.2. Time for Adoption
4.3. Challenges of Ajax Adoption
4.4. Types of Ajax Applications
4.5. Levels of Ajax Adoption
5. Ajax Frameworks
5.1. Requirements for Ajax Frameworks
5.2. Ajax Frameworks Overview
5.2.1. Ajax Toolkit Framework
5.2.2. TIBCO General Interface
5.2.3. eXtensible Ajax Platform
5.2.4. ASP.NET Ajax
5.2.5. Backbase Ajax 360
5.2.6. Direct Web Remoting
5.2.8. Google Web Toolkit
5.2.14. Yahoo! User Interface Library
5.3. Popularity of Ajax Frameworks
5.4. Categorization of Frameworks
5.4.1. Classification according to the Level of Adoption
6. Evaluation Procedure and Sample Application
6.1. Description of the Sample Application
6.1.1. Detailed Description of the Tracking System
6.1.2. Application specific Requirements for the Ajax Frameworks
6.2. Evaluation Procedure
6.2.1. Selection Criteria for the Ajax Frameworks
6.2.2. Selected Frameworks
6.2.3. Evaluation Criteria
6.2.4. Detailed Test Specification
7. Framework Evaluation
7.1. Adobe Spry Evaluation
7.1.1. Implementation of the Sample Application
7.1.2. General Aspects of the Framework
7.1.3. Developing Company and Community
7.1.4. History, Maturity, Outlook of the Framework
7.1.5. Costs of the Framework and Terms of License
7.1.6. Available Documentation and Support
7.1.7. Productivity of Development
7.1.8. Generated Traffic
7.1.9. Client-side Workload
7.1.10. Load and Response Times of the Application
7.1.11. Maintainability of the Application
7.2. Google Web Toolkit Evaluation
7.2.1. Implementation of the Sample Application . .
7.2.2. General Aspects of the Framework
7.2.3. Developing Company and Community
7.2.4. History, Maturity, Outlook of the Framework .
7.2.5. Costs of the Framework and Terms of License .
7.2.6. Available Documentation and Support
7.2.7. Productivity of Development
7.2.8. Generated Traffic
7.2.9. Client-side Workload
7.2.10. Load and Response Times of the Application .
7.2.11. Maintainability of the Application
7.3. ASP.NET Ajax Evaluation
7.3.1. Implementation of the Sample Application . .
7.3.2. General Aspects of the Framework
7.3.3. Developing Company and Community
7.3.4. History, Maturity, Outlook of the Framework .
7.3.5. Costs of the Framework and Terms of License .
7.3.6. Available Documentation and Support
7.3.7. Productivity of Development
7.3.8. Generated Traffic
7.3.9. Client-side Workload
7.3.10. Load and Response Times of the Application .
7.3.11. Maintainability of the Application
7.4. Overall Comparison
7.4.1. Analysis of the Features and general Aspects .
7.4.2. Developing Company and Community Analysis .
7.4.3. History, Maturity and Outlook Analysis
7.4.4. Cost and License Analysis
7.4.5. Analysis of the available Documentation
7.4.6. Analysis of the Productivity of Development .
7.4.7. Traffic Analysis
7.4.8. Client-side Workload Analysis
7.4.9. Load and Response Time Analysis
7.4.10. Analysis of Maintainability Aspects
8. Further Issues and Outlook
8.2. Reverse Ajax
8.3. Offline Ajax
8.4. Mobile Ajax
A. Detailed PCTS Specification
A.1. Use Case Description
A.2. Design Overview
B. Detailed Evaluation Results
The rapidly growing popularity of Ajax has led to the publication of numerous frameworks in the last years. Not only big companies but also small development teams have developed their own Ajax frameworks or libraries. Consequently, finding the best framework for a specific project can be difficult and time-consuming. This thesis compares three of the most popular Ajax frameworks in order to facilitate the technology selection process
The evaluation was carried out by implementing a tracking system for public transportation with particular focus on the applicability, productivity and technical limitations of each framework and Ajax in general. In addition, this thesis presents a general approach for the evaluation of arbitrary Ajax frameworks and points out particular issues that should be given special consideration when applying Ajax initially. The thesis concludes with a brief analysis of trends that may be relevant to the future development of Ajax
When it comes to web application development there has also been a lot of progress in the field of Ajax: Ajax frameworks of all kinds massively gained popularity and flooded the development community. From the biggest companies through to small development teams, almost everyone has published his own Ajax framework or library in the last two years. In the meantime there are far more than 150 different frameworks for various programming languages and diverse aims. Because of this uncontrolled growth of frameworks it is quite difficult to say which of those is most suitable for a specific project.
There are two key questions that have to be considered in case of Ajax or Rich Internet Ap- plications1 (RIAs) in general: How can Ajax significantly increase the business value of an application and how can it be applied productively? This thesis mainly focuses on the latter question by evaluating three Ajax frameworks of large companies with a strong background by means of an example application with respect to commercial applicability, productivity, perfor- mance as well as enhancement and adaptation possibilities. Furthermore this work discusses the technical limitations and problems of Ajax and provides an outlook on future developments in this area.
As example application for the evaluation a web-based tracking system for public transporta- tion is implemented. Each single vehicle is visualized on a street map according to its current position. By the implementation of this application with each of the three chosen Ajax frame- works their applicability, productivity and performance is illustrated as well as their weaknesses and limitations.
In order to provide a short overview about this topic, Section 2 defines the term Rich Internet Application, compares it to conventional web applications and discusses its advantages and weaknesses. In Section 3 a short overview about the different RIA technologies is given and the basic differences to Ajax are highlighted. Section 4 describes the technical aspects of Ajax, gives a critical view on the hype of Ajax and reveals the challenges developers have to face when introducing Ajax. Furthermore some categories of typical Ajax applications as well as different levels of Ajax adoption are defined in this part.
Section 5 defines the general requirements for an Ajax framework, gives an overview over a short selection of diverging frameworks and classifies them in two different ways. In Section 6 the sample application is described in detail and the evaluation procedure as well as the criteria upon which the evaluation is based are specified. Section 7 represents the core of this paper by presenting each of the three frameworks explicitly including the results of the evaluation. At the end of this part these results are compared to each other in order to highlight the differ- ences between these frameworks. Finally, in Section 8 an outlook on current trends and future developments is given.
Rich Internet Applications (RIAs) are currently becoming more and more popular and there is no indication that this trend will stop in the near future. Since Ajax is a technique for creating RIAs it is part of this trend. Therefore, this chapter takes a closer look at RIAs in general by describing what they are and how they relate to traditional web applications. Furthermore it outlines the advantages and disadvantages of this kind of web application.
A Rich Internet Application is something between a web application and a desktop application and combines the benefits of both approaches. Desktop applications are highly responsive and interactive and certainly have advantages when it comes to graphics (especially vector graphics) as well as audio and video applications. There is no need to load data from a remote machine as the application is installed locally and therefore it is reacting immediately to the user’s actions. The drawbacks of desktop applications are obviously that they depend on the underlying platform and distribution and maintenance costs are much higher.
A traditional web application based on HTML has its strengths where a desktop application has its weaknesses: They are highly available through the web and are by far easier maintain- able as they do not require any updates or patches to be shipped. Furthermore web applications are platform independent since they are based on standards like HTML and are running within a browser. However, they also have some disadvantages: They are by far not as responsive and interactive and not very well-suited for visualizing or manipulating complex data or charts. A quite disturbing mannerism of web applications is that for each task a new page has to be loaded [Deb06].
Rich Internet Applications attempt to combine the advantages of both types of applications and to eliminate their disadvantages. They combine ‘the reach of Web applications with the richness of desktop applications’ [Bac07]. The main benefits of RIAs are described in the following list:
- Rich Internet Applications provide a rich user interface which is not downloaded re- peatedly as in traditional web applications. This user interface provides interactive UI controls in order to support increased interactivity (e.g. sortable lists, drag & drop, tree views, etc.) and make the application more feel like a desktop application.
- The application reacts immediately to user actions without reloading the entire applica- tion. Contrary to traditional web applications some actions can be entirely handled by the client without asking the server. However, if a request has to be send to the server it is done asynchronously for not breaking the user’s workflow.
- Rich Internet Applications reduce the bandwith since the application is only downloaded once and updated according to the user’s requests.
- RIAs have almost the same reach as traditional web applications as they are accessible via the web. Only specific requirements, like plug-ins or certain browser versions, may restrict the use of the application.
- Their maintenance costs are as low as those of conventional web applications since the application is not installed locally and therefore no updates have to be distributed.
Table 2.1 summarizes this comparison between desktop, web and Rich Internet Applications. It shows where each type of application has its strenghts and weaknesses and shows how RIAs try to combine the benefits of the others.
illustration not visible in this excerpt
Table 2.1.: Different characteristics of desktop, web and Rich Internet Applications [Deb06]
Another drawback is that the history function every browser offers does not work properly with Rich Internet Applications since they usually represent a single page. If the back button is pushed by the user the browser displays the page that has been requested before starting the application which is often not intended by the user. Since RIAs change their state without changing the page, bookmarking the current state of an application cannot be done by simply bookmarking the page’s URL. Some RIA technologies even offer ways to bypass this problem but currently these features are rarely used.
Since Rich Internet Applications need, contrary to traditional web applications, some additional client side logic, the initial download of the application may last longer. It depends on the application how much has to be downloaded at the startup and which parts are downloaded on demand. These decicions depend most notable on the type of application.1
Another characteristic of RIAs is that they require more resources on the client since their main part is running there. The positive effect of this shift is that the server is relieved of these tasks which are now performed on the client. Old devices that do not have much computational power may have problems when executing Rich Internet Applications in combination with other applications.
Rich Internet Application also bring a new, though desirable, user experience. Some users might be irritated by the new way of interaction with this kind of web application, e.g. the browser’s back button. Due to the rich effects that are possible with these technologies, another risk might stem from the fact that the application gets overloaded and possibly discourages the user to use it. Therefore, a very important issue is to create user friendly applications in order to minimize these risks and avoid user dissatisfaction.
Since (most of) these applications are running in the browser’s sandbox they usually do not have access to system resources.2 For example it is not allowed for an application running in the browser to access the file system without special privileges the user has to grant. This may lead to the situation that the user is afraid of granting these privileges but the application does not work properly without them.
A big advantage of conventional web sites is that they can be easily found using search engines. To achieve this these sites have to be indexed by the search engine. Since Rich Internet Applications do not consist of several HTML pages their content might be invisible to search engines. A short summary of all advantages and disadvantages is also provided in Section 2.3.
The architecture of a Rich Internet Application is quite different from a traditional, server- based web application. A conventional web application processes everything on the server by receiving the user’s request with the controller, updating the model according to the request and combining the view with the updated model. This conglomerate is then sent to the client’s web browser where it is interpreted and displayed. Each action of the user results in an HTTP request to the server and therefore interrupts the workflow of the user. Considering that the amount of data contained in an HTML page only accounts for approximately 20% of its total size it is easy to see that a lot of extra traffic is generated by HTML tags. [Ste07a]
Figure 2.1 shows an MVC (Model-View-Controller) architecture of a server-based web ap- plication. The user interacts with the controller on the client (i.e. the application that is dis- played in the browser). Each interaction results in an HTTP request that is send to the con- troller on the server which updates the model (if needed) and delegates the request to the view. The view constructs an HTML response using the (updated model) and sends it back to the client where it replaces the previously displayed page. Thus every action of the user entails a replacement of the whole page. As the user does not interact directly with the web server but via a browser the client has its own model and controller elements that mediate the interaction between user and server. The client’s view is responsible for rendering the received page to the screen whereas the controller reacts to user inputs and sends requests to the server. If the user performs an action that does not result in a page reload (e.g. filling in a form or scrolling the page) the client’s controller directly updates the view. All other interactions require a round trip to the server.
illustration not visible in this excerpt
Figure 2.1.: MVC architecture of server-based web applications
Avoiding the permanent round trips to the server and the consequent disruption of the user’s workflow is a main goal of Rich Internet Applications. Therefore, RIAs have a different archi- tecture than conventinal web applications as we can see in Figure 2.2. A big difference to the diagram above is that there is model element on the client side in addition to the server side model. This model facilitates that an interaction of the user does not automatically result in a request to the server. For the most part an action results in a change of the client’s model and therefore the application responds much faster and is much more interactive. This allows for example client side validation of user input or manipulating tables (e.g. sorting, deleting items, etc.) without server interaction. The client side controller only sends a request to the server if neccessary and, of course, in an asynchronous manner for not disturbing the user’s workflow. Another difference is that there is only a single view element, namely on the client side. If the server side controller receives a request from the client it always effects a change of the model as there is no more view element on the server. Changes to the view happen exclusively in the client’s browser. Another consequence of this change is that the server does not respond to the request by sending HTML. The server only returns the updated model as XML, JSON or something else. This data is then used to update the view on the client.
illustration not visible in this excerpt
Figure 2.2.: MVC architecture of Rich Internet Applications
To summarize both the advantages and disadvantages of Rich Internet Applications in general this section provides an overview of their pros and cons. These characteristics affect all RIA technologies but each of them has of course its individual qualities. The following list describes the advantages that arise with the use of Rich Internet Applications.
- Improved user experience. Rich Internet Applications improve the user’s experience significantly since they reduce the waiting times considerably. Some actions do not re- quire a communication with the server and hence can be performed immediately on the client. And those actions that need an interaction with the server do not block the whole application while the data is loaded. Besides, the user interface is only created once and updated with the latest data (compared to traditional web applications which are rendered every time a request is sent to the server).
- Increased interactivity. Since an essential part of the application logic is executed on the client the application can immediately react to the user’s actions. In this regard a RIA resembles more a desktop application than a web application.
- Reduced traffic. Due to the fact that the data that is required by the application is transferred without any markup, the traffic of a RIA is significantly lower compared to conventional web applications. This and the fact that the data is loaded asynchronously leads to much less idle time.
- No installation. A very important criterion for the rapid diffusion of RIAs is that they do not have to be installed on the client. They are simply downloaded and run in the previously (and only once) installed runtime environment (i.e. the Flash Player, the Java Runtime Environment (JRE) or the browser’s scripting engine) they require.
Besides all this advantages there are also some drawbacks. They have to be considered carefully to ensure that the benefits outweigh the disadvantages. The following list describes the most relevant drawbacks regarding Rich Internet Applications.
- Longer loading times. Loading a RIA initially in the browser usually results in more traffic compared to HTML based web applications. This is caused by the application logic and the more complex user interface elements that have to be transferred to the client when the application is loaded. But since these parts of the application are only downloaded once the overall traffic and loading times are much less compared to traditional web applications.
- Special runtime environments required. The application logic that runs on the client requires a special runtime environment where it is executed. This can be a Flash Player, the Java Runtime Environment (JRE) or the scripting engine of a browser.3 If the required runtime environment is not available the application cannot be executed.
- More client-side resources needed. Due to the fact that more application logic resides on the client and downloaded data is processed by these parts of the application, more resources are needed compared to displaying simple HTML pages. The development of RIAs should always respect this fact in order to minimize this disadvantage.
- Accessibility problems. Accessiblity of traditional web applications has already come to an adequate level during the last years. In case of Rich Internet Applications making an application widely accessible is a bit more difficult. Especially governmental web sites are often obligated to conform to special guidelines.
- Content invisible to search engines. The content that is provided by RIAs is usually not accessible by unique URLs and simple HTML, which is the basis for search engine indexing, and therefore their content cannot be crawled and indexed as easily as that of conventional web applications. As search engine optimization is an important issue for every web application appropriate measures to mitigate the effects of this drawback have to be taken. Since RIAs are becoming more and more popular it is also the responsibility of the search engine providers to adjust their search strategies in order to take this trend into account.
- History confusion. Another thing that often leads to confusion of the user is the browser’s history mechanism. A Rich Internet Application is usually located on a sin- gle web page and does not create history events on standard actions. A click on the back button leads the user to the page that was displayed before the application has been loaded, discards the state of the application and confuses the user. Most RIA technolo- gies provide convenient solutions for this issue but many developers do not implement them.
The ultimate challenge when developing Rich Internet Applications is to exploit the advantages and to minimize the disadvantages. For most of them solutions and workarounds are available but they are certainly associated with some effort. Therefore, the secret of success is to find out which measures are worth its costs.
There are a handful of technologies available for building Rich Internet Applications (RIAs). Some of them have been on the market for several years and some are quite new or expected to be released in the near future. Like in many other domains there is always the question which approach is the best. Each technology has its supporters and its opposers since each of them has its pros and cons. This chapter presents the most popular and relevant RIA technologies and tries to give some advice when it comes to deciding which of them is to be chosen.
Silverlight, which was formerly named WPF/E (Windows Presentation Foundation/Every- where), is a light-weight version of Microsoft’s WPF (Windows Presentation Foundation). According to the official website, ‘Silverlight is a cross-browser, cross-platform plug-in for delivering the next generation of Microsoft .NET-based media experiences and rich interactive applications for the Web’ [Mic07b]. XAML-based Silverlight allows viewing rich applications including videos and animations in the browser and is independent of any media player.
The Silverlight browser plugin supports every version of Internet Explorer, Firefox and Safari. Support for Linux platforms is developed by the Moonlight project.1 With Silverlight Microsoft tries to compete with Adobe’s Flash technology, which is installed in more than 98% of all web browsers. It is hard to say how long it will take until Silverlight has a similar diffusion and acceptance like the current market leader of this segment.
The possibility of running Java programs, so-called Applets, in the browser offers a lot of advantages compared to traditional web applications. As Java programs are platform independent they run on every operating system as long as the user has installed the appropriate (platform specific) Java Virtual Machine (JVM). The Internet Explorer comes with an integrated JVM, users of other browser have to install it themselves. Despite the platform independence the JVM behaves slightly different on each platform.
illustration not visible in this excerpt
Figure 3.1.: Java-based RIA architecture [Deb06]
Figure 3.1 shows the typical architecture of a Java-based RIA. The applet runs in the Java Runtime within the browser and communicates through arbitrary protocols with the server. Since this communication is not limited to HTTP requests Java applets are not limited to the traditional request-response model of web applications.
For security reasons all applets run in a restricted environment called sandbox. This sandbox restricts for example the access to the local file system which can only be bypassed if the applet is signed with a trusted certificate. Applets can use the entire J2SE API and are therefore espescially suited for more complex applications that would meet the technical limitations of HTML-based applications. There are also frameworks, like the Asperon AppProjector2, which facilitate the development of applets.
As applets are embedded in an HTML page they can be easily distributed via the web. The relatively long loading time of the JVM and the time for downloading and initializing the applet seem to be a drawback of this technology.
In the end of the 1990s applets were also a reason for the fast diffusion of the Java program- ming language. In March 2007 the JVM had a penetration of approximately 88% [Ado07a], which is 10 percentage points lower than the penetration of the Flash Player.
According to the project’s website JavaFX is ‘a highly productive scripting language for con- tent developers to create rich media and interactive content for deployment on Java environ- ments’ [Sun07]. JavaFX script is a declarative language that allows defining the arrangement of grafical elements like images, layout elements or form fields. It enables the developer to easily create Rich Internet Applications for various devices. JavaFX uses the swing UI library and all Java concepts including the Java security model. JavaFX is not similar to Java but works closely together with it. Along with JavaFX script comes JavaFX mobile, a software environ- ment for mobile devices which uses this new script language. This new open source platform follows the principle of ”write once, run anywhere” and addresses developers of rich appli- cations for mobile devices, set-top boxes, desktops and even blu-ray discs. There are plugins available for Netbeans and Eclipse that ease the development of JavaFX applications. JavaFX is released under the GNU General Public License (GPL).
One of the probably most popular technologies for RIAs is Flash. It was originally developed by FutureWave and released by Macromedia in 1996 [Wal02]. Macromedia was taken over by Adobe in 2005. Flash is a proprietary software for developing multimedia applications that are displayed with a Flash Player. Using a Flash Player plugin for the web browser, websites can be combined with Flash animations, or entire websites can be created.
Maintaining several versions of a website because of different browsers can be very hard. As the Flash Player is backwards compatible maintenance is much easier. Another often presented argument is the download size of Flash files compared to Ajax applications. This is mainly due to the fact that greater animations, sounds or videos can be used in Flash applications. Another drawback seems to be the availability of Flash developers. There are plenty of web developers out there but only a few are able to develop rich Flash applications. Concerning accessibility for people with disabilities Flash has also its weaknesses. Since version Flash MX 2004 there are posibilities for accessing Flash sites with screen readers but they are barely used. Flex is an application server that compiles applications built with the ‘Multimedia eXtensible Markup Language’ (MXML) and ActionScript to Flash applications at runtime. Flex comes with a library of pre-defined Flash elements which can be used to build up Flash applications. This library includes building blocks for sortable tables, drag & drop, charts, animations (e.g. zooming or fading), web services, remote objects, etc.
illustration not visible in this excerpt
Figure 3.2.: Flash-based RIA architecture [Deb06]
Figure 3.2 shows the architecture of a Flash-based RIA. The Flash part runs in the Flash Player within the browser. On the server the Flash content is compiled from MXML (Flex) or LZK (OpenLazlo) and sent to the client.
The big difference between Flash and a traditional web application is that the whole Flash application is downloaded to the client and therefore the interaction is much faster. As from version 3 Flex will be released open source under the Mozilla Public License (MPL). A cheaper alternative to Flex is OpenLaszlo (see Section 3.4).
AIR (Adobe Integrated Runtime, formerly known as Apollo) is a cross-plattform runtime envi- ronment for Rich Internet Applications. As we have seen so far all technologies that support the creation of Rich Internet Applications somehow extend the browser (or use some extensions) in order to provide a richer experience for the user. AIR goes a step further and combines Flash, HTML and usesful desktop extensions (e.g. for file system access) in its runtime and is there- fore completely independend from a browser. AIR applications run directly on the desktop and so they feel much more like desktop applications than other RIAs. A big advantage of the run- time is the integrated local database which allows storing data locally and using the application even when working offline.
Adobe AIR (the runtime as well as the SDK) is currently available as a beta version for Windows and Macintosh platforms. A final version is planned for spring 2008. Support for Linux and other languages are planned for future releases.
As its name implies the XML User Interface Language (XUL) is an XML-based language for defining rich user interfaces. It has been developed in association with the Mozilla web browser since XUL is used for describing the browser’s UI. According to Peter Bojanic [Boj07] the main features of XUL are:
- Easy user interface declaration. XUL allows the easy definition and usage of UI arti- facts like buttons, windows, etc. which are essential for building Rich Internet Applica- tions.
- Separation of concerns. One of the basic characteristics of XUL is the separation of presentation, application logic and localisation. This facilitates the detached development of user interface and application logic, which is quite important since different developers are involved in these interdependent processes, as well as much easier maintenance of these applications.
As XUL is rendered by the Gecko engine it can be used for Rich Internet Applications within Gecko-based web browser. An example of a XUL-based RIA is the Mozilla Amazon Browser5, which incorporates services provided by Amazon (e.g. searching for books, displaying details of a book, etc.) into a more responsive desktop-like application. However, there is also a serious drawback: XUL is a cross-platform but not a cross-browser language since the Gecko layout engine, which is used in all Mozilla-based applications, is currently its only full implemen- tation. Therefore a XUL-based web application can only be accessed via Mozilla-based web browsers, which account for less than a third of all used browsers [W3S07]. It is not very likely that XUL implementations will find their way into other browsers since Microsoft is focussing on its own markup language XAML, which is used for building Silverlight-based applications (see Section 3.1). Nevertheless, XUL-based applications might be an alternative for fat clients, for example within an enterprise, since the main requirement, namely using a Mozilla-based browser, can only be accomplished within a manageable community.
illustration not visible in this excerpt
Figure 3.3.: Ajax-based RIA architecture [Deb06]
This chapter gives an overview of the field of Ajax. In Section 4.1 a short introduction to the technical aspects of Ajax is given. Section 4.2 discusses its hype and business value and gives an answer to the question why and where Ajax can be applied in a useful way. The following section shortly summarizes the different kinds of applications that can be built using Ajax techniques. Finally, Section 4.5 describes different levels of Ajax adoption which are used later on in Section 5.4.1 for classifying the selected Ajax frameworks.
Unfortunately, the implementation of this object is different in almost every browser and older browsers do not even know it. The Internet Explorer, which regards this as an ActiveX object, is aware of the XMLHttpRequest object since version 5.0. So even if the browser is able to create such an object, the ways how to create it are very different.
(1) xmlHttp = new XMLHttpRequest ( ) ;
(2) xmlHttp = new ActiveXObject (” Msxml2 .XMLHTTP”) ;
(3) xmlHttp = new ActiveXObject (” Microsoft .XMLHTTP”) ;
Listing 4.1: Different to create an XMLHttpRequest object
In listing 4.1 three common ways for instantiating an XMLHttpRequest are shown. The first variant works in most browsers (i.e. Mozilla, Opera, Safari and Internet Explorer since version 7.0). Alternative (2) must be used for Internet Explorer Version until version 6. If this does not work the last line should solve the problem. This is certainly not a complete manual for creating an XMLHttpRequest object but it is meant for illustrating how difficult the application of Ajax might get without the use of an appropriate framework that handles such differences.
illustration not visible in this excerpt
Listing 4.2: XMLHttpRequest interface as proposed by the W3C [Kes07]
Listing 4.2 shows an excerpt of the XMLHttpRequest object specification as proposed by the W3C [Kes07]. Since this is the heart of Ajax, a short description of this interface is provided in the following. The basic methods for sending an request are ‘open’ and ‘send’. The open method is needed for initializing the XMLHttpRequest. With its help the HTTP method (i.e. GET, POST, etc.) and the URL of the server side resource are set. Furthermore there is an optional parameter for specifiying whether the request is sent asynchronously or not. Another very important element is the ‘onreadystatechange’ field, that holds a reference of the method that has to be called whenever the state of the request changes. This state is stored in the ‘readyState’ attribute. Its values range from 0 (which means ‘unsent’) to 4 (‘done’).
After initializing the request it can be sent by calling the send() method. A POST request’s body can be defined by providing either a string or a DOM document as parameter for the send method. If the request is set to be sent asynchronously the execution of the program is not blocked but runs parallel to sending the request. When the provided callback function is finally called and the readyState equals 4 the server’s response can be retrieved from the response’s ‘responseText’ or ‘responseXML’ fields, depending on which format is preferred. The status of the response — whether it has been successful or not — can be identified by checking the ‘status’ attribute (or its readable equivalent ‘statusText’) of the response.
Since quite a lot of code is run on the client side another very important part of Ajax is the scripting engine. Therefore, a short history of browser scripting is provided in the follow- ing [Cha01].
Some popular scripting engines are ‘JSpcript’, Microsoft’s ECMAScript implementation, ‘Spidermonkey’, which is included in Gecko-based applications such as Firefox, Rhino, Mozilla’s Java-based script engine, and ‘Tamarin’, Adobe’s new scripting engine that has been donated to the Mozilla foundation and hence will be part of Mozilla 2 [GB07].
The fourth and latest edition of ECMAScript adds native XML support, which is called ECMAScript for XML (E4X), to the language that makes it easier to handle XML responses than when using the DOM interface. E4X is already implemented in scripting engines like SpiderMonkey, Rhino and Tamarin. However, since the Internet Explorer does not support this enhancement the use of E4X is currently not advisable.
Although Ajax is essentially a method for asynchronously sending requests by using the XMLHttpRequest object the real benefit arises only when it is combined with rich user interface components. This combination may lead to a better user experience and can increase the quality of an application significantly. Accordingly, in the following section the question how Ajax can raise the business value is discussed.
When the term Ajax first came up employing Ajax was not an easy task. The core parts of the Ajax functionality had to be implemented manually and the different browser implementations had to be considered. Nowadays there are hundreds of frameworks available which ease the development of such applications, provide a lot more features like handling Ajax requests, managing browser differences or offering testing tools and make the process of construcing Ajax applications far more productive. There are several questions that have to be considered carefully before Ajax is used within a company in order to fully exploit its capabilities. The following sections discuss these questions and provide some recommendations.
The key question when adopting a RIA technology is whether the benefits of this improvement are worth their expenses whereas measuring the benefits of a Rich Internet Application can be quite difficult [Rog07]. Especially web applications that make available complex business processes or configurations may be improved notably by applying RIA technologies. A normal website that does not provide lots of functionality is certainly not the standard use case of a RIA.
On the other hand the costs associated with RIAs have to be considered. The use of Ajax techniques will require some training for the developers involved and developers with good Ajax skills might be more costly and scarce than normal web developers. If an application changes significantly by applying Ajax techniques there has to be some introduction for the users (depending on the type of application and the audience). Although there are many zero- cost Ajax frameworks available, costs for customizing the framework and arranging tool sup- port for it may arise [Fer07].
According to a survey conducted by Forrester 47% of the firms that measure the benefits of RIA implementations to their business said that they meet their expectations and 41% said that they even exceeded their goals [Rog07]. This numbers clearly show the chances Ajax (and RIA in general) offers if its usage is considered carefully.
For some years Gartner3 ranks emerging technologies in its annual Hype Cycle for Emerging Technologies in which they evaluate ‘the maturity, impact and adoption speed of about 30 key technologies and trends during the next ten years’ [PG06]. The key questions of these hype cycles are which trends will have the biggest impact on an organisation’s business and how these trends will influence it. Based on this hype cycle an answer to the question when is the right time for Ajax adoption can be found.
Gartner’s Hype Cycle (Figure 4.1) consists of five phases [Gar07]: The Technology Trigger is the first phase of the Hype Cycle and desribes the emergence of a new technology that leads to considerable interest. In case of Ajax this may be the first mention of the term Ajax in Garrett’s article [Gar05] in February 2005. The second phase is the Peak of Inflated Expectations which represents the top of the hype. This peak is typically characterised by ‘over-enthusiasm and un- realistic expectations’ [PG06]. The regarded technology may be successful employed in some cases but in the vast majority the results do not meet the expectations. This disappointment leads usually to the third phase, the Trough of Disillusionment. This phase is characterised by a significant decline of the visibility of the technology. The trend gets increasingly un- fashionable and is hardly covered by the press any more. After this depression the regarded technology comes to the Slope of Enlightenment. In this phase the technology is successfully used by an increasing number of organisations that understand how to benefit from this trend. Since ever more businesses recognise the benefits of the regarded technology its use becomes more widespread over time. Along with improvements regarding stability and productivity the technology finally reaches the Plateau of Productivity. Each trend is marked with a little icon at its estimated position on the Hype Cycle. The colour of the icon shows how long it will take until the technology reaches the Plateau of Productivity. This speed of adoption can vary significantly since the observed trends are very divergent.
illustration not visible in this excerpt
Figure 4.1.: Gartner’s Hype Cycle for Emerging Technologies 2006 [PG06]
In its hype cycle from August 2006 (Figure 4.1) Gartner sees Web 2.0 as one of three major themes which are extremely hyped. According to Gartner the most important trends behind the term Web 2.0 are Social Network Analysis (SNA), Ajax, Collective intelligence and Mashups, which will all reach mainstream adoption in less than two years (as of August 2006). Ajax is rated to have passed its peak but also that it may have high impact on a company’s business [Vec06]. A requirement for this is to add usability-centered design to the development process and to leverage server-side processing.
The second trend in the field of Web 2.0 are mashup applications. These applications combine several services or data sources into a single user interface and fill the gaps between them (see Section 4.4 for a more detailed descripion). Mashup applications are usually built using Ajax techniques and require only few code since the individual parts of the application already exist. Mashups are rated to have only moderate business impact and will reach maturity within less than two years. Since these applications rely on several sources they are also depending on them which causes the entire application to fail if a single source is not available at the moment.
As the term Web 2.0 consists of several aspects, enterprises have to decide which of them are relevant for their business. These issues include social aspects like establishing an online community or enabling easy collaboration as well as technical aspects like Really Simple Syndi- cation (RSS) or Ajax. According to Gartner [Vec06] the business impact of the non-technology aspects exceeds that of the technology issues whereas the latter are adopted earlier by the en- terprises. Briefly speaking the organisations adopt the least important aspects first. Gartner’s advice is to be ‘selectively aggressive’ [PG06]. That means that each company has to identify which technology or issue influences their business in a positive way and evaluate them more precisely. The others that do not have a reasonable impact on the organisation’s business should be adopted later when the technologies are more mature.
Since Ajax is quite advanced on the Hype Cycle adoption already makes sense if there is a significant business value. Simply using Ajax because everyone does is certainly the wrong way. Furthermore, the available frameworks and toolkits make the development of Ajax appli- cations far more productive than a few years ago. As the internet is an extremely fast growing medium you simply have to adopt to new relevant trends in order to stay competitve. More about the available frameworks and an evaluation regarding their productivity can be found in the Sections 5 and 7.
Beside its hype there are also critical voices regarding Ajax. This might not be surprising since there are always critics with every new trend. This section is dedicated to these sceptical people and discusses the challenges that come along with the professional use of Ajax.
According to Backbase [Bac07] there are five major challenges when it comes to the use of Ajax in an enterprise. The first problem is that many Ajax frameworks or toolkits are developed by a small group of developers. They mostly consider it as a spare time job and work on it whenever they have time. This is certainly not a solid background for a framework and does not ensure that it will be further enhanced and supported for a long time. Despite the vast amount of frameworks that are currently available there are only a few whose future development can be considered ensured. Since most frameworks are open-source they obviously do not include any support or guarantees for the future. Therefore, if an enterprise has to decide which framework to choose this is certainly a point that has to be considered carefully.
The second problem arises because of the young and fast evolving nature of Ajax. Although there are many developers using Ajax, only a few know about best practices of Ajax develop- ment. This deficit can lead to increased maintenance costs, security issues and project delays. Applying best practices can therefore save quite a lot time and money.
Another challenge is the ‘poor development lifecycle integration’. Only a few frameworks facilitate fast application development by offering for example testing and debugging tools. However, integrating Ajax into established application development processes is essential for a successful adoption.
Since most Ajax frameworks are open-source they do not come with any support. Some frameworks are indeed supported by big communities that can assist at solving specific problems but if professional support is needed this might not be enough. It has to be considered if building up an internal support group for training and consulting purposes or hiring an external consulting agency is more valuable for the company.
Especially smaller frameworks are often built up from many sources on the internet. Some developers of Ajax frameworks do certainly not care under which license the used snippets are released and may therefore violate patent rights. Due to this it is always necessary to examine the license in order to not break any law.
As we can see these challenges are not insuperable but they have to be considered carefully. Beeing successful at adopting Ajax to the enterprise depends to a certain degree on how these challenges can be hurdled.
Since Ajax can enhance the interactivity of a web application significantly it brings advantages for a wide range of applications. In case of a framework decision it also has to be considered what kind of applications will be built with it. This section gives a short overview of the different types of applications that can be built using Ajax.
According to Backbase [Bac07], the vendor of the commercial Ajax framework Ajax 3604, there are four main types of Ajax applications. The probably most popular and easiest sort of application is created by ‘ajaxifying’ existing web applications in order to improve their usabil- ity, interactivity and responsiveness. Since most web applications are based on simple HTML pages Ajax functionality can be added by simply incorporating a client-side Ajax framework. Usually these frameworks fit into level 1 and 2 of the classification in Section 4.5. The big advantage of this way is that existing assets can be used and the application does not have to be developed from scratch. Only a few adaptations have to be done at the server side to support the new way of responding to client requests.
The second category of applications that make use of Ajax is the migration of fat clients used within an enterprise. This migration requires re-implementing the affected application but brings along advantages without reducing its richness and responsiveness. The main advantage of this approach is that these applications can be distributed easily via the web and do not have to be updated on the client since the latest version is always downloaded. Therefore, mainte- nance costs can be reduced significantly. Offering these applications to a broader audience is also easily possible as it can be accessed by a browser and does not have to be installed on every client.
Another field of application is given by self-service applications. Providing rich applications for customer self-service can help reducing costs as well as increasing customer satisfaction. Using Ajax functionality to make these applications more user-friendly and interactive is an important point in order to encourage many customers to make use of them and in consequence leads to a relief of the support staff.
The fourth and also very popular type is the so-called mashup application. Such an ap- plication combines multiple sources into a single UI. A mashup application is usually highly customizable, provides an intuitive and homogenous user interface and has to be easy to use in order to attract people. Mashups combine for example a map service (e.g. Google Maps or Yahoo! Maps) with traffic information, the local weather report or other useful location- specific information like hotels or restaurants. They may provide new information themselves but mostly simply link different sources of information. A good mashup is far more valuable to the user than the individual parts would be since it fills the gaps between them. Nevertheless there are also many mashups out there whose value is quite disputable.
According to Ray Valdes [Val06] the adoption of Ajax can be classified into four levels. When a company starts using Ajax in their projects they have to choose the right level of adoption. These levels are described in the following:
The first level of Ajax adoption, which is called Snippet Level, covers individual developers that build in snippets of code into their sites. Therefore this level usually means ajaxifying existing web applications, the application’s architecture and the server side are rarely altered. They neither take advantage of any sophisticated UI library or framework nor do they make use of user-centered development processes in order to ensure an improved user experience. This level includes frameworks like DWR (Section 5.2.6) and Prototype (Section 5.2.10).
The second level, also called Widget Level, describes developers which pick out ‘the best’ widgets from the diverse sources (e.g. open-source toolkits) in order to add to their projects. They enhance existing and add new UI elements in order to improve their sites. There is still no user-centered development process but the incorporation of widgets is done in a more considered way. The Widget Level includes frameworks like Scriptaculous (Section 5.2.12) which provides UI components and builds upon the level-1 framework Prototype.
illustration not visible in this excerpt
Figure 4.2.: Levels of Ajax adoption
The third level of adoption (Client Framework Level) includes the use of a client-side Ajax framework. The employed framework may be open-source or from a commercial vendor. This level mostly means throwing away an existing application and re-developing it from scratch, but it also brings many advantages like a completely new look and feel, greater responsiveness and more productivity. There is no doubt that rewriting an application comes along with more risks than enhancing it. Therefore, when choosing the framework a lot of things have to be considered in order to be successful. Especially the reliability of the vendor regarding enhance- ment and maintenance of the framework is very important. A more detailed list of mandatory and optional requirements can be found in Section 5.1. Representatives of this category are for example Dojo (Section 5.2.7) and Spry (Section 5.2.13) which only work on the client side.
The most complete level of adoption is the Full Framework Level. It extends level three by the integration with the back end. This means that the client-side code is interacting with server-side code. Choosing the appropriate framework (and vendor) is even more important at this level since each framework has specific requirements for the server-side platform. In order to acquire an increased business value a user-centered development process has to go along with the higher levels of adoption. ASP.NET Ajax (Section 5.2.4), Backbase Ajax 360 (Section 5.2.5) and the Google Web Toolkit (Section 5.2.8) fall into this category.
The terms framework, library and toolkit are often used synonymously although their concepts are not exactly the same. Since there are different definitions of these terms and even the ven- dors do not really conform to them, there is no concrete differentiation between these concepts in this paper. Far more important than how they are called are the features and characteristics of the frameworks.
In the field of Ajax, a framework, library or toolkit has to assist the developer with those problems that arise from each Ajax-enabled application. These problems include sending asyn- chronous requests to the server, receiving and processing the server’s response, altering the page according to the new data, providing UI elements that support a rich user experience as well as providing all these features in a way that the application can be used with every major browser. Since these features are needed in every Ajax-enabled application and reinventing the wheel does not make that much sense an Ajax frameworks supports the reuse of this functionality.
According to Ray Valdes the ‘Framework-level use of Ajax among Global 2000 companies is still very rare’ [Val06]. Due to this, many of them will come to the issue of choosing an Ajax framework in the near future.
The following section discusses which features an Ajax framework has to offer in order to benefit the developer and which features would be desirable. After that, a short review of 14 of the most popular and promising Ajax frameworks is presented in Section 5.2. This overview is meant to show the different approaches of the various frameworks as well as to give a taste of the hundreds of Ajax frameworks, libraries and toolkits that are available out there. In Section 5.3 the popularity of these Ajax frameworks is discussed by means of a survey conducted by Ajaxian.com. Finally, the frameworks are categorized in two different ways.
This section discusses the requirements an Ajax framework has to fulfill to be useful to the developer. Since there are many things we can expect from a framework, the list of requirements is divided into two parts: requirements that are essential to a framework and requirements that would be desirable.
The essential requirements are vital for the framework and make it useful for the developer. There are certainly frameworks that do not meet all of these requirements or meet a requirement only to some extent. In that case it depends on the project (or types of projects) the framework has to support. It does not automatically mean that the framework is absolutely useless since it may have its strengths elsewhere. The following list can be seen as a checklist when evaluating an Ajax framework:
- Managing asynchronous requests. The framework has to provide convenient solutions for recurring problems like sending asynchronous requests or receiving the server’s re- sponse. These pieces of code occur in every Ajax application and therefore handling these tasks should be done by the framework.
- Efficient data processing. Furthermore, an Ajax framework has to provide methods for easily and efficiently processing data received from the server, including XML, JSON and plaintext responses. The data has to be easily accessible for further processing so that the developer does not have to spend much time on that and can focus on the application specific problems.
- Resource friendly. The framework has to use resources in an efficient way that enables even older devices to run the application in combination with others.
- Sufficient documentation. There has to be a good documentation for the framework and its public interfaces in order to become acquainted with it in a reasonable amount of time. This documentation has to provide a complete description of the API as well as examples including code samples.
- Useable as blackbox. On the other hand the developer should not be concerned with the inner details of the framework. Using the framework must not require to know how the various functions are implemented. Since this would mean an extra effort it should not be necessary.
- Set of rich UI elements. An Ajax framework does not only have to provide functions for sending and processing XMLHttpRequests but also has to provide a set of UI elements (so-called widgets) that enable a rich user experience. These widgets include for example sortable lists, modal dialogues or drag & drop features and should be adjustable for the developer. To put it briefly, an Ajax framework has to facilitate the development of Rich Internet Applications.
- Solid background. For the development team it is very important that the framework has a solid background. That means that it is developed by a company or organisation that is likely to exist for a considerable time and continues enhancing and maintaining the framework. Furthermore it is essential that the framework has already reached a certain degree of maturity. A good indicator for the maturity of a framework can be its version number, the date of the first public release as well as the intervals at which new versions are released.
- Little training required. The training period for a framework has to be comparative to its benefits. The costs for introducing a framework should amortize within the first or a few projects, depending on their size.
- Enhancement of exisiting applications. Depending on the project the framework should support the enhancement of existing applications in a more efficient way than without framework. If an application has to be completely re-implemented in order to add Ajax functionality to it, the selection of the framework should be reconsidered. This might not be a requirement if the framework is only used to build Rich Internet Applications from scratch but should be considered when choosing a framework.
If one would ask a few developers about desired features the list of requirements can get quite long. The following list is meant to give an overview of features that are quite desirable but not mandatory. These features are of course not present in every framework but they may serve as a hint for future enhancements. This list does not have a special order of priority since such an order would change case-by-case.
- Open source. The implementation of a framework should be accessible to the developer to allow him to get to know to the inner details of its functions. This might be useful for further enhancements of the framework as well as for learning from its implementation.
- Separation of concerns. An Ajax framework should support the architectural principle of separating presentation, control and data (MVC) in order to be able to alter these components without effecting the others.
- Tool support & life cycle integration. There should be at least some IDE integration or tooling available for the framework that supports the development process. These tools include drag & drop of widgets or other elements to the application, code completion fea- tures, debugging and testing tools and other useful instruments. A lack of these features has to be compensated by third party tools or may lead to inefficient development.
- Compatibility with other Ajax frameworks. An Ajax framework should be compatible with other Ajax frameworks or libraries. In some cases it might be useful to combine the benefits of two different frameworks which should not be inhibited because of incompat- ibilities.
- Easily replaceable. In the case that a framework is not enhanced or maintained by the vendor any more it would be very desirable that it is replaceable by another framework without much effort.
There are currently more than 200 Ajax frameworks available and this number rises almost every day. Every big IT company is contributing to this trend by developing its own Ajax toolkit. Adobe, Microsoft, IBM, Google, Yahoo and TIBCO are just the biggest contestants in this competition. Some other frameworks are furthermore supported by a small firm or a group of several companies. But the vast majority of the dozens of frameworks are developed by small teams or even a single person.
In the following section 14 frameworks of different categories are described shortly to get an overview about the different types of frameworks and their diverging approaches that are available out there.
1 A definition of the term Rich Internet Application is provided in Chapter 2.
1 See Section 4.4 for a description of some popular categories of Rich Internet Applications.
2 Only Adobe AIR (see Section 3.5) allows access to system resources since it is not running in a browser but directly on the desktop.
3 A more detailed description of the different RIA technologies is provided in Chapter 3.
6 see Section 4.1 for more details
1 The press release can be found here: http://wp.netscape.com/newsref/pr/newsrelease67.html.
4 See Section 5.2.5 for a presentation of this framework.
Der GRIN Verlag hat sich seit 1998 auf die Veröffentlichung akademischer eBooks und Bücher spezialisiert. Der GRIN Verlag steht damit als erstes Unternehmen für User Generated Quality Content. Die Verlagsseiten GRIN.com, Hausarbeiten.de und Diplomarbeiten24 bieten für Hochschullehrer, Absolventen und Studenten die ideale Plattform, wissenschaftliche Texte wie Hausarbeiten, Referate, Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Dissertationen und wissenschaftliche Aufsätze einem breiten Publikum zu präsentieren.
Kostenfreie Veröffentlichung: Hausarbeit, Bachelorarbeit, Diplomarbeit, Dissertation, Masterarbeit, Interpretation oder Referat jetzt veröffentlichen!