Conceptual Items (High Level Damnatians)
<< Introduction
EJB's choice is Hobson's Choice. If you don't like EJB's locking, caching, performance, failure or persistence mechanisms, then write your own, says JavaSoft.
101 Damnations to you.
"Thomas Hobson, a seventeenth-century liveryman in Cambridge, England, told every customer he could have any horse he wanted as long as it was the one nearest the door. Hobson's choice should not be used in the context of dilemma or mere indecision. It is a choice between what is offered and nothing."
Source: Communication World December 1992
On to the Damnations:
| 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.
Very little effort was made getting EJB to naturally extend the Beans specification (remember JavaBeans are not just about GUI widgets).
For example, there is no mention of Events in the EJB model. Enterprise Beans don't have property change events or vetoable events, or indexed properties. The specifications focus almost entirely on the server side specification and hypothetical roles.
|
| 2. |
A rigorous set of examples and design goals for application programmers has been missing from the start. Instead the focus has been on remote objects and pessimistic locking, rather than the high performance and soft locking required by most Internet applications today. |
| 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. |
| 4. |
Sun's recommendation to "Use Container-Managed Persistence When You Can" is contrary to our experience. I am sure we're not alone in that CMP seems to be useless for complicated applications.
|
| 5. |
The EJB specification makes no reference to other well known distributed system design references - for example the ISO Basic Reference Model of Open Distributed Processing 1992.
Most seminal communication specifications make reference to the ISO Open Communication Models. Either there is a lack of theoretical grounding, or perhaps the designers didn't think it was worth mentioning.
The above-mentioned ISO ODP reference model has several goals for a distributed system. Many of the important goals have not been met - in particular (points 6-9 as follows):
|
| 6. |
The EJB spec doesn't address access transparency. Local and remote object definitions are not transparent, as you inherit from a different interface and have to cast using the narrow convention.
|
| 7. |
The EJB spec doesn't address performance transparency. The performance solutions for EJB involve radical redesign of your code, such as session-based methods, value objects, entity bean serialization or client side caching.
|
| 8. |
The EJB spec doesn't address migration transparency. If any object moves, the client must throw away the remote or local interface and get a new one.
|
| 9. |
The EJB spec doesn't address Concurrency transparency. There are no clear sets of locking strategies to suit different application programming tasks. The application and EJB programmer is left to handcraft locking strategies.
|
>> Next Category: Design
Message Forum
<< Back to EJB Central
<< Back to Software Reality
|
Programming
