What is Wrong with J2EE
Monday, April 3rd 2006 | Ismael Ghalimi
This is the fourth edition of our weekly BPM 2.0 post. Today, I will try to explain what’s wrong with J2EE, and why ABAP, PHP and VB folks like BPM 2.0 so much. Java — and it’s enterprise offspring J2EE — are extremely powerful technologies. Problem is, with power comes complexity, and J2EE is a perfect example for it. The Java Community Process (JCP) website lists 320 Java Specification Requests (JSRs), and the Java Enterprise Edition 5 Beta API Specification has 1438 classes. Whichever way you look at it, Java grew big and complex over time, and things are not getting any better.
J2EE was supposed to bring portability for applications developed on top of an application server, but reality is that beyond the most simple ones that only take advantage of a Servlet container, you cannot port applications from one application server to an other, especially if they make use of Enterprise Java Beans (EJB) components. The EJB 3.0 component model is promising to change that, and it might. Unfortunately, when a problem is fixed here, a new one pops up there. We experienced this recently when we tried to port our process server on top of Apache Geronimo. Everything worked fine until we tried to package all the components together — process server, workflow services, XForms engine, etc. — then it broke. Somehow, one component was turning a shared Log4j service off, and we had no easy way of isolating which component was at fault. This vexing problem, alongside a dozen similar roadblocks, kept a team of three highly-talented Java developers busy for the best part of last quarter. If a software company like Intalio, which business is to develop software, is facing this kind of challenges, how is it for end-users whose primary business is selling widgets or processing financial transactions? Well, as far as I can tell from many discussions with customers, it’s not that great either…
Your average developer cannot deal with this level of complexity. Not that she is not smart enough, but she’s got better things to do, like taking care of business for example. And what is true for J2EE is also true for collateral technologies, such as Eclipse for example — have you ever tried to use EMF and GEF? For me, BPM 2.0 is all about offering a quantum leap in abstraction that will allow your average developer — ABAP, PHP and VB folks — to bypass this complexity and focus on higher levels of the stack, namely processes, rules, and interfaces. To a large extent, these developers have felt left out with the exploding complexity of J2EE and .Net, and BPM 2.0 gives them the tools to be productive again, with a vengeance. That’s precisely why they like it so much.
UPDATE 07/10/2006: Good article from SearchWebServices.com on the subject.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I would agree with you. Our shop has been using J2EE for five years now, and I have noted that it can take three years or more to become proficient. This is ridiculous. One of our big commercial clients still uses Oracle’s PL/SQL for the majority of their development. I suspect you would find a great many IT shops using PL/SQL. The reason is simple. A computer science graduate can be proficient with it in a matter of months. Plus, it is not difficult for others to maintain this code.
The tools that big BPM vendors, like webMethods and SeeBeyond, provide are mostly fancy front-ends to complicated J2EE development. Whenever you need to do something complex, such as manipulate vectors of datatypes, you immediately drop into their Java development environment. To develop complex process scenarios, your developers must be proficient in J2EE, plus they must be well versed in the BPM product’s particular classes of Java.
Yes, J2EE is complex, but so is building high performance, secure, transaction-aware, distributed, integrated enterprise applications. I see J2EE as the evolving assembly language supporting such applications. Clearly, abstraction and model-driven development are needed to make J2EE accessible to developers who need to focus on their business problems. This is a common evolution in computer science that is likely to repeat itself a number of times.
But another possible problem with J2EE is that we tooled J2EE based on what it is (the J2EE specifications) rather than by how it is used. This perhaps needlessly exposed unnecessary complexity to J2EE users. As an industry, we need to be careful that we do not make this mistake again with SOA. Otherwise we might end up recreating the same complex solution with tools for WS-* based on an XML foundation.
Jim,
I could not agree more with your summary of the situation.
[…] Back in April, I explained what is wrong with J2EE. Today, I will try to identify who cannot write J2EE code, with an interesting customer example, as part of our second BPM 2.0 weekly series. […]
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment