An oft-heard complaint, echoed recently by Annrai O'Toole, is that J2EE app servers are oversold:
The J2EE vendors have done a fantastic job of convincing the world that you can't run a line of Java unless it runs inside a J2EE container. This is just pure bunkum.
I like his formulation that "J2EE is the Java equivalent of a mainframe." We also have, of course, in COM+, the Windows version of the same idea, which in its earlier MTS incarnation predated J2EE. I also notice that the real mainframes haven't gone away. With respect to the middleware services for which the J2EE server is best known -- "TP-heavy" transaction management, connection and object pooling, role-based security, and declarative control of these aspects -- the question of when and why this stuff is or isn't overkill seems never to go away.
Here are some of the arguments and counter-arguments I hear:
| You need a J2EE container / EJB architecture because... | But... |
| Your app has to scale. | Other clustering and load-balancing solutions are available -- for Java, for Windows (with and without COM+), and for LAMP. |
| Your app is heavily transactional. | TP-Heavy solutions like CICS, Tuxedo, and TopEnd haven't gone away. TP-Lite is arguably getting more interesting, as well, now that the database engines can cluster, and produce/consume Web services. |
| You need object-relational persistence. | And there are other ways to get it. E.g.: Castor, servlets with JDO (Java Data Objects), Apple's Enterprise Object Framework. |
| You need a low-impact way to evolve business logic. | J2EE's complexity bites you. It's easy to change what's inside a chunk of business logic, but it's hard to refactor in-the-large. |
| You need your business logic available to multiple applications. | What if those other applications aren't Java-based? |
| You want to standardize on one environment and one language. | Even the most dyed-in-the-wool J2EE developer is likely to touch (at least) SQL, JSP, XSLT, and a scripting language for automation. |
For an upcoming article, I'd like to explore these and related themes with people on all sides of this complex, many-sided discussion. In an earlier posting, I characterized one axis of the debate as robustness versus agility, and wondered how we can have our cake and eat it too. Sam Ruby pointed to WS-Transaction, to which Patrick Logan replied "I think we need a rethinking of databases, messages, and coordination." I'm sure that's true. Meanwhile, what to do?
I'm going to contact some people privately, but it seems useful to invite feedback here as well, hence this comment link.
Former URL: http://weblog.infoworld.com/udell/2003/05/12.html#a686