Unit 11

Web Base Applications

OverviewThis unit focuses on web applications. Web based applications are the ultimate way to

take advantage of today's technology to enhance organizations productivity & efficiency.

Web based application gives an opportunity to access business information from

anywhere in the world at anytime. It also facilitates to save time & money and improve

the interactivity with customers and partners.

It allows administration staff to work from any location and sales staff to access

information remotely 24 hours a day, 7 days a week. With a computer connected to the

Internet, a web browser and the right user name and password one can access the systems

from any location. Web-based applications are easy to use and can be implemented

without interrupting existing work process.

Lessons

1. Introduction to Web Base Application

2. Advantage and Disadvantage of Web Application

3. Types of Web Application

4. Web Application Architecture

5. Web Application Development Method

Lesson 1 – Introduction to Web Base Application

Objectives:

At the end of this lesson you will be able to:

Understand web application

History

In earlier types of client-server computing, each application had its own client program

which served as its user interface and had to be separately installed on each user's

personal computer. An upgrade to the server part of the application would typically

require an upgrade to the clients installed on each user workstation, adding to the support

cost and decreasing productivity.

In contrast, Web applications dynamically generate a series of Web documents in a

standard format supported by common browsers such as HTML/XHTML. Client-side

scripting in a standard language such as JavaScript is commonly included to add dynamic

elements to the user interface. Generally, each individual Web page is delivered to the

client as a static document, but the sequence of pages can provide an interactive

experience, as user input is returned through Web form elements embedded in the page

markup. During the session, the Web browser interprets and displays the pages, and acts

as the universal client for any Web application.

On 1999, the "web application" concept was introduced in the Java language in the

Servlet Specification version 2.2. At that time both JavaScript and XML had already been

developed, but AJAX had not still been coined and the XMLHttpRequest object had only

been recently introduced on Internet Explorer 5 as an ActiveX object, so web applications

consisted mostly of applications running on the server and using static HTML pages on

the client side.

What is Web Application?

A web application is a software program that uses HTTP for its core communication

protocol and delivers Web-based information to the user in the HTML language. A web

application is also called a Web-based application. The web application interacts with

users using Web browser and executes business logic on the server where the user is

interacting. The software and database reside on a central server rather than being

installed on the desktop system and is accessed over a network. The outline of a typical

Web application looks something like as below:

1. The user clicks on a link or button.

2. The application completes any actions that need to be done.

3. The application prepares data to show to the user.

4. The application generates HTML (etc.) output.

5. The user reads and interacts with the output.

6. Repeat.

Web applications are by nature distributed applications, meaning that they are programs

that run on more than one computer and communicate through a network or server.

Specifically, web applications are accessed with a web browser and are popular because

of the ease of using the browser as a user client. For the enterprise, the ability to update

and maintain web applications without deploying and installing software on potentially

thousands of client computers is a key reason for their popularity.

Like desktop applications, web applications are made up of many parts and often contain

miniprograms, some of which have user interfaces, and some of which do not require a

graphical user interface (GUI) at all. In addition, web applications frequently require an

additional markup or scripting language, such as HTML, CSS, or JavaScript

programming language. Also, many applications use only the Java programming

language, which is ideal because of its versatility.

A web application can be as simple as a page that shows the current date and time or as

complex as a set of pages on which you can look up and book the most convenient flight,

hotels, and car rentals for your next vacation.

In order for many of these technologies to work on a server, the server must have a

container, or web server, installed that recognizes and runs the classes you create. For

development and testing of these technologies, you can use the tools detailed in this

article, but when you deploy, make sure that the server has Java server software installed

to run Java technology-based web applications. If you don't have access to this

information, ask the server administrator.

Web applications are popular due to the ubiquity of a client, sometimes called a thin

client. The ability to update and maintain Web applications without distributing and

installing software on potentially thousands of client computers is a key reason for their

popularity. Common Web applications include Webmail, online retail sales, online

auctions, wikis, discussion boards, Weblogs, MMORPGs and many other functions. One

web application can be accessed and used by millions of people.

