Evaluation and comparison of Ajax Frameworks regarding applicability, productivity and technical limitations
©2008
Magisterarbeit
141 Seiten
Zusammenfassung
Inhaltsangabe:Abstract:
For some years the Internet has been dominated by phrases like Web 2.0 and Ajax. The catchword Web 2.0, which was originally established by OReilly at the first Web 2.0 conference in October 2004, not only describes a new way of perception and usage of the internet (e.g. social software like blogs, wikis, etc.), but also stands for more or less innovative techniques as for instance RSS or Ajax. The latter is a combination of techniques that have been available since the late 1990s, such as JavaScript, asynchronous requests and XML. However, the term Ajax only exists since Jesse James Garret introduced it in his article in February 2005. Since then Ajax has experienced a real hype. Google Mail, Google Maps or Flickr just serve as examples for the mass of applications that have to attribute their success substantially to 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 Applications (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, performance 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 transportation 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 frameworks their applicability, productivity and performance is illustrated as well as […]
For some years the Internet has been dominated by phrases like Web 2.0 and Ajax. The catchword Web 2.0, which was originally established by OReilly at the first Web 2.0 conference in October 2004, not only describes a new way of perception and usage of the internet (e.g. social software like blogs, wikis, etc.), but also stands for more or less innovative techniques as for instance RSS or Ajax. The latter is a combination of techniques that have been available since the late 1990s, such as JavaScript, asynchronous requests and XML. However, the term Ajax only exists since Jesse James Garret introduced it in his article in February 2005. Since then Ajax has experienced a real hype. Google Mail, Google Maps or Flickr just serve as examples for the mass of applications that have to attribute their success substantially to 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 Applications (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, performance 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 transportation 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 frameworks their applicability, productivity and performance is illustrated as well as […]
Leseprobe
Inhaltsverzeichnis
Lukas Ostermaier
Evaluation and comparison of Ajax Frameworks regarding applicability, productivity
and technical limitations
ISBN: 978-3-8366-1058-2
Druck Diplomica® Verlag GmbH, Hamburg, 2008
Zugl. Technische Universität Wien, Wien, Österreich, Magisterarbeit, 2008
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2008
Printed in Germany
Abstract
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 frame-
work 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 con-
sideration when applying Ajax initially. The thesis concludes with a brief analysis of trends
that may be relevant to the future development of Ajax.
Contents
1. Introduction
6
2. The Trend to Rich Internet Applications
8
2.1. What is a Rich Internet Application? . . . . . . . . . . . . . . . . . . . . . . .
8
2.2. Architectural Overview of RIAs . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3. Advantages and Disadvantages of RIAs . . . . . . . . . . . . . . . . . . . . .
12
3. Technologies for Rich Internet Applications
15
3.1. Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2. Java/JavaFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.1.
JavaFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3. Flash/Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.4. OpenLaszlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.5. AIR (Adobe Integrated Runtime) . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.6. XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.7. Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4. Ajax
22
4.1. Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2. Pure Hype or real Business Value? . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2.1.
Creating Business Value . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.2.
Time for Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3. Challenges of Ajax Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.4. Types of Ajax Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.5. Levels of Ajax Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5. Ajax Frameworks
31
5.1. Requirements for Ajax Frameworks . . . . . . . . . . . . . . . . . . . . . . .
31
5.2. Ajax Frameworks Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.2.1.
Ajax Toolkit Framework . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.2.2.
TIBCO General Interface . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.3.
eXtensible Ajax Platform . . . . . . . . . . . . . . . . . . . . . . . . .
36
2
5.2.4.
ASP.NET Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2.5.
Backbase Ajax 360 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.2.6.
Direct Web Remoting
. . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.2.7.
Dojo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.8.
Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.9.
JMaki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2.10. Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2.11. Rico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.2.12. Script.aculo.us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.2.13. Spry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2.14. Yahoo! User Interface Library . . . . . . . . . . . . . . . . . . . . . .
48
5.3. Popularity of Ajax Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.4. Categorization of Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.4.1.
Classification according to the Level of Adoption . . . . . . . . . . . .
51
5.5. Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6. Evaluation Procedure and Sample Application
53
6.1. Description of the Sample Application . . . . . . . . . . . . . . . . . . . . . .
53
6.1.1.
Detailed Description of the Tracking System . . . . . . . . . . . . . .
53
6.1.2.
Application specific Requirements for the Ajax Frameworks . . . . . .
56
6.2. Evaluation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.2.1.
Selection Criteria for the Ajax Frameworks . . . . . . . . . . . . . . .
57
6.2.2.
Selected Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.2.3.
Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.2.4.
Detailed Test Specification . . . . . . . . . . . . . . . . . . . . . . . .
63
7. Framework Evaluation
68
7.1. Adobe Spry Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
7.1.1.
Implementation of the Sample Application . . . . . . . . . . . . . . .
68
7.1.2.
General Aspects of the Framework . . . . . . . . . . . . . . . . . . . .
70
7.1.3.
Developing Company and Community . . . . . . . . . . . . . . . . . .
73
7.1.4.
History, Maturity, Outlook of the Framework . . . . . . . . . . . . . .
74
7.1.5.
Costs of the Framework and Terms of License . . . . . . . . . . . . . .
76
7.1.6.
Available Documentation and Support . . . . . . . . . . . . . . . . . .
77
7.1.7.
Productivity of Development . . . . . . . . . . . . . . . . . . . . . . .
77
7.1.8.
Generated Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.1.9.
Client-side Workload . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
7.1.10. Load and Response Times of the Application . . . . . . . . . . . . . .
80
3
7.1.11. Maintainability of the Application . . . . . . . . . . . . . . . . . . . .
81
7.2. Google Web Toolkit Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . .
81
7.2.1.
Implementation of the Sample Application . . . . . . . . . . . . . . .
81
7.2.2.
General Aspects of the Framework . . . . . . . . . . . . . . . . . . . .
82
7.2.3.
Developing Company and Community . . . . . . . . . . . . . . . . . .
88
7.2.4.
History, Maturity, Outlook of the Framework . . . . . . . . . . . . . .
89
7.2.5.
Costs of the Framework and Terms of License . . . . . . . . . . . . . .
91
7.2.6.
Available Documentation and Support . . . . . . . . . . . . . . . . . .
91
7.2.7.
Productivity of Development . . . . . . . . . . . . . . . . . . . . . . .
91
7.2.8.
Generated Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
7.2.9.
Client-side Workload . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
7.2.10. Load and Response Times of the Application . . . . . . . . . . . . . .
94
7.2.11. Maintainability of the Application . . . . . . . . . . . . . . . . . . . .
95
7.3. ASP.NET Ajax Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
7.3.1.
Implementation of the Sample Application . . . . . . . . . . . . . . .
96
7.3.2.
General Aspects of the Framework . . . . . . . . . . . . . . . . . . . .
97
7.3.3.
Developing Company and Community . . . . . . . . . . . . . . . . . . 102
7.3.4.
History, Maturity, Outlook of the Framework . . . . . . . . . . . . . . 102
7.3.5.
Costs of the Framework and Terms of License . . . . . . . . . . . . . . 104
7.3.6.
Available Documentation and Support . . . . . . . . . . . . . . . . . . 104
7.3.7.
Productivity of Development . . . . . . . . . . . . . . . . . . . . . . . 105
7.3.8.
Generated Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.3.9.
Client-side Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.10. Load and Response Times of the Application . . . . . . . . . . . . . . 107
7.3.11. Maintainability of the Application . . . . . . . . . . . . . . . . . . . . 108
7.4. Overall Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.4.1.
Analysis of the Features and general Aspects . . . . . . . . . . . . . . 108
7.4.2.
Developing Company and Community Analysis . . . . . . . . . . . . . 109
7.4.3.
History, Maturity and Outlook Analysis . . . . . . . . . . . . . . . . . 110
7.4.4.
Cost and License Analysis . . . . . . . . . . . . . . . . . . . . . . . . 111
7.4.5.
Analysis of the available Documentation
. . . . . . . . . . . . . . . . 112
7.4.6.
Analysis of the Productivity of Development . . . . . . . . . . . . . . 112
7.4.7.
Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.4.8.
Client-side Workload Analysis . . . . . . . . . . . . . . . . . . . . . . 114
7.4.9.
Load and Response Time Analysis . . . . . . . . . . . . . . . . . . . . 115
7.4.10. Analysis of Maintainability Aspects . . . . . . . . . . . . . . . . . . . 116
8. Further Issues and Outlook
117
4
8.1. Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.2. Reverse Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.3. Offline Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.4. Mobile Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9. Conclusion
120
A. Detailed PCTS Specification
122
A.1. Use Case Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
A.2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
B. Detailed Evaluation Results
128
5
1. Introduction
For some years the Internet has been dominated by phrases like Web 2.0 and Ajax. The catch-
word Web 2.0, which was originally established by O'Reilly at the first Web 2.0 conference
in October 2004, not only describes a new way of perception and usage of the internet (e.g.
social software like blogs, wikis, etc.), but also stands for more or less innovative techniques
as for instance RSS or Ajax. The latter is a combination of techniques that have been available
since the late 1990s, such as JavaScript, asynchronous requests and XML. However, the term
Ajax only exists since Jesse James Garret introduced it in his article [Gar05] in February 2005.
Since then Ajax has experienced a real hype. Google Mail, Google Maps or Flickr just serve as
examples for the mass of applications that have to attribute their success substantially to 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-
plications
1
(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
1
A definition of the term Rich Internet Application is provided in Chapter 2.
6
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.
7
2. The Trend to Rich Internet Applications
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.
2.1. What is a Rich Internet 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.
8
· 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.
Feature
Desktop
Web
Rich Internet
Applications
Applications
Applications
Rich user experience
+
-
+
Interactive, responsive
+
-
+
Low maintenance
-
+
+
High reach
-
+
+
Table 2.1.: Different characteristics of desktop, web and Rich Internet Applications [Deb06]
Since every technology has its downside Rich Internet Applications also have some weak-
nesses. First of all they need a special plugin (e.g. a Flash Player or a Java Runtime Environ-
ment) or have special requirements for the browser (e.g. that JavaScript is enabled or that it
supports the XMLHttpRequest object). A lack of these settings entails that the application is
not executable on a specific client or may lead to unexpected behaviour because of unsupported
functions or different browser implementations.
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.
9
Since Rich Internet Applications need, contrary to traditional web applications, some addi-
tional 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.
When it comes to accessibility aspects Rich Internet Applications are also unfavourable.
Since many RIAs use JavaScript, similiar scripting languages or animations that are not sup-
ported by screen readers visually handicapped people may not use the application. Providing
an additional version that is accessible for a broader audience may be a possible workaround to
this problem but is also associated with extra costs, especially when it comes to maintenance
issues. Providing a sound solution to this issue will be a challenge for the future in order to
make these applications also accessible for handicapped people.
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.
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.
10
2.2. Architectural Overview of RIAs
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.
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
11
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.
Figure 2.2.: MVC architecture of Rich Internet Applications
2.3. Advantages and Disadvantages of RIAs
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
12
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 tradi-
tional 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.
3
A more detailed description of the different RIA technologies is provided in Chapter 3.
13
· 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 advan-
tages 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.
14
3. Technologies for Rich Internet
Applications
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.
3.1. Silverlight
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.
As of February 2008, there are two versions available: Silverlight 1.0 and Silverlight 1.1 Al-
pha. Version 1.0 only supports JavaScript for building Silverlight applications whereas version
1.1 also allows the use of managed code like C# or VB.Net since it includes a CLR (Common
Language Runtime). Due to the additional features, the 1.1-plugin is approximately 4.2 MB
in size compared to 1.2 MB of version 1.0. The final release of Silverlight 1.1 is expected for
spring 2008 [Str07].
The Silverlight browser plugin supports every version of Internet Explorer, Firefox and Sa-
fari. 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.
1
http://www.mono-project.com/Moonlight
15
3.2. Java/JavaFX
The possibility of running Java programs, so-called Applets, in the browser offers a lot of ad-
vantages 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.
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 AppProjector
2
, 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],
2
http://www.asperon.com/
16
which is 10 percentage points lower than the penetration of the Flash Player.
3.2.1. JavaFX
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).
3.3. Flash/Flex
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.
Flash provides a script language called ActionScript which makes it possible to build more
interactive web applications. Flash is also a specialist when it comes to multimedia applications
as it natively supports streaming video as well as audio. Traditional web applications relying
on HTML and JavaScript do not provide built-in features like these. Another big advantage
is given by the fact that the application is not depending on the user's browser (as long as he
has the Flash plugin installed). Flash content runs in the Flash Player which behaves in the
same way on every platform and in every browser. According to Adobe the Flash Player has a
penetration of more than 98% [Ado07a].
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
17
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.
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).
3.4. OpenLaszlo
OpenLaszlo
3
is an open source platform for building Rich Internet Applications. It is developed
by Laszlo Systems and available for free under the Common Public License Version 1.0. With
OpenLaszlo RIAs are created using XML and JavaScript and then compiled to Flash or, since
version 4.0, to an Ajax enabled DHTML application. OpenLaszlo uses a declarative language
called LZX, which is based on XML, and a presentation server (including the LZX compiler).
3
http://www.openlaszlo.org
18
The LZK language is quite similar to XHTML and uses JavaScript for the dynamic behavior.
Therefore it is easily readable and can be learned relatively quickly. If a user requests an
application the presentation server compiles the LZX code into a Flash movie and sends it back
to the browser. Compiled Flash movies are cached on the server and only recompiled if the
LZX code has been changed [Gro05]. OpenLaszlo can be seen as an attractive alternative to
Flex (see Section 3.3) as it offers almost the same possibilities at lower costs.
3.5. AIR (Adobe Integrated Runtime)
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.
In order to build AIR applications the Adobe AIR SDK is needed which can be downloaded
for free from the official AIR website.
4
As the runtime combines HTML and Flash, AIR
applications can be built using HTML/CSS, JavaScript, Flex and Flash. Developers are also
able to use their preferred Ajax toolkit. Adobe has also presented an add-on for Dreamweaver
CS 3, which allows to automatically compile projects to AIR applications. The KHTML-based
Webkit HTML engine, the ActionScript Virtual Machine (AVM; also known as Tamarin) as
well as the SQLite database are released open source.
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.
3.6. XUL
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:
4
http://labs.adobe.com/technologies/air
19
· 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.
· Use of standards. The language is based on mainstream standards like XML, HTML,
CSS, DOM and JavaScript and is therefore easy to learn for people who are used to these
wide-spread technologies.
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 Browser
5
,
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.
3.7. Ajax
Ajax is an abbreviation for Asynchronous JavaScript and XML. It describes a concept intro-
duced by Jesse James Garrett [Gar05] for building Rich Internet Applications. But Ajax differs
from all other RIA technologies as it does not require any plugin but simply runs in every
modern web browser. As shown in Figure 3.3 an Ajax engine, that is running as JavaScript in
the browser, is responsible for sending asynchronous HTTP requests to the server. The server,
which does not need to know anything about Ajax, processes these requests and sends back
the response to the browser. The response format is, contrary to what the acronym suggests,
not limited to XML but it can also be JSON, HTML or even plaintext. The server's response
5
http://www.faser.net/mab
20
is finally received by the Ajax engine in the browser that makes the data available for further
processing and passes it on to a previously specified callback function. A more detailed view
on the technical aspects of Ajax is provided in the following section.
Figure 3.3.: Ajax-based RIA architecture [Deb06]
As already mentioned, the big difference between Ajax and other RIA technologies is that
Ajax does not require any plugins. This is associated with some advantages but also some
drawbacks. The biggest advantage is certainly that Ajax-enabled applications simply run in
the browser. This allows that traditional web applications can be easily enhanced with Ajax
functionality without the need to redevelop the whole application. A clear disadvantage is
given by the fact that an Ajax application is depending on the browser's functionality. If the
browser does not support the required functionality (i.e. if it does not support JavaScript or the
XMLHttpRequest object
6
) the application will fail. Furthermore an Ajax application cannot
provide additional features (for example video streaming or vector graphics) since the majority
of browsers simply do not support them.
6
see Section 4.1 for more details
21
4. Ajax
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.
4.1. Technical Overview
From the technical point of view Ajax is a combination of several technologies. As the
acronym Ajax (Asynchronous JavaScript and XML) implies, these technologies comprise the
XMLHttpRequests object for sending asynchronous requests, XML for wrapping the data and
JavaScript which glues everything together. Other concepts like the DOM (Document Object
Model) and the presentation layer (consisting of HTML and CSS) also play a significant role in
the field of Ajax. By means of the XMLHttpRequest object data can be updated dynamically
without refreshing the entire page. Therefore this object is the central element of this technique.
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 ) x m l H t t p = new XMLHttpRequest ( ) ;
( 2 ) x m l H t t p = new A c t i v e X O b j e c t ( " Msxml2 . XMLHTTP" ) ;
( 3 ) x m l H t t p = new A c t i v e X O b j e c t ( " M i c r o s o f t . 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
22
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.
i n t e r f a c e XMLHttpRequest {
/ /
e v e n t h a n d l e r
a t t r i b u t e
E v e n t L i s t e n e r
o n r e a d y s t a t e c h a n g e ;
/ /
s t a t e
r e a d o n l y
a t t r i b u t e
u n s i g n e d
s h o r t
r e a d y S t a t e ;
/ /
r e q u e s t
v o i d o p e n ( i n DOMString method ,
i n DOMString u r l ,
i n b o o l e a n a s y n c ) ;
v o i d s e t R e q u e s t H e a d e r ( i n DOMString h e a d e r ,
i n DOMString v a l u e ) ;
v o i d s e n d ( ) ;
v o i d s e n d ( i n DOMString d a t a ) ;
v o i d s e n d ( i n Document d a t a ) ;
v o i d a b o r t ( ) ;
/ /
r e s p o n s e
DOMString g e t A l l R e s p o n s e H e a d e r s ( ) ;
DOMString g e t R e s p o n s e H e a d e r ( i n DOMString h e a d e r ) ;
r e a d o n l y
a t t r i b u t e DOMString r e s p o n s e T e x t ;
r e a d o n l y
a t t r i b u t e Document responseXML ;
r e a d o n l y
a t t r i b u t e
u n s i g n e d
s h o r t
s t a t u s ;
r e a d o n l y
a t t r i b u t e DOMString s t a t u s T e x t ;
} ;
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.
23
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].
JavaScript, the foundation for running scripts in a browser, has been published in December
1995 by Netscape and Sun.
1
It was first included in the Netscape Navigator 2.0 and gained
popularity very quickly. The limitation to Netscape's browser and some security concerns
were working against this trend. In 1997 this language has been standardised by the European
Computer Manufacturers Association
2
(ECMA) and was named `ECMAScript'. Unfortunately,
the various implementations of this standard are not fully compatible. This fact has led to
the rise of many libraries trying to compensate these differences. Hence, such a library is an
essential part of every Ajax framework.
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.
4.2. Pure Hype or real Business Value?
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.
1
The press release can be found here: http://wp.netscape.com/newsref/pr/newsrelease67.html.
2
http://www.ecma-international.org
24
4.2.1. Creating Business Value
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.
4.2.2. Time for Adoption
For some years Gartner
3
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
3
http://www.gartner.com/
25
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.
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 busi-
ness [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
26
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.
4.3. Challenges of Ajax Adoption
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-
27
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 prob-
lems 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.
4.4. Types of Ajax Applications
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 360
4
,
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
4
See Section 5.2.5 for a presentation of this framework.
28
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2008
- ISBN (eBook)
- 9783836610582
- DOI
- 10.3239/9783836610582
- Dateigröße
- 4.1 MB
- Sprache
- Englisch
- Institution / Hochschule
- Technische Universität Wien – Informatik, Studiengang Wirtschaftsinformatik
- Erscheinungsdatum
- 2008 (März)
- Note
- 1,0
- Schlagworte
- ajax wirtschaftsinformatik framework
