Help with reasons why JEE is better than LAMP

I know this question is broad but I thought the EJB forum would be the best place to ask because you have the best understanding of the complexities of the JEE framework. I'm building a simple program on a small team that does some basic MVC type operations and displays them on the web through a servlet. Most of the team wants to use LAMP instead but instead of PHP they want to use Python. I'm trying to point out that if we develop in Java we'll have a statically typed language running in eclipse for much better error detection because of strong typing, Also java runs on anything with a JVM, has a strong community of supporters and is Open Source. Some of these qualities can be said of Python, however I do not believe python has the same community as Java.

And specifically to JEE vs LAMP, JEE has the advantage of a container which managers pooling, transactions, asynchronous calls, entity management and more. You also get a clear path of development IE there is a common way to lay your your framework and classes in a logical way so that you are learning best practices as you go. Not only that but full container enviroments like Glassfish have many features like java mail, java messaging, and java security. These are all standard technologies that provide avenues for further learning. Not to mention built in WSDL generation for SOAP with easy annotations to make an EJB a web service.

Can anyone think of more examples or help me with this? Their alternative to JEE6 is web2py running on Apache/Linux.

To compare LAMP with JEE is a bit of an apples-to-oranges comparison. LAMP does not include an app server, it only has the view layer (in the shape of PHP or Python). You wouldn't (and shouldn't) build an entire enterprise app that way, but have an app server in the background - which could be a JEE server.

Furthermore, like LAMP, JEE often runs on Linux, often uses the Apache web server, and often uses MySQL as the DB. So the comparison is only between PHP/Python as the view layer and a Java-built web layer. Since you'd use Java in the app server anyway, the question comes down to: do you want to maintain code in two languages? Does the team have the knowledge and inclination to do so?

Lastly, note that EJB has gone a bit out of fashion. Just because you're running JEE doesn't mean you necessarily would use EJBs - persistence is often handled via JPA directly.

J Nix
Greenhorn

Joined: Oct 10, 2011
Posts: 9

posted Nov 12, 2011 00:37:49

0

Tim Moores wrote:To compare LAMP with JEE is a bit of an apples-to-oranges comparison. LAMP does not include an app server, it only has the view layer (in the shape of PHP or Python). You wouldn't (and shouldn't) build an entire enterprise app that way, but have an app server in the background - which could be a JEE server.

Furthermore, like LAMP, JEE often runs on Linux, often uses the Apache web server, and often uses MySQL as the DB. So the comparison is only between PHP/Python as the view layer and a Java-built web layer. Since you'd use Java in the app server anyway, the question comes down to: do you want to maintain code in two languages? Does the team have the knowledge and inclination to do so?

Lastly, note that EJB has gone a bit out of fashion. Just because you're running JEE doesn't mean you necessarily would use EJBs - persistence is often handled via JPA directly.

Thank you, I'm nost sure what you mean about using Python as the view tier and Java as the web tier. Can you put those in examples so I know what you mean? Our team loves both Python and some of us Java and some both so it's a good mix we could find some one that wouldn't mind two languages like that.

Also could you expand on "EJB's are going out of fashion"? Where should we be putting our business logic? How do we handle asynchronous operations without EJB's? What about Stateful session management?

"LAMP does not have an app server" but can you load mods like mod_wsgi that run python on the apache server. couldn't an app be written using that server side Python code?

Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2409

posted Nov 12, 2011 01:06:42

1

I was actually talking more about PHP, as I'm not all that familiar with Python. PHP is geared very much towards the view layer, whereas Python is more of a general-purpose language.

As to EJBs, if it's a web app the logic can be triggered off servlets or whatever web tier technology you use. Async operations can be implemented by starting threads or via JMS. EJBs make a bit more sense if the client is a desktop app as HTTP request handling and session management wouldn't be available (although you could create a REST API for the desktop app to use, and thus be back to using HTTP).

