Need Help Defining/Understanding the Java EE "Stack"

Question

LAMP is a stack defined from left to right (bottom to top) as Linux/Apache/MySQL/PHP or generically you can look at it as Operating System/Web Server/Database/Scripting Language. In the generic form you can pop in any operating system, such as Windows instead of Linux to get WAMP or put in some other DB, or even run some other language other than PHP, like Ruby. However, generally you'd only have one of each thing. One database, one OS, one web server, though your application might transition from one stack to another with some finite amount of changes.

I've done a few years of development in the LAMP stack, and I've been reading about JSF, and the component libraries RichFaces and IceFaces. The whole idea of building the website UI out of AJAX enabled components, and getting all sorts of nifty things like validation, and the messy AJAX calls for free is really exciting.

The problem is I'm having a hard time understanding what generic components make up a Java EE stack. From my research, it seems like you have the below categories from which to build a "Java EE stack" out of:

Java EE Application Server - JBoss, Tomcat

Database - MySQL, Oracle

Database Abstraction - Hibernate, JPA

JSF Ajax-enabled Component Library - ICEFaces, RICHFaces

I feel like I'm definitely missing some things. I'm not sure where Seam, or Spring fit into this. Also, is Hibernate something that uses the JPA? Or is the JPA a fully featured API that I can easily use on its own? Where do containers fit into this? Can I go out and get a container to run on my Java EE application server? Also, where does Maven fit into all of this? From what I've gleaned it doesn't seem like a part of the web service stack, but instead a tool used before deployment.

I've been reading ICEfaces 1.8 by Rainer Eschen and this diagram is presented by him as a sort of Java EE stack. My guess is that AppFuse is to Java EE as XAMPP is to LAMP. Is that true? If someone could break down the various pieces in the below diagram and how they fit together, that would be super helpful.

I know these are a lot of varied questions. If I've failed to ask something you think I should know, feel free to throw it out, or if I've stated something incorrectly, PLEASE correct me! The Java EE stack, and all the parts that go together with it, is intimidating to say the least. I just want to get a good handle on the high level view before I dive down in and start building anything.

Thanks!

Overcautious

Prepare for a long road of learning. Each of these layers is supposed to simplify the layer below it, but any time you need to do anything non-trivial you will proabably have to dig down to a lower level of abstraction. There are always leaks in the abstractions. I'm not saying they always suck, but some days I just feel like throwing away the whole stack and doing C/CGI/flat files. – Frenchman

PHP can start looking pretty good.... – Allynallys

This is more of a discussion than a programming question (about code). Voting to move it to programmers, which is more appropriate. – Malacca

Answer 1

That diagram is NOT a Java EE stack.

This may be helpful (or not:):

• Java EE is a managed runtime system. (LAMP has no such concerns.)

• Java EE uses a component-container general architecture (LAMP does not define an explicit component container API)

• Application servers such as JBoss, Glassfish, etc. provide the Java EE container. (Tomcat does not support the full Java EE stack. Tomcat and Jetty provide only the web container (or the web profile per latest specs.))

• Note that Java EE web containers (Servlets) are much simpler than the full blown Java EE stack, but are based on the same architectural approach.

• Web components of Java EE are (fundamentally) Servlets, and Filters. Various higher order frameworks (such as Faces) are built on top of this architecture. The Java EE Web container is both relatively simple and very effective. It is the closest thing to LAMP.

• Enterprise components of Java EE (supported by Java EE Application Servers such as GlassFish) are various flavors of stateless, stateful, and persistent components (known as "Beans" in Java land).

• Hibernate is an ORM and is redundant in context of full Java EE (e.g. EntityBeans). Typically, JPA is used with Web-Container "Java EE" systems to connect to a backend JDBC compliant RDMBS. Oracle, MySQL, whatever.

• you (and/or some 3rd party library) provide the components.

• The managed runtime is primary concerned with taking care of "orthogonal" "enterprise" "concerns" such as transactional integrity, and you, the component/application writer, are supposed to be focused on the "business logic".

• Java EE manages references, transaction boundaries, connectivity, and life-cycle of your components.

• References: Using semantic references looked up at runtime via a namespace mechanism aka JNDI and RMI; and dependency injection via declarative deployment descriptors.

• Life-cycle: your components will have proper startup, work, and shutdown phases. You can hook into these LC events and participate if necessary (typically not necessary). This formalized LC allows for the distribution and scaling of the architecture.

• Connectivity: broadly addresses incoming (clients) and internal (EIS) integration points. For clients you have the web/RMI/JMS, etc. This gives you sync req/rep semantics and async fire and forget. For backend (in general) the JCA specifies connectors to other systems. JPA is a specialization of JCA (in theory not practice) that specifically addresses database EISs with JDBC user API.

• Transactions: declarative means to apply transaction semantics to specific methods of a component. This can be done at design time (via annotations) or at deploy time (via XML).

Deployment packages

Java EE systems are typically packaged as either WAR (for the web only) or EAR (for the full stack).

Deployment descriptors

The latest specs of Java EE favor zero-config operations with sensible defaults (or trivial mappings). But it is important for you to wrap your head around what this is all about and at some point, any serious Java EE app will require dealing with these artifacts at some level. (It is much easier for the web.xml, so don't freak out.) It is a key aspect of the architecture. Understand this and everything else is very clear.

Java EE uses indirection to make its magic happen. This is the problem that is being addressed here:

We have components written by some 3rd party (some time ago) and we need to use them in our application. The deployment descriptors allow mapping of your application specific semantics e.g. name of component or its transaction semantics to the components generic semantics. For example, you may wish to expose a "Acme-Logger" as "My-Very-Own-Logger". You accomplish this by mapping the desired environment name to the class of the component. (Original component may have had an annotation declaring its generic name to be simply "the-logger").

Spring, in effect, came about because of the serious pain of the creation and maintenance of these mapping descriptors. Again, Spring is an alternative approach to container based systems.

Containers

Theoretically you should be able to plug an entire container into a compliant server, but the general idea is that you are writing your components for a universal container e.g. the Java EE container. In any event, as you can imagine, vendors of Java EE app servers were not too keen on having a pluggable container API for the stack as it would make their product a complete commodity.

Spring

Spring is actually a counter-thesis to Java EE. It is (or was) a light-weight container system to address the pain points of J2EE (which was entirely unreasonable without effective tooling, given the elaborate architecture and ceremony of deployment). In effect, a Servlet front end and Spring container are an alternative to a full blown Java EE stack. That said, they can co-exist.

Maven

Maven is a build tool. There is also ant. Or you can jump on the Gradle. Maven archetypes exist that allow you to get started with a basic Java EE project with little effort.

---

Suggestion:

Start with (and stick with) Web-container subset. Jetty or Tomcat are fine choices for the container/server.

Get to know WEB-INF/ and web.xml. Write a simple HTTPServlet extension, and play around with features of the web.xml. Try setting up a filter, or, bind some parameters into the web-app context. Master these fundamentals. Everything else is built on top of these. Everything.

In the servlet, explore the API provided. Get to know the difference between application, session, and request "contexts". A key matter in the web-tier. Learn how to redirect requests. Get http headers, etc. Everything else is built on these. Master these fundamentals.

Lets say you have your HelloWorld web-app up at this point. Next step, try JPA and add persistence to your project. Here is where you can try a Spring/Hibernate/Tomcat tutorial example. Spring will setup the non-Java EE container for your business components (classes). Hibernate will take care of persisting your data. Couple of new artifacts are introduced when you do this. Spring related xml files and the JPA/Hibernate mappings. Get to know these and what it is all about.

You're almost done. Finally, lets turn to the view or presentation concerns. This is where Java (imo) sucks as it is far too verbose and this tier is all about mindless repetition of put widget here, put widget there, etc.

At its simplest (and out of box), you have the basic HTTPServlet and ability to send back whatever you feel like it. You can write your html in your code (a very bad idea), or use a template approach (Velocity, FreeMarker), or step up to the specialized components for presentation: JSP, Faces, etc. There are literally dozens of frameworks (and approaches) out there for the presentation tier.

Hope this helped.

Dogmatics

Thanks so much for all the insight. You really took the time to answer all the questions that I asked! – Overcautious

I had another quick question. What do you gain, or lose, by going with a web container instead of going for the full blown application server? – Overcautious

You lose a sub-set of the stack i.e. EJBs. The web-container of JEE also (effectively) only provides you with HTTP based connectors (i.e. no RMI, or JMS). Typically this is fine for a large sub-set of apps out there. Are you building a web-app? Go with JEE-Web unless you have specified JEE requirements. – Dogmatics

Answer 2

Yes, the diagram you posted is intimidating, but you need not use all that stuff. It's not all necessary.

If you're new, keep it simple and build up.

Here's the rock-bottom, must-have items to start with:

1. Servlets and JSPs. This means deploying on a servlet/JSP engine like Tomcat or Jetty. Servlets are HTTP listeners that handle incoming requests, collaborate with back-end classes to fulfill them, and route the responses to the appropriate next view.
2. JSPs are a templating solution for generating HTML. You should only write these using JSTL, the JSP standard tag library. No scriptlets.
3. HTML, CSS, and JavaScript for the UI. You need these for web-based UIs.
4. JDBC for relational database access.

That's it. You can go a very long way just with these.

I love Spring, but it's a lot to swallow the first time. Do a site or two without it. You'll understand things better and appreciate what Spring does for you more.

You don't need JSF. I'd argue that it's a technology on the decline. The one JSF/Faces app that I saw personally absolutely s*cked. You could time the page load with a sundial. I don't see it as a big winner, in spite of the fact that it's touted as a Java EE standard. Are you gonna run JSF on a mobile UI? I don't think so.

UIs are written using HTML, CSS, and JavaScript talking to services on the back end. Those services can be REST-ful servlets.

Hibernate is an object-relational mapping technology. If you don't have an object model, you don't need Hibernate. If you have simple one-to-one relationships between objects and tables, you don't need Hibernate. If you like stored procedures as an interface into your relational database, you don't need Hibernate. If you don't mind writing a little SQL and mapping the results, you don't need Hibernate. Ditto for JPA - Hibernate is one way to implement JPA, which took a great deal from Hibernate.

Begin with these and build up. If you try to learn all the stuff you cited all at once you'll never get anywhere.

Allynallys

Vote +1. Good answer. In the JEE world KISS is definitely something to live by. I've done a lot of work in JEE and if there's anything I would recommend it's being very careful about adding technologies and APIs. One of JEE's weaknesses (IMHO) is the 1001 APIs all trying to tell you how much easier they will make JEE. Most of them are not that good or very limited in scope and I've seen a lot of pain resulting from things that promise to give you lots for free. Spring and Hibernate are two solid foundations to work from and cover pretty much everything. Start with them. – Retro

Spring is a solid foundation; I don't agree on Hibernate. – Allynallys

I had another quick question. What do you gain, or lose, by going with a web container instead of going for the full blown application server? – Overcautious

Easier deployment - less set-up to deploy a WAR package. – Allynallys