Advantages of EJB 3/JPA over spring/hibernate

[Dilshan Edirisuriya]

Still lots of advance software engineers prefer spring/hibernate approach over ejb because ejb is said to be heavy weight. Introducing JPA they have introduced a new approach for data access but i feel because of jndi and stuff ejb 3 is still heavy weight (Comparing to spring/hibernate approach).
What are the advantages and diadvantages using ejb 3 with jpa over spring/hibernate? Also is there any additional overhead when invoking jndi for local ejbs comparing to spring/hibernate approach? Ranchers post your opinions.
[ December 20, 2007: Message edited by: Dilshan Edirisuriya ]

[Pradeep bhatt]

The biggest plus point of EJB3 is that, it is a standard. For local EJB, you don't have to do an JNDI lookup, you can use dependency injection(DI). I dont see overheard here.

[Dilshan Edirisuriya]

Yes I agreee with you Prad. Any ideas?

[Pradeep bhatt]

regarding?

[Dilshan Edirisuriya]

Regarding that jndi thing. But I still think that spring/hibernate approach is far more better than EJB/JPA. Any different ideas?

[Pradeep bhatt]

Originally posted by Dilshan Edirisuriya:
Regarding that jndi thing. But I still think that spring/hibernate approach is far more better than EJB/JPA. Any different ideas?

How is it better ? JPA uses annotations which is nothing but DI. New version of Spring has annotations but I havent worked with it.

[Dilshan Edirisuriya]

Yes also we can configure our web application with spring using annotations.
Check this link
http://sannotations.sourceforge.net/

And talking about spring annotation i also have not used that. But i feel it is really interesting to consider according to this topic.

http://www.theserverside.com/news/thread.tss?thread_id=42791

[Pradeep bhatt]

Originally posted by Dilshan Edirisuriya:
Yes also we can configure our web application with spring using annotations.
Check this link
http://sannotations.sourceforge.net/

And talking about spring annotation i also have not used that. But i feel it is really interesting to consider according to this topic.

http://www.theserverside.com/news/thread.tss?thread_id=42791

Those are not from Spring guys.It is an independent project. Spring 2.5 comes with annotations from Spring guys themselves.
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config
You haven't answered my question though ?

[Dilshan Edirisuriya]

Yes according to the link you gave me, I feel that it is very much simillar to the annotations used in EJB. But EJB is pretty much richer than this when considering about annotations, isnt it?

Then what about ejb scheduling machanism? Have you worked with that? According to Mastering Enterprise Java Beans book it is not flexible and declaration of time intervals in the DD is not supported.

Also it states that "we cannot create timers that expire on given days of the week but not on other days". So still it is developing. It is true that we can use timer services such as Quartz but I really feels that EJB lacks required important functionality with the timers.


[ January 02, 2008: Message edited by: Dilshan Edirisuriya ]

[Z Sugiarto]

warning: all this is just personal opinion, I have not conducted a technical analysis so whatever I say here is based on my 'gut feeling'

In my opinion,

EJB3 over spring because it is a standard, and because it enforce modularity (to certain degree). It's possible to write an EJB once and have it reused by multiple system, regardless of the architecture of the system.

performance wise, there's no question about the use of remote interface having considerable overhead.

but local interface, I think the difference is quite trivial if you compare it with spring-hiber approach. This little difference for the gain in features and standard is a tradeoff I am willing to make.

On the whole JPA-hibernate issue. Personally I go for JPA for the container anaged transaction. I'd say, 85% of what you can do with Hibernate can be done through JPA (with hibernate as the vendor, of course), the other 15% belongs to the hibernate-specific feature. But I have yet to find a situation that requires hibernate-specific feature.

So in other words, JPA is slightly less powerful than hibernate, but in return we have portability and ease of use (trans mgmt, standard, etc). Again it is a trade-off that I am willing to make.

Also, you need to think about other constraint that usually exist as well. Such as the expertise of the team that develops it, client preferences, etc. No matter how good EJB is, there's no point to take the plunge is the team is leaning more towards spring-hibernate and the time constraint is very tight.

[Dilshan Edirisuriya]

Thank you Zenikko for your opinion.

