• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Spring + Hibernate - EJB = ?

 
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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".
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Craig Walls
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
reply
    Bookmark Topic Watch Topic
  • New Topic