One application speaks volumes about the state of EJB development: Petstore. Even Microsoft have picked up on this supposed example of correct EJB design, and trounced its design and performance (see the fallout from this episode at TheServerSide).
Sun's response was that Petstore is not supposed to be used as a model of speed and efficiency. Why not? If EJB was a brilliant design, this would never have been an issue.
| 35. |
Use of CMP beans locks you very much into the vendors' proprietary mapping technology. Beware of the apparent ease of use that CMP tries to offer. |
| 36. |
The EJB Spec imagines the role of a container builder and a server builder. This assumption that there would be separate container products that would run in the application server is incorrect. Hence the service puts unnecessarily tight constraints on state control. This should have been left up to the vendors. |
| 37. |
Development is very slow. For example, the development cycle is tens of minutes, rather than seconds, simply to change a small value in a JSP. This is a huge project killer. Increased development time hardly helps with 'Internet time' projects. |
| 38. |
There is no concept of a design time state, like in the Beans model that allows for a quick development cycle. |
| 39. |
EJB represents a huge learning curve. The EJB spec is supposed to help, but seems to hinder. It's very complex. Even for the most experienced engineers and architects, getting all the niggling details correct makes development painfully slow. |
| 40. |
Many sites do not need EJB complexity, yet people use EJB for the sake of fashion, or getting skills on their CV. Too many people are happy to sacrifice the future of their company/project, in order to get 'sexy' skills. |
| 41. |
Petstore. No databases are used to stress test the design or implementation. It's as badly thought out as sending pets through the post.
|
| 42. |
Petstore is too big to be a quick demo test case. |
| 43. |
Petstore is too small to stress test the memory. |
| 44. |
Petstore involves too little data to stress test scalability. |
| 45. |
Petstore is too homogeneous to stress test Code Generators. This is probably a slightly unfair complaint to make, as Petstore was obviously not designed with automated code generation in mind. However, code generation is an increasingly important aspect of EJB design and development as it removes the drudgery of churning out endless beans to the same design pattern.
Therefore, we would argue that the J2EE reference application should reflect the manner in which an increasing number of EJB projects will be written. In this regard, the problem with Petstore is that it is very samey all the way through, and the database doesn't do enough "weird" things. For example: the tables don't contain all the data types, there are no 3 way primary keys, and no views or read only tables.
The result is that code generating Petstore doesn't prove very much.
|
| 46. |
Vendors all supply their own versions of Petstore, where each seems to be mostly handcrafted.
There should only be one version of Petstore as a container managed bean that is fully working. At the moment every vendor has to create their own CMP to get it working.
|
| 47. |
There is no way of knowing when set property values are done. Explicit transaction demarcation is done at the property level, not at the Bean level. If there was a store method on a home/session this would do this. |
| 48. |
There are no standards for optimising Entity Beans, serializing the whole bean or sending property sets. |
| 49. |
One way to fix the previous two problems would be to introduce "smart stubs" *. Instead however, the programmer is expected to write straight to the wire for every property get or set, or to use facades, dependent objects etc. That's an awful lot of extra code, especially when it conceivably affects every single entity bean in your application.
* Smart stubs are a concept that CORBA came up with. A client side CORBA stub would have another stub subclassed (and could be delegated from). So the client side programmer thought they were going straight to the remote stub, but the application programmer had the opportunity to 'fiddle' with the call before it went.
Subclassing meant you could only do a little bit of fiddling, but delegation allows you to completely alter the RMI method call, so that you might write to the client a sequence of "set" method calls, and all the time it would be storing the set values in a property list, instead of shoving them over the wire every time.
Then, when you call the commit transaction method, all the sets that you have done on all the objects in that transaction are bundled up and sent in one message. Conversely all the properties can be pulled over when you call the first get, so you're not getting every tiny property every time you call a get method.
At Javelinsoft, we do this in our CJBs (Client Java Beans) by serializing the Entity Bean from the EJB server when we make the first get call, and filling it up and squirting it back when we say save on the Home.
|
| 50. |
Stateless session beans are supposed to be the most scalable, yet they are not much more than RMI. However we still need to jump through all the hoops to get them working. |
| 51. |
It isn't easy to put EJB in Applets. There is no concept of a lightweight interface. |
| 52. |
EJB does not have count methods optionally automatically generated. This feature is used in many applications I have worked on to save loading objects into memory. |
| 53. |
Non web app client access to EJB is vague, and inconsistently supported. Sometimes an application server will supply you with a jar to include in your application to get access to the EJBs; sometimes you just have to figure it out yourself and end up including several megabytes of jars. |
| 54. |
The spec for EJB cross beans mapping is constantly under change, and inconsistent across servers. It's also not flexible. The result is that you cannot easily port from one application server to another. |
| 55. |
We need to use value objects to get any real performance, else each get/set makes an RMI call. Why was this concept of local stubs or property sets not put into EJB? Performance should not be an irrelevance. |
| 56. |
The EJB Compliance Tests do not appear to include proper examples that rigorously test all scenarios. Because the CMP and BMP are different for all vendors, it would be nice to have some examples that have say 100,000 rows being loaded and used, or 100 rows containing all the data types being tested.
For example, in JDJ volume 7 issue 1, an HP engineer reveals why the CTS is so important vs the reality of the process that they endured with HP-AS.
How is it possible to be 'compliant' yet full of bugs? Answer: bad tests.
So yes, we need tests, much better tests. But these synthetic tests, even if they weren't so bug ridden, would still only test some synthetic criteria.
If instead they simply said, "let's try to use EJB to do business in these scenarios" and picked 5 or 6 hard business areas they'd do much better than all this synthetic design.
If we examine Java's history, we see that the same was also true for Swing. The specification would have advanced much faster if they had simply said, "let's do Office in Swing". You can only abstract from the concrete, yet Sun engineers again and again try to abstract from their imaginings, guessing what might be cool, or pure, as opposed to what people need. What's the point of writing software to meet future needs if it won't even meet your current ones?
Another problem is that the tests are only done on toy examples, and there are no theoretical underpinnings. Therefore, you are never sure when EJB is going to let you down. At least with Java and SQL we know there is a rich history and/or theory so we can make measured predictions of what we can do and how the system will perform.
|
| 57. |
EJB wizards are often shaky and dangerous. They end up creating code that simply won't work. So you waste time thinking it must be your own problem somewhere. For example, the RI (Reference Implementation) 1.3 container entity bean wizard misses out "throws CreateException" on ejbCreate. |
| 58. |
The RI seems to have had 0 to little Q.A. For example, 1.3 RI code generation tools simply produce wrong code. Their entity bean managed findByPrimary would never work. This is of no help to anyone learning EJB.
As the RI is the "Reference Implementation" this is very bad. No one expects the RI to be fast, but we do expect it to be a model of compliance and correctness.
|
Programming
