An Enterprise RIA Framework for Service Consumption
For ICOMP'07
Udayan Banerjee, [email protected]
Kanaklata Narayan, [email protected]
Deepesh P C, [email protected]
Ravikiran Belthur, [email protected]
Technology Innovation Centre, NIIT Technologies Ltd.,
31/2 Hosur Road, Bangalore, INDIA
Phone - +91 80 3028 9582, Fax - +91 80 3028 9799
Keywords: Rich Internet Application, XML, SOA, AJAX
Abstract
Rich Internet Application (RIA) has become
popular as it combines the power of desktop
interface with the manageability of a
browser based application. However the
focus of most of the RIA initiatives is to
make existing web pages more interactive.
On the other hand enterprise application
also require features which are related to
presentation of complex data structure, the
ability to manipulate the same, integration
with the business layer apart from providing
desktop like functionality.
In this paper, we outline an RIA framework
which is designed for building enterprise
applications. This is a client side framework,
which is expected to work in conjunction
with services. It uses the request response
model of interaction with services as the
only method of communication with the
server. Case study of using the framework in
one application is also briefly covered.
1. Introduction
Information Technology (IT) has
become core to business operation.
Enterprise applications are increasingly
becoming more and more complex. There is
greater demand for more user friendly
interfaces while retaining the convenience of
a browser. Accessing applications over
internet has become a standard practice.
Enterprise applications have to quickly
change in response to the changing business
needs.
The core problem of application
complexity has partially been addressed by
Service Oriented Architecture (SOA). It
allows a monolithic application to be broken
down into multiple more manageable
services. As a result it provides the building
block for a more flexible application.
However, it does not address the problem of
having a flexible user-friendly interface
made available over the internet.
Enterprise applications require feature
rich user interface and the traditional
browser based user interface has been found
to be lacking in this respect. A typical
desktop application provides the power user
with many features which and normally not
supported in browser-based application
made available over the internet.
A technology which promises to offer a
solution to this problem is Rich Internet
Application (RIA). The attempt is to
combine the power of desktop interface with
low footprint and ease of manageability of a
browser based application, which can be
easily accessed over the internet.
However, most of the RIA initiatives are
aimed at either making traditional web pages
more interactive and easier to use or to
design user-friendly social networking sites.
A very limited attention has been paid to
address the special need of a typical
enterprise application. Such an application
requires many features related to
presentation of complex data structure and
manipulation of the same.
Though it is possible to implement these
features in most of the popular RIA
frameworks, they are not an integral part of
the framework and additional programming
is required to achieve the same.
Additionally, the lack of a suitable
framework also makes the application more
difficult to change.
In this paper our attempt is to define the
features required by an enterprise RIA
framework. First we provide a brief survey
of the existing RIA technologies and explain
the rationale behind our choice of
technology. Then we outline the user
interface features required for an enterprise
application. We also share our experience of
building and using the framework with an
actual case study.
Use a client other than a browser – In
this approach a client program different
from the browser is used. Apollo initiative
being followed by Adobe is an example of
this approach.
Use a plug-in for the browser – In the
second approach, the browser is used only as
a container. The actual implementation is
through a plug-in. Adobe Flex and Java
Swing based application follows this
approach.
Extending browser capability – The
third approach is being pursued by the
developer of the browser where browser
capability is being extended by including
additional markup languages. Mozilla XUL
and Microsoft XAML are the main example
of this approach.
JavaScript library – In this approach
additional functionality is provided through
and set of JavaScript libraries which utilize
the built-in capability of the browser but
hide the complex programming needed for
utilizing them. Open Source script.aculo.us
is one of the most popular examples of this.
2.2 Definition options
2. Different approaches to RIA
There can be different approaches to
building an RIA framework. There are two
dimensions to be considered. The first
dimension is what the choice of architecture
will be for the actual implementation of the
framework. The second dimension is to
decide how the developer will use the
framework in designing the user interface.
2.1 Implementation options
The common component in any internet
based application is the browser. To
implement a RIA, it is necessary to enhance
the capability of the browser. There are
different architecture options available and
each has its advantages and disadvantages.
Following are the popular options in use.
In addition to how the RIA is actually
implemented, it is also necessary to decide
how the developer will be using the
framework to design and develop the user
interface. The approaches can be broadly
classified into the following categories.
Specialized IDE – In this approach
developer uses a specialized IDE where
most of the development happens visually. It
may involve some amount of scripting in
either a standard or a proprietary scripting
language. This approach is followed by
Adobe Flex.
Library calls provided on the server
side – In this approach the developer is
shielded from the complexity of client side
programming. A set of library calls are
provided at the server side which gets
translated to necessary client side code
automatically. Microsoft Atlas and Open
Source ThinWire are examples of this
approach.

