javajsfjakarta-eeicefaces

Need Help Defining/Understanding the Java EE "Stack"

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.

ICEcube Architecture Diagram

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!

Solution

  • That diagram is NOT a Java EE stack.

    This may be helpful (or not:):

    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.