Originally J2EE was a short acronym for a Java platform variant for each version....
Thus Java 1.2 (Called Java 2) had J2SE and J2EE (Standard Edition and Enterprise Edition) respectively. The EE variant had some additonal tools that were thought to by unique to requirements of an enterprise system (large scale business oriented system)...
Later the J2EE took on a life of its own, developing into more of a framework, and even becoming a standard of "how things worked"... The general idea is that if you are developing a system to meet a small scale need, a small business, a one-off system etc. then you can build it any way you like and typically have total control over the entire envornment; HOWEVER, in an enterprise environment the systems are typically standardized for reuse, resale and/or compatibility with various hardward/OS/Network etc. environments... The promise of Java's write once run anywhere is a key of the J2EE world... If an application is built to follow these standards it should be 99% sure to run on any architecture that is J2EE certified... I say 99% because the ideal has never been truely reached and there is a difference between "compatible" and "compliant"... while compliant means follows the rules 100%, compatible simple means it will work... symantically small difference, actually a large difference... as we see in browsers every day...
Since takingon this nature of a standard many extensions to the J2EE have developed, including Enterprise Bean as opposed to regualr Java Beans...
Java Beans make upto 10 cups
Enterprise Beans make 1000s of cups...
small joke... but fairly accurate ;-)
Ok, no one every said I was funny, except that girl at the mall (and put looking after it)...
So if you want to create enterprise solutions which will likely be able to run on numerous systems and resell these you will want to learn the ins and outs of the J2EE also...
ALSO, J2EE incorporates interation between systems, so if you need to integrate with other systems, J2EE is the best way to start...
Now, the biggest enterprise software vendors in the world are NOT J2EE compliant, they may in SOME aspects be J2EE compatible, but that is even stretching it...
ONE major problem with stanardization is that you loose any advantage you may have with prorietary design... some people say the benefits outweight the risks, but those benefits are typically theoretical and usually end user/ customer focused, Unless the corporate giants see stronger REAL benefits they won't willing walk the path, as it requires significant real costs to even find the path...
The theoretical benefits may or may not materialize, but they will never find out because they choose to take the easiest path...
It will come eventually, because more and more customers want the assurance that they system will work correctly with their other systems, the J2EE battle cry gives them a false sense of security, but unless you are crying this with them, many of them won't talk to you these days... It is not yet reached critical mass though...Still too many customers put their pocket books before their brains... compliance has a cost up front, and the promise of lower TCO (Total Cost of Ownership)... but they all too often look only the the up front impact on their wallets...
Whenever I do any project, PHP, JSP, etc. I provide 5 and 10 year costs break downs... It requires knowledge of "true" consulting, to analyze the costs related with "doing nothing", which is always an option, or taking other available options, or doing it the way I suggest...
When done well, you will seldom loose to the cheaper option if your solution is truely superior...
I showed a 200% ROI (Return On Investment) in 6 months and a 5 year NPV (Net Present Value) of a solution versus the 2 main options (do nothing & verdor Bs solutions)... Both other options were VERY cheap up front, while my options freed a large number of workers to do other things reducing the effective manpower costs required to do the same work... meanwhile showing long term growth and maintenance plans that cost very little while the other options did little to effectivly reduce workload and had higher maintenance and growth costs...
Do nothing was ruled out within the first year's ROI, and vendor B's solution was rules out after the second year's ROI...
If this customer had been only looking at up front costs, as so many do, he would never have paid my price which was 4 times that of vendor B... But presenting it in the way I did forced them to look at the TCO...
J2EE can help you with this, but it also introduces a level of complexity...
