I've a small doubt in my mind; could anyone please clarify me is the Tomcat web server or Web container?
It's both a web server (supports HTTP protocol) and a web container (supports JSP/Servlet API, also called "servlet container" at times).
As mentioned above, Tomcat is both a web server and a web container, but it's not really meant to function as a high performance web server, nor does it include some features typical of a web server. Tomcat is meant to be used in conjunction with the Apache web server, where Apache manages static pages, caching, redirection, etc. and Tomcat handles the container (web application) functions. You'll often hear the phrase "Apache Tomcat" together, which is both a proper attribution of the Tomcat project (as part of the Apache Foundation), but also appropriate as a label, as they're usually used together as a package.
If you don't have an high performance server requirements and/or want to embed a relatively simple web server with container functionality, Tomcat is fine for that (and probably the easiest embedded web container to work with, comparable with Jetty). Interestingly, the Catalina class used as the main Tomcat engine is actually a subclass of the Embedded class that can be used in a standalone web application.
A web server is any program that accepts incoming HTTP connections.
Related
I know that Tomcat is a web server but why it is not an application server?
Any server needs to follow some specification. What is that spec?
Is it possible for apache to make the tomcat application server?
Also I have read in a blog that the tomcat do not have some lib to act as an application server. What are those libs?
Thanks
I've heard once the following explanation I tend to agree with:
There is a spec of JEE (Java enterprise edition).
Formally you can think about it as a bunch of pdf-s describing the behavior of various technologies that comprise the JEE stack (for example: JMS, EJB, JPA, JPA, JSF, CDI and so on and so forth) as well as deployment models (EARs for example).
Implementors of Application servers have to implement all those technologies and offer interfaces that can be used by the application developers. So teams that stand behind WildFly (former JBoss), Geronimo, WebSphere, WebLogic and so on have read these specs and implemented everything in there.
Now, Tomcat didn't do that, they've only concentrated on (primarily) Servlets/JSPs. These are web technologies, so Tomcat can't be considered as an Application server that implements the whole JEE stack.
In general Tomcat (as well as Jetty, incidentally) should be more lightweight than full JEE compliant Application servers, it should start-up faster and it memory footprint should be smaller. So Tomcat/Jetty call themselves web servers.
I understand that this answer can be considered as speculation, but for me it makes a lot of sense.
Bellow is my perceive:
know that Tomcat is a web server but why it is not an application server?
Here, Application Server is specially for Java EE Server，Java EE is a huge specific collections for Enterprice Application Development，So Application Server should implement most specifics of these, while Tomcat(or Jetty) is only a Web Server(More accurately，Servlet Container)，they only implements the specific about Web(such as Servlet Spec(JSR340), JSP(JSR245)). Therefore，Application Server is stronger than Web Server，but Web Server is more lightweight and enough to satisfy most web applications.
Any server needs to follow some specification. What is that spec?
Of course，it depends on that your Server want to provide what services(functions)，these specifications can view here.
Is it possible for apache to make the tomcat application server?
I don't think apache will make tomcat to be an application server. Now, there are some popular Java EE Server: Jboss，WebLogic, etc. Not all enterprices need a heavyweight Application Server, on the contrary, most only need a lightweight Web Server。
Also I have read in a blog that the tomcat do not have some lib to act as an application server. What are those libs?
Tomcat only need care the specs about Web，and implements them.
Hope for your help.
Tomcat is used for running Java servlets, but it also has the webserver functionality built in, so it can run independently. However, I see several articles on how to integrate Apache Webserver with Tomcat? What's the purpose of doing this? Does it improve performance?
I am using Tomcat for serving WebServices.
Tomcat is a fine Servlet container, but there are a lot of things an Apache httpd can do better (easier and/or faster).
For example Apache can handle security, SSL, provide load balancing, URL rewriting etc.
You can also split content: you can have your Apache httpd to serve static content like images, static html, js etc. and leave the dynamic content (like servlets, jsp etc.) to Tomcat. This also has the advantage that a failure in Tomcat will not render your whole web site unusable / unavailable (just the servlets/jsp pages).
You can also separate the 2 and thus increase security: you can run Apache httpd on one server (which would be reachable on the internet) and direct it to another server running Tomcat, invisible from the outside.
Depends. Quite often a separate web server is used to distribute traffic or allow for extra functionality provided by Apache Web Server modules, which there are plenty. It can also be more performant, depending on your use case.
In short, even if Tomcat has the basic web server functionalities, Apache Web Server can also do other things Tomcat cannot.
I am newbie to EJB's. From all the reading and searching I have done till now, I understood the following:
EJB are the beans in which an applications business logic is written and maintained.
All EJB's are put into something called EJB container.
EJB container is nothing but a server side program written in order to manage EJB's, and to provide basic functionalities which are meant to be provided by EJB(viz, transaction management, security, collision free envt, etc).
1) My doubt is, does the so called EJB component reside in all application servers?
2) When we say EJB 2.1/3.0/3.1, does it mean that the new version of EJB container has been released?
3) Does the EJB container reside in web servers too?
Thank you.
You understood the EJB idea correctly.
Yes and no. Depends on what you understand as "Application server" (ambiguity described below in answer 3.)
When you say EJB 2.x/3.0/3.1 or so on, you're referring to a particular EJB specification which means that you're referring to a set of services this version supports. In other words - yes, it means that the EJB container must be in a given version.
First the specification is released (you can see the draft versions, vote for new features and basically participate in this process). Then, a reference implementation (RI) is written just to show that it's "doable" and you can use it right away. Then, different vendors might provide their own EJB containers which must conform to the particular EJB specification.
There are few different terms you need to be aware of. Just to be sure, we're talking about the same things:
Web server is a HTTP/HTTPS server like Apache HTTP Server which serves clients requests. This term is not only related with Java EE.
Web container is a Java EE term which can mean few things, but usually it refers to Servlet container and, let's say JSP container. Those containers are serving web clients, so that's why it's web container. Generally, web container have a web server within it (like in the case of Tomcat.) However, you can configure it so that the static resources will be server by only pure web server while dynamic content (your Java App, Servlets, JSP, etc.) will be server by your web container.
Application server is a vague name. In Java EE purists world it can mean only such server that provides all the Java EE services. Non-Java EE purists treats Application server just as an arbitrary server which consists of your application. According to this definition, you can call Tomcat (a web container and web server) an application server.
As you see, the vocabulary is not sharp, as one thing might mean few slightly different things. Moreover, since Java EE 6 we have profiles. This means that you can have Java EE Application Server conforming to the Web Profile or Full Profile. In such terms, just the Web Profile server should be treated as an application server.
Just as a summary - you can use EJB Container in Web Container. Take a look at OpenEJB or basically at project TomEE.
To answer your questions
Generally yes. Application server is generally referred to a server with has EJB container like Glassfish, Jboss etc. But you need make sure that the application server has EJB support.
YES
NO. Web servers or Web containers (Tomcat, Jetty etc ) serve a different purpose than EJB container. But all the application servers do have web servers (along with EJB containers. ).
The EJB container and web container (servers) server are different layers in a Java EE application scenario . Check this link for more info.
I have a standalone java application which uses java based TCP NIO to collect some information from various clients (not on web/HTTP but through some indigenously developed middleware). Now I have to develop a front-end for the users to perform a lot of querying through HTTP. So is there a way to put this application inside tomcat, so that servlets can invoke required functions on this application ???
The thing is it has to listen on that middleware outside tomcat too and at the same time service servlets inside tomcat. How to do this ??
Putting this application outside tomcat and using RMI is an option but I don’t want to do that.
Can embedding tomcat inside my application is an option ???
The brand-new Tomcat 7 has Embedded version for download.
Tomcat is big. You should try to embed Jetty, which is meant in order to make it possible.
http://jetty.codehaus.org/jetty/
I don't know about embedding Tomcat, but you can embed a servlet container inside your application using embedded Jetty. If what you want is to add an HTTP interface to an existing server, I think that's the way to go.
It also should be perfectly workable to launch your server's TCP listening components from a standard servlet in Tomcat. Then the servlet can call methods in your existing application directly, while it continues to listen to its usual TCP ports.
A third option is to write a servlet that just talks to your existing server in the same way other clients do.
The way you want to go, is to have an embedded web server to your existing application since you just need a little bit of web functionality.
Going the other way is possible. You can use servlet listeners to get started and stopped, and you need to take great care of any thread you start since Tomcat have no idea they exist.
As Traroth said, embedding Jetty is a much better option than doing the same with Tomcat. You have an example and a small tutorial in the Jetty website:
http://docs.codehaus.org/display/JETTY/Embedding+Jetty
You can always open the ports and listen manually if the requests aren't complicated.
Have you considered going the other way? That is embedding your application inside a web application?
Using spring you can instantiate your web application and then inject in into the appropriate web classes (e.g. struts2 actions).
This way you can deploy your web application into any web server that is preconfigured separate from your application.
If you do have to use Tomcat, you're best just making your application as a .war file which when Tomcat is ran will deploy your code. This can then talk to any RMI/middleware you like.
I'm not sure I understand your comment regarding memory spaces.
At a very basic level you have two choices:
Run your appication and the web
application in the same virtual
machine.
Run your application and
the web application in a different
virtual machine
If you take approach 1, you will be able to get instances of your applications classes from the servlets and call methods on them.
Embed tomcat / jetty inside your application. You will start your application normally through its main method. After starting your app you will need to create instances of the tomcat / jetty classes which will start up their own threads.
Embed your application inside a war file to be deployed on tomcat / jetty. Similar to the previous option instead you will need to start your application from a context listener.
If you prefer approach 2; start tomcat / jetty and deploy your web app and separately deploy your application. You'll now have two jvms running. To communicate between these two processes you'll have to use some form of socket communication: OutputStream/InputStream over sockets; RMI; JMX; JMS etc.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!