EJB 3.0 is surely a job well done, and the expert group deserves all the praise for a wonderful effort towards making the life of an EJB programmer easier. With that said, life will be easier, but surely not easy, with more than 50 annotations already defined (several more expected in the next draft), each with its own set of rules for defaults and other behavioral specifications. Of course, I wasn't really expecting an "EJB 3.0 = EJB 2.1 for dummies" kind of equation. Still, I would like to express my humble opinion about a few issues:EJB 3: An overview and critical analysis of the latest EJB specification
- For one, the specification has surely made iterative development easier with fewer program artifacts, intuitive defaults, and a simpler model for access to the runtime environment. I also like the fact that the home interface is gone, which means fewer artifacts to even visualize.
- In earlier EJB specifications, entity beans used to be a view into the persistent store. It was theoretically (and probably only theoretically) possible to map an entity bean to any legacy EIS (enterprise information system) also. Doing so was accomplished with longer-term extensibility in mind and was meant to allow wider adoption of entity beans for business data modeling. Instead, the accompanying complexity only hurt the prospects of entity beans. As proposed in this draft, an entity bean is just a view into the database. Life is much simpler with no abstract persistent schemas and a simpler data-access model.
- While I warmly welcome the above change, I'm not comfortable with the idea of having SQL snippets in EJB code (annotations). Some developers are totally against even the apparent "SQLness" of annotations (like @Table and @Column annotations). In my opinion, this "SQLness" is okayafter all, we are clear that we are talking about databases. But SQL snippets like columnDefinition="BLOB NOT NULL" make me really nervous because such an approach encourages a tight coupling between EJB code/annotations and SQL representation of the same.
- Though support for native SQL queries appears tempting, embedding SQL in EJB code is a very, very bad idea. Of course there are ways to avoid hard-coding your SQLs, but those approaches would serve better as part of the specification, rather than individual developers' custom patterns.
- I assume that use of annotations like @Table is only declarative in the bean class. The table name specified through the name member of the @Table annotation will probably have to be mapped to actual database tables at deployment time. The specification should be explicit on this issue and prescribe a consistent model.
- The specification also needs to be more explicit about changes to the client-programming model, particularly standalone Java clients. All references to the client-programming model in the draft have implicitly assumed EJB clients. The draft also fails to touch on the issue of backward compatibility for client programs.
- he Transient annotation should probably be renamed to avoid conflict if it is used in place of the transient keyword. In fact, on this issue, I believe we should be willing to deviate slightly from the configuration-by-exception approach and define an @Persistent annotation to explicitly mark all persistent fields. The @Persistent annotation could be just a marker annotation or it could have a few annotation members to possibly associate with O/R mapping annotations.