Sudden Death Of Enterprise Projects?

It seems like the huge, data driven, projects are either somehow completed, or were replaced by standard solutions. Especially in tougher times, even big enterprises are interesting in saving money and build software in more pragmatic ways.

These are actually good news. Often (almost always) you can implement the same functionality with only a fraction of the originally planned resources, patterns, architecture, with a few passionated developers.

In the same time Java EE became leaner and leaner, so that it is particularly interesting for smallest projects. In the Java EE 6 release it is hard to find a superfluous artifact. Although projects became leaner, there is still need for transactions, persistency, remoting (e.g. over REST), and concurrency. Exactly that is already addressed by EJB 3.1 + JAX-RS + JPA 2.0.

The small / smallest projects in particular, are built with plain web container - with a considerable overhead. You have to install, sometimes implement, everything by yourself, without any benefit. You could argue that the result is leaner, but you should measure the results and compare it to a full "Java EE 5/6" stack.

I was asked in the recent few months, whether it is possible to install an EJB 3.1 container inside tomcat, just for out-of-the-box management of transactions / concurrency. You will find the answer here. On the other hand developers (I also) were surprised by e.g. Glassfish v3 incremental deployment capabilities - even method signature changes were recognized correctly. I'm already curious about JBoss 5.2.0 Java EE 6 capabilities...

Comments:

Hello Adam.
From your analysis, I rescue:

1. Enterprise Projects = Bloated projects. Still, lean, just what you need, projects are still "enterprise" in business sense. What I mean then is the project designers confused size with business level? Can we see that trend in tools that have a personal version, a professional one and an Enterprise one? Interesting.

2. Agree totally with your "lean" analysis. Lean does not mean "home built" but "just what you need". Lean should not only reduce the amount of code, or frameworks, or documentation, buy also the amount of work to be done.

Cheers!

Posted by William Martinez Pomares on November 04, 2009 at 03:40 PM CET #

@William,

"Enterprise Projects = Bloated projects" - this is the common perception. And sometimes they are bloated.

Nowadays, however, enterprise projects become more pragmatic, and so lean.

Btw. I never (except few times for the generation of some legacy adapters) used an Enterprise version of a tool in enterprise projects :-). Your framework / infrastructure should be so lean, that you should be able to develop it with any IDE you like.

thanks for your feedback!,

adam

Posted by Adam Bien on November 04, 2009 at 04:14 PM CET #

"install an EJB 3.1 container inside tomcat"

Instead of installing openejb in Tomcat I'd rather use Geronimo and create a Geronimo server assembly with only the needed plugins for EJB: http://publib.boulder.ibm.com/wasce/V2.1.0/en/creating-custom-server-assemblies.html

Posted by Juergen on November 05, 2009 at 04:50 PM CET #

Most(small) projects don't require the full functionality of EJBs, in those cases JPA is enough.

For these apps we started using grails to cut off the bureaucracy overhead you mentioned.

We're having great productivity gains so far. Most needed when in lean times.

Posted by Shinji Mikami on November 06, 2009 at 04:21 AM CET #

*projects don't require the full functionality of EJBs*

This true, but you need support for concurrency, transactions, REST integration what makes about 80% of the functionality :-)

JPA without EJBs = bloat: http://www.adam-bien.com/roller/abien/entry/jsf_jpa_ejb_bloat

But: in your case Spring is managing transactions for you, so that you don't have to do it by yourself.

Btw. Grails is great choice as well!

Posted by Adam Bien on November 06, 2009 at 09:53 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License