Sure, you can run everything in the Apache using mod_php, mod_python and other such modules, but you'd generally want to separate web server and app server. The most common setup I've seen in the Java world is to use an Apache as the front for several Tomcats that run the actual application (assuming it's a web app). The Apache would handle SSL termination, load balancing between the Tomcats, and possibly serve some static files, whereas the app would run on the Tomcats.

J Nix
Greenhorn

Joined: Oct 10, 2011
Posts: 9

posted Nov 12, 2011 11:17:34

0

Such good information. I would love to just talk to you for an hour and steal your knowledge. What your talking about sounds like some pretty complex Servlets. I guess you could have some supporting classes that were just plain old java objects POJO's assisting the Servlet and just importing those classes into the servlet so that you could reference them. But then you'd have to instantiate them and they wouldn't be properly managed by the Container like tomcat wouldn't be able to pool them. Actually that sounds like a really bad idea because every time some one visited the webpage and called the server you'd be instantiating a new support class. 1 EJB could manage all of that.

I am going to have to disagree with Tim regarding EJB having gone out of fashion. I will admit back in the EJB 1.x and 2.x days, it was painful to work with and the likes of Spring/Hibernate sprang up and solved a lot of problems while for the most part making things less painful to deal with. In particular Hibernate.. I've not been a fan of the XML HELL formula of Spring back in the day, wiring up beans and such. But, most developers that moved away from EJB turning to Hibernate haven't given EJB 3.x a good look. Most of EJB 3.x is based off of Hibernate, and is by far the easiest ORM I've had the pleasure of working with the past couple of years. That said, it's dependent on JPA of course, and the argument would be better said that it's not that people have gone away from EJB more so they turned to JPA.. which EJB 3.x is basically an implementation of.

What you say about using JEE makes all the sense in the world. I've worked briefly with php and it's very much reminiscent of the first round with how JSP pages were built.. where by the form submits and href clicks would go directly to other JSP pages, tons of java/scriplet code inside JSP pages.. it was a nightmare to deal with and to this day I am still having a hard time understanding why many people prefer php over some of the better approaches of today. I've yet to dabble with python..it is on my todo list to learn, but ruby/rails is another one I worked with for about a year and couldn't stand it.. which as I understand is rare of a java developer to actually prefer java over ruby/rails.

What Tim means by using php/python i the view layer is simply the front facing portion of the overall application that people access.. they hit index.php or index.py or index.jsp and a page renders..a link on the page then routes to some python, php or java class.. this is the "view logic" or controller class on the view tier.. the web tier. You would write code here in whatever language you want to provide the html/css/javascript responses that the browser receives. However, the code behind it would call it to the logic tier..typically the EJB deployed app on a different server (tier). As JNIX said.. robust enterprise applications with heavy usage needs and such will benefit from what the ejb containers give you, and as you said too.. caching, secuirty, transactions, etc. But a lot of developers back in the JEE3/4 days found it cumbersome to deal with all the JEE requirements and moved to a simpler model.. something akin to just servlets, jsp pages using Struts or Spring MVC, and using JDBC directly, or hibernate to talk to the database. To this day most apps can get away with this. It's typically faster, easier to scale, and easier to manage, all while being much less complex. A store front end web site for example would probably be a good example of doing it this way. A large banking or stock market app may be better suited for a full scale enterprise deployment utilizing all that the containers provide. The really neat thing about JEE6.. is that you can bundle everything up into WAR files now and with annotations and such directly find and use ejbs in your servlets and resource (jersey rest) classes, without any JNDI lookup. They are easier to scale and you get the majority benefits of the full JEE6 stack, including async session beans which are handy for dealing with long running tasks while keeping your user interface smooth (typically async tasks would be initiated by some ajax request from a web page so the UI doesn't get locked while a long running task occurs).

Another web framework you might take a look at is Wicket. It's very slick with a little bit of a learning curve but has some great features. You'd still use JEE6 and take advantage of ejbs and such, but for the presentation tier Wicket handles a lot of the hard work for you with minimal effort, and you can get web page builders to actually build the web pages with only having to insert special tags that get replaced with dynamic content later.

J Nix
Greenhorn

Joined: Oct 10, 2011
Posts: 9

posted Nov 16, 2011 22:48:03

0

Thanks, I actually have a full JEE6 webstack implemented right now with JPA and a derby database, entity beans, DAO's, servlets, and jsp pages. All of that for a very simple task initially but I'm hoping it will be worth using this model as I add features. I like the separation of concerns, using eclipse, and annotations are amazingly simple. Now I'm exploring JSF for managing the view tier better. Hopefully I've not created a bloated overly complex design. I'm sure you could do it easier in some frameworks but I'm setting myself up to handle larger tasks in the future.