What is Web Application Development?

Web application development is the process of creating applications which run "across" the internet, rather than simply on the end-users 'client' computer.  We say "across" rather than "on" because "on" would suggest that a web application runs entirely on some set of remote servers.  As we will see later, much of the work involved in web applications is handled by the client's own personal computer - in effect, the work is shared across both client and server machines.

As a result, web application development consists of two primary parts:

• Client-side Development
• Server-side Development

Perhaps the easiest way of understanding this concept is to view the following diagram and to consider some examples:

Figure 1.1. Client-side And Server-side

Client-side Application Examples

• Executables - These .exe files (assuming Windows) run entirely on the user's own PC, whether they are Word Processors, windows applications, games or small programs. While they may have been previously downloaded from the internet they are run on the client side, using the PC as a host for processing, memory and storage.

• Applets - Java applets are small programs designed to run within another program. They prove very useful in the contex of the web for the reason that the moment that their bytecode is downloaded, they can be executed quickly within the web browser. Again, while they may have been downloaded, or indeed may have continuous communication with other clients/servers (ie. synchronous chat servers) they are still executed on the client side using the client computer's resources.

• Javascript - JavaScript is an object oriented-based interpreted scripting language that is embedded into HTML pages. With it you can control and program elements of your own web pages on the client-side without depending on server-side scripts etc. Using JavaScript you can design your own windows, create forms, perform mathematical calculations, and connect to existing applets and plug-ins. JavaScript is an interpreted language, which means that all that is needed is a JavaScript-enabled browser, which interprets and executes and JavaScript code as the HTML file is loaded. Again, this is a client-side technology since the code is executed from within your browser, which is running on the local machine.

Server-side Application Examples

• CGI Scripts - The Common Gateway Interface, normally referred to as CGI, was the first server-side scripting language to be developed. These CGI applications are executed remotely, on the server and the resulting output is returned to the client through a browser. Virtually all processing (with the exception of the client browser, rendering the output into a viewable form) occurs on the server side and simply the output is returned to the client. Even though a CGI program can be written in almost any language, the Perl programming language has become the predominant choice. Many web servers such as Apache enable CGI through dynamically loaded modules.

• PHP - Hypertext Preprocessor (PHP) is an open source, cross-platform and free scripting language which has a fairly large developer base. It has been around for quite some time now and like CGI has a number of disadvantages when compared to the servlet/JSP architectures, which will be dealt with in the next Chapter.

• Servlets/JSPs - A considerable section of this course centers around the concept of Java servlets and JSPs which are written entirely in Java and provide arguably the best solution for server-side scripting today. They run entirely on the server-side on a servlet or JSP container, embedded in a web server or application server. These are dealt with in detail in the following chapter.

Client-side Advantages

• Server Resources - Each client uses its own resources to execute the code on the webpage, hence saving resources for the provider. This is inherently the disadvantage with server-side scripting, where the server must use valuable resources to parse each page it sends out, possibly slowing down the web site.

Server-side Advantages

• Code Protection - Because the server side code is executed before the HTML is sent to the browser, your code is hidden.

• Browser Independent - Server-side code is browser independent. Because the HTML code returned by your browser is simple HTML, you do not need to worry about the version of browser, javascript etc. that the client is using.

• Local Access - Server-side code is the only choice if you want to access files and directories on the server machine. Client-side languages such as JavaScript are unable to provide this functionality for security reasons.

• Application Updates - By operating on the server-side updating to new versions, fixing bugs, implementing code patches become a simple process of updating the server machine. Consider in opposition to this, a windows application running on the client - in order to update or make fixes, the client must download the latest version each time.

Working Together

Web sites can be designed to take advantage of the strengths and weaknesses of both client-side and server-side. For example: Company A might wish to register users before they can access their site and provides an online form for this purpose. The obvious server-side element occurs after the information is submitted, where the customer details are processed into a file or saved in a database. However, client-side scripting such as JavaScript might be useful to validate the form before the details are submitted and this is performed from within the user's browser. This can be freqently seen throughout the web, where phone numbers, valid credit card numbers, dates of birth etc. are validated at the form stage before submission.

Many developers in the past would have argued against the use of any significant level of client processing. For example, JavaScript can be disabled in browsers; does this cause your web-site to cease to function? Is the client using a mobile phone? does their phone browser even have JavaScript capability? JavaScript was also known for its cross-browser incompatibility problems; would your web application function correctly on every brand and version of client browser? There are other alternatives; why not just use server-side validation for form fields?

