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.
1
