IceSoft - Rich Apps With Java Ajax (2005).pdf - Ajax - darekisap

Rich Web Applications

with

Java and AJAX

June 2005

Stephen Maryka

CTO

ICEsoft Technologies Inc.

The Evolution of the Enterprise Application

Is evolution really circular? Or, maybe it’s a never-ending spiral. This appears to be the case

when we examine the history of the enterprise software application. In the early era of

enterprise computing there were no trade-offs made with regard to an appropriate application

model. There was only one option — a thin-client model leveraging centralized servers and

delivering presentation to the user via a dumb terminal.

With the onset of the personal computer, the model changed, and power to the desktop had a

strong evolutionary effect on the application model, moving it away from centralized computing

toward a distributed model where individual computers hosted their own set of applications.

This fat-client model pushed computation and presentation to the client. With advancement in

graphics technologies, it became feasible to provide the user with a rich interactive presentation

environment for applications. But these advancements did not come for free. Power to

the desktop resulted in skyrocketing costs for deployment, management and maintenance

of applications. Total cost of ownership for applications within the enterprise increased

dramatically.

Next came the Internet era, into which the web application was born, and we spiraled back to

a thin-client model. This time around, the application’s presentation was delivered as markup

(HTML speciﬁcally) and the web browser (the modern dumb terminal) rendered that markup

to generate the user presentation for the application. For the enterprise, this new thin-client

model reversed the total cost of ownership trend from the previous era, but again, not for free.

The crude user interaction model for the web seriously impacted the richness that could be

delivered to the application user, resulting in less effective applications and impeded the total

cost of ownership gains that the thin-client model touts.

So what’s next in the evolution of the enterprise application? Are we doomed to spiral back

toward a thick-client model in order to achieve the application richness that we have come to

expect? Microsoft would like to think so as they push forward with their vision of the Universe—

namely Longhorn and Avalon. Replacing the web model entirely seems a bit far-fetched, even

for Microsoft, so we ask ourselves, ‘Can the existing web model be leveraged to deliver the

superior presentation capabilities we demand while continuing to drive down the total cost of

ownership for enterprise applications?’ From the business perspective, can we create industrial

strength enterprise applications that transform the user experience without increasing total cost

of ownership? Must we spiral backward to the thick-client model to achieve richness, or can we

leap forward within the existing thin-client model?

This paper explores this possibility further through the examination of current trends, dissection

of the underlying problem, and the introduction of an approach that delivers a superior user

experience to web-based enterprise applications, while minimizing the total cost of ownership of

those applications by preserving the thin-client model.

State of the Art—A Proprietary Hodgepodge

The J2EE technology stack is a shining example of a standards-based approach that works.

Look no further than the number of J2EE applications deployed today to validate its

Download a copy of ICEfaces.

success — over 250,000 J2EE enterprise application deployments, and growing

by more than 30,000 per year. The J2EE stack provides a solid foundation for

both B2B and B2C applications, and a multitude of commercial and open source

solutions exist for the development and deployment of these applications. Naturally, a very

strong development community has matured around J2EE, and the Java Community Process

continues to drive new capabilities into the stack. One of the newest additions is JavaServer

Faces (JSF), which ﬁnally delivers a comprehensive, component-based application model for

client-presented web applications. So it would seem that J2EE delivers an industrial-strength,

standards-based solution for the development of rich web applications today. Unfortunately,

while JSF undoubtedly delivers a superior component-based framework for web applications,

it is a server-side technology that relies on markup-based presentation and the existing web

application model. As such, JSF is exposed to all the same limitations that seem to be driving us

back toward the thick-client model.

It is apparent that while J2EE provides a solid technology foundation and has fostered a

vibrant development community, it still struggles in the ﬁnal mile when we leave the server

environment and deliver content, and supposedly, the rich user experience to the browser.

So how has industry compensated? Well, up until recently it has been through a variety of

proprietary approaches that require proprietary markup formats and rely on applet or plugin-

based support at the browser to create the desired richness. While these approaches can be

effective, they don’t typically mix well with existing web content and often require a proprietary

development environment, which forces developers away from their core competencies of J2EE

development. Last, these approaches begin to drive back up total cost of ownership as both

Java Applets, and browser plugins introduce browser and operating system idiosyncrasies. At

enterprise scale, the maintenance issues become signiﬁcant quickly and can have a devastating

impact on total cost of ownership. As a result, these proprietary approaches have been largely

relegated to green ﬁeld applications and have gained little, if any, traction in the enterprise.

AJAX – The JavaScript House of Cards

If we dismiss proprietary approaches, as most of the J2EE world has, what are we left with?

Today, a tremendous amount of energy is being expended on the one standards-based,

client-side mechanism available to us — namely, JavaScript. We all know JavaScript as the

script-based Java mutation that has succeeded in delivering some basic rich features to web

applications. It achieves this through manipulation of the web application’s UI via the DOM

representation of that UI in the browser. JavaScript also facilitates client-side response to user

interaction with the application UI. Thus we get dynamic behavior such as buttons changing

their presentation when we mouse over them. The user of JavaScript and HTML is often

referred to Dynamic HTML or DHTLM.

Most recently, industry has pushed beyond basic DHTML and has begun to exploit a server

