Rich Internet Application

Rich Internet Applications (RIA) are web applications that have the features and
functionality of traditional desktop applications. RIA's typically transfer the
processing necessary for the user interface to the web client but keep the bulk of
the data (i.e maintaining the state of the program, the data etc) back on the
application server.
RIA's typically
! run in a web browser, or do not re"uire software installation
! run locally in a secure environment called a sandbo#
$istory of RIAs
%he term &Rich Internet Application& was introduced in a 'acromedia whitepaper
in 'arch ())(, though the concept had been around for a number of years
before that under different names such as
! Remote *cripting, by 'icrosoft, circa +,,-
! . Internet, by /orrester Research in 0ctober ()))
! Rich (1eb) 2lients,
! Rich 1eb Application
Comparison to standard web applications
%raditional web applications centered all activity around a client3server
architecture with a thin client. 4nder this system all processing is done on the
server, and the client is only used to display static (in this case $%'5) content.
%he biggest drawback with this system is that all interaction with the application
must pass through the server, which re"uires data to be sent to the server, the
server to respond, and the page to be reloaded on the client with the response.
6y using a client side technology which can e#ecute instructions on the client's
computer, RIAs circumvent this slow loop. %his difference is somewhat
analoguous to the difference between &terminal and mainframe& and 2lient3
server7/at client approaches.It should be noted that Internet standards have
evolved slowly and continually over time to accommodate these techni"ues, so it
is hard to draw a strict line between what constitutes an RIA and what does not.
4sually what can be done in an RIA is limited by the capabilities of the system
used on the client.
Benefits
6ecause RIAs take advantage of the client's 284, they offer real3time user3
interface options that are not possible with the standard $%'5 widgets available
to browser3based 1eb applications. %his richer functionality may include
anything that can be implemented in the system being used on the client side
(see below), including &drag and drop,& using a slider to change data,
calculations that happen on the client (e.g., an insurance rate calculator) and do
not need to be sent back to the server, etc. $igh interactivity of RIA applications
(when compared to standard web applications) may approach that of fat clients.
%here are also performance benefits
%he computing resources of both client and server are more balanced, so
the server need not be the workhorse that it is with a web application. %his
frees server resources and allows the same hardware to handle more
sessions concurrently.
%he network traffic may also be significantly reduced because the client
can be more intelligent (e.g. application specific optimi9ation) than a web
browser in determining what it needs to send back and forth to the server.
%hus, it takes less time to transfer any single re"uest or response because
of two reasons 3 they are smaller and overall network load is lower.
*hortcomings and restrictions associated with RIAs are
! 6ecause RIA applications run within a sandbo# they have restricted
access to system resources. 1hen access to e#pected7assumed
resources is disabled RIA applications may fail to operate correctly.
! :ava*cript or another scripting language is often re"uired. If this is
disabled the RIA will not function properly, if at all.
! ;epending on the client3side programming language or method used (e.g.
:ava*cript), the client code may run at comparatively low speed. %his
limits what functionality can be migrated from the server.
! Although it does not have to be installed, additional client3side intelligence
of RIA applications needs to be delivered by the server to the client. 1hile
much of this is usually automatically cached it needs to be transferred at
least once. ;epending on the si9e and type of delivery it may be
unpleasantly long.
%he current status of RIA development and adoption
RIAs are still in the early stages of development and user adoption. %here are a
number of restrictions and re"uirements that remain
! 6rowser adoption 'any RIA applications re"uire modern web browsers in
order to run. Advanced :ava*cript engines must be present in the browser
as RIAs use techni"ues such as .'5$%%8Re"uest for client3server
communication, and ;0' *cripting and advanced 2** techni"ues to
enable the rich user interface.
! 1eb standards ;ifferences between web browsers can make it difficult to
write an RIA that will run across all ma<or browsers. %he consistency of the
:ava platform, particularly after :ava +.+, makes this task much simpler for
RIAs written as :ava applets.
! ;evelopment tools ;ue to a lack of ade"uate development tools they are
currently significantly harder to develop.
! Accessibility concerns Additional interactivity may re"uire technical
approaches that limit applications' accessibility.
! 4ser adoption 4sers e#pecting standard web applications may find that
some accepted browser functionality (such as the &6ack& button) may
have somewhat different or even undesired behaviour.
:ustifications
Although developing applications to run in a web browser is a much more
limiting, difficult, and intricate a process than developing a regular desktop
application, the efforts are often <ustified because
! installation is not re"uired 33 updating and distributing the application is an
instant, automatically handled process
! users can use the application from any computer with an internet
connection, and usually regardless of what operating system that
computer is running
! web3based applications are generally less prone to viral infection than
running an actual e#ecutable
! as web usage increases, computer users are becoming less willing to go
to the trouble of installing new software if a browser3based alternative is
available
%his last point is often true even if this alternative is slower or not as feature3rich.
A good e#ample of this phenomenon is webmail.
Methods and techniques
:ava*cript
%he first ma<or client side language and technology available with the ability to
run code and installed on a ma<ority of web clients was :ava*cript. Although its
uses were relatively limited at first, combined with layers and other developments
in ;$%'5 it has become possible to piece together an RIA system without the
use of a unified client3side solution. A<a# is a new term coined to refer to this
combination of techni"ues and has recently been used most prominently by
=oogle for pro<ects such as =mail and =oogle 'aps. $owever, creating a large
application in this framework is very difficult, as many different technologies must
interact to make it work, and browser compatibility re"uires a lot of effort. In order
to make the process easier, several A<a# libraries have been developed.
%he &rich& in &Rich Internet Applications& may also suffer from an all3:ava*cript
approach, because you are still bound by the media types predictably supported
by the world's various deployed browsers 33 video will display in different ways in
different browsers with an all3:ava*cript approach, audio support will be
unpredictable, realtime communications, whiteboarding, outbound webcams,
opacity compositing, socket support, all of these are implemented in different
ways in different browsers, so all3:ava*cript approaches tend to cluster their
&richness& around te#t refreshes and image refreshes.
'acromedia /lash 8layer
'acromedia (now owned by Adobe *ystems) is one vendor in this area. %heir
*hockwave browser e#tension, and later their /lash 8layer, have provided
browsers with te#t3refresh abilities since the mid3+,,)s, and 'acromedia
invented the term &Rich Internet Applications& in ())(.
%he 'acromedia /lash technology includes /lash 'edia *erver, /lash
Remoting, 2entral, 6ree9e and /le#, all of which are rendered in viewers'
differing browsers via the 'acromedia /lash 8layer. 'acromedia claims ,-> of
Internet users have some version of the /lash plug3in, and ma<or services such
as =oogle, ?ideo, $ollywood and automakers all use these abilities as a matter
of course. %he /lash 8layer is supported by many browsers (including Internet
@#plorer, 'o9illa /irefo# and 0pera), and is distributed as a free browser plug3in.
%he 8layer runs across various versions of the 1indows and 'acintosh
operating systems, on several ma<or 5inu# varieties, on set3top bo#es and mobile
phones, on ambient signage and automobile consoles. %he /lash 8layer is
essentially a widely3supported virtual machine that e#ecutes byte3code found in
files following the *1/ format.
Active. 2ontrols
@mbedding Active. controls into $%'5 is a very powerful way to develop rich
Internet applications, however they are only guaranteed to run properly in
Internet @#plorer. At the time of this writing, the 'acromedia /lash 8layer for
Internet @#plorer is implemented as an Active. control for 'icrosoft
environments, as well as in multi3platform Aetscape 8lugin wrappers for the
wider world. 0nly if corporations have standardi9ed on using Internet @#plorer as
the primary 1eb 6rowser, is Active. per se a good choice for building corporate
applications.
:ava applets
:ava applets run in standard $%'5 pages and generally start automatically when
their web page is opened with a modern web browser. :ava applets have access
to the screen (inside an area designated in its page's $%'5) , speakers,
keyboard and mouse of any computer their web page is opened on, as well as
access to the internet, and provide a sophisticated environment capable of real
time applications.
:ava applications
:ava 1eb *tart allows desktop :ava applications to utili9e the client workstation.
It also allows the application to break free of the web browser. %his approach
offers the richest functionality without the limitations of $%'5 or the specific web
browser in use.
4ser Interface languages
As an alternative to $%'57.$%'5 new user interface markup languages can be
used in RIAs. /or instance, the 'o9illa /oundation's .'53based user interface
markup language .45 3 this could be used in RIAs though it would be restricted
to 'o9illa3based browsers, since it is not a de facto or de <ure standard. %he
1B2s Rich 1eb 2lients ActivityC+D has initiated a 1eb Application /ormats
1orking =roup whose mission includes the development of such standards
0ther techni"ues
RIAs could use ./orms to enhance their functionality.
4sing .'5 and .*5% along with some .$%'5, 2** and :ava*cript can also be
used to generate richer client side 4I components like data tables that can be
resorted locally on the client without going back to the server. 'o9illa and
Internet @#plorer browsers both support this.
References
+. E 1B2 (())F). 1B2 Rich 1eb 2lients. w3c.org.
(. E 1B2 (())F). 1eb Application /ormats 1orking =roup. w3c.org.
%his is a list of Rich Internet Applications.
(G*even0ffice a web3based @R872R' solution
/lickr by 5udicorp (now HahooI), photo management
=mail by =oogle, e3mail
=oogle 'aps by =oogle, interactive maps
?irtual @arth by 'icrosoft, interactive maps
1in5IJ@ a 1eb 1indow 'anager
Kimbra, 0pen *ource @nterprise 2ollaboration