I think you have gotten some things wrong about EJB3. First, EJB3 persistence is pluggable. There is a service provider interface that has to be implemented by the provider. The provider is specified in persistence.xml. This allows the persistence provider to be swapped out at will.
EJB3 is also supported in J2SE, it doesn't tie you to the application server. In fact, I have written an application that is started from a main method of a Java class that uses a Stateless Session bean, and three entity beans. All of the EJB3 capabilities are there, with transactions and persistence. You can even do message driven beans, although I have not had the need for them.
EJB3 also doesn't do away with things like Hibernate. Hibernate is infact, the persistence provider for the JBoss EJB3 persistence implementation.
You also talk about testability, and since EJB3 is not a heavy component model, but simple annotated Java objects, you can use all the normal tools for unit testing. In my case, I have been using Eclipse's standard JUnit integration to do all of my unit testing, and it works very well. There are some tricks to make it all work, but they are not very hard to overcome.
On the topic of binding meta data to implementation classes, I have had some of the same uneasyness that you describe. Is this really a good thing to do? After actually building a couple of applications though, I must say that I have fallen in-love with the annotations, and not having deployment descriptors is great! When you think about it, everyone has been binding their meta data to their implementation classes all along anyway. Since no one really did EJB development without XDoclet, you were putting your meta data into the implementation classes their anyway. The only difference is that you have a pre-processor that generates the deployment descriptor. Big deal! While with this approach you could certainly still change the generated deployment descriptor to change behavior, it would be out of sync with the code. This leads to all sorts of trouble. Besides, you really couldn't get the benefit of being able to change descriptors without careful packaging considerations. For example, you would have to do an exploded deployment, otherwise, you would have to rebuild your application to get a regenerated war, jar, ear, etc. I never found the separation to be very useful in the first place.
Another thing to consider is that with EJB3 all of the patterns that everyone was using can really be tossed out the window. For example, transfer or value objects become a completely unnecessary thing. You just implement Serializable on your entities, and you can use the same POJO through all your application tiers.
I could go on and on, but in summary, EJB3 is finally what we have been looking for all along. It truly makes Java development on the server side easy. Now on to the unification of the web tier. Check out JBoss Seam for that. Talk about another lead forward! |
java.net RSS Feeds
