SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
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?
Spring Boot in Action - Spring made easy!
Spring in Action - Build powerful applications!
Build Talking Apps for Alexa - Add voice to your applications!
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).
SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Not a no-no, but perhaps "not needed as much".Originally posted by Chengwei Lee:
Does this means that even session beans are a no-no in Spring?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Not a no-no, but perhaps "not needed as much".
SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
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
Exactly right.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?
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.
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?
Spring Boot in Action - Spring made easy!
Spring in Action - Build powerful applications!
Build Talking Apps for Alexa - Add voice to your applications!
Originally posted by Chengwei Lee:
So would I still have the container managed transaction made availale from Spring's AOP framework?
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.
Originally posted by Chengwei Lee:
Hmm, doesn't this means that I've have to handle rollbacks & when to persist myself?
Originally posted by Chengwei Lee:
Does this means that even session beans are a no-no in Spring?
Spring Boot in Action - Spring made easy!
Spring in Action - Build powerful applications!
Build Talking Apps for Alexa - Add voice to your applications!
SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |