Part 02. Learning Web Technologies With Sri – Servers [Applications Servers & Web Servers]
Note: This post or article are governed by following disclaimer policy.
In this second part of “Learning Web Technologies with Sri”, we will understand & learn about web servers, application servers.
Rather than talking about Web Server & Application[App] Server differences, it’s better to know the definitions or the basics of each & then the knowledge of each would bring out the differences between them automatically!!.
Lot of resources are available on web on similar topics. I have gone through few of them & tried to put the things in little different manner so that people can understand it better, especially [School or college Students who have just started to understand or know the web]. In the final segment of this article I have references for the source which I have used or refered. Full Credit & gratitude goes to original author’s of those sources. Without wasting anymore time, let’s dive in & learn about web servers & applications servers. To start with lets talk about Web server.
Web Server
A web server is a computer program that delivers (serves) content, such as web pages, using the Hypertext Transfer Protocol. The term web server can also refer to the computer or virtual machine running the program. In large commercial deployments, a server computer running a web server can be rack-mounted in a server rack or cabinet with other servers to operate a web farm.
When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a client [example: Web browser]. Next let’s see the history behind the web server.
History behind Web server
In 1989 Tim Berners-Lee proposed to his employer CERN (European Organization for Nuclear Research) a new project, which had the goal of easing the exchange of information between scientists by using a hypertext system. As a result of the implementation of this project, in 1990 Berners-Lee wrote two programs:
- a browser called WorldWideWeb;
- the world’s first web server, later known as CERN httpd, which ran on NeXTSTEP.
Between 1991 and 1994 the simplicity and effectiveness of early technologies used to surf and exchange data through the World Wide Web helped to port them to many different operating systems and spread their use among lots of different social groups of people, first in scientific organizations, then in universities and finally in industry.
In 1994 Tim Berners-Lee decided to constitute the World Wide Web Consortium to regulate the further development of the many technologies involved (HTTP, HTML, etc.) through a standardization process.
Features
- Virtual hosting : to serve many web sites using one IP address.
- Large file support : to be able to serve files whose size is greater than 2 GB on 32 bit OS.
- Bandwidth throttling : to limit the speed of responses in order to not saturate the network and to be able to serve more clients.
- Server-side scripting : to generate dynamic web pages, but still keeping web server and web site implementations separate from each other.
- Path Translation : Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
- a local file system resource (for static requests)
- an internal or external program name (for dynamic requests).
I know it might not be quiet appropriate at this point to talk about Virtual hosting and other stuff, so I will skip explanation of those things & move on path translation.
Whenever user types in url in the Web Client [web browser], such as http://www.riawanderer.com/path/file.html [Note: this is only true for static content requests such as html files, images etc..], the client’s user agent will translate it into a connection to www.riawanderer.com with the following HTTP 1.1 request:
GET /path/file.html HTTP/1.1 Host: www.riawanderer.com
The web server on www.riawanderer.com will append the given path to the path of its root directory. What is this root directory on www.riawanderer.com? to know what is it , let’s assume that the webserver is running on Unix machine, then webserver root is commonly /var/www directory. The result is the local file system resource: /var/www/path/file.html. The web server will then read the file, if it exists, and send a response to the client’s web browser. The response will describe the content of the file and contain the file itself.
The above was just explained in layman terms. Actually the entire flow of request and response are done inside something called HTTP messages. When client [browser] makes a request for a url, as you already know the user agent translates the url into a HTTP request, which is nothing but a request message. A message format is of below
Request
Request = Request-Line ; *(( general-header ;| request-header ;| entity-header ) CRLF) ;CRLF[ message-body ]
The information on what each item/term means in above request can be found in www.w3.org request protocol section.
After receiving and interpreting a request message, a server responds with an HTTP response message. The below is message format for the response
Response
Response = Status-Line;*(( general-header;| response-header;|entity-header)CRLF);CRLF[ message-body ];
The information on what each item/term means in above response can be found in www.w3.org response protocol section.
Ok now we know how a request is sent & how the server responds back. Now next question that would arise is, Are there any limits on how much requests it can handle or respond to?
A Web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 80,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
- its own settings
- the HTTP request type
- content origin (static or dynamic)
- the fact that the served content is or is not cached
- the hardware and software limits of the OS where it is working.
When a Web server is near to or over its limits, it becomes unresponsive.
There are many other things/terms/factors to be considered, but I believe the point till what I have covered is sufficient enough to understand what is a web server ! ;-). So next let’s switch gears to understand what Application server is.
Application Server
An application server is a software framework dedicated to the efficient execution of procedures (programs, routines, scripts) for supporting the construction of applications. The term was originally used when discussing early “client-server” server systems and servers that ran SQL services and middleware servers to differentiate them from file servers.
Later, the term took on the meaning of web applications, but has since evolved into more comprehensive service layer. An application server acts as a set of components accessible to the software developer through an API defined by the platform itself. For web applications, these components are usually performed in the same machine where the web server is running, and their main job is to support the construction of dynamic pages. However, present-day application servers target much more than just web pages generation, they implement services like clustering, fail-over and load-balancing so developers can be focused just on implementing the business logic.
Advantages of Application Servers
- Data and codeintegrity
By centralizing business logic on an individual server or on a small number of server machines, updates and upgrades to the application for all users can be guaranteed. There is no risk of old versions of the application accessing or manipulating data in an older, incompatible manner.
- Centralized configuration
Changes to the application configuration, such as a move of database server, or system settings, can take place centrally.
- Security
A central point through which service-providers can manage access to data and portions of the application itself counts as a security benefit, devolving responsibility for authentication away from the potentially insecure client layer without exposing the database layer.
- Performance
By limiting the network traffic to performance-tier traffic the client-server model improves the performance of large applications in heavy usage environments.
- Total Cost of Ownership (TCO)
In combination, the benefits above may result in cost savings to an organization developing enterprise applications. In practice, however, the technical challenges of writing software that conforms to that paradigm, combined with the need for software distribution to distribute client code, somewhat negate these benefits.
- Transaction Support
A transaction represents a unit of activity in which many updates to resources (on the same or distributed data sources) can be made atomic (as an indivisible unit of work). End-users can benefit from a system-wide standard behaviour, from reduced time to develop, and from reduced costs. As the server does a lot of the tedious code-generation, developers can focus on business logic.
So that’s about application server. I hope by now you would have understood both the things & probably understood the difference between them. If not complete, if it has helped to understand both of the terminologies little bit, that satisfies me.
[signoff]
References