I have decided to work on a super secret (for you) Android project.
Time to put some fun in the Java learning process!!!

Need to force myself to make more regular updates…

Anyway.. since my last post many things have changed in my life, among which:

• New job @ FTSE UK
• New toys… Ipad and HTC Desire
• New obsession… Improving my programming skills!
• New house (to call my own)

Introduction

The growth that The Internet as has in the last years has changed the expectation in terms of number of users that a web infrastructures is required to serve. A web server infrastructure might nowadays need to be able to cope with millions of users.
Whenever it is possible to foresee such a high demand of connections, it is important to make sure that the system we work with is able to expand in order to easily accommodate the increased load. Such ability to expand is called Scalability.

The purpose of this article is to show different ways to design a scalable system, and explore the opportunity given by the AJAX technology to facilitate Scalability by removing the need for stateful servers.

Scalability

The need for scalability

It is not always easy to understand how many users will be accessing a web resource.
Furthermore, it is not always possible to have a precise idea of when users will decide to access such resources. Special events, advertising or news sometimes tend to create a burst of connections that will have no mercy for architectures that are not prepared to this kinds of traffic patterns, creating the famous (or infamous) Slashdot effect.
Other factors, like SSL Cryptography, might also reduce the capacity of a Server even on a low number of users.
The result would be a web site with a reduced availability, which will lead to problems like losing customers, loss of profit and bad reputation.

Approaches to Scalability

Scalability can be approached in 2 different ways. A system can scale up (Vertical Scalability) or scale out (Horizontal scalability).

• Vertical scalability is obtained by increasing the capacity of the Server (processor, memory, storage). It increases manageability but decreases availability and reliability, as the system is still relying on one server.

• Horizontal scalability is known to decrease manageability by increasing the  complexity of the system, as it is achieved by adding servers to the infrastructure, and having the global load shared between the machines usually by the means of a Load Balancer.

This article is focused on showing the limitation and complexity of scale out architectures, and how GWT and AJAX can simplify the scenario.

Problem: Servers are stateful

The foundation of the web is a stateless protocol named HTTP. Because of its stateless nature, a web server is not naturally able to understand whether two or more incoming requests are related to the same user or not. This creates a huge number of problems when a web application needs to remember a user in order to perform a task (i.e. a shopping chart application).

Traditionally, to solve this problem web servers implement ways to store a “session state” in order to offer to a user the same environment it had in its previous request (i.e. the shopping chart remembers the product added by the user).
In this scenario, session states for each user are maintained on each server, and the load balancer always needs to route requests coming from  the same user to the same server (called “session affinity”).

This means that although the load balancer could send each request to a different server, it actually needs to send the same user to the same server or the whole web application will not work.
In this scenario, scalability suffers from a reduced reliability and availability.

In fact, if one of the servers dies, the same faith will be shared by all the user sessions that were stored on the server, preventing the system from being fault tolerant even if there are more active servers available.

Clustering the web servers or using databases for session persistency are both method used to increase the availability of the solution, but with the cost of a more complex infrastructure .

In fact, using a DB to store our sessions is slower to access and makes the Database a single point of failure. Clustering the DB to solve this problem would increase the complexity to the solution.

On the other hand, creating a web cluster forces us to use a proprietary solution that supports clustering, and limits us to have the same web server on each machine. Also, implementation of clustering have a number of limitations, especially concerning the number of nodes supported.

Solution: Stateful Clients, Stateless Servers

Although the traditional approach described above considers the browser a “dumb” terminal, over the years browsers have become more and more powerful.
Additions like DOM (1998), Javascript (1995) and XML technologies pave the base for AJAX (Asynchronous Javascript And XML), which transforms the web browser into something more than a simple terminal.

With AJAX, technologies like Javascript, CSS and DOM are used to build a Single Page Application which, which presents a number of benefits over traditional HTML Multi-page Web Applications.

Such application holds the state and communicates with the server just when data needs to be fetched or sent back to the system.

From a Scalability point of view, with Ajax based applications:

• Less data is exchanged between the server and the client, improving responsiveness, bandwidth utilization and server load;

• Session State can be kept on the client, effectively decoupling client-server and removing session affinity, with benefit on scalability.

• Some Business logic is pushed to the client (i.e. page flow), removing this task to the server.

As for the cons, Ajax applications have built the bad reputation of being not maintainable, lacking of enterprise grade tools and suffering from issue due to different implementations of DOM and Javascript on the different browsers, leaving the Developer to keep track of browser glitches.

Google Web Toolkit (GWT) Framework attempts to solve many of these problems by allowing the developer to code the application in Java, and as such relying on a wider base of tools and support. Browsers differences are also mostly hidden by the Java to JavaScript compiler, which allows the Developer to concentrate on the actual code.

Simplified Architecture

Pushing the state to the client, and making the servers “stateless” greatly simplifies the architecture  of a load balanced web server farm.

Under this scenario, because the session state is now kept on the client, the load balancer is free to send the requests to any server.

The most direct consequence is that fail-over is almost immediate.

Limitations

Although keeping the state on the client clearly shows the benefits it can bring to the whole infrastructure, it is important to clearly identify limitations and problems.

While the application is able to keep the state while running, it is important to remember that such state is lost whenever the user hits the reload button, creating a huge number of problems regarding session persistency and usability of the application.

Although, like in legacy web application, it is still possible to use cookies as a way to recover from a reload, it is important to consider that:

• Cookies were conceived to be small and simple, and some browsers allow for a small number of data to be stored.

• Storing authentication information and other sensitive data on cookies is seen as a security risk.

Conclusions

AJAX (and frameworks like GWT) have changed the way we used to think and develop web pages and web applications.

The same seems to be happening to the way we think and design the web infrastructure that will deliver the solution.

Making a completely stateless web server infrastructure requires the client to be able to offer the web application a better environment, especially in terms of data persistency, which is currently not possible by using cookies.

Because of these huge limitations, the author believes that, until better client side persistency technologies will be available (now available through plug-ins like Google Gears), keeping the state completely on the client is non feasible for complex web applications.

Posted in Architectures Tagged: AJAX, Glassfish, Google Web Toolkit, GWT, Load Balancer, Scalability ]]> http://alessandrodemaria.wordpress.com/2008/11/28/12/feed/ 0 Alle http://alessandrodemaria.wordpress.com/2008/07/03/the-right-tool-for-the-right-task/ http://alessandrodemaria.wordpress.com/2008/07/03/the-right-tool-for-the-right-task/#comments Thu, 03 Jul 2008 21:11:17 +0000 alledm http://alessandrodemaria.wordpress.com/?p=6 ]]> My biggest and most recent achievement while working in my company comes from a really basic concept. Every task can be completed in a number of ways, but one tool (the right one) will make it easier!

In our complex infrastructure, the biggest bottleneck was validating data within XML Files. The files, usually representing Purchase Orders or Invoices, had to be validated against a number of simple rules.

The process that was taking care of it was extremely inefficient, and some files would take up to 40 seconds to be validated.

This article on Schematron and this on RelaxNG gave me the idea, while SUN’s MSV and ZVON’s SaxonServer gave me the tools.

Now my Java Frankenstein can munch documents at the average speed of 20ms (yes… MILLISECONDS) saving hours of processing time and integrating seamlessly in the present infrastructure.

Not bad, uhu?

Ask me how to have the same in your system.