Interview Fundas

Servers

The servers involved in handling and processing a user's request break down into a few basic types, each of which may have one or more tasks it solves. This flexibility gives developers a great deal of power over how applications will be created and deployed, but also leads to confusion over what server is able to, or should, perform a specific task.

Starting at the basic level, a user is typically submitting a request to a system through a web browser. (We are conveniently ignoring all other types of clients (RMI, CORBA, COM/DCOM, Custom, etc..) for the time being for purposes of clarity.) The web request must be received by a Web Server (otherwise known as an HTTP Server) of some sort. This web server must handle standard HTTP requests and responses, typically returning HTML to the calling user. Code that executes within the server environment may be CGI driven, Servlets, ASP, or some other server-side programming language, but the end result is that the web server will pass back HTML to the user.

Web Servers

The web server may need to execute an application in response to the users request. It may be generating a list of news items, or handling a form submission to a guest book. If the server application is written as a Java Servlet, it will need a place to execute, and this place is typically called a Servlet Engine. Depending on the web server, this engine may be internal, external, or a completely different product. This engine is continually running, unlike a traditional CGI environment where a CGI script is started upon each request to the server. This persistance gives a servlet connection and thread pooling, as well as an easy way to maintain state between each HTTP request. JSP pages are usually tied in with the servlet engine, and would execute within the same space/application as the servlets.

Web servers allow you to serve content over the Internet using the Hyper Text Markup Language (HTML). The Web server accepts requests from browsers like Netscape and Internet Explorer and then returns the appropriate HTML documents. A number of server-side technologies can be used to increase the power of the server beyond its ability to deliver standard HTML pages; these include CGI scripts, server-side includes, SSL security, and Active Server Pages (ASPs). ServerWatch keeps tabs on the top Web servers, check 'em out by click on the server of your choice at right.

There are many products that handle the web serving and the servlet engine in different manners. Netscape/iPlanet Enterprise Server builds the servlet engine directly into the web server and runs within the same process space. Apache requires that a servlet engine run in an external process, and will communicate to the engine via TCP/IP sockets. Other servers, such as MS IIS don't officially support servlets, and require add-on products to add that capability.

There are three types of servlet engines: 1) StandAlone Servlet Engine: It is a web server that includes built in support for servlets.For eg Java Web Server etc. 2) Add on Servlet Engine:It functions as a plug-in for an existing server,a server that was not originally designed with servlets in mind.For eg JServ, JRun,IBM WebSphere etc. 3) Embeddable Servlet Engine:It is a lightweight server deployment platform that can be embeddable in another application. That application becomes the true server.For eg JavaServerEngine etc.

Application Servers

When you move on to Enterprise JavaBeans (and other J2EE components like JMS and CORBA) you move into the application server space. An Application Server is any server that supplies additional functionality related to enterprise computing -- for instance, load balancing, database access classes, transaction processing, messaging, and so on.

EJB Application Servers provide an EJB container, which is the environment that beans will execute in, and this container will manage transactions, thread pools, and other issues as necessary. These application servers are usually stand-alone products, and developers would tie their servlets/JSP pages to the EJB components via remote object access APIs. Depending on the application server, programmers may use CORBA or RMI to talk to their beans, but the baseline standard is to use JNDI to locate and create EJB references as necessary.

