Course Content‎ > ‎

Section 01: Introduction to Web Application Development


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/Server Systems have the following distinguishing characteristics:

  • Service - The Client/Server relationship exists between processes running (mostly) on seperate machines. The server process is a provider of services, while the client process is a consumer of these services.

  • Shared Resources - Because multiple clients can simultaneously connect to the same server, effectively the resources are shared. In using a server in this way, the effect is to more efficiently utilise the server resources.

  • Hardware/OS Independence - Generally, assuming wise decisions are made regarding during the development phase (ie. using Java!) the ideal client/server software is independent of hardware or operating system software platforms. For example, it sould be possible for the client to use an alternative OS or client software, while it should also be possible to move the entire server end from Solaris to Windows to Linux transparently.

  • Asymmetrical Protocols - There is a many-to-one relationship between clients and servers. Clients always initiate the dialog by requesting a service from the server. Servers are passively awaiting requests from the clients.

  • Message Based - Clients and servers are loosely coupled systems that interact through a message-based mechanism. This message passing is the delivery mechanism for service requests and responses.

  • Transparency of Location - As stated previously, clients and servers generally exist on seperate machines. However, once a request is made by the client, the server can transparently redirect service calls when needed, communicating with other tiers (such as a database), other servers and Information Systems.

  • Scalability - Client/server systems can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means either migrating to a more powerful machine or distributing the processing load across multiple servers, as is frequently done by e-Commerce Systems with large numbers (Amazon doesn't run off 1 machine!!)

  • Data/Source Protection - Because the server code and information are maintained centrally it means that there is one source, which needs to be guarded from a security point of view. Additionally, since most of the application code is kept on the server, it can not be downloaded and "de-compiled" using applications such as Jad (with which you can obtain .java files from .class files)

  • System Updates - The server is the "specialist" which determines what to do with client requests and what to return as a response. Hence, in order to perform large system updates, or even quick patches these need only be applied on to the server (or array of servers if load-balancing used).

  • Client Processing - Client/Server systems allow the server to in turn allow the Client to perform certain elements of processing. For example, considering a browser used as a client: the client performs the displaying of the server-generated HTML and JavaScript might be used for FORM validation.

As can be seen, this list of characteristics, encapsulates the advantages detailed in the list of the previous section (Client-side and Server-Side Advantages). Naturally, Client/Server Systems should harness the best of both worlds!

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



Again, these are just samples of what might occur in such a system, but all these processes occur on the server-side of the relationship.

It should be taken into account, that due to the fact that a server can be simultaneously servicing numerous (in some cases vast numbers) of clients, the server must resolve any mutual exclusion issues to prevent corruption of results. Often in any single transaction multiple database updates are required and it is the servers' responsibility to ensure that either all of these updates occur or none. The server must also ensure that that updates required to satisfy one request are isolated from, and do not interfere with, updates required to satisfy a concurrent request.

To give a basic idea of how a problem could occur with simultaneous accesses, consider the situation where Customer 1 (John in Dublin) attempts to buy "GodFather II" with 1 copy remaining in stock. The server (which has no built in concurrent protections) does a check to see if a copy exists, discovers that it does and proceeds to log the transaction (everything is going so well! Must give IT specialists a pay-rise for such a fantastic system!). Unfortunately, virtually instantaneously, Customer 2 (Mary from Sydney) has a craving for the same copy of the DVD and adds it to her shopping cart (unlikely you might say - but with millions of customers not that unlikely!). While John's server process is at the logging stage, Mary's server process passes the stock check, which says that a copy still is in stock.

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.

Web Application Servers

The concept behind splitting an application across a client and a server has been around for many years, and in many different formats for many years. Some examples include FTP servers, SQL servers and transaction servers.  For web application development, we are obviously most interested in 'Web Application Servers'.

This model consists of thin, portable, universal clients which talk to superfat servers. Traditionally, this model began with the basic Web Server which was simply a server, which returned HTML pages when a request was received from a client. The clients and server communicate using an RPC-like (Remote Procedure Call) protocol called HTTP (Hypertext Transfer Protocol). The Web Application Server model has grown significantly since the Web Server stage. While traditional Web Servers have vast amounts of extra functionality compared to their predecessors, such as CGI, Perl, HTML Security, SSL, Servlets, Java Server Pages, PHP, Lightweight Directory Access Protocol, for full scale web applications most developers are turning towards utilising one of many Web Application Servers.

In addition to servicing standard requests for web resources and applications, application servers usually handle a range of other aspects, such as:
  • Application Management: the ability to deploy, stop and restart applications through a user management interface.
  • Load balancing: where requests for resources are shared across multiple physical machines.  For example, all requests to www.google.com are not handled by one machine sitting under some guy's desk!
  • Fail-over: the automatic switchover to another application server, in the situation where a hardware or software problem is encountered
  • Database connection pooling: improves the efficiency and speed of connections to database management systems
  • Monitoring: the ability to monitor memory and CPU requirements for all web applications running on a server
  • Security: configuration of users on the application server, database connections, LDAP (Lightweight Directory Access Protocol), certificates for https security and a range of other security features.
  • Virtual Hosting: the ability of an application server to receive requests for www.domaina.com and www.domainb.com and to process them appropriately as separate applications, despite both domains pointing at the same IP address.
Some of the more popular java-based web application servers include JBoss, Apache Geronimo, Oracle WebLogic, IBM WebSphere, Glassfish, and Apache Tomcat. While Tomcat is not a "fully-blown" application server, it will be used in this module for the deployment of Java servlets and JSPs (Java Server Pages).  

Figure 1.7. Client/Server with Web Application Servers


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.

P-A-D Architecture

The most fundamental logical model of client/server information systems examines what it takes to deliver information effectively to end-users. This model is know as the P-A-D architecture, or Presentation-Application-Data, and relies on the interaction of three fundamental processes:
  • Presentation - also known as the user interface
  • Application - also known as application logic or processing
  • Data - also know as data management or data manipulation
Some logical models of client/server information system divide the application layer into three sublayers, representing the application layer's interfaces with the presentation and data layers:
  • Presentation Logic - The part of the application responsible for interfacing to the user interface
  • Business Logic - the core part of the application, responsible for executing the application and enforcing business rules
  • Data Logic - the part of the application responsible for interfacing to the database management system

Figure 1.8. Presentation-Application-Data (PAD) Logical Model



Considering the P-A-D architecture, we now consider three alternative possibilities for client/server systems:
  • The system is performed totally on the client (Client-Side System)
  • The system is cooperatively split between the client and server (Client/Server System)
  • The function is performed totally on the server (Server-Side System)

2-Tier vs 3-Tier Architectures

2-tier architectures deliver the presentation logic on the client and the database logic on the server. The business logic is buried either inside the user interface on the client or on the database server.
  • If the business/application logic is on the client, we use the term fat client.
  • If the business/application logic is on the server, we use the term fat server.
Examples of 2-tier client/server systems are file servers and database servers with stored procedures.

Figure 1.9. Structure of a 2-Tier Client/Server


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

Consider now the features of the 2-tier and 3-tier architectures:

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

Scalability can be defined as the capability of an application, software or hardware product to adapt to the changing work load applied by consumers of these systems.  In simple terms - if the number of users of your system doubles, can your server handle this load?  Will performance and user response-time decrease?  Will unexpected crashes occur due to memory shortages?
These are obvious concerns for all new software businesses deploying web applications.  The obvious intention of any company is for it to grow and for it's services to have a constantly increasing user-base.  However, this growth can be difficult to quantify and initially most start up companies don't have large amounts of capital to outlay on expensive server resources for which they currently have no need.  Additionally, buying unused server capacity in advance is cost ineffective, due to a combination of Moore's Law and the constantly reducing cost of hardware over time.

Moore's Law states that over the history of computing hardware, the number of transisters on integrated circuits (ICs) doubles approximately every two years.  The law was described by Gordon E Moore (co-founder of Intel) in a scientific paper in 1965 and has applied ever since.

Figure 1.15: Moore's Law 1971-2011   (Source: WikiMedia Commons)
Moore's Law

This has an obvious direct effect on hardware performance, including processing speed and memory capacity, meaning that we are seeing continued dramatic exponential growth in hardware.  In fact, commonly mistaken as Moore's Law is the assertion that chip performance doubles in performance every 18 months, due to both the increased number of transisters on ICs and the improvement in speed of those transisters.  

So instead of buying surplus hardware to cover all future eventualities, architects of web applications will instead look at scalability.  Let us first look at two traditional approaches to scability:
  • Vertical Scaling (Scale Up) : this means adding resources to a single hardware component, such as application or database server.  This typically involves the addition of CPUs or increasing memory capacity.  
  • Horizontal Scaling (Scale Out): this means adding new hardware components to an existing distributed system.  For example: if the current application server is experiencing high loads, then another server could be purchased to run in parallel.  Each web application server could then be used to handle every second request to the server, effectively "load balancing" the computing demand.  There are some issues here involved with distributing an application across multiple servers (e.g. sharing client sessions) but there are solutions available for such issues.
While both of these approaches can be used successfully to manage scalability in our web application systems, they involve considerable hardware expertise, system downtime (vertical scaling) and both still fall foul to Moore's Law to some extent.  

However, while both are suitable for scenarios where load is relatively consistent, neither approach works well for peaking traffic.  To demonstrate this, let us provide two sample problems:

Sample Problem #1: 
A small company has a website demonstrating their new hand-gesture interface for desktop interaction. This is very cool and someone places an article on www.slashdot.org describing the gesture system and linking to the company website.  The resulting huge number of visitors was never anticipated when creating the specification for the web server and as a result the web server falls over under the increased load.  

This scenario actually has a name, the "slashdot effect", also known as "slashdotting".  This is not limited to slashdot.org and in recent years would be more likely to be caused by newer social domains such as Twitter or Reddit.  


Sample Problem #2:
A university has a web application server and a base application where students can log into their "portal" to view their registration record, timetables, library loans etc.  This is used sporadically by students, with occasional log-ins.  For the sake of argument, let's assume 10,000 students logging in once every 2 weeks.  This amounts to 714 log-ins per day.  Assuming a core period of 16 hours during which students log-in (mostly a localised system), this would give us about 45 log-ins per hour, or less than one per minute.  A few light-weight hardware system could safely be installed to cater for these students, perhaps one which could handle up to 10 log-ins per minute to account for busier periods.

However, let's introduce the problem.  The university decides (rightly) that this portal would be an appropriate vehicle for the distribution of examination results. Students should be allowed to log in and view their results when they are released at 12:00 on February 10th.  Students eager for their results, all try to log in simultaneously.  So now we have 10,000 students all attempting to log in at 12:00 to check their results.  The result?  Our server, which could handle 10 log-ins per minute, falls over attempting to handle thousands of requests in that same period.  Additionally, when their request fails, they are likely to spam refresh resulting in more server load.  

In both of these two scenarios, neither horizontal or vertical scaling work as a true solution.  Let us look at a third approach to scaling.

Cloud Computing

Important Note: This is not a full description of 'Cloud Computing' as a concept - this would take far more than a subsection in a chapter, a full chapter or even a full course/module.  At this point, it is merely to introduce one major benefit of Cloud Computing for the scaling of web application infrastructure.

The emergence of Cloud Computing can be seen in modern-day IT infrastructure, whether in our email, social networking, calendars, file storage (Google Drive, DropBox etc.) and even in the software we use (Google Docs, Microsoft 365 Live etc.).  

Equally for web application developers, there are a number of cloud computing platforms offered via the Internet.  One company offering such a platform is Amazon, via Amazon Web Services (AWS). Using services such as AWS, developers can choose to simply buy no hardware, but instead host all of their application resources on the Cloud instead.   Amazon AWS currently (2013) hosts a large number of major websites, including NetFlix, Foursquare, Pinterest and of course, their own Amazon online store.  

Using AWS (or other solutions), it is possible to perform hardware virtualisation, whereby a virtual machine can be created, which acts like a real computer with an operating system.  AWS have vast server farms of high-end machines (the host machines), from which they can virtualise servers (guest machines) on behalf of their client users.  This means that client users of AWS, can log into AWS and choose the types of servers (CPU, memory, operating system, kernel etc) they wish to create.  Within a few minutes, client servers are set up, mapped to IP addresses and login details/encryption keys provided to the client.  

Clients pay for their server resources typically by credit card and costs can initially appear considerable.  However, when one factors in the costs saved in specifying, purchasing, building and installing software on traditional servers, as well as the ongoing costs of electricity, patching and hardware failures, these costs start to appear more competitive.  

So how does Cloud Computing help us in the two example scenarios above?  
Providers of virtualised servers introduce the idea of elasticity by dynamically provisioning resources on a near real-time basis, meaning users do not have to engineer for peak loads.  The basic proposition of cloud computing is that users pay for what they use.  This means that application components can grow and contract on demand across all tiers (presentation, application and database).    Amazon provides EC2 (Elastic Compute Cloud) whereby users can select from a number of template Amazon Machine Images (eg. 64 bit Ubuntu server) to get up and running and may choose as many of these images as needed.  

If the load on the server becomes excessive, then AWS will automatically scale your application on to the other machine images.  Users need only pay for the resources that are actually consumed, typically based on instance hours or data transfer.  

There are a large number of advantages associated with Cloud hosting of applications and databases.  While we are not going to get into them here, there are a few reasons that many companies do prefer to maintain their own resources.  These relate to reliability (for example, Amazon AWS has had some instances of downtime in the past number of years) and the security/privacy of data.  For example, would it be suitable for the university to store your personal details on a Cloud server owned by a third-party company?   Debates on these questions are ongoing in a number of organisations across the world.

Comments