Linked by Eugenia Loli on Thu 13th Jul 2006 09:08 UTC, submitted by Alex Helder
Java Java Platform, Enterprise Edition (Java EE) is not going to survive as a major standard programming model in the next five years, predicts Richard Monson-Haefel, senior analyst with the Burton Group, and SOA is part of the reason.
Thread beginning with comment 142627
To view parent comment, click here.
To read all comments associated with this story, please click here.
timkar
Member since:
2005-07-13

>we were a pure microsoft shop and when
>.net came out, we decided to go the
>Java route feeling it had a brighter
>future.

Sounds your shop struggles with the same flaw that ours does. We have nasty habit of being reactive to technology(on the order of 5-7 years), rather than striving to stay at least somewhere in the general vacinity of the curve.
Mind you J2EE isn't something that you can just pick up over night, but our company is getting ready to deploy it's first pure J2EE solution. In our case, it's that or a giant home-grown framework, so, in some sense of course, the choice was clear, as long as we were staying with java(though not necessarily, I admit.)

The point is, this happens every 7-10 years and a smart organization of any size would do well to have already made in-roads into Rails (or a couple of other alternatives). I'm not talking about doing an about face and deploying one's entire product line into Ruby. Tech shops should, however, be able to turn on a quarter or fifty-cent piece if not a dime.

I feel for ya. I really do. I feel for me.

Reply Parent Score: 1

Tuishimi Member since:
2005-07-06

Thanks, man. Let's go get a beer. ;)

Reply Parent Score: 1

JeffS Member since:
2005-07-12

"Mind you J2EE isn't something that you can just pick up over night, but our company is getting ready to deploy it's first pure J2EE solution. In our case, it's that or a giant home-grown framework, so, in some sense of course, the choice was clear, as long as we were staying with java(though not necessarily, I admit.) "

Here in lies the big reason J2EE is so successful. Yes, it's a big, complex beast. But in solves huge, complex problems that would otherwise be much harder to solve with other tools, frameworks or home grown solutions.

With J2EE, you get transactions, load balancing, messaging, remoting, connection pooling, security, persistence, SOA, legacy integration, and a host of other powerful features that are all commonly needed in big enterprise computing, all packaged into one consistent standard (into J2EE compliant application servers), that can be deployed across a myriad of platforms and hardware. And you can choose from a number of big vendors, or open source solutions, or a combination there of. And you can draw from a huge developer base.

No other software stack, not .Net, not RoR, not LAMP, or anything else, can match J2EE's power or features.

J2EE is complex out of necessity. It solves the most complex problems. It is also a big enabler. It allows enterprises to pick and choose any hardware, vendor, platform for whatever task, and J2EE can seemlessly tie it all together.

The problem lies in trying to apply full J2EE to smaller problem domains, like a simple interactive website, where RoR or LAMP would be easier and probably more appropriate. Or sometimes people apply the hardest, most complex bits of J2EE to smaller problem domains. The over hyping of EJB is a perfect example. EJB is only useful for the biggest of problems where both transactions and remoting are essential. But it is sometimes applied where a simple JSP/Servlet/JavaBean/MVC app would do just fine.

Reply Parent Score: 1