Computers have been playing a role in the business environment for more than four decades. Throughout that time, the roles of the client and server have been constantly evolving. As businesses and their employees have become more comfortable delegating responsibilities to computers, the look, feel, and architecture of computerized business applications have changed to meet the new demands. This evolving process continues today, as businesses are demanding faster, lighter, and richer Internet applications. In this lesson, you will learn about this evolving nature and understand the business requirements that push us to build rich Internet applications (RIAs).

Understanding the Evolution of Computer Applications

In the earliest days of computerized business applications, all processing took place on mainframes, with the client having no role other than to display information from the server and accept user input. This was largely dictated by the high cost of processing power. It simply was not affordable to spread powerful clients throughout the enterprise, so all processing was consolidated, and "dumb terminals" provided the user interaction.

As memory and processing power became cheaper, dumb terminals were replaced by microcomputers (or personal computers). With the added power available, more desktop applications, such as word processors and spreadsheets, could run stand-alone, so no server was necessary. One challenge faced by organizations with microcomputers was a lack of centralized data. Although the mainframe era had everything centralized, the age of the microcomputer distributed everything, adding many challenges for centralizing business rules and synchronizing data across the enterprise.

To help resolve this issue, several vendors released platforms that sought to combine the strengths of the microcomputer with those of the mainframe, which led to the birth of client/server systems. These platforms afforded end users the power and ease of microcomputers while allowing for business logic and data to be stored and accessed from a centralized locationwhich solved the problems of the day. The new challenge introduced with the client/server systems was distribution. Any time changes needed to be made to client applications, IT departments had to manually reinstall or upgrade the software on every single desktop computer. Many companies found they needed a full-time staff whose primary responsibility was keeping the software on the end users’ desktops current.

With the explosive growth of the Internet in the 1990s, a new model for business applications became available. This model worked by having a web browser act as a thin client, whose primary job was to render HTML and send requests back to an application server that dynamically composed and delivered pages to the client. This is often referred to as a "page-based architecture." This model successfully solved the distribution problem of the client/server days; the application was downloaded from the server each time an end user needed it, so updates could be made in a single centralized place and automatically distributed to the entire user base. This model was and continues to be successful for many applications; however, it also creates significant drawbacks and limitations. In reality, Internet applications bore a great resemblance to mainframe applications, in that all the processing was centralized at the server, and the client only rendered data and captured user feedback. The biggest problems with this surrounded the user interface (UI). Many of the conveniences that end users grew to accept over the previous decade were lost, and the UI was limited by the capabilities of HTML.

For example, desktop software as well as client/server applications frequently use the drag-and-drop feature. However, HTML (Hypertext Markup Language) applications almost never use the feature, due to the complexities and lack of cross-browser support for the DHTML (Dynamic HTML), which it requires to implement in a pure HTML/DHTML solution.

In most cases the overall sophistication of the solutions that could be built and delivered was greatly reduced. Although the web has offered great improvements in the ease and speed of deploying applications, the capabilities of web-based business applications took a big step backward because browser-based applications had to adapt to the limitations of the web architecture: HTML and Hypertext Transport Protocol (HTTP).

Today, the demands for Internet-based applications continue to grow and are often quite different from the demands of the mid-1990s. End users and businesses are demanding more from their investments in Internet technology. The capability to deliver true value to users is forcing many companies to look toward richer models for Internet applications; models that combine the media-rich power of the traditional desktop with the deployment and content-rich nature of web applications.

As Internet applications begin to be used for core business functionality, the maintainability of those applications becomes more crucial. The maintainability of an application is directly related to the application’s architecture. Sadly, many web applications were built with little thought about the principles of application architecture, and therefore they are difficult to maintain and extend. Today, it is easier to build a solid architecture for an application by providing a clean separation between the business, data access and presentation areas, with the introduction of elements such as Web Services, service-oriented architecture (SOA) became more feasible for web-based applications.

To meet the demands of businesses, RIAs should be able to do the following:

Provide an efficient, high-performance run time for executing code, content, and communications. In the next section of this lesson, you will explore the limitations of the standard HTML-based applications, and learn that the traditional page-based architectures have a number of performance-related challenges.
Provide powerful and extensible object models to facilitate interactivity. Web browsers have progressed in recent years in their capability to support interactivity through the Document Object Model (DOM) via JavaScript and DHTML, but they still lack standardized cross-platform and cross-browser support. Building RIAs with these tools so they will work on a variety of browsers and operating systems involves building multiple versions of the same application.
Enable using server-side objects through using Web Services or other similar technologies. The promise of RIAs includes the capability to cleanly separate presentation logic and user interfaces from the application logic housed on the server.
Enable use of the applications when "offline." As laptops and other portable devices continue to grow in popularity, one of the serious limitations of Internet applications is the requirement that the machine running the application be connected to the Internet. Although users can be online the vast majority of the time, business travelers know there are times when an Internet connection is not currently possible. A successful RIA should enable users to be productive with or without an active connection.

