Knock-On Effects
24 February 2002
<< Runtime Issues
EJB is baroque: extravagant, complex and bizarre. As a language matures, its creators have to steer the designs so they don't end up with a house of cards.
Java is going through the same maturation process, yet EJB has been badly thought through for the developer.
This section examines the effect that EJB's baroque nature has had on the enterprise marketplace.
| 88. |
Sun's marketing confuses people. Often, journalists and managers alike will confuse EJB with J2EE. Java on the server does not necessarily mean EJB. |
| 89. |
EJB exposes Java to attack, not from criticism, but from a better language. Not talking about C#, but a language based on Components and Stores instead of classes. |
| 90. |
Where is the large-scale EJB usage? The thousands of downloads of J2EE, WebLogic, HP-AS, JBoss etc don't quite tally with the number of real-life EJB systems in use. |
| 91. |
Where is the large-scale usage of EJBs? How many companies are really using EJB for massively scalable back-end systems? |
| 92. |
The Sun hype pushing EJB will backfire. It reminds us of their spin machine pushing Applets on the client before the Java UI was ready for prime time. This had a detrimental effect on Java. |
| 93. |
Where is the thriving EJB component marketplace 3 years from inception? The situation seems similar to what was said of C++. VB/Delphi/Java had and has loads of components, as it is so easy to write them. |
| 94. |
The EJB specification was not focused on any applications. There should have been two or three big, complex, real world apps that needed to be expressed in EJB as a testbed.
It took Sun about 2 years to come up with Pet Cemetery, and even then, it proves nothing except that they don't have a clue. This same criticism is just like that of Swing - it took years to come up with proper test apps, e.g. Forte!
|
| 95. |
Warnings from Gartner Group:
"As components of application server technology, J2EE and Enterprise JavaBeans (EJB) are not the same thing. Most Java projects use Java Server Pages (JSP)/servlet capabilities and not EJB. Higher-priced application servers are designed to run EJB, yet they are using JSP/servlet capabilities instead."
"Companies have overspent about $1 billion on application server technology solutions since 1998. Moreover, an additional $2 billion may be wasted between now and 2003."
"Don't let confusion or hype push you to spend more than necessary."
|
| 96. |
Sun's main revenue stream is from hardware, not Java. Their profit driver is to sell hardware. This explains why EJB has not been reigned in and rationalised. |
| 97. |
There is no real synergy between EJB and the rest of J2EE. |
| 98. |
Most, if not all, EJB articles on the web seem to be about hacks, bugs, workarounds, optimizations, as opposed to glowing success stories. Where are they? |
| 99. |
The creators of the EJB spec are in a privileged position. It's very easy to define huge, complex specifications and expect the industry to forever be trying doggedly to catch up with actual implementations of their mad schemes and "visions".
It's not so much an OO Utopia as a "Complexia". It would be much harder for them to try and implement their own specs (as they discovered with the RI mess).
The server vendors don't get a chance to make their servers useable or robust, as they're forever trying to catch up with Sun's latest promised feature-list made on their behalf. Then there's the even bigger problem of supporting legacy versions (for those vendors that can be bothered with such "trivial" notions).
|
| 100. |
Brave New World - this isn't just a comment on EJB, but on the state of enterprise computing:
Everyone expected the OO dream to materialise with interconnected, co-operating objects whizzing around global networks - instead we have gronky EJBs and labour-intensive EAI systems (e.g. BizTalk), much too complex for their own good.
|
| 101. |
The basic idea behind EJBs, and Sun's approach to APIs, is good. The principle of defining standard specifications for the industry to follow is a noble one. But something, somewhere, has gone terribly wrong.
|
>> Next: The Conclusion
And some suggestions for improving the EJB spec.
<< Back to EJB Central
<< Back to Software Reality
|