The death of the heavyweight business object?

[Sathish Nagappan]

Ranchers,
I would like to know your opinions on this topic. The EJB specification was not very well appreciated by most developers around the world who have been really working on it for some time now. If you have ever seen some of the interviews of famous EE programmers like Rod Johnson (Architect of Spring), he literally hates the EJB specification.

This was primarily due to many reasons including:

1. Failure to map the domain model to the bean, since the bean already extended some other framework specific class, i.e. Entity or Session bean.
2. People are more comfortable with using POJOs as their business objects since they were lightweight, simple to read, easy to program.
3. These days POJOs offer all the services that an EJB container would offer, remote invocations (web services), transactions (JTA), threading (Axis creates a new thread every time a client invokes a web-service), concurrency, persistency (Hibernate).
4. Sun assumes that it makes all the correct choices for developers, and does not allow the developers to tweak the deployment configuration, for example why do I need pooling on my Stateless beans if I am just reading from a static variable in the bean class and nothing else? :-(.

Of course the JPA addition to the EJB 3 spec was a definite way forward in replacing those aging 2.1 Entity Beans, but:

Why do you think that Sun would continue to support new features in Session Beans in EJB3? I understand that Sun need not remove support of 2.1 Session Beans, since that would break apps around the world. But why spend development time on new features in EJB3's Session beans when session Beans offer no advantage over POJOs, arent Session Beans more heavy weight (performance-wise) when compared to POJOs?

I would like your thoughts on this? I have been looking around the web, but Sun or anyone, does not seem to have a straight forward answer to that question?

Thank you in advance for your replies. Looking forward to your thoughts.

[ August 06, 2008: Message edited by: Ashwanth Fernando ]
[ August 06, 2008: Message edited by: Ashwanth Fernando ]

[Jeanne Boyarsky]

Originally posted by Ashwanth Fernando:
Why do you think that Sun would continue to support new features in Session Beans in EJB3? I understand that Sun need not remove support of 2.1 Session Beans, since that would break apps around the world. But why spend development time on new features in EJB3's Session beans when session Beans offer no advantage over POJOs, arent Session Beans more heavy weight (performance-wise) when compared to POJOs?

I would like your thoughts on this?

What new features are you referring to in EJB 3 session beans? To me, it looks like the same or similar features are being supported as all along - transactions/security/scalability/etc.

I disagree with the premise that session beans offer no advantage over POJOs. The container is providing services for the POJO. (And EJB 3 session beans are POJOs.) Yes, these services could be provided by something else like Spring, but that takes configuration too.

Session beans aren't as heavyweight as they used to be. They are still heavier than POJOs. They also do more.

It all comes down to your requirements. If you require the services that EJB provides, it is a great fit. If not, it is overkill. This has been true all along. What has changed is that EJB 3 became easier for people who were going to use EJB anyway.

[Sathish Nagappan]

Originally posted by Jeanne Boyarsky:

Session beans aren't as heavyweight as they used to be. They are still heavier than POJOs. They also do more.

What more do the session beans do when compared to POJOs? Starting from Transactions, concurrency, pooling, dependency injection, security, all of these are available on the POJOs too with a container like Spring,
minus the component/remote interface and implementation object, home interface and implementation object (EJB3 containers still create a component object for each bean) and minus JNDI lookups.

Originally posted by Jeanne Boyarsky:

If you require the services that EJB provides, it is a great fit. If not, it is overkill. This has been true all along.

Were EJBs were a great fit all along ? If you look at the EJB spec until 2.1. EJBs had to extend a SessionBean or EntityBean making it impossible to map on the domain model in the design phase directly onto the session or entity beans. (because Java does not support multiple inheritance). :-(. In EJB 3 finally Sun has come out with the ability to insert those EntityBean and SessionBean classes through dependency injection so that the programmer is free to extend a class of his choice. But unfortunately Spring was already out before EJB3 based J2EE containers were available. So my question was, why is Sun re-inventing the wheel again :-(, when there were other aspects of the Java platform that it can address?

Also by the way, we have seen various studies showing that Tomcat is the mainstream enterprise Java platform (web container without EJB), instead of the full blown J2EE containers like Weblogic, Websphere etc. Customers do not like bloated vendor products, they like lightweight, agile frameworks, which I don't think EJB 2.1. was (Gosh, dont even get me started on Entity Beans 2.1 ;-)).

I have built enterprise apps on both Weblogic (with EJB 3) and Tomcat (with Spring) and I repeatedly find Tomcat and Spring is more simpler to configure and more powerful to use than EJB3 and Weblogic (I am not a Spring fanboy btw, there are still some aspects of Spring that I don't favor a lot).

I am not saying Sun is not doing a proper job, but EJB has a exceedingly rare usage (when compared to JSP and Servlets, 80% - 20% probably) for the upcoming and current development projects so I frankly dont think that EJB should enjoy the luxury of being an integral part of the Java EE platform.

Thankfully Sun is coming up with profiles in the Java EE 6 spec, so that if customers dont need EJBs in their app-server, they can download the version without support for EJBs, to make their environment more lightweight and performance oriented.

[Jeanne Boyarsky]

Originally posted by Ashwanth Fernando:
What more do the session beans do when compared to POJOs? Starting from Transactions, concurrency, pooling, dependency injection, security, all of these are available on the POJOs too with a container like Spring,
minus the component/remote interface and implementation object, home interface and implementation object (EJB3 containers still create a component object for each bean) and minus JNDI lookups.

So you are comparing Spring to EJB rather than POJOs to EJB? This is fine, but I don't think it's fair to compare POJOs (without any container) to EJB which are now POJOs with a JEE container. The remote interface is useful if making remote calls. I fail to see the problem with JNDI lookups.

Were EJBs were a great fit all along ? If you look at the EJB spec until 2.1. EJBs had to extend a SessionBean or EntityBean making it impossible to map on the domain model in the design phase directly onto the session or entity beans. .... So my question was, why is Sun re-inventing the wheel again :-(, when there were other aspects of the Java platform that it can address?

I think session beans were a decent fit before. (I didn't comment on entity beans because I have trouble finding something positive to say about them prior to EJB 3.) They are less work in EJB 3 than 2.X which is good, but the concepts haven't changed much. I don't look at it as Sun re-inventing the wheel. I view it as them including ideas from the outside and (hopefully finally) getting it right. And JPA (EJB 3 entity beans) lets you plug in another framework entirely such as Hibernate. It's great that Spring came first. Now Sun can bring those ideas to be built in parts of apps servers rather than requiring the use of Spring. This is a good thing regardless of what came first.

Also by the way, we have seen various studies showing that Tomcat is the mainstream enterprise Java platform (web container without EJB), instead of the full blown J2EE containers like Weblogic, Websphere etc. Customers do not like bloated vendor products, they like lightweight, agile frameworks, which I don't think EJB 2.1. was (Gosh, dont even get me started on Entity Beans 2.1 ;-)).

I have built enterprise apps on both Weblogic (with EJB 3) and Tomcat (with Spring) and I repeatedly find Tomcat and Spring is more simpler to configure and more powerful to use than EJB3 and Weblogic (I am not a Spring fanboy btw, there are still some aspects of Spring that I don't favor a lot).

I am not saying Sun is not doing a proper job, but EJB has a exceedingly rare usage (when compared to JSP and Servlets, 80% - 20% probably) for the upcoming and current development projects so I frankly dont think that EJB should enjoy the luxury of being an integral part of the Java EE platform.

Thankfully Sun is coming up with profiles in the Java EE 6 spec, so that if customers dont need EJBs in their app-server, they can download the version without support for EJBs, to make their environment more lightweight and performance oriented.

Also by the way, we have seen various studies showing that Tomcat is the mainstream enterprise Java platform (web container without EJB), instead of the full blown J2EE containers like Weblogic, Websphere etc. Customers do not like bloated vendor products, they like lightweight, agile frameworks, ...... but EJB has a exceedingly rare usage (when compared to JSP and Servlets, 80% - 20% probably) for the upcoming and current development projects so I frankly dont think that EJB should enjoy the luxury of being an integral part of the Java EE platform.

It makes seense that EJB has lower adoption. Less applications would have complex needs. For those customers, they are less likely to get simplicity under and scenario. Some apps have inherent complexity. if not using EJB, Tomcat is a great server. I use it home and am happy with it. Of course, the app running on my home computer doesn't need security and scalability. That said, it's silly to invite more complexity if your app doesn't need it. There are other parts of the Java EE platform that are used less frequently too such as JMS.

And I agree that profiles are a good thing!

[Sathish Nagappan]

Originally posted by Jeanne Boyarsky:

I fail to see the problem with JNDI lookups.

JNDI lookups are inherently expensive in terms of performance. Whether you are performing the JNDI lookup within the box where the directory is exposed or from outside, it is slightly costly than a method that returns back an object. Requires the use of service locators or application context caching to cache the EJB reference to prevent costly lookup operations.

Dependency injection on the other hand, is not expensive at all, It does not take even a millisec to insert an object into a class from the container. So thats why I was thinking about the performance benefits also while writing the problem with JNDI lookups.