Lesson 2 – Advantage & Disadvantages of Web Based Application

Objectives:

At the end of this lesson you will be able to:

Understand the advantages and disadvantages of Web Based Application

Web-based applications have several advantages over their more traditional

downloadable software programs. Here are the key ones:

1. Cross-platform compatibility. Web-based applications have a much easier path to

successful cross-platform compatibility than downloadable software applications.

Several technologies including Java, Flash, ASP and Ajax allow effective

development of programs supporting all of the major operating systems.

2. Updating. Web-based applications are always updated to the last release, without

requiring the user to take pro-active action, and without needing to prompt or

interfere with user work habits in the hope that they will be initiate new downloads

and installation procedures (sometimes impossible when you are working inside a

large organization).

3. Immediacy of access. Web-based applications need not to be downloaded, installed

and configured. You access your account online and they are ready to work no matter

what your setup or hardware is.

4. Ease of trying. Finally there will be no more obstacles to allow easy and effective

try-outs of tools and applications before having to charge your credit card. Today,

especially when we talk about expensive software, there is still a great deal of

functionalities and small details that cannot be fully tested and discovered before

committing money to a full purchase.

5. Less memory requirements. Web-based applications have far more reasonable

demands on end-user RAM memory than locally installed programs. By residing and

running off a provider servers, these web-based applications use in most cases the

memory of the computers they run on, leaving more space for running multiple

applications at the same time without incurring in frustrating performance hits.

6. Less Bugs. Web-based applications should be less prone to crashing and creating

technical problems due to software or hardware conflicts with other existing

applications, protocols or internal custom software. With web-based applications,

everyone uses the same version, and all bugs can be fixed as soon as they are

discovered. This is the reason why web-based applications should have far fewer

bugs than traditional downloadable desktop software.

7. Pricing. Web-based applications do not require the distribution, technical support and

marketing infrastructure required by traditional downloadable software. This allows

online applications to cost a fraction of their downloadable counterparts if not being

altogether free, while offering additional components and premium services at an

option.

8. Data moves online too. Of course with the move from local applications to web-

based ones also the data we create and access will need to undergo some profound

changes. Nobody likes not to be able to access her own email when traveling, or to be

able to retrieve a particular document when connecting from an Internet cafe 10,000

miles away from your office. "Clients shouldn't store data; they should be like

telephones. In fact they may become telephones, or vice versa. And as clients get

smaller, you have another reason not to keep your data on them: something you carry

around with you can be lost or stolen." Source: Paul Graham - The Road Ahead, 2001)

9. Multiple concurrent users. Web-based applications can indeed be utilized by

multiple users at the same time. No more need to screen share or send a screenshot

when multiple users can see and even edit the same document together. Web

conferencing and online collaboration companies are in for some key transformations

and users need to explore what it really means to effectively work and co-edit

documents together.

10. Data is safer. While hard disk crashes will not disappear, it is likely that users will

hear a lot less about them. As companies take over the storage of users data, highly

reliable redundant data storage farms will become the norm rather than the exception,

and users will have much less of a risk of losing their data due to an unforeseen disk

crash or computer virus. Companies providing web-based applications will provide

extensive backups services either as an integral part of their basic service or as a paid

option. You can imagine that if a commercial company will lose people's data it will

be easily brought to its (financial) knees in a matter of days.

11. Develop applications in the language you prefer. Once applications have been

severed from local computers and specific operating systems they can be also written

in just about any programming language. Since web-based applications are essentially

a collection of programs rather than a single program, these could be written in any

programming language out there. While for desktop software you are bound to use

the same language as the underlying operating system this is not the case when the

software application is independent of the operating system.

Lesson 3 – Types of Web Application

Objectives:

At the end of this lesson you will be able to:

Understand the different types of Web application

A Web application is a dynamic extension of a Web server. There are two types of Web

applications:

Presentation-oriented. A presentation-oriented Web application generates dynamic

Web pages containing various types of markup language (HTML, XML, and so on)

in response to requests.

Service-oriented. A service-oriented Web application implements the endpoint of a