Yes it is true every technology has its own advantages and disadvantages. No doubt about that. Actually when dealing with applications we have to consider about several factors. The main things we have to consider about those is security, performance, flexibility, fault tolerance etc. Thats what customers expects from us. So we have to choose the most suitable technology by considering about the above aspects. That technology may be the widely used one or it may be the standard but still it can have drawbacks of using.

Yes we cannot compare a technology with another one. But we can get to know about those facts by considering experts ideas. Thats why I have posted this thread. Actually I would love to use EJB along with the new invention of JPA. But I would like to know why those senior developers prefer Spring/hibernate approach over EJB/JPA. Is that because of their previous bad memories with EJB 2 or is that because of the advantages you can gain from spring/hibernate.

Still I did not get a reasonable answer for my question. I would like to hear your answers.

Thank you.

[ January 07, 2008: Message edited by: Dilshan Edirisuriya ]

[Mahesh Vandi Chalil]

I dont think there is anything like "Senior Programmers" still using Spring/Hibernate Vs EJB 3.0. Five fingers are different and depending on choice and interest people use different technologies to meet their needs.

Yes, EJB 1.x and 2.x were heavy and most of the developers/architects moved towards Hibernate and Spring. Many people still continued to use EJB because of "some disadvantages they felt with Hibernate on Query generation and tuning aspects". Some people stayed away from Spring due to Opensource constraints, locking to a vendor, XML file maintenances etc to list some of them. But i am not debating on the strength of these frameworks as our current projects are still using Hibernate/Spring along with Session Beans but not entity beans. But all our future projects will be definitely looking forward to use EJB 3.0 as nothing can replace Standards and we want to fully utilize the money our company spent on infrastructure already in place. IBM Websphere Container Managed transaction is always our preference and we will prefer to use EJB 3.0 along with Session beans to utilize that benefit at its best. But will continue to use Spring for the DI features and service wiring wherever appropriate.

Again, it is all choice and understanding each and everyone has on different frameworks.. so respect that and move on ;-)

[ May 27, 2008: Message edited by: Mahesh Vandi Chalil ]
[ May 27, 2008: Message edited by: Mahesh Vandi Chalil ]

[Aurelio Calegari]

Hello,

I'm using EJB3 and the systems I have architected so far present good performance, scalability and extensibility along with other non-functional desirable qualities.

The thing about EJB is that, as stated before, it's a specification and no matter what's your Java EE infrastructure is (JBoss, WebSphere, OC4J, etc). All of them must comply with that specification. Every single developer who wants formal education on Java EE will learn how to use EJB. Every single person who want a certication on Java EE will have to learn EJB. So, by choosing EJB you're always choosing a long term technology that we know will be out there for years and there will be always qualified people to work on that system.

Even those ones who want to get certified in EJB3 must learn how to interoperate them with previous EJB versions. So, it makes EJB choice even safier. EJB3 brings all advantages the EJB model enforces plus guarantee it won't be forgotten.

The server guys (server providers) who build WebSphere, JBoss and so on spend a great deal of time, effort, and money on the EJB container. They try to make the best EJB container for us: LET'S USE IT! The thing is who you architect your solution. For huge systems you might want to sperate presentation from biz phisically, and then you go for remote interfaces. It'll bring some delay and overhead, but in the big picture, your system will scale even more and will be ready to serve thousands of users.

That's all my personal opinion. I have nothing against Spring or hibernate. But the closer we stay the specification, the safier it'll be for finding qualified people in the future to maintain that system. What's more, the system will also address functional and systemic qualities. All depends on how it's build.

Thanks!

[Dilshan Edirisuriya]

Originally posted by Aurelio Calegari:
Hello,

I'm using EJB3 and the systems I have architected so far present good performance, scalability and extensibility along with other non-functional desirable qualities.

This sounds interesting. I would like to hear how you achieve "performance" using EJB 3 (Over hibernate). Is there any considerable amount of performance difference?

Thank you

[Pradeep bhatt]

What I don't like about standards is that they evolve very slowly , particularly from EJB 2.X to EJB 3.0. While standards are important ease of development and maintenance comes before it and Spring/Hibernate have raced ahead of JEE standards. Let us not forget that JPA was inspired by Hibernate. Hibernate is now JPA compliant.

[Aurelio Calegari]

Hi,

Take a look at this article http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