Now, one thing that confuses the issue is that many application server providers include some or all of these components in their product. If you look at WebLogic (http://www.beasys.com/) you will find that WebLogic contains a web server, servlet engine, JSP processor, JMS facility, as well as an EJB container. Theoretically a product like this could be used to handle all aspects of site development. In practice, you would most likely use this type of product to manage/serve EJB instances, while dedicated web servers handle the specific HTTP requests.

Web Servers Vs Application Servers

Web server exclusively handles program control flow by HTTP requests, whereas an application server serves business logic to application programs .

A Web Server understands and supports only HTTP protocol whereas an Application Server supports HTTP,TCP/IP and many more protocols. Also many more features such as Caches,Clusters,Load Balancing are there in Application Servers which are not available in Web Servers. We can also Configure Application Servers to work as Web Server. In short, Applicaion Server is a super set of which Web Server is a sub set.

An application server is technology where developers can create, test, and execute application components. Application servers are typically J2EE-based, running EJBs or other Java components. Application servers are designed to create true applications with complex business logic, and have scalability features such as load balancing, fail-over, and process distribution. In other words, it's primarily a development environment. In contrast, Web servers are technology designed to create and deploy Web site, serving up content more so than applications. They both use Web interfaces, but Web servers are more about the interface than the back-end logic. In other words, Web servers serve up content. As time moves on Web servers are looking more like application server, as they adopt their functionality. I can understand the confusion.

Application Servers can be termed has advanced versions of we servers offering more functionality and tools to support the following features, however few of these features can also be handled using web servers (they are marked with * symbol).

1. Scalability *
2. Performance *
3. Messaging
4. Resource Pooling
5. JNDI
6. Transaction services
7. In-Built Security
8. App Diagnostics & Monitoring
9. In-Built IDEs eg: workshop for weblogic, WSAD for WebSphere

An application server is a software engine that delivers applications to client computers or devices. Moreover, an application server handles most, if not all, of the business logic and data access of the application (a.k.a. centralization). The main benefit of an application server is the ease of application development, since applications need not be programmed; instead, they are assembled from building blocks provided by the application server. For example, a wiki is an application server that allows users to build dynamic content assembled from articles. Moreover, wikipedia is an assembled wiki that delivers an encyclopedia stored in a filesystem, with changes to the encyclopedia stored in a database.

Although the term application server applies to all platforms, it has become heavily identified with the Sun Microsystems J2EE platform; however, it has also come to encompass servers of Web-based applications, such as integrated platforms for e-commerce, content management systems, and Web-site builders.

Application server products typically bundle middleware to enable applications to intercommunicate with dependent applications, like Web servers, database management systems, and chart programs. Some application servers also provide an API, making them operating system independent. Portals are a common application server mechanism by which a single point of entry is provided to multiple devices.

Java EE Servers

Following the success of the Java platform, the term application server sometimes refers to a Java Platform--Enterprise Edition (J2EE) or Java EE 5 application server. Among the better known Java Enterprise Edition application servers are WebLogic Server (BEA), JBoss (Red Hat), WebSphere (IBM), JRun (Adobe), Apache Geronimo (Apache Foundation, based on IBM WebSphere), Oracle OC4J (Oracle Corporation), Sun Java System Application Server (Sun Microsystems) and Glassfish Application Server (based on Sun Java System Application Server).

To give an example JOnAS application server was the first non-commercial, open source application server to have achieved official certification of compliance with the Java Enterprise Specification. BEA delivered the first Java EE 5 certified application server followed by Sun Microsystems' reference implementation Glassfish.

The Web modules are servlets and JavaServer Pages, and business logic is built into Enterprise JavaBeans (EJB-3 and later). The Hibernate project offers an EJB-3 container implementation for the JBoss Application server. Tomcat from Apache and JOnAS from ObjectWeb are typical of containers into which these modules can be put.

A Java Server Page (JSP) is a servlet from Java that executes in a Web container—the Java equivalent of CGI scripts. JSPs are a way to create HTML pages by embedding references to the server logic within the page. HTML coders and Java programmers can work side by side by referencing each other's code from within their own. JavaBeans are the independent class components of the Java architecture from Sun Microsystems.

The application servers mentioned above mainly serve Web applications. Some application servers target networks other than the Web: SIP servers, for instance, target telephony networks.

Non Java EE Servers

Microsoft's contribution to application servers is the .NET Framework. This technology includes the Windows Communication Foundation, .NET Remoting, MSMQ, ASP.NET, ADO.NET, and IIS.

Advantages of application servers

Data and code integrity
By centralizing business logic on an individual or 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 be done centrally.

Security
A central point through which access to data and portions of the application itself can be managed is considered 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 presentation layer traffic, it is perceived that the client-server model improves the performance of large applications in heavy usage environments.

Total Cost of Ownership (TCO)
In combination, the benefits above are considered to represent a cost saving to a company when 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.

How Web Servers Work?

Have you ever wondered just exactly how this Web page you are reading found its way into your browser and onto your computer screen? The process laregly depends on Web servers. Read on as interviewFundas briefly explains the mechanisms that bring Web pages to your home, your office or your mobile computers.

Typically, users visit a Web site by either clicking on a hyperlink that brings them to that site or keying the site's URL directly into the address bar of a browser. But how does the same site appear on anyone's computer anywhere in the world and often on many computers at the same time?

Let's use interviewFundas as an example. You decide to visit interviewFundas by typing its URL -- http://www.interviewfundas.com -- into your Web browser. Through an Internet connection, your browser initiates a connection to the Web server that is storing the interviewFundas files by first converting the domain name into an IP address (through a domain name service) and then locating the server that is storing the information for that IP address (also see Understanding IP Addressing).

The Web server stores all of the files necessary to display interviewFundas's pages on your computer -- typically all the individual pages that comprise the entirety of a Web site, any images/graphic files and any scripts that make dynamic elements of the site function.

Once contact has been made, the browser requests the data from the Web server, and using HTTP, the server delivers the data back to your browser. The browser in turn converts, or formats, the computer languages that the files are made up of into what you see displayed in your browser. In the same way the server can send the files to many client computers at the same time, allowing multiple clients to view the same page simultaneously.

Common features

The rack of web servers hosting the My Opera Community site on the InternetAlthough web server programs differ in detail, they all share some basic common features.

HTTP: every web server program operates by accepting HTTP requests from the client, and providing an HTTP response to the client. The HTTP response typically consists of an HTML document, but can also be a raw text file, an image, or some other type of document (defined by MIME-types); if some error is found in client request or while trying to serve the request, a web server has to send an error response which may include some custom HTML or text messages to better explain the problem to end users.

Logging: usually web servers have also the capability of logging some detailed information, about client requests and server responses, to log files; this allows the webmaster to collect statistics by running log analyzers on log files.

In practice many web servers implement the following features also:

Authentication, optional authorization request (request of user name and password) before allowing access to some or all kind of resources.

Handling of not only static content (file content recorded in server's filesystem(s)) but of dynamic content too by supporting one or more related interfaces (SSI, CGI, SCGI, FastCGI, JSP, PHP, ASP, ASP .NET, Server API such as NSAPI, ISAPI, etc.).

HTTPS support (by SSL or TLS) to allow secure (encrypted) connections to the server on the standard port 443 instead of usual port 80.

Content compression (i.e. by gzip encoding) to reduce the size of the responses (to lower bandwidth usage, etc.).

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.

The origin of the content sent by server is called:

static if it comes from an existing file lying on a filesystem;
dynamic if it is dynamically generated by some other program or script or Application Programming Interface called by the web server.
Serving static content is usually much faster (from 2 to 100 times) than serving dynamic content, especially if the latter involves data pulled from a database.

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).
For a static request the URL path specified by the client is relative to the Web server's root directory.

Consider the following URL as it would be requested by a client:

http://www.example.com/path/file.html
The client's web browser will translate it into a connection to www.example.com with the following HTTP 1.1 request:

GET /path/file.html HTTP/1.1
Host: www.example.com
The web server on www.example.com will append the given path to the path of its root directory. On Unix machines, this is commonly /var/www/htdocs. The result is the local file system resource:

/var/www/htdocs/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.

Performances
Web servers (programs) are supposed to serve requests quickly from more than one TCP/IP connection at a time.

Main key performance parameters (measured under a varying load of clients and requests per client), are:

number of requests per second (depending on the type of request, etc.);
latency response time in milliseconds for each new connection or request;
throughput in bytes per second (depending on file size, cached or not cached content, available network bandwidth, etc.).
Above three parameters vary noticeably depending on the number of active connections, so a fourth parameter is the concurrency level supported by a web server under a specific configuration.

Last but not least, the specific server model used to implement a web server program can bias the performance and scalability level that can be reached under heavy load or when using high end hardware (many CPUs, disks, etc.).

Load limits
A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 60,000, by default between 500 and 1,000) per IP address (and IP 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 overloaded and thus unresponsive.

Overload causes

A daily graph of a web server's load, indicating a spike in the load early in the day.At any time web servers can be overloaded because of:

too much legitimate web traffic (i.e. thousands or even millions of clients hitting the web site in a short interval of time);
DDoS (Distributed Denial of Service) attacks;
Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
Internet web robots traffic not filtered / limited on large web sites with very few resources (bandwidth, etc.);
Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
Web servers (computers) partial unavailability, this can happen because of required / urgent maintenance or upgrade, HW or SW failures, back-end (i.e. DB) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.

Overload symptoms
The symptoms of an overloaded web server are:

requests are served with (possibly long) delays (from 1 second to a few hundred seconds);
500, 502, 503, 504 HTTP errors are returned to clients (sometimes also unrelated 404 error or even 408 error may be returned);
TCP connections are refused or reset (interrupted) before any content is sent to clients;
in very rare cases, only partial contents are sent (but this behavior may well be considered a bug, even if it usually depends on unavailable system resources).

Anti-overload techniques

To partially overcome above load limits and to prevent overload, most popular web sites use common techniques like:

managing network traffic, by using:
Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns;
HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns;
Bandwidth management and traffic shaping, in order to smooth down peaks in network usage;
deploying web cache techniques;
using different domain names to serve different (static and dynamic) content by separate Web servers, i.e.:
http://images.example.com
http://www.example.com
using different domain names and/or computers to separate big files from small and medium sized files; the idea is to be able to fully cache small and medium sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings;
using many Web servers (programs) per computer, each one bound to its own network card and IP address;
using many Web servers (computers) that are grouped together so that they act or are seen as one big Web server, see also: Load balancer;
adding more hardware resources (i.e. RAM, disks) to each computer;
tuning OS parameters for hardware capabilities and usage;
using more efficient computer programs for web servers, etc.;
using other workarounds, specially if dynamic content is involved.