JavaScript library calls provided to
be used in the web page design – In this
approach, most of the programming is
expected to be done on the client side. The
task is simplified through a JavaScript
library which is to be used by the developer.
All AJAX based framework utilizes this
approach. One popular example is Open
Source script.aculo.us.

Specialized XML – The final approach
is to provide a specialized language to
define the page layout and the associated
action. Typically some form of XML is
used. Open Laszlo Mozilla XUL and
Microsoft XAML are the main examples of
this approach.
2.3 Our approach
One of the key requirements of our
framework was technology neutrality. The
framework had to be agnostic about the
server side technology. Similarly, on the
client side it should be a generic as possible
with minimum dependence on any propriety
technology. In addition, flexibility was a key
requirement.
To satisfy these requirements, the most
appropriate option was to implement the
framework based on a JavaScript library and
to use a specialized XML to define the user
interface. We wanted to concentrate on the
core features required by an enterprise
application and hence we avoided building
an IDE to visually develop the user interface
in the initial version. So, the framework will
have the following components.

A language for User Interface definition
(UID), which will also include the
associated navigation and all actions
triggered by user interaction with the
application


A browser side engine to handle the
UID
A JavaScript library to support the
engine
Necessary interface to initiate service
request and handle service response
Method of storing data returned by the
service and also data created or
modified by the user in a Data Cache
(DC)
We chose XML as language for all
information exchange and information
storage. The UI definition is also in XML.
3. Scope of our RIA framework
Before outlining on the features of our
framework it is necessary to discuss the
responsibility a client framework should and
should not have. We have used the
following as guiding basic principle.

Maximum utilization of the client
resources by ensuring that all actions
that are not necessary to be performed at
the server end should be done at the
client

Utilized caching technology to avoid
unnecessary server trips and ensure that
the data exchange between server and
client is optimized. The possibility for
duplicating a server action on the client
side should be considered if it leads to
reducing network traffic

Due consideration to be given to the
security requirement of the application
and clear demarcation of business logic
from presentation logic
Based on these principles, we have
arrived at the scope on the framework and
what should be excluded.
3.1 Features to be covered by the
framework










Ability to define the user interface,
navigation, actions to be performed in
the page using the specialized XML
definition of the framework
Based on the definition, rendering the
user interface, which should include
opening new page, refreshing complete
page or part of a page.
Initiation of all the navigation based on
the definition
Perform basic validations like checking
the type of data entered by user,
checking the range of values of an input
etc.
Initiating service request for fetching
data from a service
Maintaining a data buffer for data
retrieved from the server
Capture user input and update the data
buffer
Initiation of service request to post the
changes made in the data buffer
Initiating other types of services which
is not related to either data fetch or data
update
Handling error response from service
and showing the error messages to the
user in a meaningful manner with the
ability to handle multiple errors
3.2 Features not to be covered by the
framework
To ensure a proper segregation between
presentation, business logic and persistence
the framework should not handle any of the
functionality related to business logic
execution, database access or business
validation. These should be performed by
the service. However, the framework should
have features to initiate such action.
To ensure a secure application all
activities related to authorization and access
control should be performed by the services.
However, the presentation engine should be
capable of modifying the user interface
based on the information received from the
service to either completely hide or disable
access to certain data elements or actions on
the page.
3.3 Features to optimize data exchange
between client and server
A trip to the server and the amount of
data that is exchanged in every trip has a
negative impact on the performance of the
application. Following features should be
supported to minimize the impact.



Cashing the user interface definition
Cashing the result of services which are
almost static in nature or changes very
infrequently
Submit only changed data for all update
request
4. Feature of the User Interface
Definition (UID)
The UID should contain the actual look
& feel of the user interface. Not only will it
include the full page but also will include
part page definition, which could be
replacing content of a page already
rendered.
To implement the look & feel the
definition should definitely include standard
controls available on a browser like Text,
Input box, Radio button, Dropdown list box,
Check box, Button. Sample UID is given
which contains
Additionally it should also include
controls available on a typical desktop
application. These should include the
following.





Different types of menus like dropdown
menu, cascading menu and popup menu
Tool bar
Tree
Tabbed folder
Tabular control which is like a grid
where data is arranged in multiple rows
and columns
The following UID is for a menu
definition which has File, Edit, View, Tools,
Window and Help as the main menu option.
Each of the menu option as a set of submenu
attached to it. Submenu Show/Hide Tree
under Tools has an action attached to it
which will invoke a JavaScript function
treeToggle().
Actions referring to data element of tabular
control will refer to the current record.
There should also be other types of
container control, which will help in
organizing the page.



