11

I'm just trying to get started with Java EE and related concepts. However, I'm having some trouble understanding the relations between some technologies and the roles they play.

As far as I understand, a Java EE Servlet is a Java class that runs inside a server, and generates responses to requests (typically HTML responses to HTTP requests, though Servlets can theoretically serve any protocol).

My questions:

  • As far as I understand, I can either write a Servlet class directly, or I can use some technology like JSP or JSF, which will then generate/provide a Servlet for me. At any rate, the Java EE web container (e.g. Apache Tomcat) where I ultimately run my app will only see Servlets, and will not care how they were created (so Servlets are kind of a low level plumbing). Is that true?
  • If Servlets are kind of low-level, is there any reason to actually use Servlets directly? I have seen many tutorials that explain how to write a Servlet, but that seems rather unpractical. Is there any situation where writing a Servlet directly is better/preferred to using JSP or similar?
  • Finally, Servlets need a server to run in (e.g. Apache Tomcat). When reading about servers in that context, I've seen various names such as (Java EE) web container, or servlet container, or JSP container, or just Java EE server. Do these terms all mean the same, or is there a difference?

Thanks for helping me get started!

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
sleske
  • 81,358
  • 34
  • 189
  • 227

5 Answers5

14

When not using a MVC framework like JSF, Spring MVC, Struts, etc, you still need a servlet to do the basic request/response controlling job. The JSPs -while under the covers indeed being compiled to servlets- should be used as view only, not as controller.

I think your confusion is caused by the relatively huge amount of low quality tutorials about servlets where they are been used to print plain HTML by out.print() statements. This is in view of MVC utterly wrong. I'd suggest to start at our wiki page: https://stackoverflow.com/tags/servlets/info

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Ah, so the recommendation is to either use some MVC framework, or implement MVC "by hand" by using a JSP as the view, a Servlet as the controller and some other Java class as the model. Is that correct? – sleske May 17 '11 at 17:40
  • Yes, basically. For a simple website with, say, 4 pages/forms you can afford to create 4 specific servlets. But once you come to a point that you'd like to add (much) more pages and/or refactor all those servlets into a single front controller, it's not going to be trivial anymore (see also [this answer](http://stackoverflow.com/questions/3541077/design-patterns-web-based-applications/)) You'd really like to consider a MVC framework then which provides a Servlet (or in rare cases a Filter) as front controller. – BalusC May 17 '11 at 17:43
  • Thank you; that makes sense. BTW, awesome answer in the link you provided. – sleske May 17 '11 at 17:55
6

  1. JSP and JSF are presentation-layer technologies. While it is true that JSP's are compiled into servlets, and that you can even write plain Java code inside of a JSP, doing so is extremely bad coding style. In general, your JSP files should not contain any Java code, and should not do things like query your server's database or directly inspect request parameters. All of that should be done in a separate Servlet (or if using a web framework, then your framework's abstraction of a Servlet) prior to hitting the JSP.

  2. In the typical case, coding up a Servlet for every request you want to service is not practical. Most Java web frameworks completely abstract away the Servlet interface so that you can build a complete webapp without ever directly implementing a Servlet. However, there may be occasional unique cases where it is most effective to bypass a web framework and provide a Servlet that provides some special-case functionality.

  3. They're pretty close to the same, really. All of them are servlet containers. Some of them may also include other Java EE features beyond servlet support. Being a servlet container does not guarantee support for additional Java EE features, but being a Java EE container does guarantee support for servlets.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
aroth
  • 54,026
  • 20
  • 135
  • 176
5

When the container loads the servlet, no, it won't care much where it came from. That said, different containers handle this differently when it comes to things like dynamic loading and stuff like that, but I wouldn't worry much about it.

Servlets are low level. They're the base abstraction upon which all of the other Java EE web frameworks are based. In the "real world", most of the time, people will use some higher level framework rather than a raw Servlet.

That said, Servlets are still useful when you actually want to get to that "bare metal" (well as bare as Servlets get) interface to an HTTP request. For simple things, it's just easier to write a Servlet than stand up a bunch of framework jars and such.

As far as containers, the distinction is basically Java EE server vs Servlet container or server. Tomcat is NOT a Java EE server, it only handles the web portion of the Java EE stack. To confuse things, Java EE 6 now has a "web-profile", which is basically the Servlet stack, but whereas before a Servlet container couldn't be consider a "Java EE Server", now it can be a "Java EE Server - Web Profile".

Yea, I don't know what it means either.

The key difference is that the Servlet containers (Tomcat, Jetty, Resin) don't come bundled with the rest of the Java EE stack (notably EJBs), but have several other components that are part of the overall Java EE stack.

If you're just getting in to Java EE, I would pick a full boat container (like Glassfish) since a) you can, b) it's easy (GF is trivial to setup) and, c) you won't have to second guess what is or isn't included in your container vs whatever you're reading about requires. GF will have "everything" that is Java EE. It won't have Spring, for example, as that's not Java EE, but if it's in your Java EE book or web site article, GF will have it.

Later you can choose when you want the full kit or just want to use something like Tomcat or not.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Will Hartung
  • 115,893
  • 19
  • 128
  • 203
3

A lot of frameworks use servlets under the covers, but abstract them away from the end user. The idea is that servlets themselves are very low level, and the frameworks provide useful abstractions that allow the developers to focus on application design and business logic. I tend to agree with that, but there are hardcore developers who like to work at the servlet level.

Knowledge is power, to answer your second question. So its a good idea to know what servlets do; it can only help. If you ever need to augment your underlying framework, you might find yourself working at the Servlet level - you might do this to debug issues as well.

Servlets do run in servlet containers. There are technical distinctions between a servlet container and Java EE containers. You can have the former without the latter, but you can't have the latter without the former (I think). Servlets are one part of the Java EE stack. Other parts are things like JMS (messaging) and JMX (management extensions), among others.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
2

The frameworks like JSF, JSP, Struts etc internally depend on the servlet spec. These frameworks are built on top of servlets only.

Ayusman
  • 8,509
  • 21
  • 79
  • 132