It's a bit old (2005) but still a thing for non-standard enthusiasts to think about. The performance depends on how you architect and develop your systems. Of course that small systems do not require a standard deployable and distributalbe component for services such as EJB. That's true EJB brings overheads over spring, but it's designed for huge load and scalable systems. It makes your application natively service oriented. Other applications built with Java tech can easily reuse those deployed components. Other applications written in other platforms can also access EJB exposed as WS.

Regards

Aurelio

[liqiang yang]

I strongly agree with Aurelio's points.

[Asha Latha]

Hi

Could anyone please clear my doubt. i am newbie to Spring and EJB 3.0.

I read somewhere about Spring as "The Spring Framework is criticized by some as not being standards compliant".

What does "non-standard open source framework" means?? what are disadvantages of it ??

I know it means not following Specifications. could anyone elaborate on this??

Thanks in advance
Asha

[Mahesh G P]

Hi

EJB is standard, means rules are developed before the jar and specifications are available for discussion before the code. With EJB, you won't be locked to any particular vendor / platform.

Asha Latha wrote:Hi

Could anyone please clear my doubt. i am newbie to Spring and EJB 3.0.

I read somewhere about Spring as "The Spring Framework is criticized by some as not being standards compliant".

What does "non-standard open source framework" means?? what are disadvantages of it ??

I know it means not following Specifications. could anyone elaborate on this??

Thanks in advance
Asha

[Aalok Singh]

+10000000000000000000000000 for EJB/JPA


Regards,

Aalok

[Johan Smeaton]

EJB is standard, means rules are developed before the jar and specifications are available for discussion before the code. With EJB, you won't be locked to any particular vendor / platform.

And in what way does Spring lock you into a particular vendor / platform?

[Michael Enudi]

Building EJBs means a developer's code must end up in an application server or EJB container. Coding spring means you can use an application server, a web container like tomcat or public static void main(String.. arg). This is another big advantage.

We must also remember that use of application servers come with a great deal of reward. Clustering & High availability are a part of them. Web containers like tomcats are breaching the gap though but if we agree that an AS like Glassfish was built on top of tomcat, we must also agree that they are features in the AS that are not given in the tomcat platform.

I code a great deal using EJBs but some small project just require nothing less than a small investment. In that scenario, getting an application server is not a way to go. Spring gets the win in that scenario.

Also note, doing multithreading on spring is a lot better and easier than working threads in EJB. Infact, the EJB specification forbids us from creating and playing around with developer-maintain threads. So, you know where you should go.

I don't have a problem with hibernate but the truth is that JPA has all we need. JPA is an architecture so if one wants a better of both worlds, use the hibernate implementation into JPA and apply hibernate extension in your codes. But remember other ORM frameworks have their own extension and extension are not portable. Infact, I still feel I shouldn't use hibernate.

I love both ways of doing things and I am sharpening my spring skills because, I can find a place for them in the enterprise. The choice for any given project will always rest on the nature of the project.

[Piotr Nowicki]

Beside mixed feelings about digging a zombie-topic one thing interested me:

Michael Enudi wrote:Also note, doing multithreading on spring is a lot better and easier than working threads in EJB. Infact, the EJB specification forbids us from creating and playing around with developer-maintain threads. So, you know where you should go.

Could you elaborate on this one? Why do you think that spawning and managing new threads by developer is a good thing?

Cheers!

[Michael Enudi]

Pedro Kowalski wrote:

Could you elaborate on this one? Why do you think that spawning and managing new threads by developer is a good thing?

Cheers!

Spawning threads to handle request ordinarily is not a good thing and as such is strongly advised against. But some parallel-like processing could be required which will entail developer doing something like

take an large dataset as input
create two separate process to process the input using two different algorithm to process in parallel
one algorithm waits for the other to finish
save the result of both processes in a database
the results of both processes serve as an input to a third process

In this case we wouldn't be saying managing thread is a bad thing and though I haven't seen a reference of such, I will consider it bad to do it in an EJB.

[Piotr Nowicki]

Doesn't the asynchronous calls and CDI's observer allows you to achieve the given scenario?

Cheers!

[Michael Enudi]

Pedro Kowalski wrote:Doesn't the asynchronous calls and CDI's observer allows you to achieve the given scenario?

