Need Help Defining / Understanding Java EE "Stack"

Question

LAMP is a stack defined from left to right (bottom to top) as Linux / Apache / MySQL / PHP, or in general you can look at it as an operating system / web server / database / scripting language. In general form, you can appear on any operating system, such as Windows instead of Linux, to get WAMP or add some other database, or even run another language than PHP, like Ruby. However, as a rule, you will only have one thing. One database, one OS, one web server, although your application can go from one stack to another with some finite number of changes.

I spent several years developing on the LAMP stack, and I read about JSF and the RichFaces and IceFaces component libraries. The whole idea of ​​creating a website user interface from components that support AJAX, and getting all kinds of great things like validation and promiscuous AJAX calls for free is really exciting.

The problem is that it's hard for me to understand what common components make up the Java EE stack. From my research, it seems that you have the following categories from which you can build a “Java EE stack” from:

Java EE Application Server - JBoss, Tomcat

Database - MySQL, Oracle

Database Abstraction - Hibernate, JPA

JSF Ajax-compliant component library - ICEFaces, RICHFaces

I feel like I'm definitely missing out on some things. I don't know where Seam, or Spring fits in. Also, does Hibernate use JPA for something? Or is JPA a full-featured API that I can easily use on my 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 this? From what I have learned, this does not look like part of the web services stack, but instead a tool used before deployment.

I read ICEfaces 1.8 from Rainer Eschen, and he presents this diagram as a kind of Java EE stack. I assume that AppFuse is related to Java EE, since XAMPP is related to LAMP. It's true? If someone can break the various parts in the diagram below and how they fit together, it will be very helpful.

ICEcube architecture diagram http://img191.imageshack.us/img191/336/icecubearchitecture.png

I know that these are many different questions. If I cannot ask what, in your opinion, I should know, do not hesitate to throw it away, or if I have formulated something incorrectly, PLEASE correct me! The Java EE stack and all the parts that go with it are scared, to say the least. I just want to get a good pen at a high level before I dive and start building something.

Thanks!

Answer 1

This diagram is NOT a Java EE stack .

This may be useful (or not :):

• Java EE is a runtime driven system. (LAMP does not have such problems.)

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

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

• Please note that Java EE web containers (servlets) are much simpler than the full Java EE stack, but are based on the same architectural approach.

• Java EE web components are (mostly) servlets and filters. On top of this architecture, various higher-order structures (such as Faces) are built. The Java EE Web container is relatively simple and very efficient. It is the closest to LAMP.

• Java EE enterprise components (supported by Java EE application servers such as GlassFish) are various component options without state, state, and persistent components (known as "Beans" in the Java environment).

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

• you (and / or some third-party library) provide components.

• The managed execution environment is primarily concerned with the care of "orthogonal" "corporate" "problems", such as transaction integrity, and you, the component / application developer, should be focused on the "business logic",

• Java EE manages the links, transaction boundaries, connectivity, and life cycle of your components.

• Links: the use of semantic links viewed at runtime through a namespace mechanism, such as JNDI and RMI; and dependency injection through declarative deployment descriptors.

• Life cycle: your components will have the necessary phases of start-up, operation, and shutdown. You can connect to these LC events and participate if necessary (usually not necessary). This formalized LC allows you to distribute and scale the architecture.

• Connectivity: Widely addresses incoming (clients) and internal (EIS) integration points. For clients you have web / RMI / JMS etc. This gives you the ability to synchronize req / rep semantics and asynchronous fire and forget. For the backend (in general), the JCA indicates connectors to other systems. JPA is a JCA specialization (not theoretically practiced) that specifically considers EIS databases with the JDBC user API.

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

Deployment Packages

Java EE systems are typically packaged as WAR (Internet only) or EAR (full stack).

Deployment descriptors

