Michael Nascimento Santos's Blog

EJB 3.0 is not ready yet! That's your chance!

If you could change EJBs, what would you do? If you had full power to add features or redesign the old ones, what would be different today? Well, in fact, you have the power to do it, but you need to be fast! JSR-220 is in its early stages and during JavaOne Linda DeMichiel, the spec lead, made it clear she wants to get input from the community.

I attended her session about EJB 2.1 just because I wanted to ask a few questions - which I did -, but close to end of her presentation, I was nicely surprised to see a few slides about what EJB 3.0 may look like. And it looks prettier than today! Her idea is to simplify EJB development by using metadata to automatically generate deployment descriptors and providing superclasses that developers can extend in order to override only the methods they actually want to change. That was great!

Also, she presented a BOF called EJB 3.0 Specification Features Input. I made a lot of comments about it, but here are some suggestions and points I criticized:

• Access to the actual Subject returned by the JAAS login mechanism: OK, we can use JAAS in J2EE. JAAS is great, because it gives you enormous flexibility regarding login mechanisms, credentials, principals etc. But how is it supposed to be useful if you can't access the credentials and principals after you have authenticated the user? That's how it works now. Hope it changes, really.
• Instance-based security: I've never been able to make any meaningful use of the security features provided by the current EJB spec. It is impossible to do it if your only option is declarative security - and I am not using it in the sense the spec uses it, but I am referring to static security. You need to be able to restrict access based on what values instance properties hold. That is how real world systems work. Interceptors - or advices - would be a good way of implementing this.
• Dynamic security: In real world enterprise systems, there is no such thing as this role will access these functionalities. Users want to define new roles and new security mappings without having to call the developers and redeploying the application. It is a fact and it is reasonable, but not supported by the current spec. It should be.
• Paging facilities: If your application server does a good job when it comes to its CMP engine implementation, then probably the only JDBC code you have to write for your application is in order to provide paging facilities. If that's so, why don't we have paging facilities as part of the spec? Why aren't they supported? A solution would be to have finders that return Lists. Then, you would be able to take a slice of it and your container would know you are going to use only this little piece. So, it could load a page, instead of the whole Collection.
• Threading facilities: If know something about the EJB 2.1 draft spec, you may argue that we already have these as Timers. Really? Don't think so. Take a look at the latest proposed final draft for the JCA new spec. That's support for multithreading! We should have some kind of thread pool provided by the container or a Work-like interface. Linda didn't quite like this suggestion, though. What do you think?
• Meaningful names for commit options: Do you know what commit option A means? Those who have some experience with EJB unfortunately do. Why couldn't it be named container-exclusive-database-access or something like it? According to Linda, the commit options were supposed to be just an example, but nearly every application server uses the terms commit option A, B or C as if the difference between them was so clear as between Entity Beans and Session Beans.

The others made some very relevant comments about basic table mapping support and other issues, but all the above were suggested by me. So, if EJB 3.0 happens to have these things, blame me! :-) But that's not the main point in this entry; the point is: make your suggestions and make them now! Take a look at the URL above and send an email to the expert group with your own suggestions. You can still shape EJB's future if you do it now.

Comments

• Some discussion is taking place...
  Well, I was surprised when I noticed TheServerSide has included this entry in its news: http://www.theserverside.com/home/thread.jsp?thread_id=20777&article_count=6

  I am even more surprised someone is making comments about it apart from me :-) . If you can post your comments, whether you agree or not, feel free to do it. I really appreciate them.

  Posted by: mister__m on August 06, 2003 at 09:14 PM

• Threading for J2EE
  why not provide a threading mechanism based on JSR-166 (threading utilities) Executors framework?
  the spec can mandate a specific Executor policy thus reducing the risk of concurrency related problems.

  Posted by: gkatz on August 07, 2003 at 03:36 AM

• CMP Entities are useless in big Transactions
  Another point to mention: CMP Entities are still unusable for large transactions like imports or "Batchjobs". Any Entity which is part of a Transaction can't be passivated. So if you make eg. a Billingjob running through thousands of Orders and create 100K of Enititys ( Orderlines, Accountinformation etc) all of them have to stay in memory - and believe me, 4 GB are reached quickly and NOBODY wants to see a JVM swapping :-).

  This is a major drawback since you have to fall back to traditional SQL/JDBC instead of using your businesslogic in your Beans (Session and Entity).

  And it would be easy to fix; you could also passivate newly created Entities as there state can be reloaded from Database even if not yet commited. I dunno why this is so :-(

  Posted by: tveith on August 12, 2003 at 07:44 AM

• cmp bmp and ql are the problem

  From a developer of mainly relative large distributed systems, the facilities that ejb brings are realy a must, with the cheap prices of gigabit ethernet and cluster tecnologies improvements, rmi/iiop and the extra overload caused container service is almost no existent, but not all ejb are great, the dark side are cmp,bmp wich takes lots of time to implement correctly,make coding their ql a real pain,the learning curve of entity beans is 20% of the total j2ee learning curve, plus horrible performance makes them the dark side of the beans ^_^ , a change in entity beans is a most! the adoption of an hibernate like solution is needed.

  If i could improve a bean, i would replace entity beans for hibernate or jdo straight.
  
  pos - sorry for my bad english =P

  Posted by: andresm on June 16, 2004 at 10:29 AM

This work is licensed under a Creative Commons License.