Cheers!

Asynchronous EJB?? I haven't used them yet.. I have written codes in EJB 2.1 to 3 for production environment and really longed for that Asynchronous way of invoking EJBs. I have had to resort to MDB even for the smallest of asynchronous task. Its cool to know it was included in the latest version but I haven't begun employing them.
The same applies to CDI.

I would give it to you since that these features were added in the latest EJB release but I haven't gone 3.1


Regards.

[Piotr Nowicki]

Yeah, the EJB 3.1 and CDI really give some boost to Java EE environment, not mentioning that it solves few awkward problems i.e. the asynchronous invocation via JMS as you mentioned.

To sum up - my point was that because you're heavily discouraged (or even forbidden) to spawn and manage threads in Java EE it doesn't mean that you cannot do some heavy multithreaded processing.

Cheers!

[Michael Enudi]

Pedro Kowalski wrote:
To sum up - my point was that because you're heavily discouraged (or even forbidden) to spawn and manage threads in Java EE it doesn't mean that you cannot do some heavy multithreaded processing.
Cheers!

From what I have noticed, you could spawn your own thread but it will not be managed by the container. It will act as though it was just running on the JVM outside the container. A simple example is write a few TimerTask that does almost nothing and start it up with a Timer. Once the Timer schedule gets triggered, try stopping your Glassfish AS domain with

asadmin> stop-domain domain1

My observation is that the AS doesn't get the Timer to stop.

My workaround years ago, was to do all my scheduled work from a separate application (used spring with the quartz scheduler) to call the EJB methods. But once again, with the flexible scheduling feature in 3.1, that may not be necessary.

[Piotr Nowicki]

Michael Enudi wrote:From what I have noticed, you could spawn your own thread but it will not be managed by the container. It will act as though it was just running on the JVM outside the container. A simple example is write a few TimerTask that does almost nothing and start it up with a Timer. Once the Timer schedule gets triggered, try stopping your Glassfish AS domain with

Yeah, it's one of those things when one says 'hey, you really don't want to do it... REALLY man, put this chainsaw down!' but they can't really forbid you from doing this.

Cheers!

[Jaroslaw Szczepankiewicz]

I have experience in both Spring and EJB 3.1. I've done Springs before EJB 3.1 came out. When spring came out it was cure to EJB 1.4 - 2.0 pain. And it was great. But I had some troubles with spring that no one could answer, the answers were known only to the authors of spring. Some said that choosing spring is gaining vendor independency, in my opinion this is not true. Spring IS vendor of the product not the vendor of the STANDARD. I would choose spring if i know that project is short lived and the team is experienced in spring or I could not choose EJB Web profile (or full profile) because of some hosting platform restriction. In other cases I would choose EJB web profile or full profile. Some said that there is no batch processing / thead pools possible in EJB, that not true. You have two choices: using servlet container part and use thead pooling / workers etc., event if the servlet is not outputting anything to the client, then you can use low level thead management (same as with JSE) or you can use MDB (Queues) with selectors or not. MDB can be processed in parallel in elegant way. In case of perfomance, in my opinion there is no more powerfull technology than Stateles Session Beans with Singletons. AS can use pools of beans to achieve incredible perfomance, so the spring vs ejb perfomance comes from some ancient age and can not be compared to the modern 3.1 version of ejb. In fact EJB 3.1 was the answer to the Spring but with industry standard and competence. My answer: If you know Spring and the project is short lived use spring (or take a look on EJB 3.1 Web profile), if you have long lived project there is no better way than EJB / MDB / CDI etc. You have then predictable behaviour which will be stable and with maintenance for at least next 10 - 15 years from middleware vendors.

[Bhavesh Dak]

IMO,

Spring and EJB 3.0 are not alternative to each other. We can fine tune our application by taking advantage of both the technologies.

For e.g; Server components can be written in EJB 3.0 and other tiers can be developed elegantly using Spring framework.

It is completely depend on the architectural need of the particular application and based on that analysis only we can make decision.

Should not be biased on any of these technologies.

[Ravi Vakka]

Nice discussion topic first of all.
I feel both the technologies have its own advantages and finally it depends on the nature of the project (Simple or Complex application), size of the project (Small size or large sized project) and how much customer is willing to spend on the infrastructure.