This question already has answers here:
What is the difference between application server and web server?
(28 answers)
Closed 4 years ago.
As a layman, how do I understand the difference between web server and application server ? If you could give an example using a Java based web app in very "simple" terms that would be really great..
Also when we say Weblogic, is it a web server only ?
A web server is something that handles HTTP requests and responses.
An application server (like WebLogic, WebSphere, JBoss AS, Glassfish, etc) usually includes a web server, but also adds a lot more features. The most important is that it manages objects. Whether they will be servlets (Servlet container), EJBs (ejb container), JMS listeners, etc.
Webserver can execute only web applications i,e servlets and JSPs and has only a single container known as Web container which is used to interpret/execute web applications
Application server can execute Enterprise application, i,e (servlets, jsps, and EJBs) it is having two containers 1. Web Container(for interpreting/executing servlets and jsps) 2. EJB container(for executing EJBs). it can perform operations like load balancing , transaction demarcation etc etc
I would say definitions vary. In the generalized context, a Web Server is a server that can receive incoming web-requests and have knowledge about how they should be handled and responded to. Some requests are static (html files, images etc), some are dynamic. In the case of dynamic requests, the web server will know where to route handling of the request, could be a JSP page or a java servlet, a PHP script, a perl CGI script etc etc.
While the "web server" in this context executes the dynamic handler, it is not considered to include any supporting middleware features for the dynamic handler.
An Application Server, by contrast, is a general execution environment that offers some type of middleware tier support. Examples are EJB containers or the .NET framework built into Windows (in where Windows in itself is an "application server"). There is no inherent requirement that an application-server have anything to do with web requests (although many do), it's just a general execution context and container for any type of application that offers some sort of additional middleware support.
In a purely web-centric context, many people will draw the line at static vs dynamic content. In this definition, a "web server" can only handle requests for static information itself and it will pass on requests for dynamic content to the "application server". For example, Apache httpd is a web server and Tomcat is an application server. IIS is a combination of both. In the Java web world, an application server can be either a servlet container (like Tomcat), or a full blown Java EE container (like JBoss, WebLogic or WebSphere) that provides the Java EE middleware support (EJB) container in addition to the servlet container.
And adding to previous answers, Weblogic is app server and not only web server.
Basically if we say the major difference between Web Server & Application Server, is the protocols on which these servers work.
Web Server -- it works on protocols like HTTP & HTTPS. Example of this server is Apache. For web server you use JSP, Servlet.
Application Server -- it works on any protocol. example is JBOSS. On application server we host EJB, web service or any business Logic.
Related
Currently, I am learning about Java web development.
A lot of it seems to simply be configuration to me, and I feel that my understanding is superficial because I only see the configuration (i.e. define your servlets and their mappings in the web.xml file, make custom Servlets by extending the HttpServlet class, instantiate Tomcat in the main method, etc.)
I want do know a bit more about what is actually going on under the hood - so I am in some need of some guidance.
To this end, I have done some cursory reading on Tomcat and servlets from the following links:
What is a servlet
Difference between embedded and not embedded
Tomcat docs
So what I think I understand from this is that the servlets sit inside the Tomcat instance (a servlet container) and Tomcat handles all of the receiving all of the requests of the client and relaying them to the servlets. The servlets process the requests, send back a response, which Tomcat then sends back to the client. I suppose in the local setup I have, my machine would both be acting as the client and server.
Given the above I want to know:
How I can directly see and monitor the client's sending the request to Tomcat and verify that Tomcat has received the request? Essentially, how can I verify that this networking side of things is happening due to some implementation by Tomcat?
How does Tomcat parse the request information and send it to the servlets?
Is Tomcat a servlet container or a web server? Are these the same thing?
In the answer given in the second link regarding embedded vs. non-embedded, the answer states that an embedded server looks like a regular java program. Does this mean that for an embedded server, the server is in the java application while the web application is inside the server in the non-embedded case? Like the containment relationship is reversed? What does containment mean in the first place here?
Apologies for the numerous questions and thank you for helping to clarify.
2. How does Tomcat parse the request information and send it to the servlets?
The Servlet specification explains that in detail. The spec is surprisingly easy to read; I suggest giving it a go.
As a simplified overview…
The job of a Servlet container is to process the incoming request, which is just a bunch of text. The Servlet container pulls out the various pieces and assembles them into a request object.
Likewise, the response produced by your servlet is packaged up as a response object. The Servlet container's job is to use all the info contained in that object to create a stream of text to be sent back to the client web browser.
The whole point of Servlet containers is to relieve the servlet-writing programmers of the need to know much of the details of HTTP and how to make a server. The Servlet container does all that work. In other words, the great thing about Servlet technology is that you the programmer need not ask this # 2 question of yours!
3. Is Tomcat a servlet container or a web server? Are these the same thing?
(a) both, (b) no.
No, servlet containers and web servers are two different kinds of software.
A web server handles:
listening for incoming connections from clients (web browsers, etc.)
sending response back to the client
A web server handles all the network traffic.
A Servlet container provides an environment in which relatively small chunks of code (servlets) can process a request and formulate a response. The small servlet does not have to handle network traffic, launching & shutting down, security, and all the other responsibilities of a full server. That explains the "-let" in "Servlet".
Your servlet you write plugs into a Servlet container. The container communicates with the web server, receiving each request passed by the web server, and passing to the web server the response produced by your servlet. When a request arrives, the container invokes your servlet.
Your servlet remains blissfully ignorant as to what particular Servlet container implementation is running, as long as it complies with the Jakarta Servlet specification. And your servlet remains blissfully ignorant as to the existence of web servers.
Some products, such as Tomcat & Jetty, can be composed of both a web server and a Servlet container.
Tomcat is composed mainly of three components: (1) Catalina, a servlet container, (2) Coyote, a web server, and (3) Jasper, a Jakarta Server Pages processor. See Wikipedia.
For most people's needs, the Coyote web server in Tomcat is a suitable web server. So you can use Tomcat as as all-in-one application server, handling both web traffic and servlets.
[web request] ➜ [Tomcat Coyote] ➜ [Tomcat Catalina] ➜ [your servlet]
Alternatively, some folks choose to use Tomcat only as a Servlet container, sitting behind a separate web server such as Apache HTTP Server. In such a case, Tomcat’s Coyote component goes unused. Instead, the separate web server handles client browser components, and processes incoming requests. If a request is asking for a static resource, the web server serves it out, without any involvement from Tomcat. If the request is asking for work that has been assigned to a servlet, then the separate web server passes the request on to Tomcat and its Catalina component. After your servlet produces a response, the response moves from Tomcat back to the external web server, which traffics the response onwards to the client web browser.
[web request] ➜ [Apache HTTP Server] ➜ [Tomcat Catalina] ➜ [your servlet]
4 … embedded vs. non-embedded …
Non-embedded is the classic situation, as originally envisioned when Servlet technology was first invented.
Back then, servers were few, expensive, and already in place permanently. The goal of Servlet technology was to make it easy for companies to keep those expensive servers busy by having many web applications running alongside each other.
Servlet technology allowed many different servlets to be running on one machine without stepping on each other, and without the programmers of each servlet having known anything about the other servlets being written. The Servlet container can stay up and running as servlets are deployed and un-deployed.
Fast forward, and we have cloud technology where servers are many, cheap, and convenient to create and destroy on-the-fly. So nowadays many people want to run their web applications separately, one web app per virtual machine or virtual service. Thus the need for embedded mode. We need an application that can be launched and shutdown on its own, to run one specific servlet (or multiple servlets meant to work together) without any other unrelated web apps.
One way to achieve this new goal is to package a web server and servlet container into a standalone Java app. A system administrator can launch and quit this standalone app like any other Java app, without knowing anything about how to configure an on-going web server and Servlet container.
I have made a Java Swing application, in the GUI the user can select the type of element and choose a date then the element's informations will be shown on a JTable.i used easyPHP to create the DB.
so what is the role of apache server in this case!
can i consider it like an application server ?
A Java swing application (AFAIK out of the box, for alternatives see below) is not available over HTTP/S (and is therefore not classified as a web application) and Apache is a web server (with features such as proxy, TLS terminator etc.). Therefore there would be no need for a web server such as Apache to front your Swing application.
Apache web server is not an application server for a Swing application per se. Although it can run applications in different programming languages such as php through loading of modules. It however does not run Java web applications.
An application server in a Java perspective would be Tomcat, Glassfish, JBoss, WebLogic etc. An application server hosts an application and could provide a set of services such as Naming, HTTP processing and so on.
Perhaps you are referring to Apache Tomcat instead of Apache Web Server. If so, you would be right on the mark as that is an application server for Java web applications.
If you would like to make your application available through HTTP and enjoy the myriad and expansive benefits of an application server, I would recommend you to rethink on using Swing and utilize a technology built over Java Servlets such as JSPs, Spring MVC and so on.
If you would still like to make the Swing application available through a web server (through HTTP/S) there are some solutions out there but I have not tried any of those. Please do a search on "Swing available on HTTP" in that case. I have also provided a link as well.
You can read up on Application Servers on this wiki link.
You can read up on an HTTP end point for a Swing application here.
This Apache is not used in your application. You installed easyPHP so Apache comes with that to provide PHP programming environment.
Moreover Apache is a web server. So any web based application can be deploy here. PHP is a web programming language sot it requires Apache or any other web server.
But your application is standalone developed with JAVA SWING. So you can stop Apache server and check everything is running fine or not.
I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.
Can someone confirm or clarify for me:
From what I can tell, Java EE web apps consist of a Servlet and/or JSP driven dynamic web page being fed back in the HTTP response, triggered by the Java EE server receiving a HTTP GET or POST request.
From what I can tell, Java EE web services also make use of Servlets as the web tier components, however a WS Servlet receives a SOAP message and validates the contents of those messages with whatever WSDL the Servlet is WARed with. The response is also packaged in SOAP and sent back to the requestor.
So, from what I can tell, both Java EE web apps and WSes use Servlets as the web components, with the only real difference being the protocol used (raw HTTP vs SOAP, which is an extension of HTTP).
This is the best I could come up with - am I right? Totally wrong? Close?
The biggest difference is not in how they are delivered, but in how they are used. Web applications are targeted to web browsers and usually serve full HTML-based applications . Web services, on the other hand, are purposed to serve raw data for another application to consume.
You are right, and servlets are just a means to connect the code at a given webapp context to a URI path. Whether the servlet is serving HTML or WS is inconsequential to the webapp container, it's just data with a MIME type being sent back.
You could also manage the same thing with a filter under Servlet 2.3 and later specifications. Spring does this, and has a very robust means of adding to the filter chain to support it.
If we are to separate our web server and app server, would we need java on both machines? I've had one coworker say to install jboss on both machines (seems to defeat the purpose if both machines have app server installed) and another says just install jboss on one and apache on the other (app server/web server).
I have the web project setup already and it uses servlets and JSPs. The JSPs display the content while the servlets do the action. The servlets receive requests and forward responses to the JSP. My question is how do I do this if the web server only has apache and therefore displays static content? I understand how to forward the requests from the web server to the app server but what about maintaining session state, is that done on the web server and if so how would it be done?
If the login page is html and the content after the login is html then how could I stop people from accessing the content if they haven't logged in?
The latter setup you describe, with Apache serving static content and forwarding requests for JSP/servlets onto the app server is the standard setup.
Session state is maintained as normal, your Java webapp on the app server sends the user back a cookie containing a JSESSIONID and when the user makes subsequent requests, Apache includes all request info (including cookies) in what it forwards to the app server.
The setup becomes a bit more complicated if you want to have Apache sit in front of and load balance requests to multiple JBoss instances, but it's still pretty easy to set up with mod_proxy_balancer.
Some links that might help you:
http://help.shadocms.com/blog/2009/how-to-setup-apache-with-jboss-on-a-shado-site.cfm
http://redlumxn.blogspot.com/2008/01/configure-apache2-and-jboss-422ga.html
There are many possibilities.
On web machine install just apache with mod_jk to redirect the requests to tomcat/jboss.
In this case you don't need java on this machine.
You can also separate your jsp container (e.g. tomcat/jboss) and your app server in this case you you will need to install java where you have your web container.
Generally where there is a need of higher security people combine the above mentioned possibilities. Thin web layer (apache + no java) + Web container (e.g. tomcat) + app layer (jboss/glassfish)
The first solution is normally the standard one.
Your scenario reminds me of SiteMinder. It was used to access control into our application. It has built in HTTP forwarding so from the user's perspective the browser talks to siteminder and siteminder talks to the real application. They both use session cookies and siteminder's called SMSESSION while the app's called JSESSIONID so there is no conflict.
A common deployment is to use Apache fronting servers to serve static content and forwarding requests for dynamic content to the JSP server. This is mainly for performance reasons, Apache being both faster at serving content and reducing the load on the JSP server.
I don't see any reason why you couldn't, for example, use IIS as the fronting server (removing Java from the equation), although with the wealth Apache modules and accompanying information about the configuration I think you might be making life difficult for yourself if you did.
Short answer - No.
Long answer -
It depends on the needs of your application. There are a few reasons why you would want to have the web server on a different physical machine:
You want to have the web server serve
the static content, and leave the app
server free to only process
servlet/jsp content
You wish to implement software based
load balancing. You would have the
apache server proxy requests to
multiple backing app servers
In your login example, the html page is served by apache, and the action of the html form points to your servlet for processing - so JBoss/java will still manage the session. Keep in mind that any static content you want apache to server will need to be present on the web server.