Which applications are better implemented with Java EE and Java SE?

Forgive me if the next question is a bit vague or naive. This was inspired by some discussion in another thread that again sparked my interest in Java EE.

Over the years, I heard little bits of it and even took a program course that covered some EJBs. Nevertheless, I understand that so far I know almost nothing about this and what it was used for.

So, I have two questions: first, if I am developing a web application server, what requirements will lead me to choose Java EE and Java SE? Pretty much depends on the application I want to deploy, or are there fundamental aspects of Java EE that make it better for any application server?

My second question: what are known Java EE applications in deployment? Are there any open source sources?

Thank you very much.

+4
source share
3 answers

If you can implement your application using nothing more than servlets, JSP, and JDBC, you do not need a full Java EE stack. These three contain a subset of the full stack.

In addition to servlets, JSPs, and JDBCs, the full Java EE stack includes EJBs (Distributed, Transactional, Lifecycle-Driven Components), JPA for persistence, JMS for messaging, JNDI for naming and directory services, etc. If you need these elements, definitely use Java EE and a full-fledged application server.

The application server specification is Sun's direction because they wanted to create a market in which there were several competitors, including themselves. They succeeded quite nicely: now we have WebLogic, WebSphere, JBOSS, Glassfish, OpenEJB, Geronimo and other application servers.

But this is not 100% necessary. For example, Microsoft.NET has nothing but the IIS web server and underlying operating system. They assume that you are running Windows and .NET, so they are not trying to abstract the same things as Java EE.

If you prefer Spring to Java EE, you can write enterprise applications without using anything other than Spring plus Tomcat or another servlet / JSP engine. In this case, you do not need a full Java EE application server.

+8
source

In practice, you will almost never develop a web application on top of pure Java SE. Java SE itself is suitable for graphical desktop applications or text-based command-line utilities.

If you want to create a web application similar to the ones you also create, for example. PHP or RoR, the least used is the so-called Servlet container . They all run on top of Java SE and provide you with servlets and JSP pages from Java EE. Notable examples are Tomcat and Jetty.

However, most web applications require more than those Servlet containers offer. Almost always requires a web framework (e.g. JSF, Struts, Wicket, Tapestry, Spring MVC), some ORM framework (usually Hibernate, but there are some alternatives like EclipseLink) and a transaction manager (JoTM, JBossTS, Atomikos). Finally, most people also prefer to use a container for dependency injection and a higher level of transaction management (for example, the main container Spring, OpenEJB, Weld).

All this, however, requires developers to create and maintain their own software stack. All the different things that I mentioned need to be downloaded separately, and they may or may not be compatible with each other due to common dependencies in different versions.

It uses Java EE.

Java EE offers you a single infrastructure that gives you all of the above in one package. You can download it in one package and upgrade it in one package. As a rule, parts work better together than creating the stack yourself.

You can compare this a bit with downloading a full Linux distribution, such as Ubuntu, or create your own Linux system from scratch, starting from the kernel.

In the old days, Java EE (called J2EE at the time) was a heavyweight, expensive, closed source and ivory tower and managed by a vendor. Currently, Java EE is very lightweight, free, open source, and mainly based on what has been proven to work in practice.

Although for many Java EE implementations it considers that you are not paying (in terms of memory or startup time) for what you are not using, the current Java EE specification has defined a smaller "profile" of Java EE with all that is accepted that a typical web - the application does not need. This is called a web profile . There is no really compelling reason for the end users to explicitly opt for a web profile, but for the people creating the Java EE implementation, this is a huge win because it is much easier to implement.

Finally, almost all parts of Java EE are available separately, so you can also create your own stack entirely consisting of Java EE elements. This, however, is not so common, since there are very few advantages compared to using the existing Java EE implementation.

+2
source

Java EE is really just built on top of SE, so you would choose EE when you had a web application that needed a library or feature that exists in EE. EE is better if you need additional services. (EE is the guitar and the case. SE is just the guitar.)

+1
source

Source: https://habr.com/ru/post/1333723/


All Articles