Web Application Technologies

Chapter 1

Chapter 1 Web Application Technologies

• "I am interested in becoming a web developer, but I don't know where to begin. There seems to be so many technologies in the field of web development that I feel lost. How do all these technologies relate to each other, which ones do I need to learn in order to be considered a serious professional, and which one should I learn first?"

Of Lego Blocks and Puzzle Pieces

• "It seems to me that my job as a webmaster has continually been about fitting together a zillion little puzzle pieces. This piece talks to that piece and that piece talks to this piece. It is easy to get overwhelmed."

NOT puzzle pieces

• Web application development technologies are definitely NOT puzzle pieces.

• In web application development however, there is no right way to solve a problem and no truly unique technology. Rather, there are multiple possible configurations of essentially redundant tools, each which solves the same set of problems.

Example

• CGI, ASP and Servlets all serve the same basic function. They perform server-side processing. Similarly CORBA, DCOM and enterprise Java Beans specify how to talk to distributed objects. Likewise XML, HTML, SGML, XSL and CSS are all similar tools for marshaling and displaying data across a network.

Legos

• web technologies within the same categories, can be used interchangeably in MOST situations.

• I like to think of web application development in terms of legos. With legos, there is no overarching "right" way to solve a problem. There are just a whole bunch of block categories (6 hole, 4 hole, 2 hole) which can be put together in an infinite number of ways.

Categories

• Rather than understanding each technology on its own, you need only understand the categories into which individual technologies fall. Once you understand where a technology fits into the scheme of a web application, you already understand 60% of that technology.

Web Application

• all web applications do pretty much the same things:

1. Provide a Query Interface

2. Transmit User-Defined Query

3. Perform Server Side Processing

4. Massage Data

5. Transmit Query Results

6. Perform Client Side Processing

Consider the following generic web application workflow diagram.

                                                                    

      

Role of GUI• In its role as translator, the GUI is responsible for two

things. • First, the GUI must translate the desires, intentions,

needs, and wants of people into executable, logical machine instructions. At the same time, the GUI must also translate computer-generated data into meaningful human-readable information.

• This translation, as you might imagine, is no mean feat. In fact, in creating web applications, web developers will spend just as much time building a solid front end as they will spend developing a dependable backend.

UI Widgets or Controls• As a web application developer, when concerning

yourself with the GUI Layer, you will most likely be concerned primarily with the use and manipulation of "UI Widgets" or "controls".

• Widgets are interface tools that clients can use to make their intentions, desires, and wants known to the program.

• Widgets could include buttons, scroll bars, grids, or even click able images. Widgets should be almost intuitive to you as this is the bit of software we humans most often work with.

Understanding the Web Browser

• a web browser is a software program that knows how to contact a web server (using the HTTP protocol), request a given document from that web server, and display that document returned by the server to a human user.

• Because the communication between the browser and server is better discussed as a function of the communication layer, we'll discuss it in the next section. For now, we concern ourselves mainly with the document display that is more classically a GUI Layer issue.

HTML• Typically, the document that is returned from the web

server is formatted (according to some formatting instructions) by the browser so that when it is displayed, the document will look pretty (rather than just being displayed as plain text) or have some special functionality. All readers will certainly be familiar with HTML, the most ubiquitous web-formatting languages around today.

• Most web browsers know how to take HTML-encoded text and display it according to the HTML formatting instructions. Thus, a web browser will take <CENTER><B>Hello Cyberspace</B></CENTER> and turn it into

Hello Cyberspace

A Short History of Web Browsers

• In terms of the use of a web browser by the mass public, the history of web browsers begins with LYNX.

• LYNX is a simple text-based web browser primarily accessed via UNIX shell accounts that displays formatted HTML text (but not images). A sample of what you might see in a LYNX browser is seen below:

• In fact, soon after the development of LYNX, as the concept of web browsing took off, web browsers would quickly evolve into the graphical web browser species beginning with Mosaic, Mozilla, and finally browsers such as Navigator and Explorer (there are dozens of other browsers of course, we just name the biggies

• These browsers offered a truly user-friendly graphical interface that turned bland library-like document archives into an exciting electronic frontier.

• Consider the same page as above, viewed in Netscape and Internet Explorer!

Basic User Interactivity with HTML Forms

• However, besides displaying HTML-formatted text to users, web browsers also provide a means to solicit data from users and send that data to web servers. They do so by using HTML forms.

• The ability to create forms is really the beginning of a true, traditional web application. HTML forms allow web application developers to design standard input forms with widgets such as drop downs, text boxes and buttons. Users can enter in data dynamically using these widgets

• Behind the scenes, once the user enters in their data and hits a submit button, the web browser will collate the user defined values for the form widgets and submit them to the web server using the POST or GET methods of the HTTP protocol. Again, we will discuss the HTTP communication layer aspects in the next section.

• What you should do at this point is get comfortable with the idea that HTML provides the syntax for defining forms and that browsers will help you process those forms

• NOTE: Besides dealing with HTML form widgets, web browsers also help you maintain application state. they do so by providing an interface for " cookies".

• HTTP is a stateless protocol, most web applications will need help "remembering" what has happened so far in their workflow.

• Consider the example of a web store that might need to keep track of all the items a client has added to a virtual shopping cart. The web store application must keep track of the shopping cart items wherever the user goes on the website, or even whether or not the user leaves the website and returns later!

• To help solve this problem of state maintenance, browsers keep a log of all the application activity locally in a "cookie" (an invisible widget of sorts). Applications can access the contents of the cookie so that they can maintain the state

QUESTION :When did we start seeing web-forms that captured credit-card details, and passed them to CGI-scripts, thereby enabling interaction with server-side applications, in particular interfacing with the EFT/POS network?

The elements that were necessary to support eCommerce of this kind are:

•a version of HTML that supports forms; •a browser that implements a version of HTML that supports forms; •the HTTP POST method, to enable transmission of the data that is keyed into a web-form; •a server that implements the HTTP POST method, and supports CGI scripts; and •an application that interfaces to the EFT/POS system to get credit authorizations and capture transactions into the financial system.