|
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
|
