This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes Spring + Hibernate - EJB = ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Spring + Hibernate - EJB = ?" Watch "Spring + Hibernate - EJB = ?" New topic
Author

Spring + Hibernate - EJB = ?

Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Hi guys,

So far I've got this concept that in Spring, as far as possible, refrain from using the heavy weight Entity JavaBeans.

If this is the case, won't we be missing out on a lot of goods from the application server? We would have to handle transaction, concurrency, security & persistence on our own, won't we?

Please correct me if I'm mistaken.

Thanks!


SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Originally posted by Chengwei Lee:
If this is the case, won't we be missing out on a lot of goods from the application server? We would have to handle transaction, concurrency, security & persistence on our own, won't we?


Not really. Spring has support for declarative transactions based on its own AOP framework that is similar to, but even more powerful than, the declarative transaction support offered in EJB.

Security isn't directly addressed in Spring, but is addressed in a sister project called Acegi. Acegi takes advantage of servlet filters to provide web-layer security and Spring AOP to provide method level security.

Persistence isn't directly addressed in Spring, either. But that's a good thing because it lets you pick the transaction mechanism appropriate for your needs. If you like straight JDBC, then Spring has a really nice abstraction layer for you that simplifies JDBC (even gives meaningful error messages that your database doesn't provide). Or you can choose from Hibernate, JDO, or iBatis for persistence. And (if I recall correctly) support for Cayenne and Hibernate 3 is in the works.

And the really nice thing about all of the above is that it can be done with a simple JavaBean (not the enterprise kind).


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Not really. Spring has support for declarative transactions based on its own AOP framework that is similar to, but even more powerful than, the declarative transaction support offered in EJB.


So would I still have the container managed transaction made availale from Spring's AOP framework?

Security isn't directly addressed in Spring, but is addressed in a sister project called Acegi. Acegi takes advantage of servlet filters to provide web-layer security and Spring AOP to provide method level security.


Considering that I could get transaction, concurrency, security & persistence in 1 EJB container against the fact that I'd need another separate project to provide me with the security in Spring, I see this as a big negative point.

Persistence isn't directly addressed in Spring, either. But that's a good thing because it lets you pick the transaction mechanism appropriate for your needs. If you like straight JDBC, then Spring has a really nice abstraction layer for you that simplifies JDBC (even gives meaningful error messages that your database doesn't provide). Or you can choose from Hibernate, JDO, or iBatis for persistence. And (if I recall correctly) support for Cayenne and Hibernate 3 is in the works.


Hmm, doesn't this means that I've have to handle rollbacks & when to persist myself?

And the really nice thing about all of the above is that it can be done with a simple JavaBean (not the enterprise kind).


Does this means that even session beans are a no-no in Spring?
[ March 10, 2005: Message edited by: Chengwei Lee ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Chengwei Lee:
Does this means that even session beans are a no-no in Spring?
Not a no-no, but perhaps "not needed as much".


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Not a no-no, but perhaps "not needed as much".


Does this means that if I don't use any of the EJBs, my Spring application won't need an application server at all? Meaning to say I can run it on any web container?

And yet with the Spring AOP & its sister project, I should be able to get the equivalent of an EJB container?
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
I can't really say it any better tahn what's in Spring's online reference document.


7.6. Do you need an application server for transaction
management?
Spring's transaction management capabilities--and especially its declarative transaction
management--significantly changes traditional thinking as to when a J2EE application requires an application
server.
In particular, you don't need an application server just to have declarative transactions via EJB. In fact, even if
you have an application server with powerful JTA capabilities, you may well decide that Spring declarative
transactions offer more power and a much more productive programming model than EJB CMT.
You need an application server's JTA capability only if you need to enlist multiple transactional resources.
Many applications don't face this requirement. For example, many high-end applications use a single, highly
scalable, database such as Oracle 9i RAC.
Of course you may need other application server capabilities such as JMS and JCA. However, if you need only
JTA, you could also consider an open source JTA add-on such as JOTM. (Spring integrates with JOTM out of
the box.) However, as of early 2004, high-end application servers provide more robust support for XA
transactions.
The most important point is that with Spring you can choose when to scale your application up to a full-blown
application server. Gone are the days when the only alternative to using EJB CMT or JTA was to write coding
using local transactions such as those on JDBC connections, and face a hefty rework if you ever needed that
code to run within global, container-managed transactions. With Spring only configuration needs to change:
your code doesn't.


kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Chengwei Lee:
Does this means that if I don't use any of the EJBs, my Spring application won't need an application server at all? Meaning to say I can run it on any web container?
Exactly right.

We've finally load-tested our ported application (from session and entity EJBs in WebLogic 7 to Spring + Hibernate in Tomcat 5) on the same hardware as our production machines and it's running circles around its predecessor. And we still haven't added caching data between transactions, meaning we're hitting the database for every transaction.

Oh, and we'll be saving $500,000 a year in fees to BEA.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by David Harkness:
Exactly right.

We've finally load-tested our ported application (from session and entity EJBs in WebLogic 7 to Spring + Hibernate in Tomcat 5) on the same hardware as our production machines and it's running circles around its predecessor. And we still haven't added caching data between transactions, meaning we're hitting the database for every transaction.

Oh, and we'll be saving $500,000 a year in fees to BEA.


That's really awesome David! Good job. So do you get a cut of that savings?


GenRocket - Experts at Building Test Data
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Originally posted by Chengwei Lee:
Does this means that if I don't use any of the EJBs, my Spring application won't need an application server at all? Meaning to say I can run it on any web container?


Adding to what others have already said on this subject...Yes, you can run it in any web container. But taking it further, if you application isn't a web application, you won't need a container at all! That's right...you can write a rich client (e.g., Swing/AWT/SWT/CLI) application with JavaBeans that are transactional without even starting Tomcat, JBoss, WebSphere, WebLogic, or any other application server.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Originally posted by Chengwei Lee:
So would I still have the container managed transaction made availale from Spring's AOP framework?


Spring has several transaction manager implementations, each one suitable for different things. For example, if you are using Hibernate as your persistence mechanism, there's a HibernateTransactionManager. If you're using straight JDBC (via Spring's abstraction) you have DataSourceTransactionManager. JDO has JdoTransactionManager. And there's support for JTA via JtaTransactionManager (along with some container-specific stuff for WebLogic and WebSphere). It all depends on your needs.

Originally posted by Chengwei Lee:
Considering that I could get transaction, concurrency, security & persistence in 1 EJB container against the fact that I'd need another separate project to provide me with the security in Spring, I see this as a big negative point.


We're talking about adding 1 more JAR file to your app to get Acegi security. The configuration of Acegi still happens through Spring. I don't see that as a big negative point.

Originally posted by Chengwei Lee:
Hmm, doesn't this means that I've have to handle rollbacks & when to persist myself?


No, see my comment above regarding the array of transaction managers that come with Spring.

Originally posted by Chengwei Lee:
Does this means that even session beans are a no-no in Spring?


They're not a no-no, but you'd really need to look at your application and ask whether a session bean is necessary...or if a Spring-managed JavaBean is sufficient. More often than not, a JavaBean will be fine. But when you do need EJBs, Spring can help out with that, too. On the EJB-side, Spring has a way to develop your EJBs so that they can access Spring-managed beans (the idea being that your session bean is a skinny access point to Spring-managed service JavaBeans). On the client-side, Spring simplifies the retrieval of an EJB such that it looks like any other bean--you can even wire it into your other beans without those other beans even being aware that they're dealing with an EJB.
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Thank you guys for clarifying so much of my doubts. Its been very helpful & enlightening.

If I'm very certain that my application had to work under a distributed environment, would I still be able to use Spring to effectively replace EJB?
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Yes.
In that case you use Spring's JTATransactionManager instead of one of the others like HibernateTransactionManager. You still need a JTA implementation though so you will probably want to run in a full app server but you don't need to use SessionBeans unless you want to use RMI-IIOP remoting too. The other case where EJB is useful is for JMS messaging. MDB's are the best implemented and really most successful type of EJB. Spring currently has good JMS support for publishing messages but it does not yet have support for MDP's (Message Driven POJO) though this too is expected in the version 1.2 timeframe which is just around the corner. 1.2 should also allow transactional integration with other types of systems through its own JCA support. Spring also provides support classes that make working with EJB easier should you need to do so.

The promise of EJB was to enable component oriented development. This was not realized due to the heavyweight requirements of the EJB container and the antipatterns that have sprung up to be able to effectively work around these problems. Spring and other lightweight containers and pluggable services will change this and could possibly allow a real software component market to flourish. Whether this will actually happen however is dependent on a lot of other factors.

With all the knocks on EJB, it still has however definitely been an important evolutionary step forward in our knowledge of how to implement complex scalable systems. I think its most important legacy will be the introduction of AOP to the development of these kinds of systems. Spring's support for a conservative evolutionary approach to the use of AOP and the use of the out-of-the-box aspects it provides like transaction management is a good and relatively safe way to get started with AOP.
[ March 13, 2005: Message edited by: Ken Krebs ]
 
GeeCON Prague 2014
 
subject: Spring + Hibernate - EJB = ?