The parent of this module was known as 'Server-side Development' and that module concentrated on the development of web facilities which are focused on the "server", rather than the client. This was not to say that the client was ignored - as mentioned, it is through a combination of client and server development that web-based applications are created. However, in that module only the basics of client development were covered, whereas a number of chapters covered development based at the server end. 

In recent years there has been a revitalisation in the use of JavaScript (and Client/Server cooperation in general) due to technologies such as AJAX (Asynchronous JavaScript and XML) which is used for creating interactive web applications. JavaScript libraries have become more advanced, particularly with implementing the advanced features of HTML5 such as drag-and-drop, offline local database storage, inline document editing and the canvas element.   So while there was a push in the direction of the server in the late 90s and much of the 2000s, the client side is again coming to the forefront.

As much of the emphasis has moved away from the server and we will be introducing more client-side development, this module is known as 'Web Application Development', covering both aspects.

Client-Server Systems

So, when we develop web-based systems we are really talking about Client/Server Systems.

The key to understanding client/server concepts is in realising that they describe a logical relationship between an entity that requests a service (ie. a client) from another entity (ie. a server) that provides a shared service as requested. The client and server parts may or may not exist on distinct physical machines. A client can have a relationship with different servers and a server can satisfy requests from multiple clients. The relationship between a client and a server is conducted by means of transactions consisting of well-defined requests and responses. One of the features of client/server relationships is that the client and the server share the workload between them. As a result, client/server relationships are often referred to as cooperative processing.

Client Attributes

In any client/server relationship, the client process can be seen as being proactive, issuing requests to the server. It typically is dedicated to it's user's session and begins and ends with the session. (Note: A session means that encapsulated timespan spent by a user each time they use a system, for example until they close their application or browser connection times out). A client may interact with a minimum of one single server or with multiple servers to accomplish it's task. At the application level, the client is responsible for maintaining and processing the entire dialog with the user. This would typically involved the following:

• Screen Handling

• Menu or Command Interpretation

• Data Entry and Validation

• Help Processing

• Error Recovery

In graphical applications, this also includes:

• window handling

• mouse and keyboard entry

• dialog box control

• sound and video management in multimedia apps

One of the more important and common client tasks is that of data validation, as is frequently handled by JavaScript in web-based applications. In practice, it is not always possible for the client to handle all data-validation: some data checks need to be performed by communicating with the server. For example, consider a web-based system where users need to login, and upon registration they are asked for a unique username, which they wish to be known in the system. In this scenario, communication with the server would be required to see which usernames had already been allocated (unless all usernames were passed to the client on each form, which would be an incredible inefficient way of doing things). However, the client is often capable of handling all data preparation activities. A fat client also implements the business logic associated with an application, while a thin client supports only the the presentation element and minimal data validation. Typical examples of business logic are the rules required to cross-check data against other data and ensuring that business rules are followed by imposing a specific sequence on events (eg. a balance is verified to be nonzero before a withdrawal is processed).

As the client manages all of the users visible interaction, the server-side is made effectively invisible to the user. The user gets the effective illusion that the entire application runs on their local machine, whereas in reality there's a lot more going on!

Server Attributes

In the client/server relationship, similarly the server process can be seen as being reactive, triggered by the arrival of requests from its clients. A server process typically runs constantly, regardless of whether clients are actively connecting to the process. For this reason, reliability of server hardware is obviously very important for mission-critical server applications - if the server hardware goes down, so do the server applications, taking down all of the clients with it! Server services may be provided either directly by the server process itself or by slave processes spawned for each client request (Check out the section on servlets and their life cycle for an example). In these systems, when a request arrives, the server spawns a slave process dedicated to handling that request, allowing the master process to receive other requests immediately.

Figure 1.2. Master/Slave Server Processes

A server is function-specific, which means that it performs a set of predefined transactions. The server takes the request, works out what is being asked of it and performs the required logic to process the request. Usually the request is treated as a transaction , which can be viewed as an indivisible unit of work.

Consider for example, a standard e-Commerce process where a user (customer) wishes to purchase an item and adds the item to their shopping cart. At the client end, the user selects to add 'The Godfather II' DVD to their shopping cart. At the server end:

Figure 1.3. Example e-Commerce Process

The above example only provides a very basic structure of what might occur at the server end - in reality much more would likely occur. For example, if the items is in stock the process might be:

1. Log the transaction

2. Decrease the stock levels of this item by 1

3. Check if the stock levels have dropped below a certain level

4. If stock has dropped below this level, email notify an employee or automatically place an order with the wholesaler

5. Log this stock shortage

6. Update database information on this customer, so that the "system" knows that the customer is interested in this genre of film

7. Add the item to the users cart

8. Perform checks on the users cart to check for 2 for 1 or reduced price combinations

9. Generate the web page to return to the client

Figure 1.4. More Detailed Example

Figure 1.5. Shopping Example with Concurrent Purchase

One solution to such a mutual exclusion issue is to perform locking to prevent the corruption. For example, the entire 'Adding to Shopping Cart' procedure could be "locked" (ie. only one process can add any item to any cart at any time). This would certainly prevent the situation above from occurring but could severely limit server resources. If it takes an average of 100 milliseconds to perform the entire operation on the server, only a maximum of 10 items could be added per second on the server worldwide! (let's assume just one server for now!) If we average 100 customer purchases per second - we're in serious trouble!The diagram describes some of the possible issues which may arise: others might include (if we pass the end stage) delivery issues, theft investigation, customer billed but not supplied, customer service calls, major overstocking or an entire server crash! Obviously the effective monetary and customer service implications could be dire to a company running a poorly designed server structure.

Another more effective solution would be to only "lock" the part of the process where the mutual exclusion problem could occur. In the diagram below, we move the logging to after the stock decreasing and we "lock" just the Stock Check and the stock decrease. This part of the process might only take 5ms, allowing us to handle 200 shopping cart additions per second, allowing us to service our entire customer base.

Figure 1.6. Using Locking to Protect from Concurrency

The server is responsible for all processing associated with accessing, storing and organising shared data, updating previously stored data and any management of other shared resources. Shared resources can be data, CPU power, disk or tape storage, print capability, communications, display and memory management. Servers are responsible for load-balancing, which is the process of dividing requests between numerous servers to allow the use of the resources of multiple server machines.

Client/Server System Tiers

Client/Server physical architectures are often categorized in terms of tiers. The term tiers refers to the relationship between the logical sublayers of the application process of the P-A-D logical architecture and the physical architecture in which those sublayer processes are delivered. Before we delve into 2-tier, 3-tier and n-tier systems we should have an understanding of P-A-D.

One of the biggest driving factors of 2-tier client/server systems is simplicity. Typically, 2-tier systems are used primarily in departmental applications, such as decision support or small scale groupware. However, as systems become more advanced, requirements increase and are expected to globalise, the 2-tier systems begin to break down. Used in a departmental LAN 2-tier systems are viable, since the IS Department typically owns the local desktops. However, to deploy these fat clients on a global net is a logistical nightmare. If the Internet were to rely on fat clients for all systems, users would need to download the latest version of site-specific software at every visit to individual sites. To overcome to globalisation problem, something drastic needed to occurr and finally the development community came up with a "Gillette-like" concept - three blades are better than two! (even though Gillette now have 5 blades in their razors at this stage!)

3-tier client/server systems are the new growth area for client/server computing because it meets the requirements of large-scale Internet and intranet client/server applications. These systems are more scalable, robust, flexible and can integrate data from multiple sources. Presentation logic is delivered on the client, the business logic on one or more dedicated servers, and the database logic on one or more powerful database servers. Applications are easier to manage and deploy on the network, since the business logic is handled by the dedicated servers.

Figure 1.10. Structure of a 3-Tier Client/Server

As stated, in these systems, the business (or application) logic lives in the middle tier; it is seperated from the data and user interface. 3-tier applications minimize network interchanges by creating abstract levels of service. Instead of interacting with the database directly, the client calls business logic on the server. The business logic then access the database on the client's behalf. The client need only make a call for a service on the application tier, which in turn will generate the multiple SQL calls required to complete the database transaction. One of the obvious benefits of this (over a 2-tier database server) is that it provides better data security, since authorization is performed between the second and third tiers. Addtionally, the database schema (ie. the way the data is structured in tables etc.) is not exposed to the client user.

Considering the P-A-D architecture, the following diagram of 2-tier Vs 3-tier client/server systems, shows how the 3-tier presentation logic, business logic and database logic layers have been clearly seperated into individual tiers.

Figure 1.11. 2-Tier vs 3-Tier Architecture

2-Tier Architecture Features

• System Administration: Far more complex, since individual client machines need to be updated and maintained
• Security: Low Security, often database schemas and logins are visible
• Encapsulation of Data: Poor, since similar to security, data tables are exposed
• Performance: Poor, since multiple SQL requests are often made (unless transactions used) and large amounts of data is often downloaded for analysis by the client
• Scale: Poor, very limited management of client communications, typically only suitable for LAN based applications
• Application Reuse: Poor, typically deployed for one specific use
• Internet Support: Poor. Fat clients are particularly unsuitable for low bandwidth downloads across the Internet (less of an issue today for many users)
• Hardware Flexibility: Limited to a client and a server.
• Ease of Development: High
• Communication Choices: Limited to synchronous, connection-oriented RPC-like calls

3-Tier Architecture Features

• System Administration: Less complex, since the application exists primarily on the server, all administration can be performed on the server machines
• Security: High, clients are simply making calls to methods, functions or object-types, making data retrieval transparent
• Encapsulation of Data: Good, since mostly methods or services are called, direct data requests should not be made
• Performance: Good, only services and requests are sent between the client and server - only the exact pre-processed data is received by the client.
• Scale: Good, can easily spread load over numerous seperate servers, manages users through potentially unlimited numbers of client sessions
• Application Reuse: Excellent, objects and services can be reused efficiently, platform changes easy
• Internet Support: Excellent. Standard thin clients typically exist on user systems, or require a short download time
• Hardware Flexibility: Excellent - all three tiers can reside on different machines or the second/third tiers can reside on the same server. Multiple database servers may be used. The second tier can be load-balanced across multiple hardware servers.
• Ease of Development: While historically more difficult, the vast range of GUI and rapid development frameworks currently available both accelerate and make easier the process of development
• Communication Choices: RPC-type calls also supported but also, connectionless messaging, queued delivery, broadcast, etc

Figure 1.12. 2-Tier vs 3-Tier - Development vs Complexity

N-Tier Architecture

3-tiered client/server architectures are sometimes referred to as n-tiered client/server architectures. Typically, the middle tier in most 3-tier applications is not implemented as a single application - rather a collection of components are used. Each component automates a relatively small business function. When the client makes a single business transaction, the server response is actually the combination of the results of several seperate middle-tier components. In the following example, we can see the number of middle-tier services as seperate components:

Figure 1.13. Components in an N-tier Architecture

Writing middle-tier applications in a component-based manner allows large applications to be written in a number of smaller stages. Large mission-critical projects can be written in smaller projects, with the possibility of making early releases (with less functionality), until the "final" application is written. Indeed, no version need to be considered "final" since it is possible to add new components at a later date. The components can be reused or combined in different ways to provide extra functionality. Each programmer or team of programmers can work on individual components and simply provide each other with the required interfaces to each others componenents.

Individual components can be reused for new applications. This can be achieved in two seperate ways: firstly if the components are written in an object-oriented language (such as Java) the source code can be easily reused; secondly, compiled binary components can also be used as "binary black boxes", recombining them in different ways for new applications. Component-bases systems can grow beyond a single application to become the basis for new suites of applications. It is possible to assemble applications very quickly by adding a few new middle-tier components and reusing a number of existing components.

Clients are able to access data and functions easily and safely, since they send requests to components to execute functions on their behalf. The server components encapsulate the details of the application logic and thus raise the level of abstraction. Similarly, clients do not need to know the details of the database schemas or database security. The entire process is kept hidden from the client, apart from the request sent and the response received. The component architecture provides consistent, secure access to data and eliminates random, uncontrolled updates coming from many applications at once. For example, consider the following diagram:

Figure 1.14. Example Component Architecture

In this example, we show four components, three of which are likely to be called directly by the client. The UserManager component sits behind the other three and performs all database and data access on their behalf. In this way, we can keep one centralised component which performs all database access (creation and retrieval). As we discussed earlier in the P-A-D architecture, we saw that the Application process can be split into three subsections: Presentation Logic Interface, Business Logic and Database Logic Interface. In this example, the first three components deal with the presentation interface and some business logic - they would not make any SQL data interactions with the database. The UserManager component would contain the remaining business logic and would deal with the Database Interface, handling all of the SQL calls to the DBMS. It would not be involved in any way with the presentation of the resulting data to the client.

Additionally, using component-based architectures, it is possible to incorporate "off-the-shelf" components. Rather, than necessarily developing every component it is possible to purchase/avail of existing components which perform standard processes. For example, a company might decide that rather than writing their own database connection pool, they might use a pre-written, pre-tested component and integrate it with their own existing components. Similarly, they might decide to use a "Logging" component, which, while simple to write, might be a case of reinventing the wheel.

Scability

Cloud Computing