EJB 101 Damnations

[HS Thomas]

What would you all say has changed about any of these EJB Damnations ?
Some of these are "old".
EJB 101 Damnations
Matt Stephens the editor of (and regular contributor to) a satirical website for software developers and managers. You are looking at it.
regards
[ September 09, 2003: Message edited by: HS Thomas ]

[Chris Mathews]

I didn't think a lot of these were valid back in February 2002 when it was written. The author doesn't seem to understand the technology (EJB) or their purpose (Enterprise Applications).
For example, the very first point is way off base:

EJB Damnation Point 1
EJB represents a radical departure from the Beans model. Beans was based on the (proven) component model also used in Delphi. This means that for projects that are migrating to EJBs, much of their code base is no longer valid.

No really? The EJB component model was designed to solve a completely different problem. This is comparing apples to oranges. Anytime you move a client/server application to an n-tier enviroment you are likely to throw away quite a bit of code. This point is pure rubbish and has nothing to do with EJB.

EJB Damnation Point 3
EJB is based on an Object Pooling optimisation. Optimisations should not be incorporated into the design, but left for vendors to decide and compete on. The logic of basing a system on saving a resource as cheap as memory seems absurd.

According to who? Object pooling is not mandated by the EJB Specification, it is just recommended and supported in certain cases. Furthermore how would like change the landscape of EJB? Every vendor is and would still be doing object pooling.

EJB Damnation Point 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.

I didn't realize that EJB was a language. I thought it was a component model implemented in Java. :roll:
The list continues to make these types of absurd statements. Overall, it is a ridiculus article that makes terrible assumptions and wrong conclusions.

[Chris Mathews]

BTW, this article was discussed on TSS back in February 2002. Here is a link to the thread.

[Jeroen Wenting]

I've never seen the Holy Grail of using EJB, even when working on projects where they should (according to the hype) be used heavily.
All those projects worked out well (technically that is, 2 were failures for non-technical reasons).
IMO the ONLY reason to use EJB is to expose data to applications running remote from that data AND needing complex interaction with those applications in order to store and retrieve that data correctly.
And for that too other mechanisms can be employed that are easier to implement, more transparent and better performing (like web services, SOAP interfaces, etc. etc.).
As Rod Johnson states in his book "J2EE design and development" "EJBs add unnecessary complexity to such {non-distributed} systems. An EJB solution can be likened to a truck and a web application to a car. When we need to perform certain tasks, like moving large objects, a truck will be far more effective than a car, but when a truck and a car can do the same job, the car will be faster, cheaper to run, more maneuverable and more fun to drive".
I think that pretty well sums it up.
[ September 09, 2003: Message edited by: Jeroen Wenting ]