Random Thoughts: EJB3 Vs Spring

Following are just my random thoughts. I am not trying to determine which one is better. I think it is pretty much decided that both are going co-exists.

Spring: IoC Container and Framework Library

I think it is good idea to understand Spring in two aspects.

• First it is IoC container. This container is its core concepts. EJB as the SPEC is in direct competition. Question is: Do you want to use Spring IoC container or EJB Container?
• Second aspects of the Spring Framework is all the helper classes which makes the development so easy. Like JdbcTemplate, Hibernate helper classes, etc. EJB does not provide such classes. Those gaps are filled up by the JBoss Seam Framework and the like. You can use EJB Container and still use Spring Framework Libraries.

So along with Spring Vs EJB, it is also Spring vs JBoss Seam and the like.

Spring Not a Spec
Spring, though opensource, is controlled by Interface 21, a commercial company. Interface 21 controls (atleast decides) what needs to be in next phase and hires programmer to do it. Don't get me wrong, I really like Spring. As a developer, it is really nice experience. How simple it makes to develop application and test it. But the fact remains that in the long run, we have to "wish" (or influence) that Interface 21 makes correct choices. Also remember that once we use spring we are using "tool specific classes and libraries" so we cannot decide to change it to different platform overnight.
Even though it uses its own library. It is based on very sound design principle. Design by Interface. Framework actually builds on top of it to provide re-usable code. For example, never worrying about handling connections.

With EJB, if you dont like a vendor you can still move to different vendor. If you dont like EJB at all depending upon your design you can still convert it to different technologies as there is not dependance on specific libraries. (Meaning dependency is there but on little higher level)

EJBs dont provide that kind of framework. It does not provide you reusable classes library. It does not provide helper classes for sending email for different implemenations.

Will Spring remain light?
But with all these introduction in Spring, how light is spring or how light will spring remain. But the answer lies in its core design. Since the core concepts behind it is Design by Interface and Inversion of Control. It allows to selectively use areas which we require. You dont want to use MVC dont incldue that jar. If you only want to use with regards to JDBC operations, only use spring-jdbc.jar. It will stay light as much your requirements demand it to remain light.

EJB: Market Availability
Though it is too early to say how light is JEE. It is just out and there are really few implementations available.

EJB still implements "Remote-ness"
One difference between these two choices still exists, that EJB3 will still do remoting. Spring on the other hand does not do remoting by default. So decision has to be made what kind of architecture is required keeping in mind business application scenario.

Thoughts about RPC
Also one thing to notice here is that RPC eventually will go out of fashion (IMHO). Ultimately, architectures like SOA where core concept is to exchange data rather than invoking behavior remotely. It is more loosely coupled, more reusable, and it also has advantage of platform independance.

Separating JPA out of EJB
One good things EJB Spec3 has done has separated JPA out of EJB Spec.
Again Hibernate will be JPA compliant in coming days. There are already articles floating around how to use Spring with JPA.

What are the other benefits of EJB3?
Container Managed Persistence
If you are using Container Managed Persistence, it manages the state of entities. Meaning it calls update insert methods on its own. It has container managed persistence. Meaning you dont have to call your insert update delete. Container will manage that for you. This is a really good advantage. With Spring Framework, you still need to call specific classes, SimpleJDBCTemplate.update, or session.update if you are using Hibernate. With EJB once configured with CMP, you dont do anything. You save that one method call. Calls will be made for you before and after business methods.

Message Driven Beans
With EJB Container you will have MessageDrivenBeans. i.e. you will have mechanisms to write consumers of Messages. With Spring you have to choose a separate provider for the same. Which gives you more flexibility. Spring delegates that work. Again principle on which spring is based: Do not re-write it if somebody is already doing it in good way. Rather than that just provide the loose interface and bunch of classes with re-usable code.

Clustering
Benefits of clustering and are anyways provided by application server. Even for that matter Tomcat provides clustering now. You can still develop Spring application and deploy it in different clusters in Tomcat. You dont need EJB Container to have component level clustering.

Spring is already a winner it. It has made EJB people change the spec. EJB3 now looks less similar to EJB2 and more similar to Spring. They have almost every aspect which spring got it correct. Aspects are now Interceptors. (Though this was any ways used by EJB container provider in their implementations, no programmatic mechanisms were provided for Bean Developer though)

XML vs Annotations
Transactions
With regards to Transaction declaration as Annotations. I must say, I like XML. No matter how much verbose. It is still good. Rather than my transaction strategy littered over code, i would like to have it one place/area.

Security
Dont let me wander in code to find out what security rules are implemented. Anyways, Spring has also come us with Annotations specific declarations allowing you to do quick and dirty work though.

Do we need IoC Container Spec?
Do we need a spec so other providers can come up with their own implementations of IoC container? Or have we already convoluted J2EE area with so many specifications and implementation?

Preference
Spring will work inside container and outside container. Spring is really great for small application because it is really easy to develop. With Spring 2.0's goal being easier XML Config files and allowing Annotations and its integration with AspectJ. Spring does have capability of using it in bits and pieces, meaning you may just use it in Middel Tier, you choose to use JMS features.

JEE spec will need a container. Also the choice depend upon the business case for which the application is getting developed. If the application is big in terms of scope or it is expected that it live long time while going multiple phase changes then I think it is better to stick with Standard Spec.