Recent Java EE specifications use zero-configuration operations with reasonable defaults (or trivial mappings). But it’s important for you to wrap yourself around everything in this and at some point, any serious Java EE application will require dealing with these artifacts at some level. (This is much simpler for web.xml, so don't worry.) This is a key aspect of the architecture. Understand this, and everything else is very clear.

Java EE uses indirection to do its magic. This is the issue that is addressed here:

We have components written by some third party (some time ago), and we must use them in our application. Deployment descriptors allow you to map your semantics to your application, for example. the name of the component or its semantics of the transaction to the semantics of the components. For example, you can open Acme-Logger as My-Very-Own-Logger. You achieve this by matching the name of the required environment with the component class. (The source component may have an annotation declaring its common name simply as a “registrar”).

Spring, in fact, came about because of severe pain in creating and maintaining these matching descriptors. Again, Spring is an alternative approach to container-based systems.

Containers

Theoretically, you should be able to connect the entire container to a compatible server, but the general idea is that you write your components for a universal container, for example. Java EE container. In any case, as you can imagine, Java EE application server vendors were not too keen on having a stack container plug-in API, as that would make their product a complete product.

Spring

Spring is actually the Java EE counter-inspector. This (or was) a lightweight container system for eliminating J2EE pain points (which was completely unreasonable without effective tools, given the complex architecture and deployment ceremony). In fact, the front of the servlet and the Spring container are an alternative to the full-blown Java EE glass. However, they can coexist.

Maven

Maven is a building tool. There is also ant. Or you can go to Gradle. There are Maven archetypes that allow you to get started with your Java EE core project effortlessly.

---

Sentence:

Start with (and stick to) a subset of Web containers. Jetty or Tomcat is the perfect container / server choice.

Check out WEB-INF / and web.xml. Write a simple HTTPServlet extension and play around with the web.xml features. Try to configure the filter or bind some parameters in the context of the web application. Learn these basics. Everything else is built on top of them. All.

In the servlet, examine the provided API. Find out the difference between applications, sessions, and context queries. The main thing in the web level. Learn how to redirect requests. Get HTTP headers, etc. Everything is built on them. Learn these basics.

Let's say you have a HelloWorld web application. Next step, try JPA and add perseverance to your project. Here you can try the Spring / Hibernate / Tomcat sample tutorial. Spring will configure a non-Java EE container for your business components (classes). Hibernate will take care of saving your data. A couple of new artifacts are introduced when you do this. Spring related xml files and JPA / Hibernate mappings. Get to know them and what it's all about.

You are almost ready. Finally, let's move on to the consideration of problems or perceptions. Here Java (imo) sucks, because it is too verbose, and this level is all about senseless repetition of the widget, the widget is placed here, etc.

In your simplest (and out of the box) you have a basic HTTPServlet and the ability to send back whatever you like. You can write your html in your code (a very bad idea) or use the template approach (Velocity, FreeMarker) or approach specialized components for presentation: JSP, Faces, etc. There will be literally dozens of frameworks (and approaches) for the presentation layer.

Hope this helps.

Answer 2

Yes, the chart you posted is scary, but you don't need to use all of this. This is not all necessary.

If you are new, keep it simple and create.

Here you need to create leggings to start with:

• Servlets and JSPs. This means deploying to a servlet / JSP engine such as Tomcat or Jetty. Servlets are HTTP listeners that process incoming requests, interact with the base classes to execute them, and route the responses to the corresponding next view.
• JSP is a template solution for generating HTML. You should only write using JTL, the standard JSP tag library. There are no scripts.
• HTML, CSS and JavaScript for the user interface. You need them for web interfaces.
• JDBC to access the relational database.

What is it. You can go a very long way with just that.

I like Spring, but it's a lot to learn for the first time. Make a site or two without it. You will understand things better and appreciate that Spring does more for you.

You do not need JSF. I would argue that this is a technology in decline. One JSF / Faces application that I personally saw in person. You can load the page with a sundial. I do not see a big winner in this, despite the fact that it was touted as the Java EE standard. Are you going to run JSF in the mobile interface? I do not think so.

User interfaces are written using HTML, CSS and JavaScript to work with services on the rear panel. These services can be REST-ful servlets.

Hibernate is an object-relational mapping technology. If you do not have an object model, you do not need Hibernate. If you have a simple one-to-one relationship between objects and tables, you don't need Hibernate. If you like stored procedures as an interface in your relational database, you don't need Hibernate. If you don't mind writing a little SQL and matching the results, you don't need Hibernate. The same for JPA - Hibernate is one way to implement JPA, which took a lot of time from Hibernate.

Start with them and create. If you try to find out all the materials that you indicated immediately, you will never get anywhere.