fine-grained Web service. Service-oriented Web applications are often invoked by

presentation-oriented applications.

Lesson 4 – Web Application Architecture

Objectives:

At the end of this lesson you will be able to:

Understand software architecture

Understand the importance of architecture

Understand web application architecture

Software Architecture

The software architecture of a program or computing system is the structure or structures

of the system, which comprise software components [and connectors], the externally

visible properties of those components [and connectors] and the relationships among

them.

The Role of the Software Architecture

The main uses of software architecture are: May be used for stakeholder -, expert-, or quality attribute-oriented assessment.

May be used for configuration management

May be used to dynamically reorganise the system at run time (i.e. dynamic software

architecture).

The importance of architecture

No ethical civil engineer would build a high rise without first having a solid architecture

in place. Strangely enough, many organizations undertake morphing their Web sites into

Web applications with little thought for architecture. The presence (or absence) of a

meaningful architecture is an essential predictor to the success (or failure) of a project.

Building upon the work of Mary Shaw and David Garlan, architecture can be defined as

encompassing the set of significant decisions about the organization of a software system,

including:

Selection of the structural elements and their interfaces by which a system is

composed

Behavior as specified in collaborations among those elements

Composition of these structural and behavioral elements into larger subsystems

An architectural style that guides this organization

As someone observed, a system's architecture is not finished until there's nothing left to

take away. In other words, a system's architecture represents the necessary strategic

design decisions sufficient to form that system. A stable architecture is essential to every

successful system for two reasons. First, the creation of a stable architecture helps drive

the highest risks out of the project. Second, the presence of a stable architecture provides

the basis upon which the system may be continuously evolved with minimal scrap and

rework.

Architecture Design Process

Figure 11-1 Software architecture design process

The architecture design process can be seen as a function that:

Takes a requirement specification as input.

Generates an architectural design as output.

Is not an automated process, necessitating great effort and creativity from the

involved software architects.

The design process is comprised of the following three steps:

Functionality-based design.

1. Defining the boundaries and context of the system.

2. Identification of archetypes.

3. Decomposition of the system into its main components.

4. The first validation of the architecture by describing a number of system

instances.

Assessment of the quality attributes.

1. Each quality attribute is given an estimate.

2. If all estimated quality attributes are as good or better than required, the

architectural design process is finished.

3. If not the third phase of software architecture design is entered: architecture

transformation

Architecture Transformation.

This step is concerned with selecting design solutions to improve the quality

attributes while preserving the domain functionality. The design is again evaluated

and the same process is repeated if necessary. The transformations (i.e. quality

attribute optimizing solutions) generally improve one or some quality attributes while

they affect others negatively. The figure below shows the architecture transformation

categories available for use in this stage.

A canonical Web architecture

Drawn from some of Jim Conallen's writings, he offers the representation of a canonical

Web architecture:

Figure 11-3 A Canonical Web Architecture

The right-most elements -- the file system, the application sever, data, and external

systems -- are essentially the same as found in traditional client/server systems. The left-

most elements -- the browser, the Web server, and again the file system (in this case, a

distributed one) -- are elements unique to the Web space. From the perspective of the user

experience, this otherwise physically distributed back-end looks like traditional

mainframe computing.

However, there are significant architectural differences owing to the very different

mechanisms that tie these elements together. For example, from the browser to the Web

Figure 11-2 Architecture transformation (improvement and refinement)

server, communication is generally stateless, involving the request for, and then the

delivery of, a Web page. Here's the first architectural challenge: how do you preserve the

user's session state? There are a number of alternatives, of which cookies and

communication via IIOP (the Internet Inter-Orb Protocol) are the most common.

The placement of the application's business logic represents another architectural

challenge: should it live in the server (the thin client model), should it live in the client

(the fat client/thin server model), or should it be spread out overall? In the spectrum of

thin to thick client, each alternative has its own advantages and disadvantages: a thin

client offers simplicity of security and distribution but makes the browser look more like

a dumb terminal; a thick client offers greater locality of reference and better interactivity

but at the cost of distribution. Most systems today tend to push business logic to the

