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/.
Top Related