Free Form as a collection of multiple
basic controls
Container control where child controls
are visually arranged one below the
other
Container control where child controls
are visually arranged side by side
For a typical enterprise application
different types of actions needs to be
triggered based on user interaction with the
application. The framework should have
support for frequently used actions and those
should be built in features. In addition, it
should also support special user defined
action which could be programmed using
JavaScript. Any of those actions could be
attached to standard events of a control.
One of the key requirements of a
enterprise application is what is known as a
multiple document interface (MDI) where
multiple pages can be opened in the same
display area with only the top page being
visible. This is achieved through use of
layers, which are laid one on top of another
and only the top layer being visible.
It should be possible to bind controls to
the data in the Data Cache (DC). Whenever
the DC is updated using a service call, the
linked controls in the page should get
refreshed. Similarly any updates done by the
user should get transferred from the control
to the DC.
When the DC contains multiple
occurrences it should be possible to bind it
to a tabular control. The tabular control
should support the concept of a current
record. There should be a visual indication
of the current record. User should be able to
select the current record by clicking on it.
Some of the most common built-in
actions needed for the framework should be
the following.








To invoke service to fetch data
To update DC based on service response
To refreshing portion of a page
Update content of the DC
Send data update to a service
Create a new layer in MDI and show a
page
Open a new window and show a page
Modify the property on any control
The action which invokes a service
should also have the capability to handle
exception condition or error condition
returned by the service.
5. Case Study
Our first step was to build a framework
based on our understanding of the
requirement of a typical enterprise
application and develop it to a level where it
was ready for beta testing. The second step
was to pilot it on a typical enterprise
application which will help us identify the
limitation of the framework. The third step
was to identify the limitations of the
framework and enhance it so that the pilot
application could be completed.
To test the power of the framework we
chose an application required a desktop like
interface on the browser. It was an
application where an insurance underwriting
package written in Visual Basic was to be
migrated to a new environment such that it
is easily available to underwriters through
the internet. An earlier attempt to convert
the application to a typical browser
environment was not successful. The users
were not comfortable and found it limiting.
This application needed a multi
document interface (MDI). It needed
creation of dynamic tree to show linkages
between various data elements. It needed
liberal use of tab folders where information
regarding one entity could logically
organized and accessed at the click of a
button. It also needed to represent data in a
grid form, which could be modified by the
user. In short it needed all features required
by a typical business application.
When we started implementing the user
interface required for this application we
noticed that we needed additional controls,
actions. We summarized the additional
requirement, generalized it and went back
and enhanced our framework. At the end we
could implement the complete user interface
of the application. Below we show a sample
screen from that application which contains
menu, toolbar, tree and data displayed in
tabular format.
The effort involved in designing the user
interface for this application turned out to be
only a fraction of doing the same thing in
traditional way. The interface also closely
resembled a desktop application in look &
feel and usability. Only a minimal amount of
JavaScript had to be written.
6. Conclusion
Based on the experience of building this
framework we conclude that it is feasible to
build business application on a browser
which has the look & feel of a desktop
application and the manageability of a
browser based application. We also
conclude that this is possible to achieve this
by utilizing the existing capabilities of the
browser.
Our framework is also found to be
flexible and with minor modification can
serve as the user interface for any set of
services. Since the definition is in XML and
there is very limited programming required,
the
resultant
application
is
also
maintainable. We could also use it to build
quick prototype of application interface.
Many of the RIA libraries have a much
richer set of controls. Hence there is scope
for adding many more controls to the
framework. The implementation of the
framework is such that it can be easily
extended to include many more controls.
In its current form, the developer is
expected to create the UID using any XML
editor. We have not yet created any
interactive development environment (IDE)
which could be used to visual design the
user interface. However, it is very much
feasible to create such an IDE and we also
feel that such an IDE can itself be an RIA.
The list of actions supported by the
framework can also be expanded to reduce
the necessity of writing code in JavaScript.
However, it needs to be done in a controlled
manner, so that every action needed for
every business application does not find a
way into the action list. The repeatability of
usage of the action across applications needs
to be established.
By using this framework we also
achieved a standardization of the look and
feel of all the pages. No special effort was
required for achieving the same.
7. References
[1] Matthias Book, Volker Gruhn, Gerald Mucke, "An
Instant Message-Driven User Interface Framework
for Thin Client Applications" ase, pp. 257-260, 21st
IEEE International Conference on Automated
Software Engineering (ASE'06), 2006.
[2] Sayar, A. Pierce, M. Fox, G, "Integrating AJAX
Approach into GIS Visualization Web Services"
ase, pp. 169- 169, Telecommunications, 2006.
AICT-ICIW '06. International Conference on
Internet and Web Applications and
Services/Advanced International Conference on 1925 Feb. 2006
[3Jin Yu1, Boualem Benatallah, Fabio Casati, and
Regis Saint-Paul, "XUPClient - a Thin Client for
Rich Internet Applications", The 7th International
Conference on Web Information Systems
Engineering, Wuhan, China, October 23~26, 2006