server.

Business logic must touch the state of the business. This notion presents the next

architectural challenge. Should there be stateless communication from the logic to the

data via mechanisms such as Java Server Pages (JSP), or should it be more stateful, such

as through servlets? Again, there are advantages and disadvantages to each approach.

Scripting is easier to change but comes with computational overhead, and servlets are

potentially faster but more challenging to develop and deploy.

Connection to the application's persistence data, which may be bound in legacy systems,

also involves many architectural challenges. First, how does one give the illusion of

objects to the user while data continues to live in relational tables? Second, how should

the connection from the system's business logic to its data be manifest? For example, a

coupling via JDBC is more direct but requires that the application developer have

intimate knowledge of the data's form. Alternatively, a messaging architecture is less

direct but is more scalable.

4+1 Model View Architecture

Philippe Kruchten, of Rational Software, has observed that complex systems cannot be

understood from just a single viewpoint. Indeed, the previous diagram is really only a

simple view of a system's deployment. Philippe has pioneered the concept of a 4+1 model

view, as illustrated below:

Figure 11-4 A 4+1 Model View

A system's design view encompasses the classes, interfaces, and collaborations that form

the vocabulary of the problem and its solution. This view primarily supports the

functional requirements of the system, meaning the services that the system should

provide to its end-users.

The process view of a system encompasses the threads and processes that form the

system's concurrency and synchronization mechanisms. This view primarily addresses

the performance, scalability, and throughput of the system.

The implementation view of a system encompasses the components and files that are used

to assemble and release the physical system. This view primarily addresses the

configuration management of the system's releases. The releases are comprised of

somewhat independent components and files that can be assembled in various ways to

produce a running system.

The deployment view of a system encompasses the nodes that form the system's hardware

topology on which the system executes. This view primarily addresses the distribution,

delivery, and installation of the parts that make up the physical system.

The use case view of a system encompasses the use cases that describe the behavior of

the system as seen by its end-users, analysts, and testers. This view exists to specify the

forces that shape the system's architecture.

Note that this is where the UML fits in: the UML is a graphical language for visualizing,

specifying, constructing, and documenting the artifacts of a software-intensive system.

Thus, it is well suited to express each of these five views.

Architectural patterns

One of the most important developments in software engineering in the past few years

has been the realization that all well structured systems are full of patterns. In its classical

definition, drawn from the work of the architect Christopher Alexander, a pattern is a

solution to a problem in a context. A pattern codifies specific knowledge from experience

in a given domain and offers a common solution that resolves the forces that press upon a

system.

Ultimately, we come back to our starting point. For all kinds of computing systems, and

for Web applications in particular, a number of common patterns are emerging for

resolving the forces in that domain. Mechanisms, such as described in Gamma, Vlissides,

Johnson, and Helm's seminal book, Design Patterns, represent the codification of

collaborations among societies of classes that must work together. Architectural patterns

are emerging as well, giving us the means to express the common architecture of simple

Web sites to what is essentially an "Amazon-in-a-box."

Lesson 5 – Web Application Development Method

Objectives:

At the end of this lesson you will be able to:

Understand web application development method

Web Application Development Method

There are four methods that can be chosen from to develop a new web application. The

methods are:

Build everything from scratch

Develop on exactly the same lines as an earlier application, copy-pasting and reusing

much of the code.

Use a design pattern and build around it.

Use a framework

The first method will be a useful method when one wants to learn a new technology, but

for real life applications, this is not the best option. This is because by doing so a lot of

time and resources is used and is high-risk alternative.

The second option is chosen only if the developers of that earlier project are part of the

new one as well. These individuals can provide valuable input from their earlier

experience.

The third and fourth approach is the best in most cases. Use a design pattern that has an

established way of doing things. Use a framework that and where components are just

plugged in to get the application running.

References:

1. The Other Road Ahead http://www.paulgraham.com/road.html .2. Getting Started With Web Applications

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/WebApp.html.3. The Architecture of Web Application

http://www.ibm.com/developerworks/ibm/library/it-booch_web/.