I had posted about EJB 3.0 sometime ago, and based on my Java One experience, I thought it was worth revisiting. As I talked to hundreds of people at the JBoss booth, and also went to some of the sessions, I was struck by how little people seemed to know about the new EJB 3.0 specification.
I think that so many people either had poor experiences with the complexities of EJB versions prior to 3.0, or heard that it was complex, that they have tuned out the new specification. Granted EJB 1.0 through 2.1 was not exactly the best example of good engineering. So, there certainly is a stigma that has to be overcome.
When I told people at Java One that they should really look closely at EJB 3.0, and try it out, they became intrigued as to why. Then when I explained that you can write just plain old java objects, their eyes would light up. What? No more heavy component model and deployment descriptors? I can actually unit test this stuff through normal JUnit or TestNG? Really?
When I would be able to get into a deeper conversation about the technology, and we could discuss things like defaults that actually make sense. When you can follow a simple convention, and not have to use an annotation, it gets even simpler. For example, for an entity, you don't have to specify the database table name or the column names if you just name them the same in the database and the class. What could be easier? Now, the reality is that some corporate naming standards will probably get in the way of some of this ease of use, but I would urge any DBA to check that stuff at the door, and let the conventions be the standards. Besides, the cost of the time of the DBA to determine whether something is a table or a view, or a synonym is trivial compared to the cost of many developers time. Allow sane business names to be used for tables and columns, and everyone will be better off in the long run.
The extensibility of EJB 3.0 is also wonderful. The ability to create your own annotations, and extend things with very little code (an AOP lite) is very powerful indeed. This will allow developers to do many things you would use an AOP (Aspect Oriented Programming) framework for, within the confines of EJB, without the complete learning curve of AOP. When you consider there are no standards for AOP frameworks, you will be spending that learning curve on something that is proprietary in nature. That in and of itself, is enough of a deterrent to me.
The final thing that I have really come to like about EJB 3.0, is its embeddable. I have already written two applications that use EJB 3.0 objects from a Java SE environment! No application server required! This is wonderful for small applications and utilities.
I have become a real EJB 3.0 junkie. There is no turning back. Once you have taken that first hit, especially if you have lived through the EJB 1.0 to 2.1 days, you will be hooked. There is no doubt about it. This is the future for enterprise application development!!!
I think that so many people either had poor experiences with the complexities of EJB versions prior to 3.0, or heard that it was complex, that they have tuned out the new specification. Granted EJB 1.0 through 2.1 was not exactly the best example of good engineering. So, there certainly is a stigma that has to be overcome.
When I told people at Java One that they should really look closely at EJB 3.0, and try it out, they became intrigued as to why. Then when I explained that you can write just plain old java objects, their eyes would light up. What? No more heavy component model and deployment descriptors? I can actually unit test this stuff through normal JUnit or TestNG? Really?
When I would be able to get into a deeper conversation about the technology, and we could discuss things like defaults that actually make sense. When you can follow a simple convention, and not have to use an annotation, it gets even simpler. For example, for an entity, you don't have to specify the database table name or the column names if you just name them the same in the database and the class. What could be easier? Now, the reality is that some corporate naming standards will probably get in the way of some of this ease of use, but I would urge any DBA to check that stuff at the door, and let the conventions be the standards. Besides, the cost of the time of the DBA to determine whether something is a table or a view, or a synonym is trivial compared to the cost of many developers time. Allow sane business names to be used for tables and columns, and everyone will be better off in the long run.
The extensibility of EJB 3.0 is also wonderful. The ability to create your own annotations, and extend things with very little code (an AOP lite) is very powerful indeed. This will allow developers to do many things you would use an AOP (Aspect Oriented Programming) framework for, within the confines of EJB, without the complete learning curve of AOP. When you consider there are no standards for AOP frameworks, you will be spending that learning curve on something that is proprietary in nature. That in and of itself, is enough of a deterrent to me.
The final thing that I have really come to like about EJB 3.0, is its embeddable. I have already written two applications that use EJB 3.0 objects from a Java SE environment! No application server required! This is wonderful for small applications and utilities.
I have become a real EJB 3.0 junkie. There is no turning back. Once you have taken that first hit, especially if you have lived through the EJB 1.0 to 2.1 days, you will be hooked. There is no doubt about it. This is the future for enterprise application development!!!
