Design
10 February 2002
<< Conceptual (High-Level Damnatians)
Three years on from EJB 1.0 and still not ready for prime time. Design issues cloud development work.
Compare this with SQL, which was not even the best query language at the time it was introduced, but is now used almost universally. SQL as the client-facing interface did not try to tell database vendors how to implement internals.
The EJB specification is monolithic and causes lots of dependencies for EARs. The result is that the beans are brittle. Below, we provide some examples of why this is the case.
In addition, please bear in mind that not all of these items are outright criticism; remember this article is also a "wish list" of items that we feel would improve the EJB spec.
This section focuses on the design issues that we believe are preventing EJB from gaining greater acceptance.
| 10. |
The only justification for EJB is on large projects, yet EJB makes those large projects larger still, and yet more unwieldy. You need to scale to get EJB to perform.
|
| 11. |
Role based class/method security is rarely useful. Data security is far more important. |
| 12. |
EJB Query Language is another language to learn. This is reminiscent of the situation with WML, where an attempt to write a simpler language than HTML failed because they didn't just simplify HTML. Instead they started from the ground up, having decided erroneously that they could do a better job themselves.
EJB Query language doesn't support many SQL operators, (e.g. subqueries, IN, ALL, ANY, String comparison, ORDER BY, GROUP BY).
There is a good critique of EJB-QL here.
|
| 13. |
The specification does not provide for proper handling of views or read only tables. Back in the real world, read only tables and views are very important. |
| 14. |
EJB only handles first class objects (i.e. beans that have primary keys). It would be nice if it also handled second class objects (do not have primary keys), where they have a one-one relationship with a first class object.
For example, a Cash object might contain a currency and an amount. Using CMP Entity Beans you would be forced to have a Cash table. A better design would be to automatically map the Cash.currency and Cash.amount into the parent table's columns.
|
| 15. |
No proper handling of validation (e.g. String lengths). For a specification whose main purpose is reading and writing to a database, this is a surprising omission. |
| 16. |
No proper handling of Enumerated Types. Enumerated Types represent fixed sets of data, such as Sex, Industrial Classification, or Marital Status. It should be possible to use them as properties on Beans.
It has been argued that this is more of a Java issue, i.e. a deficiency in the Java language rather than EJBs per se. This is not necessarily the case though. For example, our JBeans spec includes Enumerated Types defined via a standard interface and an EnumeratedType abstract class.
Adding Enumerated Types to the Java language would be better; but the EJB spec would definitely benefit from a similar addition.
|
| 17. |
EJB doesn't make a clear separation between the components and the machinery that is supposed to persist it. For example a bean can remove itself, which assumes a bean is always persisted and it must always be tied to a persistence mechanism. |
| 18. |
Entity Beans bind the business logic with the persistence mechanism. Hence the need for Data Access Objects. If the persistence was orthogonal to the beans this functionality would have been accommodated more naturally. |
| 19. |
Optimistic locking is not accounted for. The EJB spec assumes either pessimistic locking or not locking, or roll your own. There could have been a locking interface; or a way to specify a logical concurrency mechanism like isolation levels. |
| 20. |
Most 'fast' EJB patterns seem to involve using sessions that go straight to the metal. Half the time is spent navigating, so half of the system ends up being rewritten.
Entity beans only appear to be useful in single entity transactions, but not where the entity bean needs to know about its dependent beans. When you save a bean, the graph of dependent beans should also be saved - but it doesn't work like that.
For EJB you can specify cascading deletes, but not combinations of creates, updates and deletes. To save a graph of beans you must create your own client side User Transaction and call each create on the home, set on the bean and remove on the bean. The beans should understand what has been changed in the graph and update the database accordingly.
If we were "putting the boot" into EJB, we would suggest that this means EJB is only half complete.
|
| 21. |
There is no meta-data for business, i.e. no meta level to describe your business. Just code. |
| 22. |
EJB tries to address both the client side interfaces and the service provider interfaces. Really as a client we should only care about the client side interfaces. This would make EJB open to different implementations. |
| 23. |
No standards for writing Session beans as Beans. Yet this approach is one of the most talked about on the web. |
| 24. |
There is no concept of dependency, so that a bean is stored, removed or updated at the same time. |
| 25. |
There is no concept of whether the primary key is generated externally by the application, internally by the container, or automatically by the database. |
| 26. |
EJB is designed to handle high-transaction units of work in a distributed environment. A very small percentage of applications need this. When we define high-transaction usage we mean thousands, not hundreds. Most users need only tens a second. The EJB spec also neglects applications that need to return static data, or real-time data. There are not designs in place to return these objects. |
| 27. |
No standardised integration with content management tools (other than "roll your own" solutions via JSP, for example). For large web sites, it isn't clear how these would integrate.
This is more of an issue with J2EE as a whole than EJB by itself.
|
| 28. |
To attach enterprise development without going to a higher level, without approaching it with a blueprint, is like trying to dig a tunnel through a mountain with ever so slightly sharper spoons. They shouldn't be working on this level. |
| 29. |
Sun doesn't have a joined up strategy for persistence, i.e. JDO, JDBC, Java Blend, serialisation, XML, EJB without any common interfaces. This is similar to the case with GUIs, i.e. Swing, AWT, MIDP, and web front-ends which they are trying to address with the mysterious JavaFaces. This gives the impression that the various design groups at Sun are out of control. |
| 30. |
ACID is not always wanted. For example, a search engine wants high performance, availability, in exchange for accuracy.
As with many of the issues raised in this article, the obvious answer appears to be: "So don't use EJB for this type of work." Unfortunately, we believe that this blinkered approach seriously limits EJB's usefulness. Why should it be limited to such a narrow field of use, simply because of some erroneous assumptions made early on regarding the sort of features that all enterprise applications would surely want?
|
| 31. |
Most web apps are not very transactional. EJB comes from a TP/MTS type background. Perhaps it should have been called TJB, Transactional Java Beans, so that people knew where it belonged. As it is, EJB co-opts areas that simply don't belong to it. It's a baroque framework for transactional Java beans, which tries to wear the clothes of the enterprise emperor.
EJB is very transactional - it sucks when it comes to high performance queries, read-only work.
|
| 32. |
EJB hasn't really addressed the issue of efficient access to remote objects. Effectively you have hand code. It would have been better to have client side beans where vendors could have generated different options. At the risk of plugging our own product, JGenerator allows you to do this.
|
| 33. |
There is no clear design for returning Relationships between beans. Should you return a primary key (and look it up on the client)? Or return a handle, which does the look up but needs Bean managed code, or return the related beans remote interface which in turn means referencing the remote bean from the server?
Container managed relationships can only exist between beans whose homes are on the same server. This makes it impossible to deploy an enterprise system where one bean references a bean in another database automatically. For example, several product databases may reference a central customer database. There is no way to automatically generate a getCustomer() method on a product. Not very Enterprise.
|
| 34. |
It's difficult for a bean to tell the server when it is dirty, or read-only. This is supported in some servers, not in others. This should become part of the specification. |
>> Next Category: Development Issues
Message Forum
<< Back to EJB Central
<< Back to Software Reality
|
Programming