Breaking away from the Page-based Architecture

For experienced web developers, one of the biggest challenges in building RIAs is breaking away from a page-based architecture. Traditional web applications are centered on the concept of a web page. Regardless which server-side technologies (if any) are used, the flow goes something like this:

1. User opens a browser and requests a page from a web server.
2. Web server receives request.
3. (optional) Web server hands request to an application server to dynamically assemble page or
4. (optional) Web server retrieves static page from file system.
5. Web server sends page (dynamic or static) back to browser.
6. Browser draws page in place of whatever was previously displayed.

Even in situations when most of the content of the previous page is identical to the new page, the entire new page needs to be sent to the browser and rendered. This is one of the inefficiencies of traditional web applications: each user interaction requires a new page loading in the browser. One of the key goals of RIAs is to reduce the amount of extra data transmitted with each request. Rather than download an entire page, why not download only the data that changed and update the page the user is viewing? This is the way standard desktop or client/server applications work.

Although this goal seems simple and is readily accepted by developers taking their first plunge into RIA development, often web developers bring a page-based mindset to RIA applications and struggle to understand how to face the challenges from the page-based world, such as, how to "maintain state." For example, after users log in, how do we know who they are and what they are allowed to do as they navigate around the application?

Maintaining state was a challenge introduced by web-based applications. HTTP was designed as a stateless protocol, in which each request to the server was an atomic unit that knew nothing about previous requests. This stateless nature of the web allowed for greater efficiency and redundancy because a connection did not need to be held open between the browser and server. Each new page request lasted only as long as the server spent retrieving and sending the page, allowing a single server to handle far more simultaneous requests.

The stateless nature of the web added challenges for application developers. Usually, applications need to remember information about the user: login permissions, items added to a shopping cart, and so on. Without the capability to remember this data from one request to the next, true application development would not be possible. To help solve this problem, a series of solutions was implemented; revolving around a unique token being sent back to the server with each request (often as cookies, which are small text files containing application specific identifiers for an individual user) and having the server store the user’s information.

Unlike traditional web applications, RIAs can bypass many of these problems. Because the application remains in client RAM the entire time it’s being used (instead of being loaded and unloaded like a page-based model), variables can be set once and accessed throughout the application’s life cycle.

A different approach to handling state is just one of many places in which building applications requires a slightly different mindset than web application development. In reality, web-based RIAs bear more resemblance to client/server applications than they do to web applications.

Identifying the Advantages of Rich Internet Applications

Unlike the dot-com boom days of the mid-to-late 1990s, businesses are no longer investing in Internet technologies, simply because they are "cool." To succeed, a new technology needs to demonstrate real return on investment and truly add value. RIAs achieve this on several levels: they reduce development costs; and add value throughout the organization.

Business Managers

By making it easier for users to work with software, the number of successful transactions is increasing. This increase occurs across many industries and can be quantified by businesses with metrics, such as increased productivity using intranet applications or increased percentage of online shoppers who complete a purchase. More productive employees can drastically reduce labor costs while growing online sales increase revenue and decrease opportunities lost to competitors.

IT Organizations

Breaking away from page-based architectures reduces the load on web servers and reduces the overall network traffic. Rather than transmitting entire pages over and over again, the entire application is downloaded once, and then the only communication back and forth with the server is the data to be presented on the page. By reducing server load and network traffic, infrastructure costs can be noticeably lower. RIAs developed using sound architectural principles and best practices can also greatly increase the maintainability of an application, as well as greatly reduce the development time to build the application.

End Users

End users experience the greatest benefits of RIAs. A well-designed RIA greatly reduces users’ frustration levels because they no longer need to navigate several pages to find what they need nor have to wait for a new page to load before continuing to be productive. Additionally, the time users spend learning how to use the application can be greatly reduced, further empowering them. Today, there are a number of excellent applications, which would not be possible without the concepts of an RIA, such as the Harley Davidson Motorcycle Configurator and the Kodak EasyShare Gallery applications. These easy to use applications give an excellent example of the ease of use an RIA can offer an end user.

Posted by: shinny
Filed under: Programming
All Entries From: March 13, 2007

TrackBack URL: http://www.7edge.net/index.php?/trackback/471/Sh44WE6v/