Posted by mister__m
on August 5, 2003 at 12:17 PM PDT
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!
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
- 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.