communication mechanism in JavaScript called XMLHttpRequest. This activity has spawned

a new generation of web applications based on an approach referred to as Asynchronous

JavaScript and XML or AJAX. The evidence is clear when you look at sophisticated AJAX-based

applications like Google’s GmailTM; AJAX can deliver a rich user experience within the existing

web application model. So, problem solved, right? Well, not exactly. Developing sophisticated

AJAX-based applications is fraught with peril. To begin with, JavaScript is not Java. It is not an

Download a copy of ICEfaces.

industrial-strength language with industrial-strength development tools, so writing,

debugging, and maintaining AJAX applications is difﬁcult. Also, JavaScript is not the

core competency of all those J2EE developers out there, so now you need to recruit

some of those scarce resources that are forging the AJAX path. Even with that expertise in

hand, you are not out of the woods yet. What about the idiosyncratic nature of JavaScript

implementations within different commercial browsers? There is nothing more rewarding than

maintaining scads of browser-speciﬁc code within your application — was that one application

or four applications that you are trying to maintain? And what about those nasty JavaScript

memory leaks? What used to be a short-lived problem (the life time of a single web page) is

now a full-ﬂedged issue as single page AJAX applications can hang around indeﬁnitely chewing

up resources. And don’t forget about all those security issues. Not only is all your source code

readily available from the browser’s source view, but also your corporate data is traveling over

the network in clear text XML documents. Financial institutions are not likely to be thrilled with

those security features. The bottom line is, ad hoc AJAX-based applications will leave your total

cost of ownership equation in tatters. There must be a way to harness the power of AJAX within

a standards-based application model like JSF to deliver truly industrial-strength solutions with

the rich features that enterprise applications are demanding.

The Root Problem With AJAX

So it seems that even though AJAX-based solutions are in their infancy, serious issues with

the approach are mounting rapidly. Let’s examine why that might be. Generally, the way we

achieve increased richness in an AJAX application is to replicate a subset of the application data

model and business logic in the client browser using JavaScript. We then pass that replicated

data through the replicated business logic to cause some sort of intelligent manipulation of

the application’s presentation via the browser DOM to create a richer user experience. That

last bit—manipulation of the presentation layer via the browser DOM — is the only bit that

JavaScript was originally intended to do. The rest of it is pushing JavaScript outside its intended

purpose, which typically spells trouble. Furthermore, the approach pretty much dismantles the

Model View Controller architecture at the root of the web application model, forcing duplication

of data and business logic between client and server. This duplication opens the door to

divergent functionality between client and server, and compounds the maintenance issues for

applications. Once again the root issue is escalating complexity, which yields skyrocketing total

cost of ownership, and makes the AJAX approach questionable for enterprise applications.

Towards a Solution — Harnessing AJAX

So if we reject complex, JavaScript-based client-side application replication as an approach, can

we still leverage AJAX mechanisms to achieve richness? Let’s start by putting JavaScript back in

its place, so we will relegate it to its primary functions of basic presentation layer manipulation

via the browser DOM and event generation based on user interaction with the presentation.

Next, we move the data model and business logic back where they belong, onto the server.

J2EE provides an appropriate foundation to support this. Now we are left with the same old

problem that we have always had. How do we bridge between the server-side application

logic and the client-side presentation layer to deliver that rich user experience? The answer is

alarmingly simple if we move the presentation layer to the server and invent a mechanism for

intelligently replicating it back to the client browser.

Download a copy of ICEfaces.

In the browser, the presentation layer is ultimately represented in a DOM, and it

is that DOM that we move to the server for manipulation. When application state

changes cause presentation changes, those changes manifest themselves in the

server-side DOM. From here, incremental DOM updates are transmitted to the browser via a

lightweight AJAX-based bridge where the changes are reconstructed and the browser DOM

is modiﬁed appropriately. This mechanism results in superior presentation updates because

only minimal incremental changes are required, not full page refreshes as we have come to

expect from web applications. Furthermore, the approach facilitates asynchronous presentation

updates driven from the server as application state changes. And yes, the AJAX bridge

overcomes most of the general concerns that we voiced earlier with regard to ad hoc AJAX.

Speciﬁcally, the AJAX bridge:

• Is small and well contained, deals with browser idiosyncrasies and eliminates

JavaScript memory leaks.

• Eliminates data and business logic replication at the browser, thus eliminating security

issues within the application.

We have now addressed most of the issues related to improving the presentation element of

the Application, but we need to address user interaction with that presentation. To achieve this

we hook the JavaScript event model back into the application event model via the same AJAX

bridge. This means that our application can react to user interaction with the presentation in

real time and effect changes in the back end application data model. Ultimately, these state

changes are reﬂected in the application’s presentation, and the incremental presentation

changes can be propagated back to the client for presentation to the user. We now have an

architecture that facilitates rich web applications and leverages server-side, industrial-strength,

standards-based J2EE technologies to achieve it. This basic architecture is illustrated in Figure 1

below.

Figure 1: Basic J2EE/AJAX Architecture

While this basic architecture has merit, there are a number of holes that need to be ﬁlled for an

Download a copy of ICEfaces.

IceSoft - Rich Apps With Java Ajax (2005).pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: