Java EE — is it just fluff or the real stuff?

StackOverflow https://stackoverflow.com/questions/169620

Question

I'm familiar with the LAMP stack and over the years have successfully deployed a handful of web sties based on it. I've used everything from Apache + modPerl, to PHP, to Ruby and Rails. With good use of caching my Rails site can sustain a pretty good load, but I'm not talking massive.

I never really liked Java as a language, or XML for that matter, and have very much been ignoring the whole Java EE side of things. For those who have had real and direct experience in both worlds: is there something super cool about Java EE that I'm missing, or is just a bunch of hot air? What justifies the high price of the proprietary app servers?

I'm not trolling here: I'm looking for concrete examples of things that Java EE really nails that are missing from modern LAMP frameworks, if such differences exist. (Modern = Rails, Django, etc). Alternatively pipe in with those things that LAMP really does better (fewer XML sit ups for one).

+++++ Update October 16, 2008

I'm sad to report that most of the replies here are not helpful, and simply fall into one of two categories: "It scales because here are three examples of large web sites" and "It scales because it is really actually much better than the LAMP stack".

I've done quite a bit of reading, and have concluded that Java EE only has one really good trick: transactions (thanks Will) and as for the rest you can succeed or fail on your own merit, there is nothing intrinsically in the environment to cause you to create a scalable and reliable web site, indeed Java EE has quite a few traps that make it easy to fail (for instance it is easy to start using session beans without realizing that you are paying now for quite a bit of JMS traffic that perhaps could have been avoided with a different design.)

Useful discussion

Was it helpful?

Solution

The key differentiator that Java EE offers over the LAMP stack can be boiled down to a single word. Transactions.

Most smaller systems simply rely on the transaction system supplied by the database, and for many applications that is (obviously) quite satisfactory.

But each Java EE server includes a distributed transaction manager. This lets you do more complicated things, across diverse systems, safely and reliably.

The most simple example of this is the simple scenario of taking a record from a database, putting it on a messaging queue (JMS), and then deleting that row from the database. This simple case involves two separate systems, and can not reliably be done out side of a transaction. For example, you can put the row on to the message queue, but (due to a system failure) not remove the row from the database. You can see how having a transaction with the JMS provider and a separate transaction with the database doesn't really solve the problem, as the transactions are not linked together.

Obviously this simple scenario can be worked around, a dealt with, etc. The nice thing with Java EE, though, is that you don't have to deal with these kind of issues -- the container gets to deal with them.

And, again, not every problem requires this level o transaction handling. But for those that do, it's invaluable. And once you get used to using them, you'll find the transaction management of a Java EE server to be a great asset.

OTHER TIPS

The big gun Java EE web servers (Jboss, WebSphere, WebLogic etc), and Windows Server/IIS/ASP.NET are truly in a different league in scalability and performance than your typical lamp stack.

My team is responsible for one of the largest telecomunications commerce sites in the united states, handling millions of hits per day (One of our databases is over 1000TB in size, to give you some perspective).

We use a combination of ASP.NET and WebSphere as well as SAP ISA (Which is also a Java EE solution) for different sections of our site, there is absolutely no way the LAMP stack could handle this kind of load without scaling to massive amounts of hardware....The .NET stack section handles the majority of the load and runs on only 32 servers.

We also don't do anything fancy, such as using a memcached type solution, or static HTTP cacheing...we do cache SOAP calls and database calls on the individual app servers, but no use of an in memory database etc...our platform can handle it so far.

So yeah, its apples to oranges to compare this kind of stuff to LAMP.

You can build really huge and scalable applications with Java EE, and it's widely used in enterprise computing.

But:

My experience with Java EE was pretty bad because it seemed like 90% of the work my team was doing was boilerplate and plumbing. Our productivity at the time was much, much lower than it could have been had we used a different technology stack.

Almost all the answers mention what it takes to build a Java EE web application. Let me mention another important consideration. Most enterprises have significant back-office requirements, where an enterprise app has to integrate with other apps. This can range from hooking up to some crufty old COBOL mainframe program, to a LAMP stack to a little Access app that some accountant whipped up at night, etc. Usually this means you will need some sort of messaging solution in order to get 2 or more apps to hook up together. In my experience, I've found the Java EE world stretches itself further to deal with these integration problems than your typical LAMP stack.

Amazon.com, ebay, google -- they all use a subset of Java EE and they are pretty successful. They all use servlets and JSPs

If you try to use EJB 1.1 or EJB 2.0, then the scalability is hit. Developer productivity is also reduced as a result of making unit testing harder.

With EJB 3.0, developer productivity and application scalability improves.

So, depending on what your application needs, use only those pieces of Java EE that makes sense for you. Do a sample POC(proof of concept) using only those pieces that you intend to use. This POC will show how well the application will work.

NEW Java EE application servers don't always need a lot of XML. They will let you use annotation to do dependency injection and database mapping.

More than 50% of all enterprise development happens on Java EE (when I say that, it is mostly using subset of the Java EE stack. someone might use stateless SESSION bean EJBs, someone might just JNDI, someone might use MESSAGE DRIVEN BEAN EJB).

Hope it helps.

The core of Java EE is simply a bunch of interfaces that have implementations provided by a container. Most applications do not use all of the Java EE specification.

There are two main aspects of the Java EE that people think of when they discuss it: EJBs and Servlets.

I have no experience whatsoever with EJBs. I use the Spring Framework and as such it provides all of the "plumbing and boilerplate" code referenced as in Ben Collins' answer. It provides all that we needed EJBs to do, and then some (transactions with database access is what we use its special features for, although we use its IOC container as well for the Servlet portion).

Servlets, however, are fantastic. They are a very good and proven technology.

The core of a Servlet is a request and response cycle: a user requests something, and the server intercepts the request and provides a response based on it. A chain of requests and responses can be kept track of by means of a Session for a single user.

As for the high price of proprietary app servers, I have no idea why the price is so high, but Apache Tomcat is a very good Servlet container and is free. We use Tomcat for testing and WebSphere for deployment (Websphere is provided by our client for the apps' use). Unfortunately it's only Websphere 6 (update 11, as we found out to our dismay, which doesn't have the fix for update 13 which enables JSTL functions to operate properly when contained inside a JSP tag), so we're forced to use Java 1.4x, not Java 1.5+.

There are also several frameworks (see the Spring framework referenced before for an example) that allow easy Servlet development. If you're just using this for HTTP/HTML, there are a large number of frameworks to easily aid you in this development.

Scalability and other matters aside, here's one simple thing that wasn't mentioned, which can be an advantage: it's Java.

  • There's a staggering amount of 3rd party libraries available for Java, both proprietary and open-source. Now, I'm sure there are huge free libraries for Perl, Ruby, PHP, etc. - but when it comes to commercial libraries for more niche application areas, they don't come close to Java (and .NET, and probably C++). Whether you need any special 3rd party libraries of course depends solely on what kind of application you are building.
  • I think there are more Java developers in the world than developers for any other platform. (Maybe I'm wrong but this is what I've heard sometimes.)

When choosing a platform in a commercial setting, either might turn out important.

In terms of scalability, Java EE gives you huge choices that you don't have with a LAMP stack, or RUBY. All of the choices revolve around N-tier applications, while most LAMP and ruby applications are 2 tier.

I'm developing an application, and plan on allowing people access to the API over the net. Java EE will allow me to easily scale the middle tier, without impacting the UI tier. As I add interfaces to my application, I can scale the middle tier very easily. A LAMP stack has no concept of this, built in.

So I have to interfaces, the web UI, and the SOAP API. Now I want a rest API. Okay...Build that interface to hit the middle tier as well.. and add more computers to the cluster.. or go multicluster doesn't really matter. This middle tier is all EJB, a faster protocol then SOAP in many ways.

Now let's say that I want to add the ability to SMS text my users. I also need to do this based on what they set, and that comes from the database. Scalability wise, I want to disconnect the actual sending of the text, from the realization the applications wants to send it. This screams JMS. I can use a Timer Bean to go off every X amount of time, and figure out what messages need to be sent, and put each message into JMS. Now I can manage the queue and how many processors are working on it etc. I can see how many texts are going out. I can even put the receivers on another box, resulting in little impact on my other servers performance wise.

Scaling wise, I can see which of my EJB's are getting hit the most, and add more resources to those, while removing resources form others. I can do that with the JMS queues, and every other part of the Java EE stack of technologies. Not only do I get scalability, I get management of my servers resources.

Since LAMP and Ruby don't yet have a JMS like queue for async processing, or the ability to easily put business logic in a separate tier they can be harder to scale with multiple interfaces. What do you have to do rip out the logic, and make it available to a different interface? Let's say that now you not only provide a Web UI, but a desktop UI, an IVR Interface and a SOAP interface for your website?

Java EE and other program languages must be treated just like any other tool. Yes, it's been used in enterprise environment and it takes good craftsmanship to get these tools to work "perfectly" and knowing when to use it. I'm currently working on a Mainframe environment and Java EE is used to some extent. If high-speed transaction is involved, Java EE would be my last choice. If multi-platform interoperability is needed, then Java EE, XML and Web Services would be more appropriate.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top