Which kinds of applications are better implemented with Java EE versus Java SE?

Question

Forgive me if the following question is a little vague or naive. It was inspired by some discussion in another thread, which re-piqued my interest in Java EE.

Over the years I've heard little bits and pieces about it, and even took a software engineering course that covered some EJB. However, I realize I still know almost nothing about it and what it's used for.

So, I have two questions really: first, if I'm designing a web application server, what kinds of requirements would lead me to pick Java EE versus Java SE? Does it largely depend 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 some well-known Java EE applications in deployment? Are there any that are open source?

Thanks much.

Answer 1

If you can implement your app using nothing more than servlets, JSPs, and JDBC, then you don't need the full Java EE stack. Those three comprise a subset of the full stack.

In addition to servlets, JSPs, and JDBC, the full Java EE stack includes EJBs (distributed, transactional, life cycle managed components), JPA for persistence, JMS for messaging, JNDI for naming and directory services, etc. If you need those items, by all means use Java EE and a full-fledged app server.

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

But it's not 100% necessary. Microsoft's .NET, for example, doesn't have anything other than IIS web server and the underlying operating system. They assume that you're running on Windows and .NET, so they don't try to abstract the same things that Java EE does.

If you prefer Spring to Java EE, you can write enterprise apps without using anything other than Spring plus Tomcat or another servlet/JSP engine. A full Java EE app server isn't necessary in that case.

Answer 2

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

If you want to develop a web application like the ones you also create with e.g. PHP or RoR, the least you would use is a so-called Servlet container. These all run on top of Java SE and give you the Servlets and JSP pages from Java EE. Well known examples are Tomcat and Jetty.

The majority of web applications however need more than what those Servlet containers offer. Almost always some web-framework is required (e.g. JSF, Struts, Wicket, Tapestry, Spring MVC), some ORM framework (typically Hibernate, but there are some alternatives like EclipseLink) and a transaction manager (JoTM, JBossTS, Atomikos). Finally, most people also like to use a container for dependency injection and a higher level of transaction management (e.g. the core Spring container, OpenEJB, Weld).

All this however requires developers to build and maintain their own software stack. All those different things I mentioned have to be downloaded separately and they may or may not be compatible with each other because of shared dependencies in different versions.

This is where Java EE comes into play.

Java EE offers you a one-stop framework that gives you all of the above in a single package. You can download it in one package and you upgrade it in one package. Typically the parts work better together compared with building a stack yourself.

You can compare this a little with downloading a complete Linux distribution like Ubuntu, or building your own Linux system from scratch starting with only a kernel.

In earlier days, Java EE (called J2EE back then) was heavy-weight, expensive, closed source and ivory tower and vendor driven. Nowadays Java EE is very light-weight, free, open source and mainly based on what has been proven to work in practice.

Although for many Java EE implementations it holds that you don't pay (in terms of memory or startup time) for what you don't use, the current Java EE specification has defined a smaller 'profile' of Java EE with things taken out that the typical web application doesn't need. This is called the web profile. For end users there isn't a really compelling reason to explicitly choose for the web profile, but for people creating a Java EE implementation it's a huge win since it's much easier to implement.

Finally, nearly all parts of Java EE are available separately, so you can also build your own stack completely consisting out of Java EE elements. This is however not as common, as there are very little benefits over just taking an existing Java EE implementation.