EJB 3.X ...the Consultants Killer
I got some requests to summarize my appreciation for EJBs. I wrote already some posts, so I will keep it briefly;
- There are no dependencies to external frameworks, libraries etc. Your project consists only of your sourcecode and few annotations needed for compilation.
- Because of 1. your code is independent of the infrastructure.
- Because of 1. there are no conflicts with already existing frameworks on the server
- EJB 3 is not a product, but a spec. There are several implementations from SpringSource, WebLogic (Oracle), WebSphere (IBM), Glassfish (Sun), Geronimo (Apache) and probably others.
- There is no XML required. Actually with EJB 3 XML descriptors become at least suspicious :-).
- Monitoring comes out of the box.
- The dependency on the framework is almost zero - in worst case you can just delete the @Stateless, @Local annotations and use something else.
- The integration with JPA is superb.
- Multithreading issues just do not exist.
- The synergy between Convention Over Configuration and Dependency Injection rocks!
- EJBs 3.0 are annotated POJOs, they can be easily unit-tested.
- ...and most important: developers, who used EJB 3 in projects already, really liked it.
I actually didn't had any problems with EJB 3, except some bugs in some commercial application servers which should be fixed already.
So if you are a consultant, you should put some additional stuff to your EJB 3 project to make it more complicated and you more valuable to your customer :-).
I'm a consultant, but with EJB 3 my "taskforces" became really short. 2 days for bootstraping, creating the infrastructure and built even a small prototype, are absolutely enough.
I will discuss some item next week at the JUG HH - so see you next week in beautiful Hamburg.
Another point is if you are a commercial customer of a Java EE 5 application server such as GlassFish and are having difficulties with EJB then your vendor can help you. If you are using Spring then they can't help and you have to look elsewhere. I've been having difficulties with Spring/JPA RI/JTA in GlassFish lately. The Spring forums have helped a bit (RTFM, use the sample apps, etc) but still JTA doesn't work. I had to spend over a week to get even this far with it. I never had to worry about piecing together the right bits of XML from around the Internet (no complete examples) and load time weavers to get an EJB to work. EJB just works out of the box with complete integration with the entire Java EE stack. EJB today is what Spring was trying to be at it's inception -- easy and light weight.
Posted by Ryan de Laplante on September 11, 2008 at 04:53 PM CEST #
I can't agree with "Actually with EJB 3 XML descriptors become at least suspicious" as it lets our POJOs be real POJOs without *any* dependencies on external libs. You will have to provide annotation classes during compilation which is enough to say it's a dependency. Without the EJB3 annotations the POJOs are "framework-clean". It's also easy to introduce EJB3 features with XML-based configuration to projects that are reluctant to leveraging EJB3 without changing the code bits in any way. With XML-based configuration you can add/remove interceptors very easily too. It's worth to point out as it's just as easy as editing an XML file - no compilation as if it was necessary when the code changes were involved.
Posted by Jacek Laskowski on September 12, 2008 at 12:29 AM CEST #
Yes. EBJ 3.0 is a huge improvement!!
However, the requirement for local interfaces still is a negative point on EJB 3.0
Hopefully they will go away soon.
Posted by Anders on September 12, 2008 at 01:05 PM CEST #
you are actually right - I was unprecise.
Please consider my previous posts:
1. (regarding size): http://www.adam-bien.com/roller/abien/entry/how_big_is_the_entire
(summary: you will need some kb for compilation)
2. (regarding xml vs. annotations):http://www.adam-bien.com/roller/abien/entry/ejb3_annotations_vs_xml_and
(summary: it depends what you are intending to do)
thanks for your comment,
Posted by Adam Bien on September 12, 2008 at 08:11 PM CEST #
if you don't like @Local interfaces, you can go without them. I tested GF prelude b23 - it already is able to deploy @Statless beans without @Local interfaces. I will blog about that - so stay tuned!,
Posted by Adam Bien on September 12, 2008 at 08:30 PM CEST #